On Wed, Dec 11, 2019 at 9:14 AM Adam Williamson
That was in Pat's version, I just re-worded it. But yeah, this is
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
I think the test case should focus on looking for the circumstantial
evidence that a previous reboot/shutdown was somehow improper.
A complete test case for all possible improper reboot/shutdown is
difficult. Little is shown on the console (Esc to hide plymouth) and
it goes by really fast. Many details of reboot/shutdown aren't logged
by default, even with systemd.log_level=debug set much of shutdown
happens after root is remounted ro and that requires special logging
(systemd debugging has a how to). In my real world example failure
case, the first indication I had that reboot went badly was a grub>
I suggest keeping the scope of this test case narrow, to that of an
I'd also drop all the preconditions like using defaults. Pretty much
any possible installer allowed configuration that trips up this test
case is an eyeball opener and should be tracked down.
How to test #1 can probably be omitted in favor of just using # in
front of commands that are expected to be run either as root user or
with sudo. *shrug*
(I'm also a fan of `sudo -i` anyway...)
I can see this, but I'm not *sure* about the 'sample
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...
I'd like the test case to have the least burden on the reporter that
also produces a useful report:
1. includes the -b journal (current, shows journal replay messages)
2. includes the -b -1 journal (previous, might show some evidence of
why unmount was not clean)
3. reproduce steps
I don't really care to burden them with having to look through the
journal manually. If they have to do that, the test case needs to be
> 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.
Expected #2 is hard to determine, short of explosions and fires,
> 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.