Solved How to delay mountroot

B

balanga

It looks like I have installed FreeBSD on a slow disk because the boot process stops with a mountroot prompt, I have three installations of 14.0-R and each stops when trying to mount the root filesystem as defined in /etc/fstab. When I enter the same value at the mountroot prompt, booting continues normally.

I was wondering if there was some way to force a short delay, or a retry to mount root....

Any ideas?
 
What message does it give?

If you just type the fs:mountpoint and it boots, then look at /etc/fstab. Show your /etc/fstab.
 
No, this is the kernel doing the mount. Any delay variable would be in loader.conf. I don't know offhand whether there is one.
 
gpatrick said:
What message does it give?
Click to expand...

Code: 
uhub2: 2 ports with 2 removable, self powered
Root mount waiting for: usbus2 usbus5
uhub5: 4 ports with 4 removable, self powered
uhub0: 4 ports with 4 removable, self powered
Root mount waiting for: usbus2
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device JMicron JMS579 (0x152d:0x0578)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device JMicron JMS579 (0x152d:0x0578)
ugen2.2: <JMicron JMS579> at usbus2
umass0 on uhub5
umass0: <JMicron JMS579, class 0/0, rev 2.10/32.02, addr 2> on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x8100
umass0:2:0: Attached to scbus2
mountroot: waiting for device /dev/da0p11...
da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
da0: <ST1000LM 010-9YH146 3202> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number A2C02386
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
Mounting from ufs:/dev/da0p11 failed with error 19.

Loader variables:
  vfs.root.mountfrom=ufs:/dev/da0p11
  vfs.root.mountfrom.options=rw

Manual root filesystem specification:
  <fstype>:<device> [options]
      Mount <device> using filesystem <fstype>
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
  <empty line>    Abort manual input

mountroot> Trying to mount root from ufs:/dev/da0p11 []...
ichsmb0: <Intel 82801H (ICH8) SMBus controller> port 0x1c40-0x1c5f mem 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0
smbus0: <System Management Bus> on ichsmb0
acpi_dock0: <ACPI Docking Station> on acpi0
em0: link state changed to UP


gpatrick said:
If you just type the fs:mountpoint and it boots, then look at /etc/fstab. Show your /etc/fstab.
Click to expand...

Code: 
# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/da0p11     /               ufs     rw      1       1
192.168.1.12:/   /net       nfs    rw    0    0
 
What does gpart show display?

Code: 
mountroot: waiting for device /dev/da0p11...
da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
da0 is the first SCSI disk in FreeBSD. da0 is a usb device, correct?

This is from FreeBSD docs

21.7. Labeling Disk Devices​

During system initialization, the FreeBSD kernel creates device nodes as devices are found. This method of probing for devices raises some issues. For instance, what if a new disk device is added via USB? It is likely that a flash device may be handed the device name of da0 and the original da0 shifted to da1. This will cause issues mounting file systems if they are listed in /etc/fstab which may also prevent the system from booting.

One solution is to chain SCSI devices in order so a new device added to the SCSI card will be issued unused device numbers. But what about USB devices which may replace the primary SCSI disk? This happens because USB devices are usually probed before the SCSI card. One solution is to only insert these devices after the system has been booted. Another method is to use only a single ATA drive and never list the SCSI devices in /etc/fstab.

A better solution is to use glabel to label the disk devices and use the labels in /etc/fstab. Since glabel stores the label in the last sector of a given provider, the label will remain persistent across reboots. By using this label as a device, the file-system may always be mounted regardless of what device node it is accessed through.
Click to expand...

Shouldn't da0p11 be da0s11?
 
gpatrick said:
Shouldn't da0p11 be da0s11?
Click to expand...
No.

gpart show -l da0 :-

Code: 
          34        2014       - free -  (1.0M)
        2048    69297544    1  Ventoy  (33G)
    69299592       65536    2  VTOYEFI  (32M)
    69365128   251658240    3  FreeBSD  (120G)
   321023368         632       - free -  (316K)
   321024000    20971520    4  (null)  (10G)
   341995520    20971520    5  (null)  (10G)
   362967040    20971520    6  (null)  (10G)
   383938560    10485760    7  (null)  (5.0G)
   394424320   125829120    8  Debian  (60G)
   520253440    20971520    9  FreeBSD-14.0-Test  (10G)
   541224960    20971520   10  FreeBSD-14.0-Test  (10G)
   562196480    20971520   11  FreeBSD-14.0-Test  (10G)
   583168000  1370357135       - free -  (653G)
 
The kernel is doing the mount and it's having a problem communicating with the device. Notice the error,

Mounting from ufs:/dev/da0p11 failed with error 19.

Error 19 is,

#define ENODEV 19 /* Operation not supported by device */

You can see that in /usr/include/sys/errno.h.

