On 12/12/19 08:28, Kamil Paral wrote:
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:-)
I don't mind; after all I'm the one still learning my way around here.
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).
I still have the samples saved if that helps.
If you like I would be happy to pull all this together into a new
version. I could also make another test case for the reboot. I just put
reboot back in because I thought one of the comments wanted it. From
what I've read it seems like we would only do the reboot test case on
the live image since the unmount messages would get wiped in the reboot.
Did I miss something. More good learning experience. :-)
Would we put the samples in the "box out"?
Have a Great Day!
Pat (tablepc)
_______________________________________________
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
