After switching to systemd, the system will not boot with systemd due to some weird device names for lvm devices. The initramfs is created with genkernel-next-35 (and 50) with "genkernel --lvm --udev". This will not be able to mount my usr device from my lvm because it is trying to mount something like ../dm-4 instead of /dev/system-vg/usr. Reproducible: Always Steps to Reproduce: 1. Have a systemd enabled system with usr on an lvm 2. try to boot with systemd Actual Results: System cant start because initramfs failes to mount /usr which in turn will cause a missing systemd Expected Results: A starting system I've found a solution which works for my case. Don't really now if there are any side effects for other configurations. Added as patch.
Created attachment 370330 [details, diff] Patch to fix my problem
What does your kernel boot command line look like? Please paste the full "cat /proc/cmdline" from a non-working system (better if you attach the full bootloader config file) and also the output of "ls -la /dev/mapper/" (and the relevant "ls -la /dev" lines).
I have exactly the same problem. (In reply to Fabio Erculiani from comment #2) > What does your kernel boot command line look like? > Please paste the full "cat /proc/cmdline" from a non-working system (better > if you attach the full bootloader config file) Here's the boot entry from grub (legacy) title=Gentoo Linux 3.10.22 (systemd) root (hd0,0) kernel /kernel-genkernel-x86_64-3.10.22-gentoo root=/dev/sda2 ro video=uvesafb:1680x1050-32@60,mtrr:3,ywrap rootfstype=ext4 dolvm real_rootflags=ro real_init=/usr/lib/systemd/systemd initrd=/initramfs-genkernel-x86_64-3.10.22-gentoo > and also the output of "ls > -la /dev/mapper/" (and the relevant "ls -la /dev" lines). This is the output from my running (!) system, but during initramfs debug console the output is the same. Note: I stripped some of the mapper entries here. ls -la /dev/mapper/ insgesamt 0 drwxr-xr-x 2 root root 280 21. Feb 2014 . drwxr-xr-x 18 root root 4200 21. Feb 10:55 .. crw------- 1 root root 10, 236 21. Feb 10:55 control lrwxrwxrwx 1 root root 7 21. Feb 10:55 system-opt -> ../dm-0 lrwxrwxrwx 1 root root 7 21. Feb 10:55 system-swap -> ../dm-3 lrwxrwxrwx 1 root root 7 21. Feb 10:55 system-tmp -> ../dm-1 lrwxrwxrwx 1 root root 7 21. Feb 10:55 system-usr -> ../dm-9 lrwxrwxrwx 1 root root 7 21. Feb 10:55 system-var -> ../dm-7 ls -la /dev/dm-{0,3,1,9,7} brw-rw---- 1 root disk 254, 0 21. Feb 10:55 /dev/dm-0 brw-rw---- 1 root disk 254, 1 21. Feb 10:55 /dev/dm-1 brw-rw---- 1 root disk 254, 3 21. Feb 10:55 /dev/dm-3 brw-rw---- 1 root disk 254, 7 21. Feb 10:55 /dev/dm-7 brw-rw---- 1 root disk 254, 9 21. Feb 10:55 /dev/dm-9 I took a picture of the failed boot process and the problem lies in this line I transcribed: >> Mounting ../dm-9 as /usr: mount -t ext4 -o default,ro ../dm-9 /newroot/usr
The command line is the same for a non-working (without the patch) and a working system. cat /proc/cmdline BOOT_IMAGE=/kernel-genkernel-x86_64-3.12.6-quasimodo root=/dev/sda2 ro i915.i915_enable_rc6=7 i915.semaphores=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 video=1440x900-32@60 dolvm init=/usr/lib/systemd/systemd real_init=/usr/lib/systemd/systemd splash=silent,fadein,theme:asuka console=tty1 quiet ls -la /dev/mapper 0 lrwxrwxrwx 1 root root 7 20. Feb 06:46 asuka_system-gentoo -> ../dm-6 0 lrwxrwxrwx 1 root root 7 20. Feb 06:46 asuka_system-opt -> ../dm-5 0 lrwxrwxrwx 1 root root 7 20. Feb 06:46 asuka_system-usr -> ../dm-3 0 lrwxrwxrwx 1 root root 7 20. Feb 06:46 asuka_system-var -> ../dm-4 0 lrwxrwxrwx 1 root root 7 20. Feb 06:46 asuka_user-emul -> ../dm-2 0 lrwxrwxrwx 1 root root 7 20. Feb 06:46 asuka_user-home -> ../dm-0 0 lrwxrwxrwx 1 root root 7 20. Feb 06:46 asuka_user-space -> ../dm-1 ls -ls /dev/dm* 0 brw-rw---- 1 root disk 254, 0 20. Feb 06:46 /dev/dm-0 0 brw-rw---- 1 root disk 254, 1 20. Feb 06:46 /dev/dm-1 0 brw-rw---- 1 root disk 254, 2 20. Feb 06:46 /dev/dm-2 0 brw-rw---- 1 root disk 254, 3 20. Feb 06:46 /dev/dm-3 0 brw-rw---- 1 root disk 254, 4 20. Feb 06:46 /dev/dm-4 0 brw-rw---- 1 root disk 254, 5 20. Feb 06:46 /dev/dm-5 0 brw-rw---- 1 root disk 254, 6 20. Feb 06:46 /dev/dm-6
I think that the problem is only about the fact that we should use "realpath" rather than "readlink".
Created attachment 371122 [details, diff] use realpath instead of readlink Can you try this patch on top of genkernel-next 52 or 53?
(In reply to Fabio Erculiani from comment #6) > Created attachment 371122 [details, diff] [details, diff] > use realpath instead of readlink > > Can you try this patch on top of genkernel-next 52 or 53? Applying https://github.com/Sabayon/genkernel-next/commit/fd8ba0d9dbb4df760e1798eab5fa7156d91df1e4.patch using epatch_user on sys-kernel/genkernel-next-53 a newly generated initramfs works.
Fixed in genkernel-next-54.
