Created attachment 481766 [details] Shouldn't the required filesystem packages be genkernel dependencies? Easy to fix, but - "genkernel all", after successfully building kernel and busybox, fails with: * ERROR: Binary /sbin/mount.zfs could not be found Is the filesystem detected dynamically - or simply assumed that the root filesystem support programs are already present on the system? Shouldn't the required filesystem packages be made dependencies for genkernel? For the record, my root filesystem is ext4. Just learning the ropes here so I can step up to maintain packages in future.
Actually - I don't have zfs use flag set in my system - shouldn't genkernel just exclude everything it can related to ZFS?
Version: sys-kernel/genkernel-3.4.52.4-r2
Thank you for your report. Best practice is to put the full name sys-kernel/genkernel-3.4.52.4-r2 in the title.
Genkernel ships with a default of only enabling ZFS if your root filesystem is ZFS. gen_determineargs.sh: set_config_with_override BOOL ZFS CMD_ZFS "$(rootfs_type_is zfs)" genkernel.conf:#ZFS="no" Did you have it enabled somehow? Can you please attach a full log run of genkernel with --loglevel=5?
Created attachment 484682 [details] genkernel.log genkernel.log attached.
(In reply to dagelf from comment #5) > Created attachment 484682 [details] > genkernel.log > > genkernel.log attached. Seeing as that it takes so damn long to build, I would rather make it fail (ie. when doing the zfs check, also check zfs.mount - and fail at the beginning, otherwise someone who doesn't know how to make it pick up where it left off has lost around an hour waiting for it to compile...)
In your genkernel.log output: * ZFS defaulted to "yes". This comes from the rootfs: awk '($2=="/"){print $3}' /proc/mounts | grep -sq --line-regexp "$fstype" Somehow that is ZFS on your system. I'm wondering why that is the case. Can you check out the /proc/mounts and see?
I'm hitting this on a catalyst installcd-stage2-minimal.spec build, until I force --no-zfs in the spec. /proc/mounts while genkernel is currently running inside catalyst: /dev/root / ext4 rw,relatime,data=ordered 0 0 devtmpfs /dev devtmpfs rw,relatime,size=8057248k,nr_inodes=2014312,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0 tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/unified cgroup2 rw,nosuid,nodev,noexec,relatime 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,name=systemd 0 0 efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0 mqueue /dev/mqueue mqueue rw,relatime 0 0 tmpfs /tmp tmpfs rw,nosuid,nodev 0 0 hugetlbfs /dev/hugepages hugetlbfs rw,relatime,pagesize=2M 0 0 debugfs /sys/kernel/debug debugfs rw,relatime 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 nfsd /proc/fs/nfsd nfsd rw,relatime 0 0 rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 /dev/sda3 /mnt/btr btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 /dev/sda1 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0 tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=1611656k,mode=700,uid=1000,gid=1000 0 0 /dev/md0 /mnt/tb ext4 rw,relatime,stripe=384,data=ordered 0 0
My vote would be to remove this broken autodetection unless someone can specifically identify the problem and fix it. People have been reporting the problem off and on for literally years.
Wait, is this the issue fixed in bug 552052 and commit https://gitweb.gentoo.org/proj/genkernel.git/commit/gen_funcs.sh?id=c37d0daba2f264c72a945dcebd08e9a42d8649f7 ?
(In reply to Ben Kohler from comment #10) > Wait, is this the issue fixed in bug 552052 and commit > https://gitweb.gentoo.org/proj/genkernel.git/commit/gen_funcs. > sh?id=c37d0daba2f264c72a945dcebd08e9a42d8649f7 ? That was supposed to fix it originally yes. I don't see why that function would claim your rootfs is ZFS.
I believe everyone still affected in this bug report was still using the 3.4 version w/o the fix. So at most this is waiting on a stabilization, doesn't need any more code fixes. Sorry to add to the confusion with my report.
Closing this one, fix is in 3.5.3.3 which is stable.
