Bug 960076 - dracut doesn't mount root mountpoint which is on degraded BTRFS RAID1
Summary: dracut doesn't mount root mountpoint which is on degraded BTRFS RAID1
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: dracut-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: fedora19rtt
TreeView+ depends on / blocked
 
Reported: 2013-05-06 14:31 UTC by Ľuboš Kardoš
Modified: 2016-12-20 12:38 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-20 12:38:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Logs from booting. (31.06 KB, text/x-log)
2013-05-06 14:32 UTC, Ľuboš Kardoš
no flags Details
File /etc/fstab. (595 bytes, application/octet-stream)
2013-05-06 14:32 UTC, Ľuboš Kardoš
no flags Details
output of btrfs df fi / (256 bytes, application/octet-stream)
2013-05-06 14:33 UTC, Ľuboš Kardoš
no flags Details
File /proc/cmdline (191 bytes, application/octet-stream)
2013-05-06 14:33 UTC, Ľuboš Kardoš
no flags Details

Description Ľuboš Kardoš 2013-05-06 14:31:32 UTC
Description of problem:
Dracut doesn't mount root mountpoint which is on degraded BTRFS RAID1.

Version-Release number of selected component (if applicable):
dracut 027-36.git20130418.fc19

How reproducible:
always

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.
  
Actual results:
After booting system remains frozen in dracut.

Expected results:
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.

Additional info:

Comment 1 Ľuboš Kardoš 2013-05-06 14:32:12 UTC
Created attachment 744167 [details]
Logs from booting.

Comment 2 Ľuboš Kardoš 2013-05-06 14:32:42 UTC
Created attachment 744168 [details]
File /etc/fstab.

Comment 3 Ľuboš Kardoš 2013-05-06 14:33:22 UTC
Created attachment 744169 [details]
output of btrfs df fi /

Comment 4 Ľuboš Kardoš 2013-05-06 14:33:54 UTC
Created attachment 744170 [details]
File /proc/cmdline

Comment 5 Harald Hoyer 2013-05-06 15:22:21 UTC
Hmm... that would need systemd logic or the kernel command line parameter "rootfsopts=degraded"

Comment 6 Harald Hoyer 2013-05-06 15:23:40 UTC
(In reply to comment #5)
> Hmm... that would need systemd logic or the kernel command line parameter
> "rootfsopts=degraded"

sorry... "rootflags=degraded" of course.

Comment 7 Lennart Poettering 2013-05-06 15:44:05 UTC
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?

Comment 8 Lennart Poettering 2013-05-06 16:49:13 UTC
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...

Comment 9 Ľuboš Kardoš 2013-05-07 10:12:26 UTC
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".

Comment 10 Marian Ganisin 2013-05-07 10:35:36 UTC
(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.

Comment 11 Harald Hoyer 2013-11-19 15:20:11 UTC
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

Comment 12 aaraodeo 2015-01-18 17:57:36 UTC
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.

Comment 13 Harald Hoyer 2015-01-22 14:43:19 UTC
Started a discussion on the btrfs mailing list:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/42000

no outcome yet

Comment 14 Jaroslav Reznik 2015-03-03 16:52:57 UTC
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:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 15 Jan Kurik 2015-07-15 14:47:49 UTC
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:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 17 Fedora End Of Life 2016-11-24 10:58:42 UTC
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'
of '23'.

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.

Comment 18 Fedora End Of Life 2016-12-20 12:38:34 UTC
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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.