On Sat, May 4, 2013 at 12:42 PM, Luca Barbato <lu_z...@gentoo.org> wrote: > On 05/01/2013 12:04 PM, Fabio Erculiani wrote: >> PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. >> THIS IS NOT A POST AGAINST OPENRC. > > Amen > >> With the release of Sabayon 13.04 [1] and thanks to the efforts I put >> into the systemd-love overlay [2], systemd has become much more >> accessible and easy to migrate to/from openrc. Both are able to >> happily coexist and logind/consolekit detection is now done at >> runtime. >> It is sad to say that the "territoriality" in base-system (and >> toolchain) is not allowing any kind of progress [3] [4]. This is >> nothing new, by the way. >> >> There are several components that need patching in order to work as >> expected with systemd: >> - polkit needs a patch that enables runtime detection of logind/consolekit >> - pambase needs to drop USE=systemd and always enable the optional >> module pam_systemd.so >> - genkernel needs to migrate to *udev (or as I did, provide a --udev >> genkernel option), mdev is unable to properly activate LVM volumes and >> LVM is actually working by miracle with openrc. Alternatively, we >> should migrate to dracut. > > [unrelated] Do you have more insights about this part? mdev MUST work, > lots of thin recovery options are based on busybox.
Scenario: - you have an initramfs with mdev, your pivot_chroot system runs udev. - you have a LVM volume group, containing the lvm volume for / and /home, and perhaps you also have swap on another volume. - you boot using the current genkernel initramfs, which uses mdev and comes with lvm support The initramfs code activates your lvm volumes, lvm itself may or not may be compiled with udev support. In the former case, nothing gets written onto /run/udev (and devtmpfs), in the latter case, lvm writes metadata that are useful to lvm itself to udev. mdev is not udev, doesn't deal with udev rules so the metadata is either pristine or completely unavailable. busybox switches root and the boot starts: you obviously have lvm compiled with udev there, since you're using udev (or systemd-udevd, or gudev). The lvm there is either unable to find valid metadata so it doesn't automatically activate the volumes (note: /home does not get activated by the initramfs code) or, until some time ago but now defaulted to off, lvm itself creates the device nodes (which should have been created by udev + udev rules if lvm is compiled with udev support). If it's not enough, our current genkernel initramfs code (I fixed this as well, it's in the systemd-love overlay) doesn't mount --move /run to /newroot before switching root, so /run/udev is not ported over, which means that even if mdev would have been able to do do all the udev magic, things wouldn't work anyway. Long story short, we should: 1) give up with cross compiler support in genkernel, which has been anyway in a broken state for ages. Nobody is using it anyway. 2) make possible to optionally use udev in the initramfs (compiling just for it is a pita and the trend here [dracut and others do this] is to copy udevd from the system) 3) default to udev? > >> - networkmanager need not to install/remove files depending on >> USE=systemd but rather detect systemd at runtime, which is a 3 lines >> script. > > Sounds sensible. Also, I forgot that I wrote a NetworkManager patch that makes it able to detect logind/consolekit at runtime. It works and is in the systemd-love overlay (it's a git format-patch patch). > >> - openrc-settingsd needs to support eselect-settingsd, which makes >> possible to switch the settingsd implementation at runtime, between >> openrc and systemd. This also removes the silly conflict between >> openrc-settingsd and systemd friends. > > Would make sense merge init and settingsd in a single eselect or at > least make so switching init would warn if the settingsd doesn't match? They are really two separate things, even though I agree that it should be made even easier. I don't think it's hard though. > >> - genkernel should at least support plymouth (work in progress my side) > > Looking forward to it. I should have something ready soon. > >> - other ~490 systemd units are missing at this time and writing them >> could also be a great GSoC project (don't look at me, I'm busy >> enough). > > Hopefully we might have a gsoc student volunteering to make a > runscript/lsb-script/systemd-unit compiler and a small abstraction so we > write a single init.d script and generate what's needed. > Probably we might even support pure-runit that way with minimal effort. > >> It looks like there is some consensus on the effort of making systemd >> more accessible, while there are problems with submitting bugs about >> new systemd units of the sort that maintainers just_dont_answer(tm). >> In this case, I am just giving 3 weeks grace period for maintainers to >> answer and then I usually go ahead adding units (I'm in systemd@ after >> all). > > See above. > >> The only remaining problem is about eselect-sysvinit, for this reason, >> I am probably going to create a new separate pkg called >> _sysvinit-next_, that contains all the fun stuff many developers were >> not allowed to commit (besides my needs, there is also the need of >> splitting sysvinit due to the issues reported in [4]). I am sure that >> a masked alternative sysvinit ebuild won't hurt anybody and will make >> Gentoo a bit more fun to use. > > Exactly, which is the problem at hand? I'd like to be able to safely > switch back and forth sysvinit and bb-init as well. That's the only way to do it reliably and programmatically. Can you imagine having to parse grub.cfg, lilo conf and only god knows what else...? > >> The final outcome will hopefully be: >> - easier to migrate from/to systemd, at runtime, with NO recompilation >> at all (just enable USE=systemd and switch the device manager from >> *udev to systemd -- unless somebody wants to drop the udev part from >> systemd, if at all possible) >> - we give the users the right to choose without driving them nuts with >> weird emerge-fu. >> - we make possible to support new init systems in future, and even >> specific init wrappers (bootchart anyone?) > > Here! o/ Currently in my list are > > - bootchart2 (as an add-on to the other init systems) > - bb-init (requires different custom inittab) > - runit (openrc can use it instead thanks to benda xu past GSoC) > >> - we prepare the path towards a painless migration from consolekit >> (deprecated for long time now) to logind (we probably need to fork it >> off the systemd pkg -- upstream projects are _dropping_ consolekit >> support right now!) > > Again it is something I consider an option for a GSoC project, we have > already some openrc variant for other systemd-originated daemons in our > git. > >> - we put back some fun into Gentoo > > That's always good. > >> If you want to see a working implementation of my systemd-love >> efforts, just go download [1] and see things working yourself. > > Thank you a lot for your positive attitude and the huge effort =) > > lu > > -- Fabio Erculiani
