Bug 868465 - ERR anaconda: /boot filesystem cannot be of type btrfs subvolume
ERR anaconda: /boot filesystem cannot be of type btrfs subvolume
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-19 21:48 EDT by Chris Murphy
Modified: 2013-01-02 16:49 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-02 16:49:42 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)
anaconda.log (19.87 KB, text/plain)
2012-10-19 21:48 EDT, Chris Murphy
no flags Details
program.log (17.84 KB, text/plain)
2012-10-19 21:49 EDT, Chris Murphy
no flags Details
storage.log (269.52 KB, text/plain)
2012-10-19 21:50 EDT, Chris Murphy
no flags Details
anaconda.log per c9 request (17.26 KB, text/plain)
2012-10-30 22:18 EDT, Chris Murphy
no flags Details
program.log per c9 request (52.78 KB, text/plain)
2012-10-30 22:19 EDT, Chris Murphy
no flags Details
storage.log per c9 request (233.26 KB, text/plain)
2012-10-30 22:20 EDT, Chris Murphy
no flags Details
storage.state per c9 request (28.00 KB, application/octet-stream)
2012-10-30 22:20 EDT, Chris Murphy
no flags Details

  None (edit)
Description Chris Murphy 2012-10-19 21:48:32 EDT
Description of problem:
Anaconda allows Boot to be Device Type BTRFS, after clicking Finishing Partitioning the hub reports: Storage > Installation Destination > Error checking storage configuration.

Version-Release number of selected component (if applicable):
anaconda 18.18
Fedora-18-Beta-TC5-x86_64-netinst.iso

How reproducible:
100%

Steps to Reproduce:
1. Boot netinst
2. Installation Destination > select single local disk > choose 'let me customize the partitioning' 
3. Manual Partitioning: click Home > Customize > Device Type BTRFS.
4. Repeat for Boot.
5. Repeat for Root.
6. Click through Home, Boot, Root, again to confirm Device Type BTRFS for all.
6. Click Finish Partitioning.
  

Actual results:
Installer cannot proceed with selected option due to the error.


Expected results:
1. Worked with smoke11, I had a btrfs volume with boot, root, home subvols, although I don't know if anything would install to it;

2 /boot on boot subvolume does work[2] so the error is bogus, installation should proceed.

3. Manual partitioning shouldn't allow the user to select an invalid option.


Additional info:

[1] Fedora-18b-smoke11-x86_64-netinst.iso

[2] grub2-install bakes proper prefix into core.img to support boot in subvol; grub2-mkconfig creates proper grub.cfg pointing to boot subvol as well. Works with arbitrarily named subvols.
Comment 1 Chris Murphy 2012-10-19 21:48:55 EDT
Created attachment 630308 [details]
anaconda.log
Comment 2 Chris Murphy 2012-10-19 21:49:26 EDT
Created attachment 630318 [details]
program.log
Comment 3 Chris Murphy 2012-10-19 21:50:59 EDT
Created attachment 630319 [details]
storage.log

21:24:15,251 DEBUG storage: stage1 device cannot be of type btrfs subvolume
21:24:15,252 DEBUG storage: stage1 device cannot be of type btrfs volume
21:24:15,252 DEBUG storage: stage1 device cannot be of type btrfs subvolume
21:24:15,252 DEBUG storage: stage1 device cannot be of type btrfs subvolume
Comment 4 Chris Murphy 2012-10-19 22:40:09 EDT
Reproducible with Fedora-18-Beta-TC5-x86_64-Live-Desktop.iso. After updating to anaconda-18.19-1.fc18 the problem appears to be fixed: boot, root, home are subvols, resulting system is bootable.
Comment 5 Chris Murphy 2012-10-19 22:54:47 EDT
With two disks selected, all other steps the same, the error occurs. According to btrfs wiki documentation this should be possible with grub 2.00.

If there is a way to override this check in anaconda, and allow it to install to a 2+ disk raid0/1, I'll test.