What kind of device is this? It's da(4) so it not ata. Is it SCSI or USB? You could try to increase the following in loader.conf or device.hints:

kern.cam.scsi_delay: 5000

Change it to something like 15000. That's what it used to be under FreeBSD 5.

Failing that you can try increasing this in loader.conf or device.hints:
kern.cam.da.default_timeout: 60
 
Code: 
# fdisk -B -b /boot/boot0 <device>

15,2 FreeBSD Boot Process

You can also try glabel label on da0 and use the partition name in /etc/fstab and then the device name won't matter. You can destroy the label with glabel destroy if you no longer want to use it.

Since there are multiple FreeBSD partitions on one disk and three of them have the same problem seems to be a bootsector problem. Hence, fdisk above. Or it is a usb drive and then labeling it may get around the device name issue.
 
According to /usr/src/sys/sys/errno.h error number 19 is
Code: 
#define ENODEV          19              /* Operation not supported by device */
.
It could mean that device node da0p.. has not been created yet, or not all of them. If you are using amd64, you may want to look at kernel config file /usr/src/sys/amd64/conf/GENERIC. It contains an option
Code: 
options         SCSI_DELAY=5000         # Delay (in ms) before probing SCSI
. You could try to raise that value

You will have to bake your own kernel for that, see https://docs.freebsd.org/en/books/handbook/kernelconfig/#kernelconfig-config Nowadays it seems possible to do that without vi!

Edit: I see cy@ was faster, but I like to point out that placing a variable in a file in the root FS system won't help to mount that root FS.
 
Looking at the code, there actually is a loop around the mount. It will loop until a timeout is exceeded and try every kernhz / 10 seconds until the timeout is done, also printing a message every retry. There is no condition based on count.

The variable for the timeout is:
vfs.mountroot.timeout

ETA: we didn't find that earlier because it doesn't show up in `sysctl -a`.
 
cracauer@ said:
The variable for the timeout is:
vfs.mountroot.timeout

ETA: we didn't find that earlier because it doesn't show up in `sysctl -a`.
Click to expand...

Maybe a tunable, not a sysctl? I don't have 14 sources to hand.

See /boot/defaults/loader.conf section "Kernel tunables" for a list of these.

As Alain spotted,
kern.cam.boot_delay and/or
kern.cam.scsi_delay
might be useful in loader.conf?

Also 'vfs.root.mountfrom' to specify root partition directly in loader.conf?
 
Usually it's a good habit to grep'ping /boot/defaults/loader.conf with proper keyword.
Putting kern.cam.boot_delay="10000" or larger in /boot/loader.conf would help.

grep -A 2 delay /boot/defaults/loader.conf
results in
#loader_delay="3" # Delay in seconds before loading anything. # Default is unset and disabled (no delay). #autoboot_delay="10" # Delay in seconds before autobooting, # -1 for no user interrupts, NO to disable #password="" # Prevent changes to boot options -- #kern.cam.boot_delay="10000" # Delay (in ms) of root mount for CAM bus # registration, useful for USB sticks as root #kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI #kern.ipc.maxsockets="" # Set the maximum number of sockets available #kern.ipc.nmbclusters="" # Set the number of mbuf clusters
 
Tieks said:
/usr/src/sys/amd64/conf/GENERIC. It contains an option
Code: 
options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI
. You could try to raise that value

You will have to bake your own kernel for that, see
Click to expand...
...
Tieks said:
Edit: I see [FONT=monospace]cy@[/FONT] was faster, but I like to point out that placing a variable in a file in the root FS system won't help to mount that root FS.
Click to expand...
and now ...
Tieks said:
If an error happens with mounting the system disk during boot, how is it going to read file /boot/loader.conf residing on that unmountable disk?
Click to expand...

No, as cy@ and others pointed out, we're in the loader already, from the disks' bootcode, now looking for which kernel to load.

So setting tunables in loader.conf or the hints will affect delays from here on.
 
cy@ said:
What kind of device is this? It's da(4) so it not ata. Is it SCSI or USB? You could try to increase the following in loader.conf or device.hints:

kern.cam.scsi_delay: 5000

Change it to something like 15000. That's what it used to be under FreeBSD 5.

Failing that you can try increasing this in loader.conf or device.hints:
kern.cam.da.default_timeout: 60
Click to expand...


cy@ after setting :-

kern.cam.boot_delay="20000"
kern.cam.scsi_delay="20000"

the mountroot prompt no longer appears, so the basic problem has been overcome. Now to fine tune things...

Also I notice quite a few other suggestions, which may well have a similar effect, but try to amend these values to see which is optimal.

Many thanks to all that helped.
 
Tieks said:
If an error happens with mounting the system disk during boot, how is it going to read file /boot/loader.conf residing on that unmountable disk?
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top