On Wed, 2019-12-11 at 14:13 +0100, Kamil Paral wrote: > On Mon, Dec 9, 2019 at 7:05 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> > wrote: > > > On Sat, 2019-12-07 at 09:45 -0500, pmkellly@xxxxxxxxxxxx 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. 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 check. > (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.) Yeah, good point. > 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 *sigh* ten points > 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) 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 > > 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. 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 reboot > unmount". Yeah, I was actually thinking the same. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