"GRUB 2.00 supports many btrfs configurations (including zlib and lzo compression, and RAID0/1/10 multi-dev filesystems)."
https://btrfs.wiki.kernel.org/index.php/FAQ#Does_grub_support_btrfs.3F
Comment 6 Chris Murphy 2012-10-19 23:42:25 EDT
(In reply to comment #5)
DISREGARD: this was user error. 18.19-1 had not been installed. Once installed the error does not occur with a 2 disk raid0 btrfs volume, which also places boot, root, home in subvols. System is bootable.
Comment 7 Chris Lumens 2012-10-30 14:43:38 EDT
Am I reading correctly that this bug report can therefore be closed?
Comment 8 Chris Murphy 2012-10-30 16:17:05 EDT
Yes. Was a bug in 18.18, fixed in 18.19.
Comment 9 David Lehman 2012-10-30 17:24:29 EDT
The code to disallow /boot on a subvolume is still there. If convenient, please attach the logs from the install described in comment 6.
Comment 10 Chris Murphy 2012-10-30 22:18:25 EDT
Created attachment 635899 [details]
anaconda.log per c9 request

TC6/18.19 using /boot on btrfs subvol
Comment 11 Chris Murphy 2012-10-30 22:19:20 EDT
Created attachment 635900 [details]
program.log per c9 request

TC6/18.19 using /boot on btrfs subvol
Comment 12 Chris Murphy 2012-10-30 22:20:14 EDT
Created attachment 635901 [details]
storage.log per c9 request

TC6/18.19 using /boot on btrfs subvol
Comment 13 Chris Murphy 2012-10-30 22:20:58 EDT
Created attachment 635902 [details]
storage.state per c9 request

TC6/18.19 using /boot on btrfs subvol
Comment 14 David Lehman 2012-10-31 10:47:07 EDT
Somehow we're setting the storage spoke as complete in spite of errors in the sanity check. I think I see the problem. Will update after testing.
Comment 15 Chris Murphy 2012-10-31 14:48:29 EDT
Is the idea to have or not have /boot on a boot subvol? It does work, although it instigates a bug in grubby, bug 864198 (viable work around is to manually use grub2-mkconfig).
Comment 16 Reartes Guillermo 2012-11-03 18:07:15 EDT
I also tried to create /boot btrfs subvol and found that i cant.
 
Will the requirement for /boot to not to be a btrfs subvol be enforced for F18?
Comment 17 David Lehman 2012-11-14 11:40:51 EST
Can someone find out whether /boot on a subvol with a name other than boot works with grub2?
Comment 18 Reartes Guillermo 2012-12-16 14:31:09 EST
What is the status of the support of /boot as a btrfs subvol?

Currently (18.37.2) anaconda still does not let me create one.

Is there any chance that it will be supported for F18 or has it been delayed for F19? (or ditched?)

Maybe a different bug is happening: This is the third distinct time that i noticed that an anaconda-tb-XXX file was generated but no 'unknown error' has ever been shown. I now routinely check for unreported 'unknown error', or more likely an 'incognito error' :-(
Comment 19 Chris Murphy 2012-12-16 14:43:59 EST
(In reply to comment #17)
> Can someone find out whether /boot on a subvol with a name other than boot
> works with grub2?

Sorry I missed this question somehow. Yes it does. It also works if /boot is on a subvol which is also in a subvol, e.g. Fedora18/hello. Both grub2-install and grub2-mkconfig figure this out so long as the fstab subvol= is correct.
Comment 20 Fedora Update System 2012-12-21 18:32:40 EST
dracut-024-17.git20121220.fc18, anaconda-18.37.7-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2012-20838/dracut-024-17.git20121220.fc18,anaconda-18.37.7-1.fc18
Comment 21 Fedora Update System 2012-12-22 16:11:06 EST
Package dracut-024-17.git20121220.fc18, anaconda-18.37.8-1.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-17.git20121220.fc18 anaconda-18.37.8-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-20838/dracut-024-17.git20121220.fc18,anaconda-18.37.8-1.fc18
then log in and leave karma (feedback).
Comment 22 Chris Murphy 2012-12-23 17:27:27 EST
Works for me: dracut-024-17.git20121220.fc18, anaconda-18.37.8-1.fc18

"Guided" autopart "partitioning scheme configuration" = BTRFS still produces /boot on ext4. Intentional?

Manual Partitioning, Boot, Root, Home on Btrfs subvols is bootable. Renamed subvols boot, root, home; changed them in fstab accordingly; rerun grub2-install and grub2-mkconfig. System is still bootable.
Comment 23 Chris Murphy 2012-12-26 04:20:14 EST
(In reply to comment #22)
> Works for me: dracut-024-17.git20121220.fc18, anaconda-18.37.8-1.fc18
> 
> "Guided" autopart "partitioning scheme configuration" = BTRFS still produces
> /boot on ext4. Intentional?

As a consequence of this, I think, I cannot add a new Boot mount point to an existing Btrfs volume. Bug 890302.
Comment 24 Fedora Update System 2013-01-02 16:49:43 EST
dracut-024-17.git20121220.fc18, anaconda-18.37.8-1.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.