Here is an old system with separated / and /usr partition without systemd. The root partition is a raid1 /dev/md126, the usr partitions is the logical volume /dev/mapper/vg0-usr. unused devices: <none> root@orca:/usr/src/linux(243)# df Filesystem 1K-blocks Used Available Use% Mounted on none 6134832 3588 6131244 1% /run udev 10240 0 10240 0% /dev shm 6134832 16 6134816 1% /dev/shm /dev/md126 1943632 825436 1017796 45% / /dev/dm-0 131980772 32036996 93232892 26% /usr cgroup_root 10240 0 10240 0% /sys/fs/cgroup ... root@orca:/usr/src/linux(253)# ll /dev/disk/by-id/ | grep dm-0 lrwxrwxrwx 1 root root 10 Sep 27 2016 dm-name-vg0-usr -> ../../dm-0 lrwxrwxrwx 1 root root 10 Sep 27 2016 dm-uuid-LVM-3yJN9chSlwKfZ5vc2i2qwKaWSg5JC9BEwUQK1LlbwvumMDQxK277Ur0NNqmRp2Cx -> ../../dm-0 The running kernel is 4.7.5-gentoo. It was installed Sep. 2016 probably with genkernel-next-64. If I now try to install this kernel again or any newer kernel, 'genkernel --oldconfig --udev --mdadm --lvm all' wants to access /usr/share/v86d/initramfs: ... ./scripts/gen_initramfs_list.sh: Cannot open '/usr/share/v86d/initramfs' I do not have a /usr/share/v86d directory. Any hint is appreciated.
sys-apps/v86d has been removed from portage. see https://forums.gentoo.org/viewtopic-t-1066432.html?sid=1d7d9ee964b21aad269e5e58951be84f
Regardless, it should only look for v86d if SPLASH is enabled (but not plymouth). Also people still using fbsplash will also most likely be using v86d from bug or overlay; although the wiki page implies v86d is only needed for uvesa (and not needed for intel/radeon/nvidia framebuffers) I'm not sure that's true, as I still saw errors during boot about "can't start /sbin/v86d..." So *if* we can get plymouth and genkernel-next cleaned up then maybe we can just drop support for fbsplash/v86d but that time isn't quite here yet. IMHO we should probably just add a fixed v86d back to the tree for now.
Package removed.
