Bug 890577 - drop to dracut shell if /usr is on a btrfs subvol
drop to dracut shell if /usr is on a btrfs subvol
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: dracut-maint
Fedora Extras Quality Assurance
AcceptedBlocker
:
Depends On:
Blocks: F18Blocker/F18FinalBlocker
  Show dependency treegraph
 
Reported: 2012-12-27 18:14 EST by Chris Murphy
Modified: 2013-01-03 23:58 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-03 23:58:47 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
journalctl.txt (85.62 KB, text/plain)
2012-12-27 18:41 EST, Chris Murphy
no flags Details
fstab (687 bytes, text/plain)
2012-12-27 18:43 EST, Chris Murphy
no flags Details
Proposed patch (1.23 KB, patch)
2013-01-02 07:45 EST, Harald Hoyer
no flags Details | Diff

  None (edit)
Description Chris Murphy 2012-12-27 18:14:13 EST

    
Comment 1 Chris Murphy 2012-12-27 18:40:18 EST
Hmm, I had a full description filled out when submitting but the BZ totally dropped it. Attempt 2.

Description of problem:
Anaconda allows creation of Usr mount point as Device Type Btrfs, which causes a subvolume called usr to be created and /usr contents to be placed in there. However, on reboot following a successful installation, the system drops to a dracut shell.

Version-Release number of selected component (if applicable):
dracut-024-17.git20121220.fc18


How reproducible:
always

Steps to Reproduce:
1. Use Manual Partitioning to create a Usr mount point.
2. Set the Device Type to Btrfs
3. Create any combination and device types for other mount points as needed (in my case I used all Btrfs mount points).
4. Proceed with installation, and reboot after successful install.
  
Actual results:
Drop to dracut shell. btrfs: 'root' is not a valid subvolume

Expected results:
Should arrive at FirstBoot.

Additional info:
There may be two problems:

1. The dracut fstab appears to contain an incorrect entry:

dracut:/# cat /etc/fstab
/dev/disk/by-uuid/64383cfe-c31d-4d25-97c4-4e6b7e788b26 /sysroot btrfs subvol=root,ro 0 
/dev/disk/by-uuid/64383cfe-c31d-4d25-97c4-4e6b7e788b26 /sysroot/usr btrfs subvol=usr,subvol=root,ro 1 2

The 2nd line contains a request to mount two different subvolumes to the same mount point which doesn't seem proper.

2. When attempting to manually mount usr from dracut shell, this fails:

dracut:/# mount -o subvol=usr /dev/sda1 /sysroot/usr
[ 1153.468711] device label fedora_f18v devid 1 transid 31 /dev/sda1
mount: /dev/sda1 is already mounted or /sysroot/usr busy
       /dev/sda1 is already mounted on /sysroot
       

Is dracut unaware or not permitting the same device, but a different subvol, to be mounted multiple times?
Comment 2 Chris Murphy 2012-12-27 18:41:53 EST
Created attachment 669715 [details]
journalctl.txt
Comment 3 Chris Murphy 2012-12-27 18:43:39 EST
Created attachment 669716 [details]
fstab

When subvol=root is mounted, its /etc/fstab is different than the one reported by dracut. This is the actual anaconda produced fstab, attached.
Comment 4 Chris Murphy 2012-12-28 23:03:29 EST
Proposing as blocker, Fedora 18 alpha release criterion #17: "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode."

I have no idea how common it is for users to put /usr on a separate partition, who would put it on a Btrfs subvol. Strictly speaking it seems to meet blocker requirement. But I'll propose a work around so QA can feel better about making it NTH if that's more sensible.

