Test-installing on USB3 stick, "error checking storage configuration"

User Support General
1

I have an AMD machine without proper SATA connection, on which I’d like to do some tests, so I’m trying to install to a 32GB USB stick (from another 4.1rc3 install stick).

Once I select the target drive in the installer, the “installation summary” page claims “Error checking storage configuration”. When I get back to “installation destination screen” and use “click for details”, I’m told “new lv is too large to fit in free space”, and the “Modify storage layout” button just brings me back to the main “installation destination” screen.

This 32GB-labelled stick is shown as 29GB in the installer, but I imagine I’d get a clear “not enough space” error if that was the problem, right ?

Now switching to the text console and browsing the “storage-log” tab does not reveal any error or obvious problem.

If I go through “manual partitionning”, the “create mountpoints automatically” option gets me to the same situation: nothing visible in the details tab, nothing apparent to act on.

Any ideas about what goes wrong here ?

Trying manual partitionning, I’m asking for creation of a 10GB / and a 500mb /boot. That leaves a warning about not having a swap… and despite no :warning: sign remaining I’m unable to click the grayed-out button to proceed with the installation.

So I try adding a 512mb swap… and then I’m told I’m missing 2.6GB (while at the same time the UI shows 17GiB available space, and the storage-log tab shows “vg qubes_dom0” has -4MiB free"). Then I try removing the “swap” entry to see if that would change anything, and the UI just becomes unresponsive - I can still switch to text mode but that seems to be all I can do.

Trying to change the “desired capacity” of the rootfs, clicking on “update settings” button also makes the UI unresponsive (but this time the mouse pointer has been changed to a “busy” spinner).

I also note that in the manual-partitionning interface the qubes-dom0 vg is always listed with “0 B free”.

When requesting creation of a 15GiB rootfs at last I can hit “begin installation”… but the partitionning UI seems to be in need of a revamp :confused:

2

Storage: 32 GB free space

3

Well, if that is indeed the reason, I’d expect the installer to just say it explicitly. But the fact I was indeed able to proceed with installation by just using manual partitioning makes me believe the problem is probably more subtle.

4

Another detail puzzling me after getting out of disk space quite rapidly: the lvm volume group was created with only a 20GB partition, leaving ~11GB unused on the install media. What can be the reason behind such a choice ?

5

The default 20GB is only for the root pool, which does not store any of the VM volume images.

The vm volume storage pool is created in what remains on the device. So, 32GB (esp due to GB vs GiB meaning some “32GB” sticks are “29GiB”) isn’t enough, I’d recommend 64GB for testing installs.

B

1 Like
6

Maybe it’s because I had to go with manual partitioning, but there is a single VG with a single pool on this install (and on my laptop-upgraded-from-4.0 too). What’s the exact setup I should expect from a 4.1 install ?

7

I redid the install, after realizing the just-debian-template setup is non-functional (#5233), this time selecting only the Fedora template. This time the installation of the fedora-34 template itself, during first-boot configuration, ended in error with a python stack trace displayed in error popup.

I expected to see thin-pool errors in the system logs (because PV does not use whole disk on new install · Issue #7226 · QubesOS/qubes-issues · GitHub), but in fact not. I should have screenshot this, as I cannot find this one anywhere in /var/log/.

Situation now is I can’t even install templates by hand, qvm-template list complains about missing /etc/qubes-rpc/qubes.TemplateSearch.

Do we have information somewhere about running the first-boot configuration by hand ? I mean, something like re-running the GUI program, or a reference list of qubesctl commands that are used to do the requested changes ? I’d be happy to avoid re-re-running the full install just to collect that error :slight_smile:

8

@unman I redid the install with just the Debian template-11 to reproduce that issue I thought linked to Downloading some dom0 packages with Debian-based updatevm fails · Issue #5233 · QubesOS/qubes-issues · GitHub. This time I used the verbose install and activated serial console on dom0 commandline, This possibly introduced more variation on the install, notably I had to use the text installer UI, which proposed different choices for partitionning (could not find how to delete the partitions from the previous install (the one that failed to download the fedora template), but I could reuse/reformat them.

The result has different issues:

Then I have a quick look around to better understand the situation, and notice that:

  • no qube has anything in their appmenu
  • the appmenu config GUI shows no available app in debian-11
  • qvm-sync-appmenus debian-11 fails with Error getting application list, can’t see anything in /var/log/qubes/*debina-11.log
  • qvm-run debian-11 xterm however launched fine
  • but then when I rerun qvm-sync-appmenus debian-11, with -vvv to be sure to have details to give, then it finally does its job (but I had done a break and was not sure of its impact)
  • trying to do the same with debian-11-dvm I get a similar behaviour – namely, with some details and no break in between:
    • a first qvm-sync-appmenus -vvv debian-11-dvm reminds me it needs the qube started
    • a second one after qvm-start gets me the same exception (and this triggers the launch of sys-firewall, which does succeed this time
    • qvm-run debian-11-dvm xterm this time does not work: command failed with code: 1
    • and a third qvm-sync-appmenus call this time succeeds (though it apparently does very little, but then it’s not a template)
  • I realized by chance that several qubes don’t have the same idea of what the default default_dispvm is: sys-firewall seems to be the only one with the good idea (D debian-11-dvm) while all others show D None
  • I cannot access the appmenu edition for sys-firewall in Qube Manager (greyed out) and have nothing in the appmenu, I have to use qvm-run to get any app

All in all, it looks like there is some sort of race condition, that possibly only show up because this is a low-spec machine.

Now for my initial problem with sys-gui-gpu setup:

How do you propose we make progress here ?

9

In fact calling qubes-dom0-update dummy-psu-dom0 by hand does work, contrasting with qubes-dom0-update kernel-latest, and we do see a potentially important warning in the xterm, which does not make it to qubesctl output:

IMG_20220130_120646
IMG_20220130_1206461920×907 206 KB

This Unable to detect release version, which I sever saw with a Fedora qube, seems to imply we’re relying too much on the chosen qube (akin to “host contamination” during cross-compilation).

But it appears the problem would be much simpler: there is just no such package as dummy-psu-dom0, and the sys-gui-gpu instructions just fail with a fedora updatevm just the same way - how I can make assumptions about things that “should work” sometimes baffles myself :slight_smile:

10

I think you should split the topic ?
fyi, dummy-psu-dom0 is changed to dummy-psu-sender, if you installing using salt, you should change package name.

I once try sys-gui and it work, no idea with sys-gui-gpu, i’m stucked somewhere.

11

ah, your answer and my update came concurrently :slight_smile:

Apparently the sys-gui-gpu.sls in 4.1 did not get the information. Reported as sys-gui-gpu.sls still references dummy-psu-dom0 · Issue #7230 · QubesOS/qubes-issues · GitHub.

12

it’s still experimental and i can’t help you setting sys-gui-gpu.
in /srv/formulas/base/virtual-machines-formula/qvm/default/sys-gui-gpu.sls change dummy-psu-dom0 to dummy-psu-sender

13

np I’d already set up one (even though the passthrough does not work yet) – I’m merely setting up one on a different hw to see how much is does (or not) work there.

Not even necessary, as is the dummy-psu-sender package appears to be already there. I’m more worried about possible other implications, as the recipe seems obviously not to be tested much those days.