On Wed, Dec 11, 2019 at 9:14 AM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > 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. 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> prompt :D I suggest keeping the scope of this test case narrow, to that of an unclean unmount. 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. > > https://unix.stackexchange.com/questions/7013/why-do-we-use-su-and-not-just-su > > *sigh* ten points 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...) https://unix.stackexchange.com/questions/35338/su-vs-sudo-s-vs-sudo-i-vs-sudo-bash/35342 > 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... 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 tweaked. > > 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, singularities appearing... > > > 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. Concur. -- Chris Murphy _______________________________________________ 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
