Hello, Am 19.12.2016 um 09:33 schrieb Michael Biebl: > On Thu, 18 Sep 2014 11:46:49 -0400 Zack Weinberg <[email protected]> wrote: > >> I've just tripped over the same bug with the latest systemd. My >> configuration >> is considerably simpler: >> >> # <file system> <mount point> <type> <options> <dump> >> <pass> >> UUID="eaf36848-eadc-4138-b2a9-db3d8ce82f34" / ext4 >> noatime,errors=remount-ro 0 1 >> UUID="1e04942e-c69b-4430-84f3-1622ef1afe75" none swap sw >> 0 0 >> UUID="ec93d2c2-7937-40f8-aaa6-c20c9775d93a" /home btrfs subvol=/home >> 0 2 >> >> The BTRFS volume spans /dev/sdb and /dev/sdc. >> >> # ls -l /dev/disk/by-uuid/ >> total 0 >> lrwxrwxrwx 1 root root 10 Sep 18 11:29 10C8D0B8C8D09D72 -> ../../sda4 >> lrwxrwxrwx 1 root root 10 Sep 18 11:29 1e04942e-c69b-4430-84f3-1622ef1afe75 >> -> ../../sda2 >> lrwxrwxrwx 1 root root 10 Sep 18 11:29 eaf36848-eadc-4138-b2a9-db3d8ce82f34 >> -> ../../sda1 >> lrwxrwxrwx 1 root root 9 Sep 18 11:29 ec93d2c2-7937-40f8-aaa6-c20c9775d93a >> -> ../../sdc >> >> root@moxana:~# udevadm info --query=all --name=/dev/sdb | grep BTRFS >> E: ID_BTRFS_READY=1 >> root@moxana:~# udevadm info --query=all --name=/dev/sdc | grep BTRFS >> E: ID_BTRFS_READY=0 >> >> Manually mounting /home from the emergency shell allows boot to continue. > > Is that still an issue on an up-to-date sid/stretch system? > In that case, we should probably take this upstream.
I'm reluctant to upgrade my system at the moment, as I need it for my daily work. I tried to create a test scenario with Qemu, but was never able to reproduce it there. Timing seems to be critical and I was not able to trick Qemu into delaying the availability of a disk. Maybe I find some time over the Christmas holidays to give it another try. Philipp _______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
