Solved How to delay mountroot

This is something I always wondered about but never asked.

dmesg shows loads of info before it mounts root. How does it do that? You need to mount root to read /etc/fstab... obviously not, but it sounds logical...

This continues to be a great mystery to me.
Loader uses bios calls to read the disk. Once the kernel gets control it uses the driver. The FreeBSD drivers are more aggressive, using DMA and interrupts. The bios uses device polling for I/O. Though more reliable it's slow.

Device polling is what MS-DOS did, because it used the BIOS. Modern operating systems use more efficient means.

Consider the timeouts as device settle times. Some devices will flap after initial configuration. To avoid this the O/S must patiently wait for the device to settle down before any real requests are made to it.
 
dmesg
Boot messages are stored by the kernel even before syslog service is started.
& by configuring syslog you can also log console messages of the boot process.
 
dmesg
Boot messages are stored by the kernel even before syslog service is started.
& by configuring syslog you can also log console messages of the boot process.
It's a ring buffer. When syslogd starts it fetches the contents of the ring buffer and writes it to wherever syslog.conf says it should.
 
This is something I always wondered about but never asked.

dmesg shows loads of info before it mounts root. How does it do that? You need to mount root to read /etc/fstab... obviously not, but it sounds logical...

This continues to be a great mystery to me.

The trick you are missing is that the bootloaders have enough filesystem code in them to do minimal readonly operations to read individual files.

Check /usr/src/stand/kboot and the efi equivalent.
 
Given that 5000 was original kern.cam.boot_delay, it must be kern.cam.scsi_delay that fixed things by setting it to 1000 (1 second), right?

So what was the original value of kern.cam.scsi_delay?
I just checked that I hadn't made a typo, and that is what I do have.

I'm wonderind if the commented out values are actually correct.

On another system I have the commented out values as 10000 and 2000. That is on 13.2. Not sure if that has been changed on 14.0.

Will check later.
 
No, as cy@ and others pointed out, we're in the loader already, from the disks' bootcode, now looking for which kernel to load.
Looks like you're right, it seems to have access to the root of a system FS. Makes me wonder why it stops instead of falling back to single user mode. I'm lost on this one, an xhci versus USB3 issue perhaps?
 
Given that 5000 was original kern.cam.boot_delay, it must be kern.cam.scsi_delay that fixed things by setting it to 1000 (1 second), right?

So what was the original value of kern.cam.scsi_delay?
After quite a bit of experimenting today, I settled on:-

kern.cam.boot_delay="5000"

and left the other parameter commented out.

This seems to work on the computer on which it runs.

As for the commented out values, are they the 'default' values? If it was 10000, then I can't see why it didn't work without a change.

So, just as an experiment, I set it to 10000, the supposed default, and it booted, then I commented out the value, and it stopped at the mountroot prompt. Weird!
 
So, just as an experiment, I set it to 10000, the supposed default, and it booted, then I commented out the value, and it stopped at the mountroot prompt. Weird!
The default is 0, not 10000.
grep -A1 SYSCTL_INT /usr/src/sys/cam/cam_xpt.c | grep boot_delay
Code:
SYSCTL_INT(_kern_cam, OID_AUTO, boot_delay, CTLFLAG_RDTUN,
           &xsoftc.boot_delay, 0, "Bus registration wait time");
The values listed in /boot/defaults/loader.conf are not default.
grep -A1 kern.cam.boot_delay /boot/defaults/loader.conf
Code:
#kern.cam.boot_delay="10000"    # Delay (in ms) of root mount for CAM bus
                                # registration, useful for USB sticks as root
 
If you don't specify any configuration, just the default should be used.
Commented values in /boot/defauts/loader.conf is sometime the defaut, but sometime the non-default hint for workaround something.
 
Back
Top