1 |
On Sun, Jan 01, 2012 at 09:23:11AM +0000, Duncan wrote: |
2 |
> Gentoo has historically been both "light patch", with a policy of staying |
3 |
> close to upstream if possible, and "customizer's choice", allowing users |
4 |
> far more flexibility than most distros. Keeping both goals in mind, |
5 |
> migrating with upstream is ultimately the only viable alternative for a |
6 |
> whole host of reasons including both staying close to upstream and simple |
7 |
> manpower resource issues. |
8 |
|
9 |
> That said, we can continue to try to support a separate /usr as long as |
10 |
> possible, while switching new installs to the new way and changing the |
11 |
> handbook to document it, preferably as soon as possible. |
12 |
|
13 |
In this situation, I don't know how we will be able to support both |
14 |
ways because there is more involved than just where things are |
15 |
installed. |
16 |
|
17 |
Udev 175 is currently masked, because the way it operates has changed |
18 |
enough that it doesn't work correctly if it starts before /usr is |
19 |
mounted, and the failures you find will be very difficult to track down. |
20 |
So, udev isn't only changing where it is installed, but how it runs. |
21 |
|
22 |
Supporting a separate /usr without an initramfs will require one of two |
23 |
things. |
24 |
|
25 |
One possibility is a customization to openrc, which we have been |
26 |
looking at, that would be able to run fsck on /usr and mount /usr all |
27 |
before udev starts. The drawback here is this will only work for openrc |
28 |
users. |
29 |
|
30 |
Another possibility is a script that would run as the init= parameter to |
31 |
the kernel, which would fsck /usr and mount /usr then start the real |
32 |
init process. This would be more generic and would be able to run |
33 |
regardless of whether you are using sysvinit/openrc. |
34 |
|
35 |
Here is the big problem with both of these solutions as I see them. They |
36 |
depend on several pieces of software remaining on the root filesystem, |
37 |
and if/when this software is migrated, we will be back to having this discussion |
38 |
again. |
39 |
|
40 |
> Further, as |
41 |
> previously discussed, a near-static bare-minimal initramfs that can be |
42 |
> configured and forgotten about for long periods over many kernel upgrades |
43 |
> should make the switch as painless as possible at least for "simple" bare- |
44 |
> partition installations. |
45 |
|
46 |
I want to look at dracut and see if there is a way to configure it to |
47 |
create a minimal initramfs like you are suggesting, because, if there is |
48 |
we don't need to re-invent the wheel. |
49 |
|
50 |
I don't think your portage feature/use flag suggestion is a good idea, |
51 |
because, right now most of this is about where things are installed, |
52 |
but, eventually we might have to start actually patching software to |
53 |
make it work if it is installed on / instead of /usr, and there is no |
54 |
way to know how much patching we would have to do. |
55 |
|
56 |
What are your thoughts? |
57 |
|
58 |
William |