Persistent reference to device used as root device when booting

Up until this now, I have mostly used Linux (and Windows (more Linux than Windows)) and I have a good grasp of how to make sure that Linux uses the desired root device in the face of attaching/detaching storage devices and the non-deterministic way in which it assigns names to storage devices. By passing root=UUID=, root=LABEL=, root=PARTLABEL=, or root=PARTUUID= followed by, respectively, the filesystem UUID, filesystem label, partition label, or partition UUID as a kernel command line parameter, the same root filesystem will be selected every time (assuming there are no other partitions/filesystems present with the same UUID/label).

From what I can tell, FreeBSD does not have a kernel command line, but it still has boot arguments. I have thus far seen that it may be passed to the kernel with set kFreeBSD.vfs.root.mountfrom=... in GRUB and the configuration variable currdev/rootdev when using loader/loader.efi. In each case, how would I write the value so that the kernel selects the value based on partition UUID, partition label, filesystem label, and filesystem UUID?
 
First of all, I haven't configured multiboot systems with grub for a long time. Following menuentry examples might not be up to date, but you should get an idea:

https://forums.freebsd.org/threads/da0-da1.79635/post-503976 .

https://forums.freebsd.org/threads/mount-error.89083/post-610445 .

When using Root-on-ZFS, assigning different pool names would solve the problem of interfering with each other.
I only gave GRUB as an example of the vfs.root.mountfrom boot argument. GRUB otherwise has no bearing on what I am asking about.

With the values used to inform the kernel of which device to use as the root device, how would I write refer to a particular partition using it's GPT partition label or partition GUID?
 
Code:
     This GEOM class also provides volume label detection for file systems.
     Those labels cannot be set with glabel, but must be set with the
     appropriate file system utility, e.g. for UFS the file system label is
     set with tunefs(8).  Currently supported file systems are:

           •   UFS1 volume names (directory /dev/ufs/).
           •   UFS2 volume names (directory /dev/ufs/).
           •   UFS1 file system IDs (directory /dev/ufsid/).
           •   UFS2 file system IDs (directory /dev/ufsid/).
           •   MSDOSFS (FAT12, FAT16, FAT32) (directory /dev/msdosfs/).
           •   CD ISO9660 (directory /dev/iso9660/).
           •   EXT2FS (directory /dev/ext2fs/).
           •   REISERFS (directory /dev/reiserfs/).
           •   NTFS (directory /dev/ntfs/).

     Support for partition metadata is implemented for:

           •   GPT labels (directory /dev/gpt/).
           •   GPT UUIDs (directory /dev/gptid/).

     Generic disk ID strings are exported as labels in the format
     /dev/diskid/GEOM_CLASS-ident e.g.  /dev/diskid/DISK-6QG3Z026.

     Generic labels created and managed solely by glabel(8) are created in the
     /dev/label/ directory.
glabel(8)
 
I only gave GRUB as an example of the vfs.root.mountfrom boot argument. GRUB otherwise has no bearing on what I am asking about.
A misunderstanding on my part, apologies.

how would I write the value so that the kernel selects the value based on partition UUID, partition label,

UFS, partition labels (see gpart(8) modify to label)
Code:
vfs.root.mountfrom="ufs:/dev/gpt/<partiton label>

UFS, UUID
Code:
List provider (partition) names:

gpart show -p

Extract uuid:

gpart list | egrep 'Name|rawuuid'

Choose the freebsd-ufs partition rawuuid.

vfs.root.mountfrom="ufs:/dev/gptid/<rawuuid>

ZFS
Code:
vfs.root.mountfrom="zfs:<pool name>/ROOT/default:
<pool name> and "default" data set can be any name.

Those variables can be set in /boot/loader.conf or manually at the loader prompt.

For syntax see halt(8), reboot(8) EXAMPLES section, and loader_simp(8), section BUILTIN ENVIRONMENT VARIABLES, currdev.

currdev doesn't accept labels or UUID's, only the form seen in loader_simp(8).

The FreeBSD loader boots the first kernel found, make sure the booted kernel has at least the same or bigger version than the root.mountfrom userland, ideal would be the same. It's not a good idea to boot a smaller version kernel on a bigger userland version.
 
A misunderstanding on my part, apologies.



UFS, partition labels (see gpart(8) modify to label)
Code:
vfs.root.mountfrom="ufs:/dev/gpt/<partiton label>

UFS, UUID
Code:
List provider (partition) names:

gpart show -p

Extract uuid:

gpart list | egrep 'Name|rawuuid'

Choose the freebsd-ufs partition rawuuid.

vfs.root.mountfrom="ufs:/dev/gptid/<rawuuid>

ZFS
Code:
vfs.root.mountfrom="zfs:<pool name>/ROOT/default:
<pool name> and "default" data set can be any name.

Those variables can be set in /boot/loader.conf or manually at the loader prompt.

For syntax see halt(8), reboot(8) EXAMPLES section, and loader_simp(8), section BUILTIN ENVIRONMENT VARIABLES, currdev.

currdev doesn't accept labels or UUID's, only the form seen in loader_simp(8).

The FreeBSD loader boots the first kernel found, make sure the booted kernel has at least the same or bigger version than the root.mountfrom userland, ideal would be the same. It's not a good idea to boot a smaller version kernel on a bigger userland version.
Thank you. Now, how would one write it for currdev and rootdev?
 
how would one write it for currdev and rootdev?

currdev and rootdev share the same syntax as shown in loader_simp(8):
Rich (BB code):
     currdev   Selects the default device to loader the kernel from.  The
               syntax is:
                     loader_device:
               or
                     zfs:dataset:
               Examples:
                     disk0p2:
                     zfs:zroot/ROOT/default:

Be adviced one more time, rootdev (and vfs.root.mountfrom) won't load necessarily the kernel in the specified root file system. The boot loader will load the first kernel found on any file system.

If the case is to boot different versions of the system (not only major versions but also patch-level versions) it makes more sense to use currdev. The kernel loaded will be the one in the specified file system, kernel and userland will be the same.
 
Back
Top