HELP. in place upgrade to 4.3 broke VMs

After starting an inplace upgrade to 4.3, it failed on installing kernel 6.12.25-1 and 6.12.64-1

I cannot start any other qube and networking doesn’t work. I’m afraid to reboot for fear of everything failing. Luckily my USB qube is still working for now but I won’t dare attempt to restart it.

I don’t know what to do? Please help.

Any error appear?

What was last step you perform? Which guide you follow?

Verify your steps:

In the terminal that I was running the upgrade command, it just says error: transaction failed. And above that it says failed with the two kernels. I checked the /boot, But I’m not sure I should expect those kernels to be in there.

I’ve tried to rerun the upgrade command. But it hangs because there’s no networking anymore.

I was following the official upgrade guide in docs.qibes.org

The qubes-dist-upgrade.log shows a few curl errors and horns being not to proceed with the next upgrade step. But I think I may have overwritten it with my subsequent attempt to run the command.

`sudo qubes-dist-upgrade --releasever 4.3 --all-pre-reboot`

was the last and only command run

official guide is here: How to upgrade to Qubes 4.3 — Qubes OS Documentation . Under docs.qubes-os.org

Yes that’s the one I was following, forgive typos, I am using TTS.

How can I fix the kernels or get networking started up?

Curl most likely not the source of your issue, curl error indicate that network was lost at the point.

I see two paths we can go:

  1. Perform clean installation, restore your old qubes from backup.

  2. Troubleshooting that may take hours or days. Still need examples of errors, more over curl errors. something was fail before of that.

(1) is the more time consuming option, considering I would need to export my backups off, and networking is easier to do that. The VM they are stored on, will not start. The data isn’t gone, but it’ll be easier to troubleshoot this as is rather than going that route.

I’ll look through the logs some more.

I think, consider it as intuitive troubleshooting, that you skip define for:

    --usbvm, -u                        Current UsbVM defined (default 'sys-usb').
    --netvm, -n                        Current NetVM defined (default 'sys-net').
    --updatevm, -f                     Current UpdateVM defined (default 'sys-firewall').

for qubes-dist-upgrade --releasever 4.3command, as a result your network was lost during patches download.

Should it have done that? Those service VMs were not renamed, and sys-usb didn’t shutdown.

Did you press ctrl+c during pre-ckecks?

“^C” that appear few times scares me.

Yes, when it hanged for several minutes… It didn’t seem to notice that sys-net and sys-firewall were running but broken and not providing network.

It seems more likely that the /boot which was getting close to full, is what caused the failure. I’ve had that happen before with regular updates.

Can you tell me if /boot is the location of these 6.12 kernels?
Or somewhere else I can check?

There isn’t any informative logging after Error: Transaction failedand an exit code of 1

Update process should run without any interaction for around 30 minutes, sometimes even more. I don’t know what to check from now on, lets wait for more comments from advanced users.

I consider fresh installation as only reliable solution at this point.

Right now I am seeing if I can get networking through the sys-usb without restarting it.

I have an IP, so I will see if the upgrade can run again.
But should I set --netvm, -n and --updatevm, -f both to sys-usb?

Still seems like it wants to use sys-firewall as the UpdateVM

You right on the way to compromise your dom0.

Never use hvm as update vm, in this case you must use at less sys-firewall and sys-usb. Another point is that sys-usb can’t function as firewall while it provide network connection, so you about to donwload patches without using any type of firewall between you and network connect.

Relax, this is recovery. The firewall isn’t validating the repo sigs anyway. Qubes can validate packages afterwards.
Its running again.