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