On 09/07/2011 20:35, Rich Freeman wrote: > On Wed, Sep 7, 2011 at 5:31 PM, Joshua Kinard <ku...@gentoo.org> wrote: > >> Never once have I had any issues >> with separate / and /usr, and none of them use an initramfs. > > > Ditto here, but that doesn't mean that problems don't exist. Right now the > problems are likely to be subtle, perhaps arising only with certain > combinations of hardware/etc. Maybe if you had a bluetooth keyboard or > something it might not work, or maybe if /usr were mounted on a bluetooth > hard drive or something (do they even make those?).
We should document these oddball hardware cases when they arise, but I would wager that they are exceptions, not rules. We shouldn't upend an established concept (splitting /usr off) for what may possibly be curious corner cases of hardware combos. My general knowledge of Linux always indicated /usr was entirely optional, from the standpoint of reaching an operable console, I.e., single-user mode. Granted, you can't do much on a setup where /usr is on its own partition, yet inaccessible due to some issue, but if lack of /usr doesn't hinder recovery efforts (those needed to make the system capable of mounting /usr), then things are okay. If we need to look at moving additional tools or daemons into /bin or /sbin to help with these cases, that's worth looking at, too. Especially for things like wireless devices. > However, long-term it seems likely that the problems will continue to grow, > as more and more upstream packages move away from supporting a /usr that > isn't available at boot. Packages that do this need to have bugs filed against them and patches need to be sent back upstream. > Well, the kernel comes with code for making an initramfs, but most likely it > would be implemented in a separate package. The initramfs isn't part of the > kernel - it is loaded by grub at boot time and its address is passed to the > kernel. So, the file needs to be on /boot. Yes, very much aware about initramfs and all the fun it involves. I've always noticed a majority of distros, to keep their boot kernels small, package non-critical modules in an initramfs that is stored in /boot. Thing is, that has always been optional, too. It should be entirely possible for me to build and boot a modular or monolithic kernel that needs nothing else to reach a usable userland shell. The fun bit about Linux/UNIX, is there are way more than 9 ways to skin a cat here. So we need to make sure that all other options to solving issues that arise when /usr is separate are looked at and all solutions considered before rubber stamping something as fundamental a change as no longer supporting separate /usr, forcing initramfs images, or crazier things. > I think that pxelinux supports initramfs - I know it supports initrd at > least and I don't think it makes any difference at the bootloader level. In > fact, things like network booting are one of the drivers behind the Fedora > project to have dracut mount /usr. Their plan is to just move everything > into /usr, allow it to be NFS-mounted, and then with one mountpoint > everything the system needs is available. Eventually in Fedora /lib and > /bin will just be symlinks into /usr. That will work fine as long as dracut > mounts /usr. Wrong arch :) SGI systems had netboot capabilities from Day 1, 1994 (and probably earlier). A LOT of non-x86 archs have had netboot support of some kind as a native feature of the hardware. X86/x64 stuff has usually been the red-headed stepchild of the bunch by either excluding it in the past, or requiring you to buy special PROM chips for your NIC. It's only been fairly recently (in terms of the last 6-8 years or so) that PXE boot has become a standard feature of generic/consumer x86/x64 hardware. > Well, it certainly could be done, but it doesn't seem to be the direction > anybody else is going. Instead the plan is to just create a very minimal > initramfs that gets the job done. Using it would just be a matter of > installing the file and editing the boot line to load it. Or, you can use > something like dracut or genkernel and get a more robust one. Whoever said we had to do what everyone else did? We're Gentoo, not a pack of lemmings. If we have to, we should be able to create an entirely new solution, never thought of before, that fixes the problem for all parties involved, yet allows us to keep the bit in our security guide about keeping /usr (and other partitions) separate. PS, yell if using PGP/MIME messes this message up. Thunderbird + Enigmail apparently is very unfriendly to inlined PGP for some odd reason. The two fight over the bloody line-wrapping mechanics. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
signature.asc
Description: OpenPGP digital signature
