Re: Please consider adding a QA test case for shutdown, which gives more time to see error mesages - i.e. uses "halt"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 1/11/19 5:08 PM, Alan Jenkins wrote:
On 11/01/2019, pmkellly@xxxxxxxxxxxx <pmkellly@xxxxxxxxxxxx> wrote:

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.

pmkelly: Prior step is manual reboot so not sure what this note means

Right, sorry!  This note properly belongs just after the "reboot"
command, i.e. it should have been in step 9 below.

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

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)

Oh, I see what you did now, moving the "expected results" underneath
the relevant step.

It's a good point, especially with the extra steps, there is actually
quite a lot to interpret in this one test case.  It might well be
there is a better way to add a "halt" test, than the edit I proposed.

Looking at your formatting, I think there was some ambiguity in the
original formatting:

-When the system boots, either from a reboot or shutdown operation,
the system successfully boots without error, and all expected disk
partitions are cleanly mounted.
+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).

E.g. do we need testers to check which filesystems are mounted after
*each* type of shutdown - reboot, shutdown/poweroff, and now halt?  Or
does "either" mean a tester can just look e.g. after the reboot, and
not after the other two, because they are really very similar?

I do not argue in favour of testing after each of the three types of
shutdown.  I think of them as not differing very much.  IMO it is a
bit unfair to tell the tester to read logs checking for errors, and
check the list of mounted partitions, three times in a row.  If that
is really what we want, then perhaps the test needs to include more
information about exactly what they are supposed to be looking at
(what commands?)

Secondly, I do want to argue in favour of looking out for `fsck`,
including when `fsck` does "recovering journal".  If nothing else, the
messages you can see with "halt" might still be unclear.   So it might
help the tester work more confidently if they know to look for `fsck`
logs at the same time.

I for one do not know 100% what "halt" is "supposed" to look like.
Most of it is I have a slow computer.  And I get very suspicious when
it looks like there is more screen-scrolling during shutdown than I
remember from last time :-).

I think it could be useful to mention looking for `fsck` log messages.
It would help define what we think "cleanly mounted" means.  I guess
"recovering journal" from fsck.ext4 will be the most common "unclean"
message.  We don't really want to see "recovering journal" because it
indicates an unclean unmount, and it's useful to mention "recovering
journal" specifically because the next message may still suggest
everything is "clean":

systemd-fsck[461]: /dev/mapper/alan_dell_2016-fedora: recovering journal
systemd-fsck[461]: /dev/mapper/alan_dell_2016-fedora: clean,
365666/2621440 files, 7297878/10485760 blocks

I think the command to check is `journalctl -b /usr/lib/systemd/systemd-fsck`

But... I understand the `fsck` part makes the test case longer to
read, and I haven't checked what would make sense for systems using
XFS in place of ext4, etc.

One alternative approach might be to add a new, separate test case
where you 1) use "halt" 2) have specific instructions about how to
boot and check the `fsck` logs afterwards.

Anyway, I should be able to attend the Monday meeting as suggested, so
you'll see the even more awkward version of me.  (I am very
unpracticed at IRC / chat in general :-).

Thanks
Alan


Alan provided additional input for the proposed new shutdown test. I have updated the document and attached it. This test case (https://fedoraproject.org/wiki/QA:Testcase_base_shutdown/reboot) does not seem to be in the Base test matrix anymore. We should consider adding it back to the matrix.

	Have a Great Day!

	Pat	(tablepc)

Attachment: PotentialNewShutdownTest.odt
Description: application/vnd.oasis.opendocument.text

_______________________________________________
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

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux