| Summary: | dev-util/catalyst: contains hardcoded emerge sys-kernel/genkernel which is not compatible with systemd | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andrii Pravorskyi <pravorskyi> |
| Component: | Current packages | Assignee: | Gentoo Catalyst Developers <catalyst> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | genkernel, jstein, livecd, systemd, tsmksubc |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=468942 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 479730 | ||
| Bug Blocks: | |||
|
Description
Andrii Pravorskyi
2017-06-04 19:55:45 UTC
genkernel works fine with systemd. Why do you think that is not the case? (In reply to Robin Johnson from comment #1) > genkernel works fine with systemd. Why do you think that is not the case? Because sys-kernel/genkernel is masked in default/linux/amd64/13.0/systemd profile: cat /usr/portage/profiles/targets/systemd/package.mask ... # sys-kernel/genkernel is not compatible with Systemd, you need # to use sys-kernel/genkernel-next instead sys-kernel/genkernel Searching for "genkernel systemd" in bugzilla doesn't turn up anything. I propose we drop that mask since no actionable justification was provided. I agree... I think it was related with something about mdev usage inside genkernel... but I don't remember :S https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6eca5192b774c452b06dbce12f897a7c0470416e commit 6eca5192b774c452b06dbce12f897a7c0470416e Author: Mike Gilbert <floppym@gentoo.org> Date: Wed Jun 7 11:56:46 2017 -0400 profiles: drop genkernel mask from systemd profile There are no obvious bug reports that would warrant a global mask, and its presence is causing new genkernel bugs to go unreported. profiles/targets/systemd/package.mask | 4 ---- 1 file changed, 4 deletions(-) Sorry for reopening but I have just found why this probably was included in the past... could genkernel team tell me how to adapt documentation for the *current* genkernel version? https://wiki.gentoo.org/wiki/Systemd#Ensure_.2Fusr_is_present_at_boot_time -> This is about how to handle splitted /usr... do we need to do something for genkernel now? https://wiki.gentoo.org/wiki/Systemd#Using_LVM_and_initramfs -> The same for lvm2... both cases look to involve this udev vs mdev issue... but I don't know much about that :/ Thanks a lot :) (In reply to Pacho Ramos from comment #6) > Sorry for reopening but I have just found why this probably was included in > the past... could genkernel team tell me how to adapt documentation for the > *current* genkernel version? > https://wiki.gentoo.org/wiki/Systemd#Ensure_.2Fusr_is_present_at_boot_time > -> This is about how to handle splitted /usr... do we need to do something > for genkernel now? You don't need to do ANYTHING other than run a genkernel of at least v3.4.21.2 (released in 2012!). It will check for $ROOTFS/etc/initramfs.mounts, which ships with a DEFAULT of specifying that /usr should be mounted. Here's how long that support has been present: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/genkernel/files/initramfs.mounts?revision=1.1&view=markup If the file does NOT exist, it defaults to containing just /usr. If it exists, but does NOT contain /usr, then your systemd will break, but you changed it away from the defaults and you get to keep the pieces. > https://wiki.gentoo.org/wiki/Systemd#Using_LVM_and_initramfs -> The same for > lvm2... both cases look to involve this udev vs mdev issue... but I don't > know much about that :/ lvmetad: We don't ship lvmetad in genkernel presently, because we offer quite an old version of LVM. I'd be very concerned about starting an embedded copy of lvmetad without knowing how it was going to be replaced by the rootfs copy later (and making sure it DID take place, so that the initramfs could be freed). mdev vs udev: again. genkernel ships mdev instead of udev, and the rootfs udev is what should be started later. It seems it was this old bug the one causing this issues -> bug 479730 If it's solved, we could close it finally (In reply to Robin Johnson from comment #7) > [...] > > https://wiki.gentoo.org/wiki/Systemd#Using_LVM_and_initramfs -> The same for > > lvm2... both cases look to involve this udev vs mdev issue... but I don't > > know much about that :/ > lvmetad: > We don't ship lvmetad in genkernel presently, because we offer quite an old > version of LVM. I'd be very concerned about starting an embedded copy of > lvmetad without knowing how it was going to be replaced by the rootfs copy > later (and making sure it DID take place, so that the initramfs could be > freed). > > mdev vs udev: > again. genkernel ships mdev instead of udev, and the rootfs udev is what > should be started later. I tried the most recent genkernel (3.5.1.0) last week with a raid + dm-crypt + LVM setup booting systemd (no separate /usr-partition) and documented the results in a comment on this bug report: https://bugs.gentoo.org/show_bug.cgi?id=468942#c21 Result was, that though system was able to boot with systemd/udev, systemd units were hanging (waiting for... and xx secs / 1 min 30) when trying to bring up the (remaining) LVM volumes. Probably the handover of LVM volumes from mdev to systemd/udev fails somehow? As stated there, I would be more than happy to help debug this (am away frow Wed through Sun this week, though). Do we have any progress? >=sys-kernel/genkernel-4.0.0_beta3 contains fix for bug 479730.
Whissi says this is fixed. |
