-
Notifications
You must be signed in to change notification settings - Fork 355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable /boot on btrfs subvolume with GRUB2 #2255
Enable /boot on btrfs subvolume with GRUB2 #2255
Conversation
eaaa184
to
9287ed7
Compare
This depends on a version of grubby with btrfs subvolume support. For example, grubby >= 8.40-10. This essentially reverses the block imposed in response to rhbz#864198 and correctly fixes rhbz#1038885. Resolves: rhbz#1418336
9287ed7
to
c113e6b
Compare
@@ -114,7 +114,7 @@ class GRUB2(BootLoader): | |||
stage2_must_be_primary = False | |||
|
|||
# requirements for boot devices | |||
stage2_device_types = ["partition", "mdarray"] | |||
stage2_device_types = ["partition", "mdarray", "btrfs subvolume"] | |||
stage2_raid_levels = [raid.RAID0, raid.RAID1, raid.RAID4, | |||
raid.RAID5, raid.RAID6, raid.RAID10] | |||
stage2_raid_member_types = ["partition"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This statement confused me. This didn't exist before, and I'm not entirely sure what it does. Should I be concerned about it for Btrfs enablement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stage2 device is a reference to the portion of BIOS GRUB found in /boot/grub (/boot/grub2 on Fedora). There are three consequences with /boot on Btrfs:
a. If the user opts for zstd compression, boot menu will fail to populate as GRUB+blscfg.mod will find but fail to read the compressed config files in /boot/loader/entries/*.conf. Fix for that is to get zstd baked into the grubx64.efi on UEFI and stage 1.5 for BIOS GRUB. I have a todo for that. (lzo and zlib compression support is built into btrfs.mod, so that's always worked). The short term work around is for the user to use chattr +C
on /boot or just don't use compression. This is the only "fatal" consequence of /boot on Btrfs, but the user has to opt to get there, because the installer doesn't give them the option to use compression.
b. On BIOS, the grubenv is located on /boot/grub2/grubenv and GRUB disallows writes to grubenv when on btrfs (and raid, lvm, luks, zfs, maybe some other things) because GRUB's file writes are sector overwrites, there's no file system metadata updates, including checksums on Btrfs. Mismatching checksums means kernel code will EIO on such files. Basically Btrfs considers such writes as corrupting file data. And it's something other fs upstreams take issue with, including XFS and ext4. A better solution for getting state out of GRUB is needed. The hidden GRUB menu feature includes GRUB changing boot_success=1 to 0, and if boot succeeds, grubenv modified to change boot_success=1. That way GRUB knows whether to display the GRUB menu following a failed boot. On Btrfs, the menu won't ever be shown unless the user intervenes by pressing a key, because GRUB won't write to gruvenv on Btrfs.
c. There's a small complication with the BootloaderSpec which ostensibly is about having a shared /boot across multiple OS installations; and I'm not sure if this is something Fedora wants to support. GPT partition type GUID provides lightweight discovery of a partitions purpose, where we lack such a facility with a /boot on Btrfs. It could be done with an xattr but that's a bit "secret decoder ring" in that it requires parsing Btrfs on-disk format, rather than looking for a GUID in a fixed location in GPT. See bug
https://bugzilla.redhat.com/show_bug.cgi?id=825236#c38
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix for that is to get zstd baked into the grubx64.efi on UEFI
This one should be easy to fix then.
Also, as somewhat of a sanity check, do I need to do anything special here for handling with BLS mode? At a glance, it didn't seem like it... (cc: @martinezjavier) |
Jenkins, test this please. |
The I wasn't aware of the issues that @cmurf pointed out but I'm also not that familiar with btrfs. |
I've assigned @Conan-Kudo to the bug and set the bug to POST. |
Also @Conan-Kudo please write here explicitly when this feature is ready for merging. We then make the sanity checking ;) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good to me.
I've done sanity check and everything seems to be working fine. Everything is ready for merge. Just waiting for @Conan-Kudo confirmation. |
@vathpela wanted to take a look first. Once I get the 👍 from him, we can merge this. |
I don't see any obvious issues here. FYI I've done https://koji.fedoraproject.org/koji/taskinfo?taskID=40191468 to address the zstd grub efi issue. |
@jkonecny12 This is good to merge then! |
🎉 🎆 🥇 💯 |
Welcome to the community maintainers team @Conan-Kudo ;). Enjoy your feature! |
hey there,
thank god you enabled booting on btrfs!
I am a end user of fedora,
don't have any programmeing skills of any kind, just wanted to thank
you and the team for this!
when do you believe that this feature will end up in fedora?
note,
i'm running fedora 31
congrats on this by the way!
Majid
…On 07/01/2020, Jiri Konecny ***@***.***> wrote:
Welcome to the community maintainers team @Conan-Kudo ;). Enjoy your
feature!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#2255 (comment)
--
kind regards,
Majid Hussain
|
cmurf and javierm noticed[0] that we don't have zstd enabled, and that could cause issues in some cases for /boot on btrfs subvolumes. This adds it to our module list. [0] rhinstaller/anaconda#2255 (comment) Related: rhbz#1418336 Signed-off-by: Peter Jones <[email protected]>
Hi, it will be part of Fedora 32. |
This depends on a version of grubby with btrfs subvolume support. For example,
grubby >= 8.40-10
.This essentially reverses the block imposed in response to rhbz#864198 and correctly fixes rhbz#1038885.
Resolves: rhbz#1418336
This pull request obsoletes #1375.