On Wed, 2019-12-11 at 14:13 +0100, Kamil Paral wrote:
On Mon, Dec 9, 2019 at 7:05 PM Adam Williamson
> On Sat, 2019-12-07 at 09:45 -0500, pmkellly(a)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:
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.
That was in Pat's version, I just re-worded it. But yeah, this is a
reasonable point (in fact you can't check the logs after rebooting the
live image because they won't be there). I think this is a bit of an
artifact of the fact that this test case is trying to cover both 'does
it shut down / reboot correctly?' and 'do filesystems unmount
correctly?', and Pat was maybe more interested in emphasizing the
second. I think checking that the live image shuts down properly is
worthwhile, but we should reword it to reflect that's all there is to
(Also, if we want to keep this, it should be the first step, not the
one. I wouldn't expect the reader to go and read the whole test case first,
before starting with the first step.)
Yeah, good point.
*sigh* ten points
If there was output from the grep command, run the command journalctl
> > journal.log
"The old options -l/--full are not useful anymore, except to undo
Again, taken from Pat's version. Quit blaming me. :P
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.
I can see this, but I'm not *sure* about the 'sample errors', because
that's the kind of content that goes stale very quickly. I usually work
quite hard to write test cases such that they shouldn't need much
updating, because no-one ever does update them...
Each grep command should produce no output.
> Running reboot should cause an orderly shutdown and restart of the
I think these "expected results" can be easily omitted, because they are
obvious from how the test steps are written. No hard feelings, though.
I'd rather keep them, just because that's how we do test cases. Also, I
mean, it *is* useful to be explicit about which of the steps in a test
case are the key ones and which aren't.
Draft testcase reboot
The testcase should be renamed, I think. Something like "Testcase
filesystem consistency" or "Testcase clean unmount" or "Testcase
Yeah, I was actually thinking the same.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net