Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Endless reboot loop after restoring qubes from R4.0 to R4.1.1 #7883

Closed
jamke opened this issue Nov 14, 2022 · 4 comments
Closed

Endless reboot loop after restoring qubes from R4.0 to R4.1.1 #7883

jamke opened this issue Nov 14, 2022 · 4 comments
Labels
P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.

Comments

@jamke
Copy link

jamke commented Nov 14, 2022

How to file a helpful issue

Qubes OS release

R4.1.1.

Brief summary

I restored qubes backup from other PC with R4.0 and restored on almost clean R4.1.1.
After that I cannot boot Qubes OS due to automatic forced reboot after entering LVM password.

Steps to reproduce

  1. Restore backup from R4.0 (with large size 100+GiB and many VMs if it's relevant).
  2. Reboot using Qubes OS menu.

Expected behavior

Qubes OS boots as usual.

Actual behavior

After entering correct password for LVM I have some messages in console for a second, black screen for a second and instant reboot of PC. It's a endless sequence, I cannot boot Qubes OS.

Additional information

The restore process provided 2 errors of setting custom kernels for 2 irrelevant appvms and finished with a success otherwise.
The final restoration message was a message box with green text: "Finished successfully!".

I had a working system after restore, but I had no links in Application menu except Start and Qube Settings, so I decided to reboot it just in case if will be fixed. Reboot was made using Logout menu of Application menu and went normal.
After PC start I got a usual password for LVM prompt, after entering the correct password I had some messages in console for a second, black screen and instant reboot of PC, it always happens now, the system is not bootable.

@jamke jamke added P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. labels Nov 14, 2022
@jamke
Copy link
Author

jamke commented Nov 14, 2022

More information:

  1. I made a video-record of boot process before forced reboot and I see that all is OK, it starts some of the imported VMs and the last messages before force reboot are:

[ OK ] Started Command Scheduler.
Starting Light Display Manager...
Starting Hold until boot process finishes up...

  1. One of VMs that had custom kernel selection and provided message during restore is starting now, it has auto-start flag.
    I think the attempt to fix the situation manualy now is to prevent this VM from auto-starting.

Any idea how is it possible to do in the current situation?
(something like boot from USB flashdisk, one something in LVM and change some option in some file)

@marmarek
Copy link
Member

See https://www.qubes-os.org/doc/autostart-troubleshooting/ how to prevent autostarting VM.

@jamke
Copy link
Author

jamke commented Nov 14, 2022

@marmarek
Thanks, that exactly what I did and it allowed me to boot.
Before that I mounted and changed autostart property inside /var/lib/qubes/qubes.xml in qubes_dom0/root from liveusb but it did not change anything (do you know why?)

So, I'm investigating the problem further.

@jamke
Copy link
Author

jamke commented Nov 14, 2022

The actual problem of instant reboot was that PCI devices that had been connected on the R4.0 PC were absent on PC that I restored backup on.
So, one of USB-controllers became VGA adapter during this backup restore. I had no warning nor errors about it.

So, the problem source to my opinion is the approach when connected PCI devices are described and stored in backups only by names like 01:00.0.
No additional checks are made in case the backup is restored on computer with this device being a completely different one or even that user switched PCI slots.

Why not keep the device string (that we see in qvm-device) or some other more or less unique device ID to prevent such problems?

I'm closing this issue, because I found out the reason, but I consider the bug to exist, that can lead to such big problems that I have.
I will open a different ticket about this enhancement with additional PCI device identification if you think #7792 is not completely the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
Projects
None yet
Development

No branches or pull requests

2 participants