On Thu, Mar 06, 2014 at 06:27:42AM +0100, Philipp Matthias Hahn wrote: > As a work-around for now I've added btrfs to > /etc/initramfs-tools/modules manually, which hopefully starts the device > scan of btrfs earlier and make my PC boot again automatically.
This still fails some times, but not that often as before. It still bad enough, since the PC is headless and powers itself on and off automatically, so the PC isn't available until I reboot it manually if this bug occurs. While looking for an update I found <http://www.spinics.net/lists/linux-btrfs/msg34212.html> and following, which described a similar bug when starting btrfs in degraded mode What currently confuses me is the order in which "btrfs device scan" and "btrfs ready" are called in /lib/udev/rules.d/??-btrfs.rules: # grep "btrfs .*dev" /lib/udev/rules.d/??-btrfs.rules /lib/udev/rules.d/64-btrfs.rules:IMPORT{builtin}="btrfs ready $devnode" /lib/udev/rules.d/70-btrfs.rules:RUN+="/sbin/btrfs device scan $env{DEVNAME}" I tried switching them around, which then doen't work either, as then systemd complains about the devices not being mounted. My current work-arount is a modified /etc/systemd/system/emergency.service: # diff /lib/systemd/system/emergency.service /etc/systemd/system/emergency.service 20,21c20,21 < ExecStart=-/sbin/sulogin < ExecStopPost=/bin/systemctl --fail --no-block default --- > ExecStart=-/sbin/sulogin -t 60 > ExecStopPost=/bin/systemctl --fail --no-block reboot This allows my PC to at least boot unattended again, as it just reboots which normally "fixes" the failed mount situation after one iteration. Philipp -- Philipp Matthias Hahn <pmh...@debian.org> GPG/PGP: 9A540E39 @ keyrings.debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
