Red Hat Bugzilla – Bug 960076
dracut doesn't mount root mountpoint which is on degraded BTRFS RAID1
Last modified: 2016-12-20 07:38:34 EST
Description of problem:
Dracut doesn't mount root mountpoint which is on degraded BTRFS RAID1.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install system on two disks (sda, sdb). Use partitioning layout where root mountpoint is on BTRFS RAID1.
2. Reboot into rescue mode and erase one RAID member (disk sdb, using 'dd' for example).
3. Boot a system with degraded BTRFS RAID1.
After booting system remains frozen in dracut.
Successful mounting of root mountpoint in degraded mode. Expexted behavior should be similar to behavior of dracut in case that root mountpoint is on degraded md RAID1.
Created attachment 744167 [details]
Logs from booting.
Created attachment 744168 [details]
Created attachment 744169 [details]
output of btrfs df fi /
Created attachment 744170 [details]
Hmm... that would need systemd logic or the kernel command line parameter "rootfsopts=degraded"
(In reply to comment #5)
> Hmm... that would need systemd logic or the kernel command line parameter
sorry... "rootflags=degraded" of course.
We should never mount a degraded root partition by default. This should always involve user interaction, after all your system is seriously fucked.
Doing rootflags=degraded doesn't sound so wrong, does it?
OK, I am pretty sure mounting the root fs degraded should require user intervention and we shouldn't mount things automatically in this case. Hence I will close this bug.
Of course, this probably should be documented prominently. For that a new bug should be opened against the right docs I guess...
Replacing "rootflags=subvol=root" with "rootflags=subvol=root,degraded" didn't help and system still remains frozen in dracut after booting. But in rescue mode I am able to mount root filesystem with command "mount -o subvol=root,degrade /dev/sda2 /mnt/sysroot".
(In reply to comment #8)
> OK, I am pretty sure mounting the root fs degraded should require user
> intervention and we shouldn't mount things automatically in this case. Hence
> I will close this bug.
It does not have to be correct in all cases. In the past I had to manage systems without any local access (including all forms of remote "local access"). At that time lvm started only in case of successful activation of all lvs even if they weren't necessary. It was pretty unpleasant, in case of any issue (let's say broken pv where just /custom/data lv was stored) we needed local assistance, who didn't have to be trained in linux at all unfortunately (that's how it worked). It seems to be quite clear it was hard task to get it running again. Nowadays it would not happen as long as all system lvs are activated without issue. And that is exactly what sysadmin expects. Logging is correct information channel, not the boot process, sysadmins track and monitor logs, so they would not (or should not) lost the information about failure.
If it can, it should.
And it really can in this case. It does it for LVM, it does it for MD, hardware RAID controllers do it transparently and it would be nice if it would do it also for btrfs, does not matter if it is implemented in dracut, systemd, kernel, wherever. It would match common behaviour.
Conclusion after discussion:
- extend btrfs ioctl(), to report, that the device can be mounted in degraded mode
- extend systemd to force mount, if a specific kernel command line / fstab option is present for the device
This does not works in Fedora 20 yet (3.17.8-200.fc20.x86_64) . This is must fix, without it, its very risky to put root filesystem on brtfs RAID 1. When second one of the paired hdd stops working the system fails to boot. Providing degraded option in /etc/fstab as well rootflags=degraded in grub does not work which is suggested as workaround by experts. The only way out is to replace faulty second hdd and complete btrfs raid1 by booting from another sources such as Live CD.
Started a discussion on the btrfs mailing list:
no outcome yet
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.
More information and reason for this action is here:
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.
(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)
More information and reason for this action is here:
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 23 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.