Error root mount waiting for : usbus1

tony33

tony33

I attached a screen shot of an error I am getting during boot.
The system can start the booting process but it ends with the error:

Code: 
Error root mount waiting for : usbus1

here is a screen shot:
Es5z66h.jpeg

there's more details in the screenshot.

After the error it forces a reboot which this issue keeps happening.

I did a clean install of FreeBSD 13.1 and it was working.
I added ntfs-3g to boot loading config. To boot loaded with the loader.
I then powered off the computer and 3 days later turned it on to get this
issue.

Got any ideas what I can do? Also after this error message it will make you reboot the system.
So, I cannot boot into command terminal normally. What should I try?
 
covacat said:
did you have zil/slog devices or other disk added removed from the boot pool ?
Click to expand...
What do you mean by "zil/slog devices" ? No, the hard drives da0 and da1 are part of the boot pool. The root pool. I made a zfs pool raid of da0 and da1 the da0 is the main drive and the da1 is a mirror. I got them in a raid 1 config with zfs.
 
If USB is unrelated and just delays your boot although not needed for your root filesystem, there's a workaround, put this in /boot/loader.conf:
Code: 
# Don't wait for USB
hw.usb.no_boot_wait=1

BUT: It doesn't look like this is your actual problem, judging from the screenshot. I'd be rather interested in this:
tony33 said:
I added ntfs-3g to boot loading config. To boot loaded with the loader.
Click to expand...
What exactly did you do here?

BTW, you should be able to boot the machine from installation media to access and correct your files.
 
zirias@ said:
If USB is unrelated and just delays your boot although not needed for your root filesystem, there's a workaround, put this in /boot/loader.conf:
Code: 
# Don't wait for USB
hw.usb.no_boot_wait=1

BUT: It doesn't look like this is your actual problem, judging from the screenshot. I'd be rather interested in this:

What exactly did you do here?

BTW, you should be able to boot the machine from installation media to access and correct your files.
Click to expand...
I did this:
Code: 
pkg install fusefs-ntfs
installed the fusefs-ntfs

I then went into /boot/loader.conf and did this:
Code: 
fuse_load="YES"

I also ran the command kldload fuse. I then mounted a external usb ntfs drive to /mnt .
It succeeded. I then unmounted it.

The installation media I have it on a thumb drive. It think it does have a live cd.
but what should I change?
 
zirias@ said:
If USB is unrelated and just delays your boot although not needed for your root filesystem, there's a workaround, put this in /boot/loader.conf:
Code: 
# Don't wait for USB
hw.usb.no_boot_wait=1

BUT: It doesn't look like this is your actual problem, judging from the screenshot. I'd be rather interested in this:

What exactly did you do here?

BTW, you should be able to boot the machine from installation media to access and correct your files.
Click to expand...
I will try this. I don't have a usb drive to boot the root. All the drives are in the server in a raid1. There's 2 disks mirrored.
I do use a usb mouse because I do have a gnome 3 installed. So, I would need the mouse usb to work at boot. I assume that line
ignores usb booting of a drive.
 
zirias@ said:
If USB is unrelated and just delays your boot although not needed for your root filesystem, there's a workaround, put this in /boot/loader.conf:
Code: 
# Don't wait for USB
hw.usb.no_boot_wait=1

BUT: It doesn't look like this is your actual problem, judging from the screenshot. I'd be rather interested in this:

What exactly did you do here?

BTW, you should be able to boot the machine from installation media to access and correct your files.
Click to expand...
I just did what you said. I booted using live cd and mounted my zfs root default which then specificlly mounted the boot directory where I vi edited the loader.conf file.
I added your line did wq command and then rebooted the system. It still acts the same. The error message shows GPT table corrupted. do you think that might be the issue?
I am going to use live cd and comment out any changes I did the loader.conf and see if the system boots.
 
it may be
geom may refuse to create the /dev/nodes, then zfs could not read the config from the providers
try to add
kern.geom.part.check_integrity="0"
in loader.conf and see if it works/boots
if yes, then fix partition integrity
this might be because you copied a disk from another of diff size with dd
 
I went back into /boot/loader.conf and comment things out.

so before I had this:
Code: 
if_lagg_load="YES"
fuse_load="YES"
cryptodev_load="YES"
zfs_load="YES"

Then changed it to this:
Code: 
#if_lagg_load="YES"
fuse_load="YES"
#cryptodev_load="YES"
zfs_load="YES"
hw.usb.no_boot_wait=1

Everything now boots perfectly normal. It works ok now.

but my question is can I add back in the lagg and cryptodev_load?

the lagg is an issue for me. Meaning I have 2 ethernet ports. I want to combine them as one.
i also want to assign 2 ip addresses to this lagg0. but no matter what I do it fails to get routing data.
does anyone know if I need to have if_lagg_load in the loder.config file?
I know I didn't add the cryptodev_load. I think some app or script added it.
 
You're using ZFS so definitely leave zfs_load in, or else the system won't boot. You'll want to keep cryptodev_load there too, it handles things like AESNI and other (hardware) crypto accelerators.
 
SirDice said:
You're using ZFS so definitely leave zfs_load in, or else the system won't boot. You'll want to keep cryptodev_load there too, it handles things like AESNI and other (hardware) crypto accelerators.
Click to expand...
ok will do. Is there any command or tools I could use to fix the corrupted GPT tabels? It's using the secondary table because the primary is corrupter.
 
tony33 said:
Is there any command or tools I could use to fix the corrupted GPT tabels?
Click to expand...
gpart(8)
Code: 
     recover       Recover a corrupt partition's scheme metadata on the geom
                   geom.  See the section entitled RECOVERING below for the
                   additional information.

                   The recover command accepts these options:

                   -f flags    Additional operational flags.  See the section
                               entitled OPERATIONAL FLAGS below for a
                               discussion about its use.
 
You must log in or register to reply here.
Back
Top