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

Better stress testing on behavior of Qubes OS after an illegal shutdown #7800

Open
logoerthiner1 opened this issue Oct 1, 2022 · 0 comments
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.

Comments

@logoerthiner1
Copy link

logoerthiner1 commented Oct 1, 2022

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.

@logoerthiner1 logoerthiner1 added 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. labels Oct 1, 2022
@andrewdavidwong andrewdavidwong added this to the Release TBD milestone Oct 2, 2022
@andrewdavidwong andrewdavidwong removed this from the Release TBD milestone Aug 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

No branches or pull requests

2 participants