Use correct subvolume for root fs

[marmarek]

Installer doesn't set properly kernel options to mount root subvolume.
https://groups.google.com/d/msgid/qubes-users/5a062df9-81a4-4cc9-b156-13e01580335a%40googlegroups.com

The problem is that:

1. Qubes installs itself to a btrfs subvolume named 'root' (This is
   according to good design)
2. Qubes adds the option 'subvol=root' to /etc/fstab so that the correct
   subvolume should be mounted at /
3. At boot Qubes mounts the top level btrfs subvolume, not 'root'. I guess
   it simply uses the "root=UUID=...." option to the kernel and not /etc/fstab
   (since that is not available).

At first I changed the default subvolume to the 'root' one from the
emergency console so that this subvolume is the one that will be mounted by
default. Later I discovered that it's possible to give the "subvol=root"
argument directly to the kernel. I will present both solutions here.

Change default subvolume
I did this yesterday and I'm writing the commands from memory only, so
there might be errors. When you are dropped to the emergency console on
first boot do this:

Make our btrfs system writable

mount -o remount,rw /sysroot

List all subvolumes. Write down the ID for the 'root' subvolume. For me it was 257

btrfs subvolume list /sysroot

Change default subvolume to 'root'. Change 257 to whatever you got from the previous command

btrfs subvolume set-default 257 /sysroot

Make sure the change was applied

btrfs subvolume get-default /sysroot

Unmount and reboot into a working system

umount /sysroot
reboot

Adding the subvol argument to the kernel
This is probably the nicest solution as it doesn't change the filesystem at
all, just how it's mounted.

In your kernel parameters you have one argument specifying the root,
looking something like this:

root=UUID=....

Just add this argument to the kernel al well:

rootflags=subvol=root

[najamelan]

This is still the case on v4rc3.

It worked fine for me when I used mbr boot (with v3.2), the kernel option get's set correctly in grub, but not on uefi (v4rc3).

That being said, the anaconda disk setup is quite a hell.

[najamelan]

This is still the case on v4rc3.

It worked fine for me when I used mbr boot (with v3.2), the kernel option get's set correctly in grub, but not on uefi (v4rc3).

That being said, the anaconda disk setup is quite a hell.

[starcraft66]

This issue remains present on v4.0-rc4.

I worked around it by mounting my EFI System Partition from the recovery shell and modifying the kernel line in EFI/qubes/xen.cfg to include the "rootflags=subvol=root" option as mentioned in the workaround above.

[starcraft66]

This issue remains present on v4.0-rc4.

I worked around it by mounting my EFI System Partition from the recovery shell and modifying the kernel line in EFI/qubes/xen.cfg to include the "rootflags=subvol=root" option as mentioned in the workaround above.

[marmarek]

Here is a test for this: https://openqa.qubes-os.org/tests/76
This will help fixing the issue (manually testing the installation is really time consuming).
Can you confirm this is what you get, and also the partitioning layout (seen on the screenshot there) is what you use?

[marmarek]

Here is a test for this: https://openqa.qubes-os.org/tests/76
This will help fixing the issue (manually testing the installation is really time consuming).
Can you confirm this is what you get, and also the partitioning layout (seen on the screenshot there) is what you use?

[starcraft66]

I just checked the partitioning layout on my machine and it seems to be identical to the QA test you linked. I just told it to erase whatever was already on the drive and use the default partitioning scheme for btrfs.

The failure at the end of the test looks exactly like what I saw on my machine. I then used that emergency shell to perform the steps mentioned in my previous comment in order to fix my system.

[starcraft66]

I just checked the partitioning layout on my machine and it seems to be identical to the QA test you linked. I just told it to erase whatever was already on the drive and use the default partitioning scheme for btrfs.

The failure at the end of the test looks exactly like what I saw on my machine. I then used that emergency shell to perform the steps mentioned in my previous comment in order to fix my system.

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-4.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-4.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-4.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-4.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update