On Wed, Dec 11, 2019 at 5:14 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
> 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.
Ah, this is where the confusion comes from. I thought we've established that this testcase is about filesystem clean unmount, and we should have a separate test case if we want to cover reboot/poweroff. I support two separate test cases.
> (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
Sorry, I was enjoying it a bit:-)
> 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...
Yes, but we use the keywords from those samples in the grep pattern. So if the sample is outdated, the grep pattern is likely outdated as well, and we need to update the test case anyway. And it might be even more obvious that we need to update it if the sample it there (otherwise you have no idea where the "unmounted" is coming from).
_______________________________________________ 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
