Various notes on /usr unification

Posted Feb 28, 2012 7:59 UTC (Tue) by jackb (guest, #41909)
In reply to: Various notes on /usr unification by tetromino
Parent article: Various notes on /usr unification

I think a lot of the resistance comes from the fact that this change will make initramfs needed for more setups and there's a lot of hate for initramfs in the Gentoo community. I was in the same camp for a long time too before I started using whole disk encryption and thus needed to have one.

A lot of this resistance could be overcome tools like Dracut had better documentation, not just command line options but a step-by-step explanation of how it constructs the initramfs and what happens between when the kernel starts executing it and it hands over control to /sbin/init. Right now it's just a black box that works most of the time but when it fails those failures tend to be inexplicable.

I'm guessing the documentation that does exist was written based on a binary distribution paradigm where most users boot a pre-compiled kernel so the users for the most part don't need to know how dracut works internally to make sure their system will boot.

Various notes on /usr unification

Posted Feb 28, 2012 11:04 UTC (Tue) by smurf (subscriber, #17840) [Link] (11 responses)

The problem with an existing seperate (possibly readonly) /usr partition can be mitigated by swapping things around so that you have a separate (read-write, obviously) /var partition instead.

The only remaining directory that's unlikely to be a mount point is /etc; symlinking the two or three files that still need to be read-write off into /var/lib land is left as an exercise to the reader.

Various notes on /usr unification

Posted Feb 28, 2012 13:27 UTC (Tue) by jwakely (subscriber, #60262) [Link]

But having a separate /var partition broke upgrading to F16, because apparently noone does that so it didn't get tested (oops, turns out lots of people do that.)

Various notes on /usr unification

Posted Feb 28, 2012 20:17 UTC (Tue) by smcv (subscriber, #53363) [Link] (9 responses)

> The only remaining directory that's unlikely to be a mount point is /etc

/etc has to be on the root filesystem (or possibly be mounted by an initramfs if you use one): it contains /etc/fstab, which is required to mount the rest.

Various notes on /usr unification

Posted Feb 29, 2012 0:09 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (8 responses)

Unless you move /root (how could we forget about that?) to /var/root first. At that point, /etc would be the only non-mount point under /, so you could convert / into a virtual filesystem that just contained a bunch of mount points, with /etc being one of those mounts.

Various notes on /usr unification

Posted Feb 29, 2012 8:14 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

Just move /root to /home where it belongs and be done with it.

Root will still be able to login even without their home directory in emergencies.

Various notes on /usr unification

Posted Feb 29, 2012 15:56 UTC (Wed) by jengelh (guest, #33263) [Link]

>Just move /root to /home where it belongs and be done with it.

The point of /root not being in /home is even more volatile (as in: potentially not available due to whatever outage) than /usr.

Various notes on /usr unification

Posted Mar 1, 2012 12:38 UTC (Thu) by smurf (subscriber, #17840) [Link] (5 responses)

Not always, no.
Some login methods require files in $HOME. sshd with authorized_keys is only one of them. Not every system has a console, and even if it has one I don't want to force somebody to go to the data center and plug something magic into some blade system just because a reboot has managed not to mount $HOME.
(Which might as well be on NFS. To require a working NFS for root login is stupid.)

Various notes on /usr unification

Posted Mar 1, 2012 12:56 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Well, in this case /root might be necessary. But it still strikes me as an extra top-level directory which is hardly ever needed now.

Maybe it could be a job for union mounts (once Valerie Aurora gets them mainlined).

Various notes on /usr unification

Posted Mar 3, 2012 17:00 UTC (Sat) by dpquigl (guest, #52852) [Link] (3 responses)

Has there been any progress on union mounts in the last year? Last I saw the conversation ended with the proposal dead in the water. I don't believe they ever determined who's responsibility it was to do culling of duplicate entries (the kernel, or glibc). Also the FUSE guy chimed in and claimed all the work was unnecessary and he could just do it in fuse.

Various notes on /usr unification

Posted Mar 3, 2012 22:07 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

FUSE union mounts actually work, but way too slow for real use.

And no, I'm not aware of any progress in that area.

Various notes on /usr unification

Posted Mar 4, 2012 18:02 UTC (Sun) by dpquigl (guest, #52852) [Link] (1 responses)

If you want to go with file system approaches unionfs and aufs have been around long before the FUSE version of unionfs. How full featured is the FUSE one? From what I understand everyone has been focusing on the most common case which is one RW branch and one RO branch. They don't want to do an arbitrary number of branches.

Various notes on /usr unification

Posted Mar 4, 2012 22:36 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

As I understand, unionfs in FUSE is pretty complete.

However, FUSE itself is not ready at all for high-performance filesystems. It's fine for things like sshfs over WAN but totally sucks for local filesystems.

Various notes on /usr unification

Posted Mar 8, 2012 9:48 UTC (Thu) by slashdot (guest, #22014) [Link]

Just use a custom init that mounts /usr and then execs the real init.