On Tue, Jul 5, 2016 at 10:53 AM, Chris Murphy <li...@colorremedies.com> wrote:
> It seems like this dracut doesn't understand rd.timeout. OK now on Fedora Rawhide and rd.timeout=30 appears to work. The failure is the same, systemd is waiting for /dev/vda2 for an unknown reason, it doesn't even attempt to mount it so this is not (yet) a mount failure. And journalctl is more revealing...but I'm still lost. https://drive.google.com/open?id=0B_2Asp8DGjJ9dE1MOWlXbjYyeVE [ 4.510767] localhost.localdomain systemd[1]: dev-vda1.device: Changed dead -> plugged [ 4.510995] localhost.localdomain systemd[1]: sys-devices-pci0000:00-0000:00:09.0-virtio2-block-vda-vda1.device: Changed dead -> plugged That never happens for vda2. [ 4.602049] localhost.localdomain systemd-udevd[205]: worker [226] exited [ 63.212453] localhost.localdomain systemd[1]: dev-vda2.device: Job dev-vda2.device/start timed out. [ 63.213227] localhost.localdomain systemd[1]: dev-vda2.device: Job dev-vda2.device/start finished, result=timeout [ 63.213904] localhost.localdomain systemd[1]: Timed out waiting for device dev-vda2.device. It goes direct from udevd stuff, long wait with nothing happening, then time out. I wonder if this is a problem in 64-btrfs.rules just because there is a missing device. I thought root=/dev/vda2 would work around the problem where btrfs udev rules does not instantiate the Btrfs volume UUID if there is a missing device; and now I wonder if this has been misunderstood all along. In the shell :/# blkid /dev/sr0: UUID="2016-07-04-07-03-49-00" LABEL="Fedora-S-dvd-x86_64-rawh" TYPE="iso9660" PTUUID="6c9a3e8e" PTTYPE="dos" /dev/vda1: UUID="b061db37-3ef5-4b5c-aef0-bbaa360f7788" TYPE="ext4" PARTUUID="6cd85e0f-01" /dev/vda2: LABEL="fedora" UUID="488791ba-5796-4653-a3da-62c36fc2067b" UUID_SUB="61d57d89-4299-4d84-8e78-c3833ac297f3" TYPE="btrfs" PARTUUID="6cd85e0f-02" :/# blkid very clearly sees both vda2 and the volume UUID. I can manually mount this volume from this same shell but somehow between systemd and udev, they can't figure it out because they're waiting for something to happen before even trying to mount. What are they waiting for, the missing device to show up? Maybe that's the problem, degraded boot of Btrfs is simply not supported at all? -- Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel