I use vanilla kernel 3.10.24, dracut-031-r1 and eudev-1.3. My rootfs is encrypted with LUKS and i need an initramfs to set it up properly. With the abouve combination the initramfs can not unlock my device. I need udev that the build initramfs can unlock my device. If i fall back to the rescue console, i can modprobe my ahci module, it gets loaded, a manual "udevadm trigger" does not create the /dev/sdax device to open my LUKS device. Reproducible: Always Steps to Reproduce: 1. install euvev, dracut 2. setup rootfs on LUKS device 3. build initramfs with dracut 4. boot --> You wont be able to unlock the LUKS device. Actual Results: i can not unlock my LUKS device Expected Results: i can unlock my LUKS device
Created attachment 365262 [details] Systeminfo about my system
mount | column -t rootfs on / type rootfs (rw) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) devtmpfs on /dev type devtmpfs (rw,nosuid,size=4035236k,nr_inodes=1008809,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) /dev/mapper/laptop-gentoo_root on / type btrfs (rw,relatime,space_cache,autodefrag) mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime) cgroup_root on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755) openrc on /sys/fs/cgroup/openrc type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/lib64/rc/sh/cgroup-release-agent.sh,name=openrc) cpuset on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cpuacct on /sys/fs/cgroup/cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct) /dev/sda1 on /boot type ext2 (rw,noatime) /dev/mapper/laptop-gentoo_home on /home type ext4 (rw,noatime,commit=0) none on /var/tmp/portage type tmpfs (rw,size=6000M,nr_inodes=1M) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
Created attachment 365264 [details] Kernel Konfig
So no problems with sys-fs/udev?. Do I understand correctly? Please add rd.debug to the kernel cmdline, then after dracut drop you to emergency shell copy file /run/initramfs/rdsosreport.txt to persistent storage (eg /boot partition) and attach it to the bug report.
Yes, you are absolutly right. With stable udev everything works ok. If i have build my initramfs, booted and then unmerge udev and switch to eudev, all is fine. If i want to build a new initramfs with dracut, i need to switch to udev, build initramfs and switch back to eudev.
Created attachment 365302 [details] rdsosreport from the rescue shell Here is the requested file. It seems that there crashes something. I did some tests with different kernels, but all did this. It did not change by exchanging the kernel.
Created attachment 365304 [details] dmesg from the rescue shell
To get the dmesg output and rdsosreport i did manually load the ahci module and created my "mknod /dev/sda1 b 8 1" the block device. This is what appears at the end of the dmesg output.
Hmm.. I need some more info. Please add "rd.debug rd.udev.debug" to the kernel cmdline and attach resulting rdsosreport.txt again. Also show the output of `lsblk` issued on sucessfully booted system.
georg@machariel ~ $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 698,7G 0 disk ├─sda1 8:1 0 200M 0 part /boot ├─sda2 8:2 0 127G 0 part ├─sda3 8:3 0 1K 0 part ├─sda5 8:5 0 97,7G 0 part └─sda6 8:6 0 473,8G 0 part └─luks-05f6359d-643e-4122-884d-55a75f238bd9 (dm-0) 253:0 0 473,8G 0 crypt ├─laptop-home (dm-1) 253:1 0 8G 0 lvm ├─laptop-wheezy_root (dm-2) 253:2 0 30G 0 lvm ├─laptop-gentoo_root (dm-3) 253:3 0 50G 0 lvm / ├─laptop-swap (dm-4) 253:4 0 10G 0 lvm [SWAP] ├─laptop-gentoo_home (dm-5) 253:5 0 20G 0 lvm /home ├─laptop-backup (dm-6) 253:6 0 50G 0 lvm └─laptop-gentoo_rt (dm-7) 253:7 0 50G 0 lvm sdb 8:16 0 931,5G 0 disk └─sdb1 8:17 0 931,5G 0 part sr0 11:0 1 1024M 0 rom
Created attachment 365688 [details] rdsosreport from the rescue shell with rd.debug=1 rd.udev.debug=1 There is the requested file.
(In reply to georg from comment #11) > Created attachment 365688 [details] > rdsosreport from the rescue shell with rd.debug=1 rd.udev.debug=1 > > There is the requested file. Seems you've uploaded the same file again and there is no rd.udev.debug in the cmdline. BOOT_IMAGE=/vmlinuz-3.12.4-slim root=/dev/mapper/laptop-gentoo_root ro vconsole.keymap=de-latin1-nodeadkeys vconsole.locale.LANG=de_DE.UTF-8 net.ifnames=0 rd.luks=1 rd.lvm=1 rd.luks.uuid=05f6359d-643e-4122-884d-55a75f238bd9 rd.debug=1
Created attachment 365690 [details] right rdsosreport from the rescue shell with rd.debug=1 rd.udev.debug=1 Somehow i mixed the files. This is now the right one
Created attachment 366054 [details, diff] dracut-eudev-compat.patch I have an idea. Please try attached patch.
(In reply to Alexander Tsoy from comment #14) > Created attachment 366054 [details, diff] [details, diff] > dracut-eudev-compat.patch > > I have an idea. Please try attached patch. Just put this patch into /etc/portage/patches/sys-kernel/dracut directory and (re)emerge dracut-034-r2 (this is the only version with epatch_user support).
Created attachment 366056 [details, diff] dracut-eudev-compat.patch fix indentations
Thanks! This did help :)
Created attachment 366164 [details, diff] udev-rules-add-eudev-rules.patch Amadeusz, I'm not sure if I should push this patch upstream. What do you think? @eudev: is there a strong reason to install this rules as "80-drivers-modprobe.rules", or it just to simplify the build system?
(In reply to Alexander Tsoy from comment #18) > @eudev: is there a strong reason to install this rules as > "80-drivers-modprobe.rules", or it just to simplify the build system? By the way genkernel-next also expects "80-drivers.rules": https://github.com/Sabayon/genkernel-next/blob/master/gen_initramfs.sh
(In reply to Alexander Tsoy from comment #18) > Created attachment 366164 [details, diff] [details, diff] > udev-rules-add-eudev-rules.patch > > Amadeusz, I'm not sure if I should push this patch upstream. What do you > think? Push this patch upstream, please. It handles special case but it doesn't break other distros. There's special case for Debian, too, as you can see. :-)
Thanks! +*dracut-034-r3 (28 Dec 2013) + + 28 Dec 2013; Amadeusz Żołnowski <aidecoe@gentoo.org> dracut-034-r2.ebuild, + +dracut-034-r3.ebuild, +files/034-0014-udev-rules-add-eudev-rules.patch: + Committing on behalf of Alexander Tsoy <alexander@tsoy.me>. + Fixes bug #494188. + + LUKS devices couldn't be decrypted with eudev because of missing rules file. +
(In reply to Amadeusz Żołnowski from comment #21) > + LUKS devices couldn't be decrypted with eudev because of missing rules > file. > + This was actually a different issue: no udev rules for loading kernel modules was installed in initramfs. No problems with LUKS. ;)