[arch-projects] [mkinitcpio] mounting /usr from the initrd
Hi guys, I have been thinking about sorting out /usr being a separate mountpoint. Mainly because I keep getting bug reports that turn out to be caused by this. The current status is that we move some tools from /usr to / in the hope that this will allow us to boot without /usr being mounted. This mostly works, but not quite, as there are still stuff left in /usr that are used by early boot (and mostly just fails silently). This website created by the systemd folks sums it up nicely (just replace "systemd" with "initscripts" everywhere): http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken. The solution they propose, and which I agree with, is to mount /usr from the initrd just as we mount / (an alternative solution is to just declare separate /usr as not supported, but I guess that would not make us popular). Before working up a patch, I wanted to hear if there are any objections to this approach, and in particular that Thomas agrees that it is the right way to go. The interface I suggest is to allow two new kernel options "usr" and "rootflags" that correspond to "root" and "rootflags". The pivot_root stuff I submitted recently will already take care of unmounting. The syntax could obviously be discussed, and I suggest getting in touch with the dracut guys to make sure we choose the same syntax (I don't think they yet have support for this, but I might be wrong). Any thoughts? Cheers, Tom PS A nice sideeffect is that once we have this we can simplify a lot of our PKGBUILDS as they never need to put stuff in / any more, and eventually /bin, /sbin and /lib will be empty and can just be symlinked to /usr/{{,s}bin,lib}.
On Tue, Aug 2, 2011 at 5:10 PM, Tom Gundersen
The interface I suggest is to allow two new kernel options "usr" and "rootflags" that correspond to "root" and "rootflags". The pivot_root stuff I submitted recently will already take care of unmounting. The syntax could obviously be discussed, and I suggest getting in touch with the dracut guys to make sure we choose the same syntax (I don't think they yet have support for this, but I might be wrong).
Forget that, we can of course just read the fstab once the root is mounted. No need for kernel options. -t
Am 02.08.2011 17:10, schrieb Tom Gundersen:
This website created by the systemd folks sums it up nicely (just replace "systemd" with "initscripts" everywhere): http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken.
Heh, doesn't the "separate-usr-is-broken" in the URL say it all? (Didn't read it yet, will have to soon.)
The solution they propose, and which I agree with, is to mount /usr from the initrd just as we mount / (an alternative solution is to just declare separate /usr as not supported, but I guess that would not make us popular).
Before working up a patch, I wanted to hear if there are any objections to this approach, and in particular that Thomas agrees that it is the right way to go.
The purpose of the initrd is to do as few things as possible to get to the "real" system. If we can support a system that gets to the point of mounting /usr without needing things from /usr, we do it. If we can't support it, there is no point in ugly workarounds - if it's broken by design, don't do it. I won't accept any patch that modifies the mkinitcpio core to support this. I might consider a patch that does this in a hook and thus keeps things modular, if you think it is necessary. For example, write a hook that adds a new mount handler: run_hook() { mount_handler=usr_mount_handler } usr_mount_handler() { # mount / default_mount_handler "$@" # mount /usr [ add code here to mount /usr ] }
On Tue, Aug 02, 2011 at 05:40:06PM +0200, Thomas Bächler wrote:
Am 02.08.2011 17:10, schrieb Tom Gundersen:
This website created by the systemd folks sums it up nicely (just replace "systemd" with "initscripts" everywhere): http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken.
Heh, doesn't the "separate-usr-is-broken" in the URL say it all? (Didn't read it yet, will have to soon.)
The solution they propose, and which I agree with, is to mount /usr from the initrd just as we mount / (an alternative solution is to just declare separate /usr as not supported, but I guess that would not make us popular).
Before working up a patch, I wanted to hear if there are any objections to this approach, and in particular that Thomas agrees that it is the right way to go.
The purpose of the initrd is to do as few things as possible to get to the "real" system. If we can support a system that gets to the point of mounting /usr without needing things from /usr, we do it. If we can't support it, there is no point in ugly workarounds - if it's broken by design, don't do it.
I won't accept any patch that modifies the mkinitcpio core to support this. I might consider a patch that does this in a hook and thus keeps things modular, if you think it is necessary. For example, write a hook that adds a new mount handler:
run_hook() { mount_handler=usr_mount_handler }
usr_mount_handler() { # mount / default_mount_handler "$@" # mount /usr [ add code here to mount /usr ] }
I like this a lot more than any of my other ideas... d
On Tue, Aug 2, 2011 at 5:40 PM, Thomas Bächler
Am 02.08.2011 17:10, schrieb Tom Gundersen:
This website created by the systemd folks sums it up nicely (just replace "systemd" with "initscripts" everywhere): http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken.
Heh, doesn't the "separate-usr-is-broken" in the URL say it all? (Didn't read it yet, will have to soon.)
I'd be very happy if we just agreed that "separate-usr-is-broken" and stopped trying to support it, and closed all bugs as WONTFIX. I just assumed that was going to be a no-go, so tried finding a workaround.
The purpose of the initrd is to do as few things as possible to get to the "real" system. If we can support a system that gets to the point of mounting /usr without needing things from /usr, we do it. If we can't support it, there is no point in ugly workarounds - if it's broken by design, don't do it.
I won't accept any patch that modifies the mkinitcpio core to support this. I might consider a patch that does this in a hook and thus keeps things modular, if you think it is necessary. For example, write a hook that adds a new mount handler:
The simple case of having /usr as a regular partition can be achieved
as simply as the below patch (which certainly could be wrapped in a
hook). The question is how complicated setups we want to support, or
if we should just give up altogether (which you alluded to above).
commit 6814b137178ad6a676b74ea57f91a3b0f8622171
Author: Tom Gundersen
On Tue, Aug 2, 2011 at 5:40 PM, Thomas Bächler
Am 02.08.2011 17:10, schrieb Tom Gundersen:
This website created by the systemd folks sums it up nicely (just replace "systemd" with "initscripts" everywhere): http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken.
Heh, doesn't the "separate-usr-is-broken" in the URL say it all? (Didn't read it yet, will have to soon.) I won't accept any patch that modifies the mkinitcpio core to support this. I might consider a patch that does this in a hook and thus keeps things modular, if you think it is necessary. For example, write a hook that adds a new mount handler:
run_hook() { mount_handler=usr_mount_handler }
usr_mount_handler() { # mount / default_mount_handler "$@" # mount /usr [ add code here to mount /usr ] }
After thinking/discussing on irc. I agree that this is the best solution. I'll post a patch which just implements the super simple case I just posted earlier, and then people can extend it if they want. I think the most important thing is that we declare separate /usr unsupported, so we stop getting bug reports, and we can start simplifying PKGBUILD's. People can use this or similar hooks if they are not able to merge /usr and /. Cheers, Tom
On Tue, Aug 02, 2011 at 05:10:48PM +0200, Tom Gundersen wrote:
Hi guys,
I have been thinking about sorting out /usr being a separate mountpoint. Mainly because I keep getting bug reports that turn out to be caused by this.
The current status is that we move some tools from /usr to / in the hope that this will allow us to boot without /usr being mounted. This mostly works, but not quite, as there are still stuff left in /usr that are used by early boot (and mostly just fails silently).
This website created by the systemd folks sums it up nicely (just replace "systemd" with "initscripts" everywhere): http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken.
The solution they propose, and which I agree with, is to mount /usr from the initrd just as we mount / (an alternative solution is to just declare separate /usr as not supported, but I guess that would not make us popular).
Before working up a patch, I wanted to hear if there are any objections to this approach, and in particular that Thomas agrees that it is the right way to go.
The interface I suggest is to allow two new kernel options "usr" and "rootflags" that correspond to "root" and "rootflags". The pivot_root stuff I submitted recently will already take care of unmounting. The syntax could obviously be discussed, and I suggest getting in touch with the dracut guys to make sure we choose the same syntax (I don't think they yet have support for this, but I might be wrong).
Any thoughts?
Cheers,
Tom
PS
A nice sideeffect is that once we have this we can simplify a lot of our PKGBUILDS as they never need to put stuff in / any more, and eventually /bin, /sbin and /lib will be empty and can just be symlinked to /usr/{{,s}bin,lib}.
This could be a fair bit of work in mkinitcpio, as we'll need to teach it some new tricks... I have a few ideas for how to go about this, in no particular order of preference... 1) introduce a new cmdline var, call it something like "latemount", which could accept options like "/dev/sda2,/usr;/dev/sda3,/var". 2) add a new var in /etc/mkinitcpio.conf called LATEHOOKS or AFTERHOOKS, which would be run after root is mounted (successfully). 3) add a new hook which pulls in /etc/fstab. A kernel cmdline option could then specify a delimited list of sources or destinations which would be passed to mount. This depends on busybox's mount not sucking. Note that all of these assume that the user is intelligent enough to figure out how exactly how to create this extra device before its mounted. I'm not sure how we'd handle this if someone has /usr on an encrypted LVM spliced mdadm array.... dave
On Tue, Aug 2, 2011 at 5:10 PM, Tom Gundersen
I have been thinking about sorting out /usr being a separate mountpoint. Mainly because I keep getting bug reports that turn out to be caused by this.
The current status is that we move some tools from /usr to / in the hope that this will allow us to boot without /usr being mounted. This mostly works, but not quite, as there are still stuff left in /usr that are used by early boot (and mostly just fails silently).
This website created by the systemd folks sums it up nicely (just replace "systemd" with "initscripts" everywhere): http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken.
The solution they propose, and which I agree with, is to mount /usr from the initrd just as we mount / (an alternative solution is to just declare separate /usr as not supported, but I guess that would not make us popular).
Before working up a patch, I wanted to hear if there are any objections to this approach, and in particular that Thomas agrees that it is the right way to go.
A quick follow up: The next initscripts release will have the attached friendly warning in case you have a separate /usr which is not mounted from the initrd. -t
participants (3)
-
Dave Reisner
-
Thomas Bächler
-
Tom Gundersen