1 |
On Sat, May 4, 2013 at 12:42 PM, Luca Barbato <lu_zero@g.o> wrote: |
2 |
> On 05/01/2013 12:04 PM, Fabio Erculiani wrote: |
3 |
>> PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. |
4 |
>> THIS IS NOT A POST AGAINST OPENRC. |
5 |
> |
6 |
> Amen |
7 |
> |
8 |
>> With the release of Sabayon 13.04 [1] and thanks to the efforts I put |
9 |
>> into the systemd-love overlay [2], systemd has become much more |
10 |
>> accessible and easy to migrate to/from openrc. Both are able to |
11 |
>> happily coexist and logind/consolekit detection is now done at |
12 |
>> runtime. |
13 |
>> It is sad to say that the "territoriality" in base-system (and |
14 |
>> toolchain) is not allowing any kind of progress [3] [4]. This is |
15 |
>> nothing new, by the way. |
16 |
>> |
17 |
>> There are several components that need patching in order to work as |
18 |
>> expected with systemd: |
19 |
>> - polkit needs a patch that enables runtime detection of logind/consolekit |
20 |
>> - pambase needs to drop USE=systemd and always enable the optional |
21 |
>> module pam_systemd.so |
22 |
>> - genkernel needs to migrate to *udev (or as I did, provide a --udev |
23 |
>> genkernel option), mdev is unable to properly activate LVM volumes and |
24 |
>> LVM is actually working by miracle with openrc. Alternatively, we |
25 |
>> should migrate to dracut. |
26 |
> |
27 |
> [unrelated] Do you have more insights about this part? mdev MUST work, |
28 |
> lots of thin recovery options are based on busybox. |
29 |
|
30 |
Scenario: |
31 |
- you have an initramfs with mdev, your pivot_chroot system runs udev. |
32 |
- you have a LVM volume group, containing the lvm volume for / and |
33 |
/home, and perhaps you also have swap on another volume. |
34 |
- you boot using the current genkernel initramfs, which uses mdev and |
35 |
comes with lvm support |
36 |
|
37 |
The initramfs code activates your lvm volumes, lvm itself may or not |
38 |
may be compiled with udev support. In the former case, nothing gets |
39 |
written onto /run/udev (and devtmpfs), in the latter case, lvm writes |
40 |
metadata that are useful to lvm itself to udev. |
41 |
mdev is not udev, doesn't deal with udev rules so the metadata is |
42 |
either pristine or completely unavailable. |
43 |
busybox switches root and the boot starts: you obviously have lvm |
44 |
compiled with udev there, since you're using udev (or systemd-udevd, |
45 |
or gudev). The lvm there is either unable to find valid metadata so it |
46 |
doesn't automatically activate the volumes (note: /home does not get |
47 |
activated by the initramfs code) or, until some time ago but now |
48 |
defaulted to off, lvm itself creates the device nodes (which should |
49 |
have been created by udev + udev rules if lvm is compiled with udev |
50 |
support). |
51 |
If it's not enough, our current genkernel initramfs code (I fixed this |
52 |
as well, it's in the systemd-love overlay) doesn't mount --move /run |
53 |
to /newroot before switching root, so /run/udev is not ported over, |
54 |
which means that even if mdev would have been able to do do all the |
55 |
udev magic, things wouldn't work anyway. |
56 |
|
57 |
Long story short, we should: |
58 |
1) give up with cross compiler support in genkernel, which has been |
59 |
anyway in a broken state for ages. Nobody is using it anyway. |
60 |
2) make possible to optionally use udev in the initramfs (compiling |
61 |
just for it is a pita and the trend here [dracut and others do this] |
62 |
is to copy udevd from the system) |
63 |
3) default to udev? |
64 |
|
65 |
> |
66 |
>> - networkmanager need not to install/remove files depending on |
67 |
>> USE=systemd but rather detect systemd at runtime, which is a 3 lines |
68 |
>> script. |
69 |
> |
70 |
> Sounds sensible. |
71 |
|
72 |
Also, I forgot that I wrote a NetworkManager patch that makes it able |
73 |
to detect logind/consolekit at runtime. It works and is in the |
74 |
systemd-love overlay (it's a git format-patch patch). |
75 |
|
76 |
> |
77 |
>> - openrc-settingsd needs to support eselect-settingsd, which makes |
78 |
>> possible to switch the settingsd implementation at runtime, between |
79 |
>> openrc and systemd. This also removes the silly conflict between |
80 |
>> openrc-settingsd and systemd friends. |
81 |
> |
82 |
> Would make sense merge init and settingsd in a single eselect or at |
83 |
> least make so switching init would warn if the settingsd doesn't match? |
84 |
|
85 |
They are really two separate things, even though I agree that it |
86 |
should be made even easier. I don't think it's hard though. |
87 |
|
88 |
> |
89 |
>> - genkernel should at least support plymouth (work in progress my side) |
90 |
> |
91 |
> Looking forward to it. |
92 |
|
93 |
I should have something ready soon. |
94 |
|
95 |
> |
96 |
>> - other ~490 systemd units are missing at this time and writing them |
97 |
>> could also be a great GSoC project (don't look at me, I'm busy |
98 |
>> enough). |
99 |
> |
100 |
> Hopefully we might have a gsoc student volunteering to make a |
101 |
> runscript/lsb-script/systemd-unit compiler and a small abstraction so we |
102 |
> write a single init.d script and generate what's needed. |
103 |
> Probably we might even support pure-runit that way with minimal effort. |
104 |
> |
105 |
>> It looks like there is some consensus on the effort of making systemd |
106 |
>> more accessible, while there are problems with submitting bugs about |
107 |
>> new systemd units of the sort that maintainers just_dont_answer(tm). |
108 |
>> In this case, I am just giving 3 weeks grace period for maintainers to |
109 |
>> answer and then I usually go ahead adding units (I'm in systemd@ after |
110 |
>> all). |
111 |
> |
112 |
> See above. |
113 |
> |
114 |
>> The only remaining problem is about eselect-sysvinit, for this reason, |
115 |
>> I am probably going to create a new separate pkg called |
116 |
>> _sysvinit-next_, that contains all the fun stuff many developers were |
117 |
>> not allowed to commit (besides my needs, there is also the need of |
118 |
>> splitting sysvinit due to the issues reported in [4]). I am sure that |
119 |
>> a masked alternative sysvinit ebuild won't hurt anybody and will make |
120 |
>> Gentoo a bit more fun to use. |
121 |
> |
122 |
> Exactly, which is the problem at hand? I'd like to be able to safely |
123 |
> switch back and forth sysvinit and bb-init as well. |
124 |
|
125 |
That's the only way to do it reliably and programmatically. Can you |
126 |
imagine having to parse grub.cfg, lilo conf and only god knows what |
127 |
else...? |
128 |
|
129 |
> |
130 |
>> The final outcome will hopefully be: |
131 |
>> - easier to migrate from/to systemd, at runtime, with NO recompilation |
132 |
>> at all (just enable USE=systemd and switch the device manager from |
133 |
>> *udev to systemd -- unless somebody wants to drop the udev part from |
134 |
>> systemd, if at all possible) |
135 |
>> - we give the users the right to choose without driving them nuts with |
136 |
>> weird emerge-fu. |
137 |
>> - we make possible to support new init systems in future, and even |
138 |
>> specific init wrappers (bootchart anyone?) |
139 |
> |
140 |
> Here! o/ Currently in my list are |
141 |
> |
142 |
> - bootchart2 (as an add-on to the other init systems) |
143 |
> - bb-init (requires different custom inittab) |
144 |
> - runit (openrc can use it instead thanks to benda xu past GSoC) |
145 |
> |
146 |
>> - we prepare the path towards a painless migration from consolekit |
147 |
>> (deprecated for long time now) to logind (we probably need to fork it |
148 |
>> off the systemd pkg -- upstream projects are _dropping_ consolekit |
149 |
>> support right now!) |
150 |
> |
151 |
> Again it is something I consider an option for a GSoC project, we have |
152 |
> already some openrc variant for other systemd-originated daemons in our |
153 |
> git. |
154 |
> |
155 |
>> - we put back some fun into Gentoo |
156 |
> |
157 |
> That's always good. |
158 |
> |
159 |
>> If you want to see a working implementation of my systemd-love |
160 |
>> efforts, just go download [1] and see things working yourself. |
161 |
> |
162 |
> Thank you a lot for your positive attitude and the huge effort =) |
163 |
> |
164 |
> lu |
165 |
> |
166 |
> |
167 |
|
168 |
|
169 |
|
170 |
-- |
171 |
Fabio Erculiani |