Bug#868164: systemd: fakeraid + cryptsetup (root) + lvm results in 90s time out waiting for device at boot
I’ve encountered what appears to be another instance of this on a Debian 10.2 system (systemd-241-7~deb10u2). The system has an LVM PV atop a LUKS container atop an mdadm RAID, and sometimes on boot, the system will time out trying to open the disk. Investigation in recovery mode suggests that the RAID is being assembled but cryptsetup isn’t figuring that out and just sits there, waiting for the disk to appear. Interestingly, the failure appears much more frequently on the systemd from buster-backports (systemd-244-3~bpo10+1) than it does on the version in buster.
Bug#868164: systemd: fakeraid + cryptsetup (root) + lvm results in 90s time out waiting for device at boot
Hi, I have found, that my problem is caused only in case of mdraid device partitioning. To reproduce: 1. Take 2 HDD (at least by 50 GB) 2. Run from any LiveCD 3. Make two partitions on each HDD: for 256-1024MB and for remaining space, make first partition bootable 4. Create mdraid1 around second partitions of both HDD 5. Repartition md device by 3 partitions: 10GB (md0p1), 20GB (md0p2) and remaining space (md0p3) 6. Using cryptsetup configure luks encryption over md0p2. 7. Install debian 9 or 10, using: /dev/sda1 - /boot, /dev/md0p1 - /root, /dev/md0p2 - /var, /dev/mapper/ - /home After reboot system do not start if default boot options are specified. It will wait for some devices to be ready, but no any password prompt. There is only one way to boot system: run rescue mode and then exit from rescue shell using Ctrl-D. If you create on HDDs four partitions and use them to build four RAID1 devices, then encrypted device configured on /dev/md3 will start on boot successfully (after prompting password). So I think, some boot scripts/services does not know anything about md device partitioning.
Bug#868164: systemd: fakeraid + cryptsetup (root) + lvm results in 90s time out waiting for device at boot
Please ignore information about start of debian9 before /var mount in my previous message. It was caused by strange config possibly kept from Jessie (/etc/systemd/system/bind9.service.d/override.conf). After removing it, bind starts after /var mount. Best regards, Sergey Belyashov
