On Mon, Dec 9, 2019 at 7:05 PM Adam Williamson <adamwill@fedoraproject.org> wrote:
On Sat, 2019-12-07 at 09:45 -0500, pmkellly@frontier.com wrote:
> I think I have it close to what you want. Please let me know.
>
> Here's the link:
>
> https://fedoraproject.org/wiki/User:Tablepc/Draft_testcase_reboot
>
>       Have a Great Day!

Hey folks! So as mentioned in the meeting today, here's my draft with a
few revisions to Pat's draft:

https://fedoraproject.org/wiki/User:Adamwill/Draft_testcase_reboot

Thanks Adam. Here are some questions and nitpicks, as always:

If you are testing a live image, perform the steps below from the live environment before doing the install. After this go ahead with the install. Then perform the steps below from the installed system.

What's the point of running the checks from Live image as well? The local filesystems will likely get wiped and re-created anyway. Extra failures in the log might just confuse us when reading the bug report.

(Also, if we want to keep this, it should be the first step, not the third one. I wouldn't expect the reader to go and read the whole test case first, before starting with the first step.)

On the installed system, run a console and become root with sudo su or su.

https://unix.stackexchange.com/questions/7013/why-do-we-use-su-and-not-just-su

If there was output from the grep command, run the command journalctl -b -l > journal.log

"The old options -l/--full are not useful anymore, except to undo --no-full."
(man journalctl)

Run the following command: journalctl -b | grep -E "dirty bit|data may be corrupt|recovery|unmounted|recovering" and see whether there is any output.
If there was output from the grep command, run the command journalctl -b -l > journal.log. Please file a bug report (the kernel is most likely the correct package to file the report against) and attach the journal.log file to the bug report.

I'd probably add another step between those two. If there was some match, I'd ask the user to see the full journal, find the matched line, and inspect it in context. If it looks to be a standard operation printout, e.g. a successful unmount operation or a message coming from some unrelated app and not from kernel/systemd/fsck, that message should be ignored. Only if it looks like a filesystem error similar to the sample errors provided by Chris, the full log should be saved and a bug reported. Which means I'd like to add sample errors inside the test case, e.g. into another section called "Filesystem errors examples". Those error samples might come in handy in the future revisions of the test case as well, e.g. if we find out that the grep command is too broad.

    Each grep command should produce no output.
    Running reboot should cause an orderly shutdown and restart of the system.

I think these "expected results" can be easily omitted, because they are obvious from how the test steps are written. No hard feelings, though.

Draft testcase reboot

The testcase should be renamed, I think. Something like "Testcase filesystem consistency" or "Testcase clean unmount" or "Testcase reboot unmount".