Bug 890577

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?

Created attachment 669715 [details]
journalctl.txt

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.

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.)

we could argue that separate /usr is not a viable layout, I guess, per http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken .

(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.

(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.

(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?

(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

Created attachment 671430 [details]
Proposed patch

dracut-024-18.git20130102.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/dracut-024-18.git20130102.fc18

(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.

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".

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).

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.