Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upInstall on btrfs is broken, won't boot, I know the cause and here is the fix #2658
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
|
Duplicate of #1871 |
marmarek
closed this
Mar 2, 2017
marmarek
added
the
duplicate
label
Mar 2, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
Rudd-O
Mar 2, 2017
Dayum, you're fast, man. Thank you! :-)
BTW, I'm introducing Qubes OS to the people at my new company. They are having a good time looking at it.
Rudd-O
commented
Mar 2, 2017
|
Dayum, you're fast, man. Thank you! :-) BTW, I'm introducing Qubes OS to the people at my new company. They are having a good time looking at it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Rudd-O commentedMar 2, 2017
•
edited
Edited 1 time
-
Rudd-O
edited Mar 2, 2017 (most recent)
Qubes OS version (e.g.,
R3.2):R3.2 installer.
Affected TemplateVMs (e.g.,
fedora-23, if applicable):None.
Install either in UEFI or BIOS mode. (Following details are exclusive to UEFI). During partitioning, select btrfs. The partitioner creates a btrfs volume "qubes_dom0" in a disk partition, and then assigns (by default) the "root" subvolume of the btrfs volume to be the place where the system will be installed.
All good. Install proceeds. Install ends. Prompt for reboot.
System reboots.
initramfs hangs after declaring that the root file system could not be found.
Upon closer inspection during initramfs boot (using the rd.break option), it turns out that sysroot.mount does succeed (the btrfs volume is mounted correctly on /sysroot) but there is a lone directory "root" within it. That "root" directory contains the successfully installed system.
A quick inspection of the
/boot/efi/EFI/xen.cfgfile shows that the kernel command lne for the installed kernels does not have the rootflags=subvol=root option which is necessary for btrfs to anchor the "root" subvolume (where the system is installed) to the /sysroot directory upon mount time.Once
xen.cfgis fixed to include this mount option, bam, the system boots flawlessly.(Question: where the hell do these parameters come from? In GRUB boot, they are in
/etc/default/grub.)This appears to be a defect in anaconda. When btrfs is selected,
rootflags=subvol=<name of subvolume of installed system>must be added to the kernel command line. Otherwise boot willl never succeed.Let it remain for the record that I am strongly against any effort being invested into LVM tooling, and I think effort should be invested into exploiting the capabilties of btrfs or other CoW file systems instead. They have superior data integrity guarantees.