On Mon, Nov 19, 2012 at 5:07 AM, Steven J. Long <sl...@rathaus.eclipse.co.uk> wrote: > On Sun, Nov 18, 2012 at 05:16:18PM +0200, Samuli Suominen wrote: >> I'm still happy enough with building udev out from systemd tree and >> letting sep. /usr consept from 90s to finally die in favour of >> simplifying the system. > > It's from a lot earlier than the 90s. Perhaps we should get rid of pipes, > too- they're /so/ 1970s. > > Torvalds expressed it well[1]: > You made the statement that you want to get away from 30 years of > history, but the fact is, "30 years of history" is a damn good argument > for "that thing worked". > >> The BIOSes have been upgraded last century to support booting from >> larger partitions, the need has long past. >> Nobody has ever provided a valid reason for using sep. /usr in the ML >> either. >> > So at the same time as you have never heard a valid reason, the need (which > you have never understood) is long past? Pfft. > > To reiterate again: many of us are used to keeping /usr on a separate > partition for security and backup purposes (other use-cases for a separate > partition include mounting /usr over NFS, or a common partition for > virtual machines.) I'm sure other people would have more. Irrespective, > it should be about mechanism, not policy, and certainly not about breaking > existing setups. > > Many of the advertised benefits of the "merge /bin and /sbin to /usr" > concept are in fact just benefits of having a separate /usr partition, > though of course they're presented as new and unique to the merge. So, if > you accept those as benefits, you cannot logically deny them as benefits of > a traditional /usr split. > > Further, as one user pointed out[2]: > "I'd be more likely to just stick /usr back on / than create an initramfs > - it was only because the LVM guide recommended that /usr go on its own > partition that I now face this situation." > > We were given a simple requirement ages ago: udev requires /usr and > /var (and going forward may require /opt for 3rd party drivers) mounted > before it starts, not for udev itself but for helper scripts that it may > call. Why get bogged down in anything else? > > The recommended (which became "supported") method to do this was > to use an initramfs, since apparently any chicken-and-egg problems (such > as requiring a udev-initiated device to mount /usr) are easier to handle > there. (Note that no-one has ever provided a description of how they did > that, eg for their bluetooth keyboard, so that the issues, and how they > are addressed, could be made more transparent to everyone.) > > A few us are happily running initramfs-less machines by fulfilling the > requirement with a couple of patches to openrc initscripts[2]. (It's > been working fine here since last August.) This works in the case where > you didn't need an initramfs before, ie have modules for local-disks and > filesystems built-in, root not on LVM or encrypted, but other partitions > might be-- which includes LVM users who followed the Gentoo docs. > > If that's not enough, there is *already* a forked udev version which quite > a few users have been using[3] and reporting success with. I'd hope the > new fork would just collaborate with them, but it's entirely up to them > what they do. > > All of this argues that, irrespective of your views of the layouts admins > prefer to use, they will still use them regardless, and indeed users will > put in the work you yourself told them to.[4] I really don't understand > why people are getting beat up on, just for going ahead and doing what > they've been told to: provide code for an alternative. > > If a Gentoo developer doesn't understand what a Gentoo project means, > that's his problem. Nor should Gentoo projects suddenly change what they > are because "the internet" doesn't understand them. That's a ridiculous > basis for any change. > > The thing none of the proponents of an initramfs, with no other support > for a separate /usr (apart from busybox sep /usr which does NOT fulfil the > requirements presented by Chainsaw, which Council voted to approve before: > for a start it doesn't handle /usr on LVM), have ever answered is: > > How do you deal with the mismatch problem? > > That is, when you have programs or libs upgraded, just as part of normal > system upgrades, and they are now different, potentially incompatible, to > the initramfs. (The potential exists, therefore it must be addressed for > a solution even to be considered as robust.) > > Do you now need another script to run after every emerge to check that > files in your initramfs are in sync? After all, we've been told the > initramfs is "the new root": iow that we should think of it as our rescue > system, so this matters.
Debian / Ubuntu have a tool that basically does this. Its update-initramfs. I believe it is called from..the postinst of packages that are supposed to be in the initramfs? honestly I'd have to look up how they implemented it. -A > > At the same time, we've been told "it's only a few hundred kilobytes at > most." That contradiction has never been answered, either. > > [1] http://lwn.net/Articles/492134/ > [2] http://forums.gentoo.org/viewtopic-t-901206.html > [3] http://forums.gentoo.org/viewtopic-t-934678.html > [4] http://forums.gentoo.org/viewtopic-p-6987380.html#6987380 > -- > #friendly-coders -- We're friendly, but we're not /that/ friendly ;-) >
