The GRUB config with qubes.skip_autostart looks good here:
Do you still have the same issue during every boot?
Did you try my previous suggestion?
After unplugging everything and plugging everything in again, he seems to be able to come to the “normal” boot screen like these:
But they don’t work.
There are no cables for another monitor/port. I’ll have to go to bring one to him in Amsterdam today or tomorrow. Is there anything we can check in the mean time?
Pressing E on each menu option and adding the skip has already been done.
Did you try to boot with older kernel?
Maybe 6.1.62?
Yes, same result.
When did this issue start?
After dom0 update?
After changing some configs in dom0?
Or maybe after changing some hardware?
when he tried the 4.1 → 4.2 update and got stuck with
Started Command Scheduler.
Starting Light Display Manager …
Starting Hold until boot process finishes up…
What dGPU does he have?
Maybe he had proprietary drivers installed in dom0 and they were not updated during Qubes OS upgrade.
But 4.1 → 4.2 upgrade is error prone and there could be just about anything that could have happened.
If he did backup his qubes before 4.1 → 4.2 upgrade then I’d just made a clean reinstall and restored the qubes from backup.
Going to communicate this to him.
Thanks.
You can also try to add nomodeset kernel option in GRUB, maybe it’ll allow you to boot.
I Will try this weekend or the beginning of next week when there’s more time.
The 2 things in mind are;
- The
nomodesetkernel option in GRUB; - Using a VGA/DVI port on the motherboard to see if there’s any output there;
Since I’m failing in providing the support needed to solve this, the user has also came to the conclusion that a reinstall of 4.2 on another SSD may yield faster results. First disconnecting the primary drive, installing 4.2 and boot up from that. Second shutdown and reconnect the internal drive. Third mount the filesystem of the original drive and make a backup of it. Forth either restore the backup to the new install or, use it as is from the old disk. What do you think of this? The system is taking more than a week to be recovered.
How about backup/restore, when fully recovered we need to do some structured backup/restore plan that can be tested on a regular basis, preferably scripted and fully automated. Ideas are welcome.
You can backup the data from the qubes like this but not the dom0 configuration.
You’ll need to recreate the qubes manually in the new system and copy their data manually.
You can’t run Qubes Backup tool from the mounted system.
How to mount a Qubes partition from another OS | Qubes OS
You can use either official backup tool:
How to back up, restore, and migrate | Qubes OS
Or wyng for incremental backups:
[Contribution] qubes-incremental-backup-poc OR Wyng backup · Issue #858 · QubesOS/qubes-issues · GitHub
GitHub - tasket/wyng-util-qubes: Qubes integration for Wyng enables backup and restore by VM name
GitHub - tasket/wyng-backup: Fast Time Machine-like backups for logical volumes & disk images