dirty reboot always results in unbootable system if root is btrfs

Bug #1451265 reported by Luiz Angelo Daros de Luca on 2015-05-03
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
btrfs-tools (Ubuntu)
High
Unassigned

Bug Description

Probably it is not a btrfs-tool bug but it is a btrfs related one.
I'm using btrfs as my rootfs in 15.04. Whenever I do a dirty reboot (power outage, sysrq-reboot, etc...) ubuntu is not bootable anymore. Ubuntu splash is kept in loop forever but Ctrl+alt+del works. The only workaround I found is to reboot in a livecd and do a

btrfs check --repair /dev/sda6 (my rootfs)

Which seems to undo part of what was changed in fs (including logs).

Is there any better way to debug this?

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: btrfs-tools 3.17-1.1
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
NonfreeKernelModules: fglrx wl
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Sun May 3 18:32:42 2015
SourcePackage: btrfs-tools
UpgradeStatus: No upgrade log present (probably fresh install)

EEPS (seiferteric) wrote :

Yes I just experienced this as well on 15.04 server on a vm. I have a btrfs root fs, did a "power off the machine" in virtual box and it would not boot after that. I ran "btrfs check --repair /dev/sda5" and was able to boot.

EEPS (seiferteric) wrote :

Also I would add, that attempting to mount the file system will hang indefinitely in 15.04. If I take the same file system and mount it in a 14.10 system it mounts and also seems to correct the problem, it will boot and mount again in 15.04. It seems like it is hanging walking the btrfs log tree.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in btrfs-tools (Ubuntu):
status: New → Confirmed
Arnaud L (arnaud-v) wrote :

Same here with 15.04, happen regularly has video driver tends to crash (but that's another story)
recovery mode does not work, I reboot in 'initramfs mode' by removing the param of the boot line and use btrfs-zero-log to fix it (or btrfs check --repair, but it did not fix the issue once)
Sometime for / sometimes for /home
Never happened once with 14.04

Arnaud L (arnaud-v) wrote :

And never in 14.10 (that I used before since it was out)

Changed in btrfs-tools (Ubuntu):
importance: Undecided → High

Hi guys,

This is confirmed and high. Can someone give some love to it?
I still need to boot with livecd everytime there is a power outage or shutdown hanged

Markus Majer (mpathy) wrote :

Just wait for Ubuntu 15.10 - there is BtrFS V4.* included - which is a huge improvement over BtrFS V3.* - all stuff should work a bit smoother..

Btw I dont have to boot from a Live CD, all tools are available in the busybox already - where you get after entering the crypt password, if the partition doesnt boot.

In the meantime: The check --repair works every time for me that it happpens.

It happend 3 times, my system hangs when some VMs make problems and only this helped back then because they deactivated the Magic SysReq Key Sequence (https://en.wikipedia.org/wiki/Magic_SysRq_key) partially.

(REISUB only works partially in Ubuntu, I didnt knew until I read it somewhere..)

So, I reactivated the Sequence - now the hangups doesnt make problems anymore as it seems. Maybe thats a compromise until the next Ubuntu release

The bug came back today with 16.04 (fully updated just yesterday). Kernel always failed with the "unable to mount root" BT on multiple could boot attempts.

Again, I needed to boot with a livecd in order to be able to boot my machine again. I only runned btrfs check with no "--repair" and not error was shown. I mounted it, unmounted and rebooted. After that, system booted normally. It seems that btrfs "recovery itself" on boot, with the simple "btrfs check" or with the mount.

It seems that btrfs is able to recover but maybe the kernel could not find the FS. My system defines root in kernel cmdline as root=UUID=9051c9b6-070c-443a-8f8f-f7c23c1b01c6. Maybe a dirty btrfs can mess with kernel procedure to list FS by UUID?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers