If the uucp group is not present on a system, the MAKEDEV command bails out, and fails to create all of the device nodes. On some systems that can lead to a boot failure before devtmpfs is mounted (e.g. dracut umounts devtmpfs, does switch_root and expected the new init to mount devtmpfs again). Trivial reproduction (do it in a testenv, due to the groupdel) $ mkdir -p /chroot/dev/ $ groupadd -g 14 uucp $ MAKEDEV -n -D /dev -d /chroot/dev/ console hda input ptmx std sd tty |wc -l 12052 $ groupdel uucp MAKEDEV -n -D /dev -d /chroot/dev/ console hda input ptmx std sd tty |wc -l MAKEDEV: no such group: uucp 320 Short-term, acct-group/uucp should probably be added as a makedev DEPEND. I found this because of some older infra systems, where the underlying /dev was not fully populated, causing boot failures. I don't know how it got to be a system without uucp however. Fixing this requires creative bindmounts prior to using makedev.
Both OpenRC and systemd mount devtmpfs very early in the boot process. sys-apps/makedev really should not be used on any modern Gentoo system.
I see that sys-apps/makedev gets pulled into stage1 builds via default/linux/packages.build. Its pkg_postinst creates several devices nodes when USE=build. I think we should either eliminate sys-apps/makedev in stage1 by moving the logic to baselayout, or update makedev's pkg_postinst to create a more minimal set of device nodes.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c0d826349c6a1bd6f7e0d001196a43325a02ac85 commit c0d826349c6a1bd6f7e0d001196a43325a02ac85 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2023-07-05 00:29:34 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2023-07-05 00:29:34 +0000 sys-apps/makedev: depend on groups used by MAKEDEV Closes: https://bugs.gentoo.org/909661 Signed-off-by: Mike Gilbert <floppym@gentoo.org> .../{makedev-3.23.1-r2.ebuild => makedev-3.23.1-r3.ebuild} | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
I found the uucp bug because I tried to use MAKEDEV to fix another issue that has blocked some infra kernel upgrades for a few months. > Both OpenRC and systemd mount devtmpfs very early in the boot process It's not early enough, something before the sysvinit message for "INIT: version 3.07 booting" message needs /dev populated. I've got a couple of infra boxes that are otherwise up to date, but the underlying /dev was empty, and they failed to boot with a newer initramfs. This was some change in the initramfs: something used by dracut caused it to hang when it should have started INIT. I think it's somehow the busybox switch_root vs util-linux switch_root. Here's a pair of logs from bobolink.gentoo.org, same kernel, 5.15.48, but the initramfs generated at some point the past, vs current. https://gist.github.com/robbat2/c3217138c0ee76c636769765ab3e11e4 Both of them claim to be dracut-55, but the broken one ALSO has VERSION_ID="2.13". I've uploaded both initramfs at https://dev.gentoo.org/~robbat2/bug-909661/ but very little in dracut itself changed between them (the modules are a bit different and the underlying host OS was updated a lot) Working initramfs was generated on 2022/07/04 Broken initramfs re-generated many times - problem persists on newer kernels as well. Snippet of the working initramfs: bobolink.good.txt-[ 1.673346] dracut: /: clean, 399712/2621440 files, 6958134/10485760 blocks bobolink.good.txt-[ 1.677068] dracut: Mounting /dev/mapper/bobolink-root with -o noatime,ro bobolink.good.txt-[ 1.683389] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. bobolink.good.txt:[ 1.700252] dracut: Mounted root filesystem /dev/mapper/bobolink-root bobolink.good.txt-Jul 05 03:58:08 | DM multipath kernel driver not loaded bobolink.good.txt-[ 1.753319] dracut: Switching root bobolink.good.txt-INIT: version 3.07 booting (and continues from there) Snippet of the failing initramfs: bobolink.fail.txt-[ 3.577210] dracut: /: clean, 399712/2621440 files, 6958134/10485760 blocks bobolink.fail.txt-[ 3.580311] dracut: Mounting /dev/mapper/bobolink-root with -o noatime,ro bobolink.fail.txt-[ 3.587826] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. bobolink.fail.txt:[ 3.606894] dracut: Mounted root filesystem /dev/mapper/bobolink-root bobolink.fail.txt-[ 3.744550] dracut: Switching root (and no further output)
(In reply to Robin Johnson from comment #4) > Both of them claim to be dracut-55, but the broken one ALSO has > VERSION_ID="2.13". It looks like it might be using baselayout versioning?
(In reply to Robin Johnson from comment #4) > I think it's somehow the busybox switch_root vs util-linux switch_root. That seems likely. The util-linux man page says this: switch_root moves already mounted /proc, /dev, /sys and /run to newroot and makes newroot the new root filesystem and starts init process. The busybox man page does not mention moving /dev. I think we really only need /dev/console and /dev/null on rootfs to cover very early boot with sysvinit and openrc. Let's continue that discussion on bug 909664.
