| |||||||||||||
separate /usr, advantages & disadvantagesseparate /usr, advantages & disadvantagesPosted Nov 27, 2012 9:26 UTC (Tue) by pjm (subscriber, #2080)In reply to: Gentoo's udev fork by mezcalero Parent article: Gentoo's udev fork
> you still need to fix the rest of the stack to support split-off /usr. There's simply way too much code in our stack that assumes /usr was already there in early boot. And this is also documented in detail here: http://freedesktop.org/wiki/Software/systemd/separate-usr... -- there's also a non-comprehensive list of packages that are broken in this regard.
Not really: that page convinces the reader that there are attempted accesses to /usr before /usr gets mounted, but doesn't identify any actual brokenness beyond saying that the listed packages “[cannot] provide the full set of functionality” — which for all the reader knows might just mean e.g. that the relevant functionality isn't available until /usr is mounted (as I'd guess is the case for the locale example).
In LWN comments (but not in the above-referenced wiki page), someone was more specific and suggested that some USB network or audio devices won't be accessible with separate /usr unless they've been plugged in since /usr was mounted. Even if this example were added to the page, it's not very convincing if the only example offered is specific to (what the reader might consider or guess to be) rare hardware: the reader almost certainly has USB hardware that seems to work fine when /usr is a separate partition, so it might not even be that all USB audio or network devices fail to work.
For the reader who has a separate /usr partition and hasn't noticed the associated brokenness, the page isn't very convincing that separate /usr is broken, or that the brokenness of a separate /usr (that even that page describes as mostly “graceful failures” that “won't become directly visible”) outweighs the rationale traditionally given for separate /usr such as filesystem reliability (“all eggs in one basket” principle) or sharability.
(Log in to post comments)
separate /usr, advantages & disadvantages Posted Nov 27, 2012 9:44 UTC (Tue) by Jonno (subscriber, #49613) [Link]
> outweighs the rationale traditionally given for separate /usr such as filesystem reliability (“all eggs in one basket” principle) or sharability.
The nice thing is that you can both eat the cake and have it too, as /usr on a separate filesystem *is* still supported, *provided* you mount it in your initramfs.
That way you get *all* the benefits of a separate /usr partition, without *any* of it's drawbacks, at the small cost of maintaining an initramfs (which your distro tools will likely do for you).
separate /usr, advantages & disadvantages Posted Nov 27, 2012 12:36 UTC (Tue) by pjm (subscriber, #2080) [Link]
Thank you, that's an important omission from that last paragraph. However, the corrected paragraph would still make a similar point given that some people (especially Gentoo users and people who might be attracted to systemd for speed reasons) do prefer not to add an initramfs.
What's initramfs do now? Posted Dec 4, 2012 16:38 UTC (Tue) by alex (subscriber, #1355) [Link]
As I understood it initramfs was a place to store kernel modules that may be needed to mount the rootfs. However there seems to be early init involved these days?
Personally I build my kernel with all the bits it needs to mount rootfs from the start so I'm not sure why I would want or need an initramfs?
What's initramfs do now? Posted Dec 5, 2012 0:28 UTC (Wed) by nix (subscriber, #2304) [Link]
The initramfs is just a cpio archive unpacked into the rootfs (the filesystem / is mounted on top of) and optionally linked into the kernel image. It contains /init, which the kernel runs as PID 1 and which generally finds and overmounts the real root (deleting the contents of the rootfs at the same time, as they are nonswappable and memory is not free) and execs /sbin/init from there. But it doesn't have to do that. It can load modules, it can run udev, it can probe for md or LVM or distributed filesystems or fsck the real / before mounting it rather than doing that gross readonly fsck hack, or do whatever the heck it wants. In particular it can mount *more than one* filesystem. (Heck, mine mounts three and does several bind-mounts as well.)
I've seen initramfses that never exec any real init at all, but run all of userspace from the initramfs (generally a fairly small userspace). I've even seen initramfses that compiled appropriate modules from source and then modprobed them, to make sure they never got out of synch with the running kernel.
initramfses are really powerful. I don't know why people have such a resistance to them. Sure, they're tricky -- the need to wipe the rootfs while overmounting the real /, and the tendency to use a non-glibc libc, makes sure of that -- but they're not actually *scary*. And they're certainly not ugly. They add enormous flexibility to a part of the boot process that used to be completely nonswappable, and particularly if you link the initramfs into the kernel image they can add a lot of robustness, giving you a single kernel image with rescue, recovery, and root-filesystem-finding tools built in and inseparable no matter what weird breakage you do to your filesytem. And they do this without necessarily adding much complexity: my /init is only 172 lines of rarely-changing shell but gives me a rescue shell and md, LVM and NBD booting for all of that.
It's true that dracut is complicated, but it's generic -- complexity is in the nature of a generic solution in a problem space as intricate as this (there are endless ways to find the root filesystem and dracut has to handle all of them). Special-purpose initramfses, or initramfses built for your own use, don't actually need to be complicated or brittle.
What's initramfs do now? Posted Dec 5, 2012 17:03 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> initramfses are really powerful. I don't know why people have such a resistance to them.
you answer this question in the next sentence
> Sure, they're tricky
They are powerful, but if you don't need that power, why pay with the complexity?
This 'extra' copy of things gives you one more place that software can get out of sync (a different version of software on the initramfs than on your main system for example
simple is better, if you don't need a layer of complexity for your systems, it's good to not have it
What's initramfs do now? Posted Dec 5, 2012 17:11 UTC (Wed) by alex (subscriber, #1355) [Link]
Exactly, currently my kernel install is:
make modules_install
Why would I want more complexity to test new kernels?
What's initramfs do now? Posted Dec 5, 2012 20:53 UTC (Wed) by nix (subscriber, #2304) [Link]
Currently my kernel install is
make install modules_install
which I think beats yours by one line. :)
(Yet again: initramfses *do not* need to be installed in separate files -- distros just do that because it makes it easier to ship prepackaged kernels. If you link them into the kernel image, they don't make it harder to test kernels at all: the installed kernel is exactly one file, just as before. A bloody good thing too given the amount of bisection I seem to have been doing recently...)
What's initramfs do now? Posted Dec 5, 2012 21:14 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
but his approach is trivial to put the kernel on a different machine, yours is not.
What's initramfs do now? Posted Dec 5, 2012 22:17 UTC (Wed) by nix (subscriber, #2304) [Link]
Uh? You put the kernel on a different machine by... copying one file (and copying the modules tree if need be). How is that hard?
What's initramfs do now? Posted Dec 5, 2012 23:02 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
plus the system specific initramfs config (raid config, etc)....
What's initramfs do now? Posted Dec 8, 2012 19:10 UTC (Sat) by nix (subscriber, #2304) [Link]
If you need that sort of system-specific config baked into the initramfs, you are doing something wrong. Both mdadm and LVM can scan for things to mount: you should be relying on that, and using config files at most as defaults overrideable on the kernel command line. (A few lines of shell while loop to parse the command line and bingo.)
What's initramfs do now? Posted Dec 5, 2012 20:51 UTC (Wed) by nix (subscriber, #2304) [Link]
Err... the software can't get out of sync because initramfses are built at kernel build time from the software *already on* your system. (Normally. Obviously you can choose to do something else, but that would be strange.)
It lets you customize things that are otherwise uncustomizable -- personally I consider this a good thing. Obviously it's not essential, but it's not some monstrous terrible hugely complex destabilizing thing either. The smallest possible /init is probably less than ten lines of shell script, and most of that is getting a useful /dev to do a mount from.
What's initramfs do now? Posted Dec 5, 2012 22:01 UTC (Wed) by jimparis (subscriber, #38647) [Link]
> Err... the software can't get out of sync because initramfses are built at kernel build time from the software *already on* your system.
How does that keep things in sync? When you update the software on your system, you need to remember to rebuild the initramfs too. Likewise with changing any configuration files that are found in both, like /etc/mdadm/mdadm.conf. I've been bitten by forgetting to run "update-initramfs -u" after changing that file.
What's initramfs do now? Posted Dec 5, 2012 22:19 UTC (Wed) by nix (subscriber, #2304) [Link]
Oh, yeah, sure, if you have config files in an initramfs linked into the kernel, and they change, you're stuffed. I just never ever do that: the only config files in my initramfs are /etc/fstab and /etc/mdadm.conf, and they're just there to default values for the array to activate and root filesystem to mount: a few lines of shell and bingo they're overrideable from the kernel command line. That sort of thing changes much less often than the kernel itself, though, so I consider a linked-in initramfs still preferable because it lets you bisect, test kernels and the like, which is one thing a standalone initramfs or initrd *does* make harder.
separate /usr, advantages & disadvantages Posted Nov 27, 2012 14:54 UTC (Tue) by raven667 (subscriber, #5198) [Link]
I find the argument convincing but maybe I am looking at things a different way. The point as I see it is that booting with a late mounted /usr is not perfect and does not work perfectly in all cases. I think the developers are perfectionists and are deeply unhappy with caveats or corner cases or less than 100% reliability.
|
|||||||||||||