On Thu, 08 Sep 2011 04:19:32 -0400 Joshua Kinard <ku...@gentoo.org> wrote:
> 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. I'd rather say we should do the work on real issues rather than imaginate 'separate /usr' problem. Honestly, most of 'advantages' of separate /usr are just hacks avoiding other problems. For example, read-only /usr is just a hack to avoid moving runtime writable files out of /etc. > > 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. And what is the bug exactly? 'My software requires yours, and yours is installed in /usr by me'? > > 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. And it will be. The point is that is either you want to have separate /usr, or tiny system. > 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. Remember Windows 9x? They didn't want to rubber stamp something as fundamental as DOS. > > 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. Yeah, we are not a pack of lemmings. And we should be able to decide when reinventing the wheel is actually necessary, and when it's just a waste of time. As mentioned before, keeping /usr separate provides no real security. It's just pretending things are better, and I see no reason to lie to users like that. > 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. Nope, it doesn't. PGP/MIME is much better than that ugly inlined stuff. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
