Error 19 on boot (from USB) after 8.2->9.0 upgrade

phobozad

phobozad

I have a FreeBSD system that was running 8.2 installed on a flash drive. To get it to properly mount the root fs when I first set it up, I had to introduce a delay to ensure the flash drive was fully detected before attempting to mount it (kern.cam.boot_delay=10000).

Following the reboot after upgrading the kernel to 9.0-RELEASE, I get error 19 and thrown a mountroot prompt. The disk does not show in the available device lists. Going through the boot messages, it does detect the device as umass0, but does not ever recognize it as da0.

If I plug in a different flash drive at the mountroot prompt it detects it completely and I see da0 and its associated slices/partitions. However, I cannot get the drive holding the root fs to show up.

If I boot up a 9.0 livecd and plug in the drive, it works perfectly fine. It just seems like something that needs to be initialized in the boot process isn't happening soon enough in the new version.
 
Hello, I am facing the same problem in FreeBSD/arm, source upgrading from 8.3-PRERELEASE to 9.0-STABLE with
Code: 
option CAM_BOOT_DELAY=4000
in the kernel config.
 
What exactly does Error 19 mean? I'm getting this across a lot of different servers/hardware for 9.0; even with a fresh install. SATA, SCSI, IDE, USB; across the board :(

Even with it set to verbose, it doesn't give much insight into what exactly is going on. 19 == general failure?
 
ENODEV (intro(2)), probably. But what it means is likely just device not ready or accessible. USB devices can fail to be ready because of needed quirks (usb_quirk(4)) or just being slow to be recognized. RAID controllers might spin up each drive separately and not be ready in time. IDE or SATA, no idea.

The two timeout sysctls that can be set in /boot/loader.conf are
Code: 
kern.cam.boot_delay=10000
kern.cam.scsi_delay=10000
 
wblock@ said:
ENODEV (intro(2)), probably. But what it means is likely just device not ready or accessible. USB devices can fail to be ready because of needed quirks (usb_quirk(4)) or just being slow to be recognized. RAID controllers might spin up each drive separately and not be ready in time. IDE or SATA, no idea.

The two timeout sysctls that can be set in /boot/loader.conf are
Code: 
kern.cam.boot_delay=10000
kern.cam.scsi_delay=10000
Click to expand...

Thanks, I tried this; but just hangs then eventually comes back to the same problem. I set both to 90000. This is weird for a couple of reasons.
  1. The boot drive and root drive are the same (there is only one disk). It has no problems bootstrapping obviously, but has a problem mounting root from very same drive :/
  2. I tried both FreeBSD 6.0 and some random linux CD that was laying around. Both of those work flawlessly, even after 20 reboots each. But 9.0 has this error 19 behavior.
  3. It doesn't happen all the time.
On FreeBSD 9.0 i386, after 20 reboots, 4 of them worked, 16 of them didn't (with GENERIC kernel and default loader.conf). With the two parameters above set to 90000 and GENERIC kernel it worked 0/10 times. GENERIC kernel, default loader.conf and disabled ACPI and it worked 1/4 times. From CDROM (9.0 installer) it worked 18/20 times.

In contrast:

FreeBSD 6.0 and random linux cd worked 20/20 times each; 6.0 installer and linux worked both 1/1 times each; OpenBSD 2.6 installer worked 1/1 times. It booted 3/3 times.
 
feralape, that seems odd. The issue I ran into is perfectly consistent - it never works. I've worked around the issue at this point by booting from an old SATA laptop drive I found laying around, instead of a USB key.

I didn't feel like fiddling with all those possible quirks to get something working in 9.0 that worked perfectly fine in 8.x
 
We are still testing, but believe this is resolved (for my case at least). Post here in case anyone else has a problem.

My bad for not checking the errata first: http://www.freebsd.org/releases/9.0R/errata.html
[amd64, i386] FreeBSD 9.0-RELEASE includes several changes to improve resource management of PCI devices. Some x86 machines may not boot or may have devices that no longer attach when using ACPI as a result of these changes. This can be worked around by setting a loader(8) tunable debug.acpi.disabled to hostres. To do this, enter the following lines at the loader prompt:

set debug.acpi.disabled="hostres"
boot

Or, put the following line into /boot/loader.conf:

debug.acpi.disabled="hostres"
Click to expand...

I added that to my /boot/loader.conf and so far seems to get a reliable boot.
 
You must log in or register to reply here.
Back
Top