Workaround:
If either anaconda or the user (post-install) were to move the usr subvol into the root subvol, delete from /mnt/sysimage/etc/fstab the usr entry, and dracut -f, the dracut fstab no longer contains the bogus fstab entry; and usr subvol acts just as if it were a folder within root, so its available at the same time the root subvol is mounted. (A variation on this paragraph can be put into release notes if it comes to that.)
Comment 5 Adam Williamson 2012-12-31 19:19:29 EST
we could argue that separate /usr is not a viable layout, I guess, per http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken .
Comment 6 Chris Murphy 2012-12-31 19:57:18 EST
(In reply to comment #5)
Does not seem to apply "An initramfs that supports mounting /usr on top of / before it starts 'init', makes all existing setups work properly." 

The failure occurs because /usr isn't mounted by the initramfs, because a.) its fstab contains an incorrect entry; and maybe b.) dracut doesn't like the idea of mounting the same device twice, even though it's mounting a different subvol. The first seems an easy dracut fix. The second, if true, may not be, in which case the bug should be bounced to anaconda to either disallow separate /usr when on Btrfs (or altogether), or place the separate usr subvol within the root subvol.
Comment 7 Harald Hoyer 2013-01-02 07:17:38 EST
(In reply to comment #5)
> we could argue that separate /usr is not a viable layout, I guess, per
> http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken .

That is _not_ true, when using an initramfs to mount /usr.
Comment 8 Harald Hoyer 2013-01-02 07:20:11 EST
(In reply to comment #1)
> Hmm, I had a full description filled out when submitting but the BZ totally
> dropped it. Attempt 2.
> 
> Description of problem:
> Anaconda allows creation of Usr mount point as Device Type Btrfs, which
> causes a subvolume called usr to be created and /usr contents to be placed
> in there. However, on reboot following a successful installation, the system
> drops to a dracut shell.
> 
> Version-Release number of selected component (if applicable):
> dracut-024-17.git20121220.fc18
> 
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1. Use Manual Partitioning to create a Usr mount point.
> 2. Set the Device Type to Btrfs
> 3. Create any combination and device types for other mount points as needed
> (in my case I used all Btrfs mount points).
> 4. Proceed with installation, and reboot after successful install.
>   
> Actual results:
> Drop to dracut shell. btrfs: 'root' is not a valid subvolume
> 
> Expected results:
> Should arrive at FirstBoot.
> 
> Additional info:
> There may be two problems:
> 
> 1. The dracut fstab appears to contain an incorrect entry:
> 
> dracut:/# cat /etc/fstab
> /dev/disk/by-uuid/64383cfe-c31d-4d25-97c4-4e6b7e788b26 /sysroot btrfs
> subvol=root,ro 0 
> /dev/disk/by-uuid/64383cfe-c31d-4d25-97c4-4e6b7e788b26 /sysroot/usr btrfs
> subvol=usr,subvol=root,ro 1 2
> 
> The 2nd line contains a request to mount two different subvolumes to the
> same mount point which doesn't seem proper.

That is a bug in dracut!

> 
> 2. When attempting to manually mount usr from dracut shell, this fails:
> 
> dracut:/# mount -o subvol=usr /dev/sda1 /sysroot/usr
> [ 1153.468711] device label fedora_f18v devid 1 transid 31 /dev/sda1
> mount: /dev/sda1 is already mounted or /sysroot/usr busy
>        /dev/sda1 is already mounted on /sysroot

That is really strange. Will try to reproduce!
>        
> 
> Is dracut unaware or not permitting the same device, but a different subvol,
> to be mounted multiple times?
Comment 9 Harald Hoyer 2013-01-02 07:42:44 EST
(In reply to comment #8)
> > 2. When attempting to manually mount usr from dracut shell, this fails:
> > 
> > dracut:/# mount -o subvol=usr /dev/sda1 /sysroot/usr
> > [ 1153.468711] device label fedora_f18v devid 1 transid 31 /dev/sda1
> > mount: /dev/sda1 is already mounted or /sysroot/usr busy
> >        /dev/sda1 is already mounted on /sysroot
> 
> That is really strange. Will try to reproduce!

try mounting it readonly:

# mount -o subvol=usr,ro /dev/sda1 /sysroot/usr
Comment 10 Harald Hoyer 2013-01-02 07:45:12 EST
Created attachment 671430 [details]
Proposed patch
Comment 11 Fedora Update System 2013-01-02 08:25:06 EST
dracut-024-18.git20130102.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/dracut-024-18.git20130102.fc18
Comment 12 Chris Murphy 2013-01-02 12:24:48 EST
(In reply to comment #9)
> # mount -o subvol=usr,ro /dev/sda1 /sysroot/usr

This works. So "bug 2" is user error. And bug 1 is a bug, which I can verify dracut-024-18.git20130102.fc18 fixes.
Comment 13 Adam Williamson 2013-01-02 13:43:28 EST
Discussed at 2013-01-02 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2013-01-02/f18final-blocker-review-8.2013-01-02-17.03.log.txt . Accepted as a blocker per criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above".
Comment 14 Fedora Update System 2013-01-02 15:20:37 EST
Package dracut-024-18.git20130102.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dracut-024-18.git20130102.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-0082/dracut-024-18.git20130102.fc18
then log in and leave karma (feedback).
Comment 15 Fedora Update System 2013-01-03 23:58:49 EST
dracut-024-18.git20130102.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

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