The genkernel team has been inactive lately and I haven't seen anybody reviewing my patches. So, in order to avoid breaking stuff and getting all the blame, I moved my improvements to a new package, called genkernel-next. genkernel-next aims to deprecate support for things that has been broken or implemented in a suboptimal way, such as: - cross compiler support (broken for ages) - unionfs (why on earth you want to use such paperweight and unstable filesystem) In change, it (currently) gives you: + udev support (runtime switchable with mdev, udev makes lvm and systemd WORK) + drop all the funky compilation code in gen_compile.sh and use copy_binaries to embed stuff in the initramfs. This reduces the complexity and the maintenance burden a lot. + plymouth support (fbsplash support is still there and working!) + faster and cleaner initialization code + some debugging improvements
(In reply to comment #0) > The genkernel team has been inactive lately and I haven't seen anybody > reviewing my patches. Have you pinged people in its mail alias?
Sure, I am part of genkernel@g.o
The entire genkernel team is rather overextended with obligations in other areas of Gentoo and real life obligations. For what it is worth, I am around and active in IRC. I am happy to review patches upon being pinged. Anyway, I will be happy to discuss your changes in IRC if you just ping me about them. :)
How about booting from LVM volume over MDADM device? it is support lvm.static?
Created attachment 355234 [details, diff] Patch for gen_initramfs.sh to dynamically support /lib/udev and /usr/lib/udev First of all, thanks for genkernel-next as it allows me to boot computers with systemd (required by Gnome 3.8) from a dm-crypt volume with LVM on top of it. Unfortunately, the creation of an initramfs failed on one of my computers due to missing file /lib/udev/rules.d/50-udev-default.rules . A little bit of debugging showed that the udev rules on that system were installed into /usr/lib/udev/ (i.e. /usr/lib64/udev/) by the systemd-206-r1 ebuild. Looking at the systemd ebuild and udev.eclass I saw that they use pkg-config there to determine the directory where rules will be installed. So I changed all static references to /lib/udev in gen_initramfs.sh of genkernel-next to $( pkg-config --variable udevdir udev ) which is the same way the directory is determined in the udev.eclass and it worked. A patch is attached. Let me know if you need further information. $ emerge -pv systemd genkernel-next [ebuild R ] sys-kernel/genkernel-next-22::systemd-love USE="crypt cryptsetup -dmraid -gpg (-ibm) -iscsi -plymouth (-selinux)" 0 kB [ebuild R ] sys-apps/systemd-206-r1 USE="cryptsetup filecaps firmware-loader gudev introspection kmod pam policykit tcpd -acl -audit -doc -gcrypt -http -lzma -openrc -python -qrcode (-selinux) {-test} -vanilla -xattr" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" 0 kB
Thank you very much Martin! I committed it into genkernel-next master branch. commit 9af1f8788cf462ffa071481e090098061a50152d Author: Fabio Erculiani <lxnay@sabayon.org> Date: Tue Aug 6 15:53:34 2013 +0200 gen_initramfs: do not hardcode udevdir but use pkg-config Thanks to Martin Wegner for the original patch, I just cleaned it up a bit and committed.
Created attachment 355284 [details, diff] Patch for gen_initramfs.sh replacing another (and last) hardcoded reference to /lib/udev I just tested booting with the initramfs generated by the patched gen_initramfs.sh script and it failed. Comparing the generated initramfs to one of a working setup showed that various rule files of LVM were missing in ./lib/udev/rules.d/ . As it quickly turned out, there is another hardcoded reference in gen_initramfs.sh to /lib/udev, in the LVM hook. Patch (hopefully following your style) is attached.
Would be nice to have genkernel-next improvements merged in genkernel, otherwise, we will need to document that genkernel-next could be needed before stabilizing gnome 3.8 (will add the blocker to remember to add a note to upgrade guide if needed finally)
(In reply to Pacho Ramos from comment #8) > Would be nice to have genkernel-next improvements merged in genkernel, > otherwise, we will need to document that genkernel-next could be needed > before stabilizing gnome 3.8 (will add the blocker to remember to add a note > to upgrade guide if needed finally) At least "udev" support needs to be merged into genkernel or we (gnome team) will need to point people to genkernel-next usage in upgrade guide :/ Thanks a lot!
Also, maybe giving Fabio commit rights to genkernel (at least for creating its own branch subject to be reviewed by genkernel devs) could speed up things :| Anyway, last time I talked with Richard on IRC was willing to review the changes... but I cannot talk now via IRC (only mails) and, also, my knowledge about genkernel is nearly zero -_- (I compile the kernel myself)
I am part of genkernel@. But the genkernel situation was so bad that I decided to completely fork and refactor the whole codebase. As of today, I've been able to clean up the messy initramfs code, but the rest of the stuff is still in its original (bad) state.
What is the status of this? What changes are pending to be done in main genkernel package?
What's the status of trying to get genkernel-next stabilized and merged into genkernel proper? I'm trying to use catalyst and it only works with genkernel, but I need a systemd version of a catalyst build so I was forced for patch catalyst to make it use genkernel-next in order to get systemd support. This whole thing is kind of messy and I'd love to try to get this issue resolved sooner rather than later. Thoughts?
(In reply to Marshall McMullen from comment #13) > What's the status of trying to get genkernel-next stabilized and merged into > genkernel proper? I'm trying to use catalyst and it only works with > genkernel, but I need a systemd version of a catalyst build so I was forced > for patch catalyst to make it use genkernel-next in order to get systemd > support. This whole thing is kind of messy and I'd love to try to get this > issue resolved sooner rather than later. > > Thoughts? Well, I don't use catalyst so don't have your problems but I will confirm that I have been using genkernel-next for quite a while now without problems. However, the longevity of this bug suggests a lack of movement in this whole area, unfortunately, so I woudn't expect much change ...
But, what concrete things need to be merged in genkernel? I mean... maybe this could be easier updating the patches for genkernel that would need to be reviewed... or are the differences with genkernel-next too big currently?
I don't know enough about the internals of genkernel and genkernel-next, but my cursory impression is that genkernel-next was basically a rewrite of genkernel not merely a set of patches... but maybe I'm wrong about that.
The real problem, in my view, is that we've effectively forked genkernel to genkernel-next and lots of bug fixes and development has gone on in both of these for quite some time. But in order to use systemd we are forced to use genkernel-next instead of genkernel. But genkernel-next seems far from being maintained. So maybe we should focus our efforts on adding proper systemd support to genkernel instead of trying to get all of genkernel-next merged into genkernel..
From a user perspective, it is also not clear whether genkernel or -next to use, this should be more clearly documented. I never needed a initramfs for the last 15 years, however with an encrypted setup I finally have to. I figured genkernel-next is the future (from the name alone) and so only worked with that. All patches/fixes/debugging I did (see bug 601444 and 600992) goes to genkernel-next because I wasn't even aware of the "forked situation".
(In reply to Marshall McMullen from comment #17) > The real problem, in my view, is that we've effectively forked genkernel to > genkernel-next and lots of bug fixes and development has gone on in both of > these for quite some time. But in order to use systemd we are forced to use > genkernel-next instead of genkernel. ... > So maybe we should focus our efforts on adding proper systemd > support to genkernel instead of trying to get all of genkernel-next merged > into genkernel.. systemd SHOULD work fine with genkernel. Can you please provide more details on how it did not work? Thereafter, let's see what other functionality remains unique to genkernel-next, and I'll work on implementing that in genkernel, so that -next can simply go away.
genkernel has been masked in the systemd profile since it was created by pacho. https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/?id=5f4b083b473944d8704991c4701d94bd750b6f92 He did not leave any bug numbers or give any explanation at the time. Basically, I have no idea what makes genkernel incompatible with systemd because nobody has been testing it since 2013. This is why we should not mask things without bug reports!
(In reply to Robin Johnson from comment #19) > (In reply to Marshall McMullen from comment #17) > > So maybe we should focus our efforts on adding proper systemd > > support to genkernel instead of trying to get all of genkernel-next merged > > into genkernel.. > systemd SHOULD work fine with genkernel. Can you please provide more details > on how it did not work? If I might join in, I think I can provide details (and testing) on this issue: My setup is LVM volumes (incl. /) on a dm-crypt volume (which itself is located on a dm-raid1). Thus, the dm-crypt volume needs to be unlocked with the initramfs and volume groups need to be activated afterwards. System is booted with systemd afterwards. For testing, I switched to the recent genkernel-3.5.1.0 update on my system, updated /etc/genkernel.conf (and adapted to my needs) and I generated a kernel and initramfs (gentoo-sources-4.11.7). However, when booting the kernel/initramfs, all LVM volumes are not detected/activated correctly: initramfs seems to look for LVM volumes (some messages a la "no volumes found" are printed), then asks for dm-crypt password, then system is able to boot via systemd. So, LVM volume with root-partition / seems to be available. Yet, systemd then hangs indefinetely with units hanging/waiting for the remaining LVM volumes. I would be happy to help debug/test this, to get the proper support into genkernel. Let me know what is needed. My settings in /etc/genkernel.conf: % grep -v '^#' /etc/genkernel.conf | grep -v '^$' INSTALL="yes" OLDCONFIG="yes" MENUCONFIG="yes" GCONFIG="no" NCONFIG="no" XCONFIG="no" CLEAN="no" MRPROPER="no" MOUNTBOOT="yes" SYMLINK="yes" SAVE_CONFIG="yes" USECOLOR="yes" MAKEOPTS="$(portageq envvar MAKEOPTS)" NICE=10 LVM="yes" LUKS="yes" DMRAID="yes" SSH="yes" MDADM="yes" MDADM_CONFIG="/etc/mdadm.conf" BTRFS="yes" DISKLABEL="yes" BOOTLOADER="grub2" CMD_CALLBACK="emerge --selective=n -1v @module-rebuild" GK_SHARE="${GK_SHARE:-/usr/share/genkernel}" CACHE_DIR="/var/cache/genkernel" DISTDIR="${GK_SHARE}/distfiles" LOGFILE="/var/log/genkernel.log" LOGLEVEL=1 DEFAULT_KERNEL_SOURCE="/usr/src/linux" System info: % emerge --info !!! Repository 'gentoo' has sync-type attribute, but is missing sync-uri attribute [74/430] Portage 2.3.6 (python 2.7.13-final-0, default/linux/amd64/13.0/desktop/gnome/systemd, gcc-6.3.0, glibc-2.24-r3, 4.11.6-gentoo-vidar-i7-efi x86_64) ================================================================= System uname: Linux-4.11.6-gentoo-vidar-i7-efi-x86_64-Intel-R-_Core-TM-_i7-7700K_CPU_@_4.20GHz-with-gentoo-2.4.1 KiB Mem: 16406876 total, 12852636 free KiB Swap: 16777212 total, 16777212 free Timestamp of repository gentoo: Mon, 26 Jun 2017 00:45:01 +0000 Timestamp of repository poly-c: Sat, 24 Jun 2017 14:37:48 +0000 sh bash 4.4_p12 ld GNU ld (Gentoo 2.28 p1.2) 2.28 ccache version 3.3.4 [disabled] app-shells/bash: 4.4_p12::gentoo dev-java/java-config: 2.2.0-r3::gentoo dev-lang/perl: 5.24.1-r2::gentoo dev-lang/python: 2.7.13::gentoo, 3.4.6::gentoo, 3.6.1-r1::gentoo dev-util/ccache: 3.3.4::gentoo dev-util/cmake: 3.8.2::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.4.1::gentoo sys-apps/openrc: 0.27.2::gentoo sys-apps/sandbox: 2.10-r4::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r3::gentoo sys-devel/automake: 1.11.6-r2::gentoo, 1.13.4-r1::gentoo, 1.15.1::gentoo sys-devel/binutils: 2.28-r2::gentoo sys-devel/gcc: 6.3.0::gentoo sys-devel/gcc-config: 1.8-r1::gentoo sys-devel/libtool: 2.4.6-r4::gentoo sys-devel/make: 4.2.1-r1::gentoo sys-kernel/linux-headers: 4.10::gentoo (virtual/os-headers) sys-libs/glibc: 2.24-r3::gentoo Repositories: gentoo location: /usr/portage sync-type: webrsync priority: -1000 local location: /usr/local/portage masters: gentoo priority: 0 betagarden location: /var/lib/layman/betagarden masters: gentoo priority: 50 gnome location: /var/lib/layman/gnome masters: gentoo priority: 50 hacking-gentoo location: /var/lib/layman/hacking-gentoo masters: gentoo priority: 50 jkolo [17/430] location: /var/lib/layman/jkolo masters: gentoo priority: 50 jorgicio location: /var/lib/layman/jorgicio masters: gentoo priority: 50 mittwinter location: /var/lib/layman/mittwinter masters: gentoo priority: 50 mozilla location: /var/lib/layman/mozilla masters: gentoo priority: 50 poly-c location: /var/lib/layman/poly-c masters: gentoo priority: 50 steam-overlay location: /var/lib/layman/steam-overlay masters: gentoo priority: 50 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/chromium/policies/managed/chrome-gnome-shell.json /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/opt/chrome/policies/managed/chrome-gnome-shell.json /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS=" --alert y --verbose-conflicts --changed-deps y --changed-use --complete-graph y --with-bdeps y --autounmask n --deep --backtrack=1000 --keep-going y" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs clean-logs config-protect-if-modified distlocks ebuild-locks fakeroot fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-backup unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync webrsync-gpg xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS=" ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://mirror.netcologne.de/gentoo/ " LANG="C" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j5 -l4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac acl acpi aes alsa amd64 amr avahi avx avx2 berkdb bluetooth bluray branding bzip2 cairo cdda cdr cli colord cracklib crypt cryptsetup cups cxx dbus dirac divx dri dts dvb dvd dvdr eds emboss encode exif f16c faac faad fam fat ffmpeg firefox flac fma3 fuse gdbm gif glamor gnome gnome-keyring gnome-online-accounts gstreamer gtk gtk3 iconv icu idn imagemagick inotify introspection ipv6 jpeg lame lastfm lcms libnotify libsecret lz4 lzma lzo mad mmx mmxext mng modules mp3 mp4 mpeg multilib nautilus ncurses networkmanager nls nptl nvidia offensive ogg opengl openmp opus pam pango pcre pcsc-lite pdf png policykit popcnt ppds pulseaudio qt3support qt5 readline realmedia samba schroedinger sdl seccomp sendto session smartcard spell sse sse2 sse3 sse4_1 sse4_2 ssl ssse3 startup-notification svg syslog systemd tcpd telepathy theora tiff tracker truetype udev udisks unicode upower usb v4l v4l2 vdpau vim-syntax vorbis vpx webm wifi wmp wxwidgets x264 x265 xattr xcb xinerama xml xv xvid xz zeitgeist zeroconf zlib zsh-completion" ABI_X86="64 32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" CURL_SSL="gnutls" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64 pc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" L10N="en de" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en de" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6" PYTHON_SINGLE_TARGET="python3_4" PYTHON_TARGETS="python2_7 python3_4" QEMU_SOFTMMU_TARGETS="x86_64 i386" RUBY_TARGETS="ruby21 ruby23 ruby24" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" USE_PYTHON="2.7 3.4 3.5" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Don’t know if this is a different report to file or not, but at a bare minimum, genkernel-next’s Plymouth support should be backported. As it currently stands, I have to “sed -i” genkernel-next into /usr/share/catalyst/targets/support/pre-kmerge.sh in order to get Plymouth to work on live media.
Hello, what's the status? The new installation with: luks/lvm/{root, home, swap} + systemd-244 + genkernel-4.0.2 failed to boot after luks decrypt for mount timeout(home and swap); if switched to genkernel-next, it boot successful. Looks like it's for the lake of genkernel's udev support, which result in lvm + systemd boot with the non-udev initramfs failed. is it possible to configure systemd only for the issue as the rootfs is mounted there, so that there is no need to change the behaviour of initramfs
(In reply to giskard from comment #23) > Hello, what's the status? > > The new installation with: luks/lvm/{root, home, swap} + systemd-244 + > genkernel-4.0.2 failed to boot after luks decrypt for mount timeout(home and > swap); if switched to genkernel-next, it boot successful. Please don't spread FUD. This is not a genkernel issue as I explained in bug 706434.
(In reply to Thomas Deutschmann from comment #24) > Please don't spread FUD. This is not a genkernel issue as I explained in bug > 706434. This isn't FUD at all. luks does not work on a system system if the volume was opened using lvm2 built without udev support. It's a real problem with no obvious solution.
Package removed.
