Bug 868465
| Summary: | ERR anaconda: /boot filesystem cannot be of type btrfs subvolume | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Chris Murphy <bugzilla> | ||||||||||||||||
| Component: | anaconda | Assignee: | David Lehman <dlehman> | ||||||||||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||
| Severity: | high | Docs Contact: | |||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||
| Version: | 18 | CC: | g.kaviyarasu, jonathan, rtguille, vanmeeuwen+fedora | ||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||
| Hardware: | Unspecified | ||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||
| Whiteboard: | |||||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||
| Last Closed: | 2013-01-02 21:49:42 UTC | Type: | Bug | ||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||
| Embargoed: | |||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Chris Murphy
2012-10-20 01:48:32 UTC
Created attachment 630308 [details]
anaconda.log
Created attachment 630318 [details]
program.log
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
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. 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 (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. Am I reading correctly that this bug report can therefore be closed? Yes. Was a bug in 18.18, fixed in 18.19. The code to disallow /boot on a subvolume is still there. If convenient, please attach the logs from the install described in comment 6. Created attachment 635899 [details]
anaconda.log per c9 request
TC6/18.19 using /boot on btrfs subvol
Created attachment 635900 [details]
program.log per c9 request
TC6/18.19 using /boot on btrfs subvol
Created attachment 635901 [details]
storage.log per c9 request
TC6/18.19 using /boot on btrfs subvol
Created attachment 635902 [details]
storage.state per c9 request
TC6/18.19 using /boot on btrfs subvol
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. 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). 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? Can someone find out whether /boot on a subvol with a name other than boot works with grub2? 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' :-( (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. 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 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). 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. (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. 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. |