Anaconda prevents installlation from an ISO stored on same disk to a different partition (Install in unpartitioned space impossible)

[tlaurion]

How to file a helpful issue

Qubes OS release

Q4.1, Q4.2

Brief summary

Recent Heads permits to boot detached signed ISOs from local disk: media-scan /dev/sda1

This works well to boot Tails, but anaconda refuses to install QubesOS on unpartitioned space.

Steps to reproduce

Heads recovery shell media-scan /dev/sda1

(Where /dev/sda1 contains q41 iso and iso.asc)

Expected behavior

Anaconda should not care about /dev/sda1 being mounted and permit to use unpartitioned space.

Actual behavior

• Anaconda prevents doing anything to /dev/sda since on same storage device (q4.1)
• Anaconda permitted to shrink /dev/sda1 and then pass all free space to installation, but refuses to install on available free space from unpartitionned space. (Q4.2)

Will edit with screenshot and hypothesis/patches when testing new Q4.2 detached signed ISOs that have landed under https://qubes.notset.fr/iso/ today.

---

Starting with https://qubes.notset.fr/iso/Qubes-4.2.202302191645-x86_64.iso and https://qubes.notset.fr/iso/Qubes-4.2.202302191645-x86_64.iso.asc that should boot after being verified against https://github.com/osresearch/heads/blob/8b479b06ccd8afb3672f0f5d153fc27d44a12453/initrd/etc/distro/keys/qubes-testing.key

[tlaurion]

Q42 installer doesn't show behavior

[tlaurion]

@marmarek : as requested, issue opened. Unfortunately we just missed 4.1 RC release :(

[tlaurion]

@marmarek: qubes 4.2 is bringing through anaconda the possibility to reclaim space from mounted partition.

Otherwise both 4.1 and 4.2 shows the bug: the installer is not using free space. Q4.2 automatically steals available space from /dev/sda1 and creates partitions with total free space, but if no additional free space available from sda1, it will refuse to install.

[tlaurion]

@marmarek: no. I gave all space to /dev/sda1 and now the installer proposes me to reclaim space of sda1, but is unable because it is mounted as well.

Not sure I understand how it was happy with the 10 GB free inside of /dev/sda1 and reclaimed it automatically to install q4.2 but then failed on second stage install.

Trying same iso in USB installer, option 10 and will wipe install on /dev/sda

[tlaurion]

Heads booting from USB doesn't show behavior (of course).

@marmarek : any insight on how to remove this limitation from anaconda?

[marmarek]

Was it working before? I'm pretty sure it didn't. Anyway, this can be implemented in R4.2, but backport to R4.1 depends on how complicated the change is.

[tlaurion]

@marmarek no it never worked before.

But having heads, not pre-provisioned, with a distinct partition offering both tails and latest qubesos directly available to boot from is really interesting for the whole "distrust everything" communities and would permit third party coreboot flashers to flash heads and distribute qubes and tails easily for DIY install/recovery/live situation for those who want Qubes available but not necessarily preinstalled.

Boot tails, download latest heads firmware. Verify qubes detached signature. Reboot. Reflash heads. Boot and install qubes. Factory reset USB security dongle. Enjoy Qubes.

[tlaurion]

@marmarek any direct pointers on where I would have to look to find source of the issue?

[marmarek]

Sorry, I don't know where exactly that's excluded. I'd start by looking at anaconda log (any of those in /tmp, possibly storage.log?) for messages about excluding that disk and then search in the code where it's done. This might be related function: https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/storage/devicetree/model.py#L370 (see "hidden" and "protected" there).

[tlaurion]

Would have been handy again. Reinstalling from usb thumb drive, but left 30gb for /isos mount point this time so in can test this later on and provide logs for collaboration on testing this.

Heads validating iso integrity from usb takes way longer then from nvme, as expected. I guess deploying qubesos for OEMs woukd also be facilitated by this and Heads end users could reinstall from provided oem custom iso directly from that partition if bug was resolved.

Would also permit ends users to put detached signed isos under /isos partition, detached signed with their keys if distro don't provide such detached signatures, and reinstall blazingly fast.

And then maybe no need for oem re-ownership if heads could just boot from qubesos installer instead of reencrypting and reowning secrets? End users coukd just freshly install from verified qubesos image from fused qubes distro keys présent under heads. Same for booting tails if needed, which boots in amnesia state under 30 seconds in nv41 from nvme.

@marmarek