I recently did a clean install of OpenSUSE 13.2 into a system with three drives - 1 SSD containing the / partition (btrfs format with default subvolumes), and 2 identical HDD’s containing /home in an encrypted BTRFS RAID1 array. Initially, I was using only one of the HDD’s as /home (still encrypted BTRFS). Once I added the second drive and started the RAID1 mirroring, my system will no longer boot without manual intervention. I get dropped into “emergency mode”, but then all I have to do is exit (Ctrl+D) to continue booting and everything works normally.
The last entry in the system log before Emergency Mode is invoked is:
BTRFS: open_ctree failed
It appears that a similar (maybe the same) bug was reported on ArchWiki here. But the solution refers to mkinitcpio rather than dracut that OpenSUSE uses, so I’m unsure how to apply it to my system.
Can anyone help me figure out the equivalent fix for dracut?Thanks!
Some relevant system information:
excerpt from /etc/fstab:
This will pre-create btrfs control device and should trigger loading of btrfs module.
And yes, you should open bug report in any case; this is prerequisite for issuing update for released openSUSE version.
I only edited the copied file (the one in /etc/udev/rules.d)
I assume by “btrfs shell” you just mean a Linux command prompt? If so, you need to use a command line text editor like nano or vim. I find nano the easiest to use. Assuming it’s installed, just execute
You will probably need to use su or sudo to get the necessary permissions.
Entering emergency mode. Exit the shell to continue.
Type “journalctl” to view system logs.
You might want to save “/run/initramfs/rdsosreport.txt” to a USB stick or /boot
after mounting them and attach it to a bug report.
From here if I "ls’ I can see all the root files and the contents but do not know how to edit the "64-btrfs.rules file as per the workaround detailed in my previous post from bugzilla.
If I Boot with a different hard drive and open dolphin, it lists the two partitions from the ssd drive as sbd1 and sdb2, but can only mount the home (EXT4) partition not the root partition.
Looking at your last post I’m not positive that this is the same bug as described in my report. In my case I got the “Emergency Mode” prompt. It says something to he effect of “type root password for maintenance or press Ctrl+D to exit” and then puts you into a shell. Assuming this is where you are:
See the previous post. At that prompt, you first need to copy the file:
This creates a copy of the file for you to edit. Then type
sudo nano /etc/udev/rules.d/64-btrfs.rules
This should open a text editor within the shell. Make your edits then press Ctrl+X. At the bottom of the editor, you will see a prompt asking you to save the file and if it is OK to overwrite. Type Y and then enter. You have now edited the file.
Reboot and with any luck your system will boot.
Note that you should also be able to boot by just pressing Ctrl+D once you get to that emergency mode prompt (as documented in the bug report). It’s not a fix but it will get you into your system. You just have to manually intervene every time your reboot.
OK, based on this and your previous post that has the error message, my best guess is that the mount is failing before your system can create the InitRD, so therefore you don’t have access to some of the usual commands. I’m not 100% sure though.
It seems clear that this is a different bug than the one that is the topic of this thread. Note that the open_ctree failed message is common to many btrfs issues, so just because you have that message in your log doesn’t mean this is the right bug. I would focus on deciphering the message
Failed to read block groups: -5
I’m afraid I’m out of ideas beyond that. Good luck.