Thanks for these! They look good and the formatted tests will make adding them a lot easier. I have opened an issue on the QA pagure page [0] and will plan to bring this up at the next QA meeting. Please attend if you can as your perspective will help us all make a decision!
Geoff Marr
IRC: coremodule
On 1/11/19 7:26 AM, Alan Jenkins wrote:
> Hi QA people!
>
> In the past few years I've seen four shutdown bugs. The problem is that the screen turns off too quickly, so even if it shows error messages, most people don't actually see them. Or at least, it requires extra effort if you want to report them.
>
> At least three of the four shutdown bugs could have been shown up by testing "systemctl halt", which leaves the screen turned and showing the final shutdown messages.
>
> * https://bugzilla.redhat.com/show_bug.cgi?id=1575376
> * https://bugzilla.redhat.com/show_bug.cgi?id=1665432
> * https://github.com/systemd/systemd/issues/6796
>
> In the first two cases, I believe it did not cause a big issue for *me*. However, the error messages were for disassembling DM devices. These may include "dmraid", such as intel "IMSM" fakeraid. If a *raid* device is not shut down cleanly, it requires a long resync on the next boot. This also breaks the redundancy of the raid array for the duration of the resync. So it can be quite undesirable!
>
> The third case was a failure to cleanly unmount the fileystem, causing ext4 journal recovery on the next boot.
>
> Please can you add a "systemctl halt" test to the relevant test case? I would love to see this tested as part of the Fedora release process.
>
> "halt" is a pretty weird case and I only find it useful for this type of testing. So IMO we must still keep both the normal poweroff (shutdown) test, and the reboot test as well.
>
> https://fedoraproject.org/wiki/QA:Testcase_base_shutdown/reboot
>
> Basically:
>
> 1. On a running system, change to a virtual console by pressing Ctrl+Alt+F2
> 2. At the virtual console, login as the root user
> +3. Halt the system by running the command
> +
> + halt
> +
> +4. Read the on-screen messages.
> +5. You now need to manually re-boot the system. On most hardware (which complies with ACPI), you can manually power off by holding the power button down for five seconds. Then press the power button to power on again.
> 6. After the system boots, again change to a virtual console by pressing Ctrl+Alt+F2. Note, manually booting the system may be required if the previous step fails.
> 7. At the virtual console, login as the root user
> 8. Reboot the system by running the command
>
> reboot
>
> 9. After the system boots, once again change to a virtual console by pressing Ctrl+Alt+F2.
> 10. At the virtual console, login as a non-root user. If no non-root user accounts are available, you can create a new user account using the command useradd
> 11. Power off the system by running the shutdown command. Consult the man page for different acceptable [TIME] values. For example, to power off the system immediately, type the following command.
>
> shutdown now
>
> 12. Lastly, power on the system. Check that it boots successfully.
>
> ## Expected Results
>
> 1. A login prompt is offered at the virtual console
> +2. The `halt` is accepted and halts the system. The screen is left powered on, showing the final shutdown messages. No system filesystem / LVM device is left mounted / active when the system finally halts. In some cases you might see a number of retries.
> 3. The `reboot` is accepted and initiates a system reboot. The system reboots with no additional user interaction.
> 4. The shutdown is accepted and powers off the system without error.
> -5. When the system boots, either after a halt, reboot or shutdown operation, the system successfully boots without error, and all expected disk partitions are cleanly mounted.
> +5. When the system boots, either after a halt, reboot or shutdown operation, the system successfully boots without error. All expected disk partitions are cleanly mounted. Boot logs do not show any "fsck" (filesystem repair) operations, or "recovering journal" (ext3/4 journal recovery).
>
> Thanks for all the testing :-)
> Alan
> _______________________________________________
> test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
>
I took a try a formatting your proposed procedure in the attached file.
I'm a very junior member of the QA team, and thought I could help a bit
by doing this. It seems like a good idea to me. Please point out any
mistakes I made.
Have a Great Day!
Pat (tablepc)
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
