The loader code that sets vfs.root.mountfrom currently requires /etc/fstab on the root filesystem to contain an appropriate device name. This proposed change provides an alternative way of passing the root device from loader to kernel, namely by relying on a volume label (in the geom_label sense) found on the candidate root device. This allows the root filesystem to be mounted even in the absence of a /etc/fstab entry for it if it has a supported label (UFS label, UFS unique id, ext2fs label, ISO 9660 volume name...) It could conceivably be extended to also include support for GPT partition labels. A typical use case for this feature is a nanoBSD setup with two possible boot slices. With this change, you do not need to have a different /etc/fstab on the two slices, you can select one slice at boot and the kernel will know to mount it using its UFS id. The new code is activated when either there's no entry for / in /etc/fstab, or when there's one mentioning the special name "/dev/rootdev". I have also included a trivial rc.d patch that creates /dev/rootdev as a symlink at boot, for consistency.
State Changed From-To: open->feedback Thomas, I tend to close this PR but would like to discuss that before. A lot of machines I'm responsible for, do not have an /etc/fstab on the boot filesystem at all, so loader(8) does not see anything at all. If vfs.root.mountfrom is properly set, neither loader(8) nor the kernel require any entries to find the root filesystem. Thus, these machines boot and find the root filesystem without user intervention and without an /etc/fstab. All it takes is the correct filesystem type and device path to the device that contains the root filesystem and that all can be set by loader.conf(5). So in the end, what your PR is all about can be done without any code changes. A code change for a problem that can be solved w/o a code change is IMHO a KISS violation. You can also use a glabel'd root filesystem. It's devicename at the mount prompt is something like "ufs:ufs/MYLABELEDROOT". It just requires geom_label to be loaded at boot time. If you're able to let your machine mount the root fs by just using proper loader.conf settings, I would like to close this PR. I'm wondering if you're able to set your root fs to be mounted at boot time, too?
Responsible Changed From-To: freebsd-bugs->vwe track
Filing further discussion. ----- Forwarded message from Thomas Quinot <thomas@FreeBSD.ORG> ----- Date: Fri, 20 Aug 2010 12:47:39 +0200 From: Thomas Quinot <thomas@FreeBSD.ORG> To: vwe@FreeBSD.org Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/149803: [patch] loader: set vfs.mount.rootfrom using label User-Agent: Mutt/1.5.20 (2009-06-14) * vwe@FreeBSD.org, 2010-08-19 : > I tend to close this PR but would like to discuss that before. > A lot of machines I'm responsible for, do not have an /etc/fstab on the boot > filesystem at all, so loader(8) does not see anything at all. > > If vfs.root.mountfrom is properly set, neither loader(8) nor the kernel > require any entries to find the root filesystem. Right, setting vfs.root.mountfrom in loader.conf (or manually at the loader prompt) is another possibility. The proposed change does not change anything to the existing behaviour in that case. > All it takes is the correct filesystem type and device path to the device that > contains the root filesystem and that all can be set by loader.conf(5). This assumes that the contents of loader.conf is consistent with the device name which the kernel will assign to the filesystem. If this information is known in advance and can be stored in the filesystem, one might just as well put it in /etc/fstab. > So in the end, what your PR is all about can be done without any code changes. I beg to differ. The use case for the proposed change is when you cannot, or do not want to, hard-code in the filesystem the specific device name that will be assigned to it. Think for example of a machine where you want to have a "rescue" slice that contains an exact copy of the root filesystem taken in some "known good" state. You want to be able to boot from that rescue slice in case something goes wrong (e.g. a system upgrade) on the main slice. With the proposed change, you do not need to remember to fix /etc/fstab or /boot/loader.conf on the rescue slice at the point where you copy the "known good" snapshot: you can have the files in the rescue slice have exactly the same contents as on the main slice. Then, you can just select the desired slice from the boot blocks prompt, and with the proposed change the kernel will end up mounting the corresponding device. If we rely on /etc/fstab or /boot/loader.conf on the other hand, you will always end up mounting the root fs from the "main" slice" even if you have read the boot blocks, fstab and loader.conf from the rescue slice. Of course, on a machine that has just a single boot slice, my change does not bring anything compared to setting vfs.root.mountfrom in loader.conf (but if we follow this line of reasoning, we might just as well get rid of the existing code in loader that reads /etc/fstab!) > I'm wondering if you're able to set your root fs to be mounted at boot time, too? Not sure I understand the question... Thomas. _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" ----- End forwarded message ----- Thomas.
Hi Volker, I am resurrecting discussion on this ancient PR. The idea being proposed was to let the boot blocks convey the label of the boot device to the loader so that it would use it as the default root filesystem. At the time you mentioned that this could also be achieved by hard-coding the proper (label-based) path in loader.conf in each bootable filesystem, to which I replied with a clarification of the use case. In practice it occurs with nanoBSD systems where you have two bootable slices, an active one and a dormant one, which are selected through the boot blocks. It is convenient maintainance-wise if the contents of these filesystems can be identical because when updating a running system, you want to be able to overwrite the dormant image and not have to worry about fixing up the device name depending on whether it happened to be on slice 1 or on slice 2. Could you please comment on this proposal as clarified? Thanks! Thomas. * Thomas Quinot, 2010-08-20 : > Date: Fri, 20 Aug 2010 12:47:39 +0200 > From: Thomas Quinot <thomas@FreeBSD.ORG> > To: vwe@FreeBSD.org > Cc: freebsd-bugs@FreeBSD.org > Subject: Re: kern/149803: [patch] loader: set vfs.mount.rootfrom using label > User-Agent: Mutt/1.5.20 (2009-06-14) > > * vwe@FreeBSD.org, 2010-08-19 : > > > I tend to close this PR but would like to discuss that before. > > A lot of machines I'm responsible for, do not have an /etc/fstab on the boot > > filesystem at all, so loader(8) does not see anything at all. > > > > If vfs.root.mountfrom is properly set, neither loader(8) nor the kernel > > require any entries to find the root filesystem. > > Right, setting vfs.root.mountfrom in loader.conf (or manually at the > loader prompt) is another possibility. The proposed change does not > change anything to the existing behaviour in that case. > > > All it takes is the correct filesystem type and device path to the device that > > contains the root filesystem and that all can be set by loader.conf(5). > > This assumes that the contents of loader.conf is consistent with the > device name which the kernel will assign to the filesystem. If this > information is known in advance and can be stored in the filesystem, one > might just as well put it in /etc/fstab. > > > So in the end, what your PR is all about can be done without any code changes. > > I beg to differ. The use case for the proposed change is when you cannot, > or do not want to, hard-code in the filesystem the specific device name > that will be assigned to it. > > Think for example of a machine where you want to have a "rescue" slice > that contains an exact copy of the root filesystem taken in some "known > good" state. You want to be able to boot from that rescue slice in case > something goes wrong (e.g. a system upgrade) on the main slice. > > With the proposed change, you do not need to remember to fix /etc/fstab > or /boot/loader.conf on the rescue slice at the point where you copy the > "known good" snapshot: you can have the files in the rescue slice have > exactly the same contents as on the main slice. > > Then, you can just select the desired slice from the boot blocks prompt, > and with the proposed change the kernel will end up mounting the > corresponding device. If we rely on /etc/fstab or /boot/loader.conf > on the other hand, you will always end up mounting the root fs from the > "main" slice" even if you have read the boot blocks, fstab and > loader.conf from the rescue slice. > > Of course, on a machine that has just a single boot slice, my change > does not bring anything compared to setting vfs.root.mountfrom in > loader.conf (but if we follow this line of reasoning, we might just as > well get rid of the existing code in loader that reads /etc/fstab!) > > > I'm wondering if you're able to set your root fs to be mounted at boot time, too? > > Not sure I understand the question... Thomas.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
I'll evaluate the patch and see if it's possible to use it, at least as a fallback position when there's no /etc/fstab.
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>