Better stress testing on behavior of Qubes OS after an illegal shutdown #7800
Labels
C: core
P: default
Priority: default. Default priority for new issues, to be replaced given sufficient information.
T: enhancement
Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.
How to file a helpful issue
The problem you're addressing (if any)
Qubes OS gets unstable when illegally shutdown. Since Qubes OS may not support certain hardware very well, sometimes the computer dies and immediately reboot, or user is forced to illegally shutdown the machine and then reboot. In both cases Qubes OS is under an unstable internal state, which can cause various problems. Possible causes of illegal shutdowns can be caused, for example, when #7340 happens.
The solution you'd like
For example, monkey testing of Qubes OS when a monkey cuts off the power of the computer at a random time spot when Qubes OS is busy doing various tasks (for example playing with creating vm, starting vm, pausing vm(suspension involves pausing them, right?), destroying vm, running lvm cleanup, commiting lvm image, attaching devices and detaching devices, flushing usb devices, ballooning, dom0 eating 100% of cpu, or even updating xen or linux kernels) and then boot the system again to check whether the system gets unstable, whether the boot time become longer or maybe even get into softlock or permanent destroyal.
At least, give out a list of Qubes OS states in which illegal shutdown is known to be catastrophic and list them as part of Qubes OS documentation, and make sure that these state must be explicit and voluntarily entered by user (for example flushing microcode of CPU or updating xen, kernel, initrd, etc can be some of such cases, as user types
qubes-dom0-update
) rather than hidden from user for example a background gc that can run at any time or a dom0 kernel worker that user has no control of (For example, if you say that, when a ext4 kernel worker is working, sudden death of Qubes OS destroys the system, then how can a normal user know a ext4 kernel worker is running at what time tick, and how can the user make sure that when he is doing a risky operation (for example suspending) no such actions are in progress?).The value to a user, and who that user might be
User of devices that Qubes OS sometimes dies. As many deaths of Qubes OS gets unsolved for a long time, the alternate ways that make deaths of computer less painful become more and more important.
The text was updated successfully, but these errors were encountered: