Bug 149803 - [patch] loader: set vfs.mount.rootfrom using label
Summary: [patch] loader: set vfs.mount.rootfrom using label
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.0-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-19 12:40 UTC by Thomas Quinot
Modified: 2017-12-31 22:23 UTC (History)
0 users

See Also:


Attachments
file.diff (8.73 KB, patch)
2010-08-19 12:40 UTC, Thomas Quinot
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Quinot 2010-08-19 12:40:00 UTC
	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.
Comment 1 Volker Werth freebsd_committer 2010-08-19 20:40:56 UTC
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? 


Comment 2 Volker Werth freebsd_committer 2010-08-19 20:40:56 UTC
Responsible Changed
From-To: freebsd-bugs->vwe

track
Comment 3 Thomas Quinot freebsd_committer 2014-05-07 19:23:15 UTC
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.
Comment 4 Thomas Quinot freebsd_committer 2014-05-07 19:29:40 UTC
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.
Comment 5 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:44 UTC
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