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 #7802

Closed
logoerthiner1 opened this issue Oct 1, 2022 · 1 comment
Labels
P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. R: duplicate Resolution: Another issue exists that is very similar to or subsumes this one.

Comments

@logoerthiner1
Copy link

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, , 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.

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 labels Oct 1, 2022
@logoerthiner1
Copy link
Author

oops sorry for the repetition, I do not have a stable internet connection

@logoerthiner1 logoerthiner1 closed this as not planned Won't fix, can't repro, duplicate, stale Oct 1, 2022
@andrewdavidwong andrewdavidwong added the R: duplicate Resolution: Another issue exists that is very similar to or subsumes this one. label Oct 2, 2022
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. R: duplicate Resolution: Another issue exists that is very similar to or subsumes this one.
Projects
None yet
Development

No branches or pull requests

2 participants