Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 620846 - dev-util/catalyst: contains hardcoded emerge sys-kernel/genkernel which is not compatible with systemd
Summary: dev-util/catalyst: contains hardcoded emerge sys-kernel/genkernel which is no...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Catalyst Developers
URL:
Whiteboard:
Keywords:
Depends on: 479730
Blocks:
  Show dependency tree
 
Reported: 2017-06-04 19:55 UTC by Pravorskyi Andrii
Modified: 2020-10-21 01:04 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pravorskyi Andrii 2017-06-04 19:55:45 UTC
In file /usr/share/catalyst/targets/support/pre-kmerge.sh there is code:

run_merge --oneshot genkernel

I tried build livecd with systemd, but genkernel is not compatible with systemd profile, instead I need install genkernel-next. But installing genkernel is hardcoded.

Propose: introduce variable with which I can choose between genkernel and genkernel-next.

Reproducible: Always
Comment 1 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-06-06 06:35:55 UTC
genkernel works fine with systemd. Why do you think that is not the case?
Comment 2 Pravorskyi Andrii 2017-06-06 06:42:39 UTC
(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
Comment 3 Mike Gilbert gentoo-dev 2017-06-06 18:44:38 UTC
Searching for "genkernel systemd" in bugzilla doesn't turn up anything.

I propose we drop that mask since no actionable justification was provided.
Comment 4 Pacho Ramos gentoo-dev 2017-06-06 19:22:22 UTC
I agree... I think it was related with something about mdev usage inside genkernel... but I don't remember :S
Comment 5 Mike Gilbert gentoo-dev 2017-06-07 16:00:01 UTC
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(-)
Comment 6 Pacho Ramos gentoo-dev 2017-06-08 08:29:24 UTC
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 :)
Comment 7 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-06-09 03:12:08 UTC
(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.
Comment 8 Pacho Ramos gentoo-dev 2017-07-03 08:51:18 UTC
It seems it was this old bug the one causing this issues -> bug 479730 

If it's solved, we could close it finally
Comment 9 Martin Wegner 2017-07-03 11:23:34 UTC
(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).
Comment 10 Pravorskyi Andrii 2018-06-08 20:02:27 UTC
Do we have any progress?
Comment 11 Thomas Deutschmann gentoo-dev Security 2019-07-16 01:11:50 UTC
>=sys-kernel/genkernel-4.0.0_beta3 contains fix for bug 479730.
Comment 12 Matt Turner gentoo-dev 2020-10-21 01:04:14 UTC
Whissi says this is fixed.