Hi there.
I have a fresh install 4.2.4 and the install goes smoothly, reboot into the Os and have only dom0 - no sys-net, sys-usb, nothing.
I have tried this five times today with three downloads and am losing my stuff.
I can attach the install media to dom0 and browse the packages folder and see the rpm’s in there but they fail when I try to run them.
I get “KeyError: ‘debian12-xfce’ “
or “KeyError: ‘fedora-41-xfce’ “ etc
Curious, What exactly is your hardware?
How did you create the install USB?
Did you try to alter any of the settings when you did the install?
The ISO offers to verify itself before installing, Did you allow it to do that? Watch carefully to see if verify finished correctly?
Edit: Are you attempting a dual boot with another distro?
Ok this is going to be fun on my phone haha.
Ok I am using hardware that is fine (I ran qubes 4.1 on it for a long time with great joy)
Custom disk install, 2 M.2 in software raid1 ext4 as /,
/boot and /boot:efi are both in the first m2.
3ssd in bios raid5 with /ext4 as /store
No other custom config.
Have tried with and without root enabled.
I have tried two different SanDisk microSsd and a transend 1TB usb external sata.
No dual boot. I had Win11 but am sick of the encroaching AI and marketing push so
wanted to go back to a system I love.
Sorry, I did verify the install media (three times) and had zero errors during or after install.
Darn. Also created the install media using rufus with the dd option.
Ok. While all of those ROM installs told me they had failed, the templates now actually appear in the qubes manager!
So I am going to see if I can get things working nicely and will post an update/diagnostic review when I am done. If this works it will be MUCH faster than redownloading/reverifying/re-installing multiple times.
If I can find anything at all in journalctl that hints at where this failure kicks in or from anaconda, I will let everyone know.
i heard these symptoms - templates not populating - on install on computer with 6 GB RAM.
Not resolved but progress.
I tried to re run the post instal scripts and it thre errors about an invalid CONTAINER. i have no containers but I did see a ghost sdb of type imim raid in the gui install that I couldn’t delete. I assumed it had something to do with the install iso.
Well, that and some other disk config mess ups polluted my anaconda kickstart file so i removed those and re-ran the script and it popped up asking which templates I wanted and about UsB keyboards/mice!!! success!
Sadly not completely, the USB setting didn’t work so I am now locked out. That’s probably due to me trying to create appvm default templates before hand.
I will fresh nuke and try to replicate. If I get the install error again I will jump straight to this change to test.
yeah my 64GB ram should be no problem!
I’ll update this thread tomorrow once I have had a chance to retrace steps. Honestly I think there is a ghost container being reported by anaconda when it does disk discovery. Something left in the configs somewhere that for some reason only affects some people
My real field of expertise is making every mistake in trying to create an functional install of Qubes. I may have done all of them, at least once.
Windows prefers UEFI. I always change the BIOS/EFI to Legacy.
I have also chosen to take the disk I am installing to (in the computer) and format it to FAT32, and using a blank tool to overwrite the entire disk. Can take awhile.
Which would get rid of your hypothesized issue.
I create the USB key using the tools in Mint Linux. One to blank the USB key - Formatting it with FAT32. (I figure the Qubes Install USB knows how to handle that. It is my understanding that some of the other ways to format, EXT3 or EXT4 just write the top of the drive. but I actually do not know. Just those formats are fast, surely did not over write the entire drive
I use the Mint Linux tool, “USB image Writer” to write to a fast USB (3.2) . I had problems trying to create the install USB using Windows. If that is what you did. But software used by Windows surely has improved since then and I really not the most knowledgeable user of the the available software to create USB on Windows.
Do what you think best…
the sdb is not a windows artifact. it is something unknown. My m.2’s had no raid at all on them beforehand.
I tried to delete it in the custom config but had zero options with it so assumed it was part of the install os.
the important fact is that the errors in the kickstarter were what caused the total failure.
The first install I did I messed with custom config a lot because I was trying to understand what the Os wanted and didn’t want one massive LVM across everything like I settled for in 4.1. (because custom disk config has very little in the way of advice).
If anaconda doesn’t reset properly between the actions on disk, which is what I think is happening, then it seems to leave stuff behind in the kickstarter file that cause the post install process to die silently.
So, the imsm mdcontainer is a pre windows (last qubes install) artifact being presented from one of my three sata ssd’s that are in a main board based intel raid controller. I have no idea how that is presenting, but that’s where it comes from.
Busy going through the install again to see if I can clear that off properly by not selecting any of the disks that are part of that container. Will add them later if needs be.
Ok, I now get further along. The post install initial setup script starts but hung during template setup.
I got Debian and Fedora installed but no Whomix.
Also failed to set up the sys-net, sys-firewall and sys-usb vms.
But it is progress.
Next step is boot into live linux, remove bios raid, format all drives completely and then try again…
It’s more about trying to isolate the issue now than it is to just get running.
Hopefully this investigation helps someone in future.
Hi barrulus
Thanks for all you work, to find what causes all the trouble.
I’ve seen (on an old MacBook) the Initial Setup die hard, when it didn’t understand the (automatic) layout of the filesystem from Anaconda. As you describe, the solution was to edit the anaconda-ks.cfg in a way, so Initial Setup could understand[1] it and rerun sudo /usr/libexec/initial-setup/initial-setup-graphical.
After that, I could install Qubes and run the Initial Setup – but the installed qubes wouldn’t start/complete the installation. The second problem was solved by switching from LVM to BTRFS.
[1]: Change --label=Linux HFS+ ESP to --label="Linux HFS+ ESP"
this sounds like my next step. Changing to btrfs.
I’ve now manually removed the LVM I created on Ssds and removed two of the ssd from the group, created a lvm thin and completed setup.
Now it hangs on startup at dev-mapper having no limit so I think I will stop messing with lvm and head on over to btrfs. (will be new for me but trouble shooting teaches a lot)
So, manually created a series of BTRFS volumes (nvme0 and nvme1, (sda,sdb,sdc as RAID1 - starting to question my thinking here) on top of luks encrypted devices.
fdisked all the drives using the qubes rescue install, removed all everything ever (had md references, luks references etc).
Set up all the design subvolumes and started the install.
Even though I had a mountpoint / set on my ROOT volume, I had to remove @root subvolume and recreate it in the installer with / mountpoint in order to “begin installation”
Seems to be going ok now, hoping for some success at the end of this run
What is now clearer than ever is that any old disk labels, type settings or md membership meta is not cleaned up by anaconda during install. Will update when this is done.
RESULT!!! This post is coming from my new [untrusted] qube.
Everything installed perfectly!
Last hitch was an Intel PCI Ethernet issue, but I knew this was coming and its well documented so took 0.5 seconds to fix.
Ok, so I have kept a lot of data around this but have a life outside of my office so am going to drop this for today and will post a separate update (and link it from here)
Thanks @ChrisA and @catacombs for the nudges, they really helped!
