Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#44385 - [linux] boot problem with an unclean btrfs root filesystem
Attached to Project:
Arch Linux
Opened by Csaba Miklos (micsuka) - Saturday, 28 March 2015, 19:13 GMT
Last edited by Tobias Powalowski (tpowa) - Wednesday, 08 April 2015, 06:53 GMT
Opened by Csaba Miklos (micsuka) - Saturday, 28 March 2015, 19:13 GMT
Last edited by Tobias Powalowski (tpowa) - Wednesday, 08 April 2015, 06:53 GMT
|
DetailsDescription:
I have an Archlinux system with ext4 on /boot and btrfs on the root filesystem. The system doesn't boot up when the btrfs was uncleanly umounted. It stucks on the following message: :: running hook [udev] :: Triggering uevents :: performing fsck on '/dev/sda3' /sbin/fsck.btrfs: BTRFS filesystem :: mounting '/dev/sda3' on real root When passing the debug parameter to the kernel, I can see this message on the output: no db file to read /run/udev/data/+bdi:btrfs-1: No such file or directory It can be solved by booting from the install dvd and simply mounting/umounting the partition. Additional info: kernel version: 3.19.2-1 or 3.14.36-1 systemd: 218-2 Steps to reproduce: Simply reset the machine without cleanly restarting it. |
This task depends upon
Closed by Tobias Powalowski (tpowa)
Wednesday, 08 April 2015, 06:53 GMT
Reason for closing: Fixed
Additional comments about closing: 3.19.3-2
Wednesday, 08 April 2015, 06:53 GMT
Reason for closing: Fixed
Additional comments about closing: 3.19.3-2
You are right, removing the fsck hook doesn't change anything. I tried with fsck.mode=skip kernel parameter too.
Doesn't really matter, though, doesn't seem to have any bearing on this problem.
I put some extra debugging messages in the initrd boot script and I found that it blocks in the mount syscall itself (default_mount_handler()/init_functions).
And when I mounted this dirty partition from the boot dvd (with the same parameters) I caught some btrfs related assertions in the dmesg (see attached). It mounted the fs without blocking and everything seemed to be ok, though.
So I'm pretty sure that it is a kernel problem.
http://www.spinics.net/lists/linux-btrfs/msg40858.html
Sounds similar but I would think that fix would have found its way into a stable kernel by now?
edit: Indeed, that fix went in with 3.19rc4 (and some stable kernels).
http://lwn.net/Articles/629131/
So... when the btrfs is dirty, the system boot blocks in the mount syscall, tried with 3.19.2 and 3.14.37 (if I wait a little bit more, I can even see the kernel hangcheck timer complaints, the process is stuck in some btrfs transaction).
When I booted from the boot dvd (I had the archlinux-2015.01.01-dual.iso with kernel 3.17.6) and tried to mount the dirty btrfs partition, I caught that assertion in the dmesg.
After your question, I downloaded the latest boot iso (archlinux-2015.03.01-dual.iso, kernel 3.18.6) and tried to mount the dirty btrfs with this kernel and there are no assertions in the dmesg anymore (I tried 3 times).
So I couldn't reproduce the blocking itself when mounting the partition with these kernels from the boot isos, although I called the mount with the same arguments like from the initrd script.
I have no idea what could be the difference between running the mount from the initrd script or from the shell with the same parameters.