On Tue, Nov 5, 2019 at 6:45 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Mon, Nov 4, 2019 at 10:26 PM pmkellly@xxxxxxxxxxxx > <pmkellly@xxxxxxxxxxxx> wrote: > > > > > > On 11/4/19 15:34, Chris Murphy wrote: > > > On Mon, Nov 4, 2019 at 7:04 PM pmkellly@xxxxxxxxxxxx > > > <pmkellly@xxxxxxxxxxxx> wrote: > > >> > > >> Here is the link to the draft: > > >> > > >> https://fedoraproject.org/wiki/User:Tablepc/Draft_testcase_reboot > > >> > > >> > > > > > > Why is "Be sure to reclaim all disk space" important for this test > > > case? It really shouldn't matter what the layout is. > > > > > > > Chris, > > > > I just wanted to be sure it was a clean install so there would be enough > > space for the install and there wouldn't be any dual boot or other stuff > > hanging around that might make trouble. If you think it will be all > > right I will defer to you on this. > > Let's see what Adam thinks. > > My opinion is that no matter what the layout is, everything should > either be cleanly unmounted, or remounted ro, or FIFREEZE() followed > by FITHAW() and in all three of those cases the next boot's system log > will show clean file systems that do not have dirty bits set, and do > not need log replay (file system journal recovery). The information > that's needed if any of that is not true: the next boot's system log > (shows if anything is dirty and needs replay/fixup), the prior boot's > system log, and potentially the shutdown-log.txt produced from > following these instructions: > > Shutdown Completes Eventually > https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 > > The more interesting part of this is whether we can block release on > such a bug. A dirty file system isn't always a form of corruption, and > we also aren't using atomic updates or file systems by default. I'm > not sure what release criterion would apply. > > From basic: > "It must be possible to trigger a clean system shutdown using standard > console commands." > > Does "clean" refer to file systems at all? And if so which ones? If > /home is not cleanly unmounted, there might be a bug, but it also > might be a benign problem because there's nothing on /home we need for > booting, and when it's mounted at the next startup, its fs journal > will be replayed. Maybe this could apply to the EFI system partition > and boot volumes? Does shutdown also apply to reboots? I think this > criterion is mostly about making sure a complete shutdown+poweroff is > possible by CLI. > > From beta: > "A system installed without a graphical package set must boot to a > working login prompt without any unintended user intervention, and all > virtual consoles intended to provide a working login prompt must do > so. " > > Really only applies following installation, I think. Not after a bunch > of packages are installed, customizations made, and dozens or hundreds > of reboots later, such a problem manifests. > > From final: > "All known bugs that can cause corruption of user data must be fixed > or documented at Common F31 bugs." > > It's not a bug that GRUB and most other bootloaders, can't read file > system journals, and therefore demand that at least one of: umount, > remount ro, FIFREEZE() then FITHAW() (suddenly it sent before I was done) ... at least one of: umount, remount ro, FIFREEZE() then FITHAW() must succeed. It is a known bootloader deficiency. Any of those three things will ensure journal entries are flushed to the file system before a reboot/shutdown, and therefore GRUB will have an accurate view of file system state. -- 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
