On Tue, Nov 5, 2019 at 6:45 PM Chris Murphy
<lists(a)colorremedies.com> wrote:
>
> On Mon, Nov 4, 2019 at 10:26 PM pmkellly(a)frontier.com
> <pmkellly(a)frontier.com> wrote:
>>
>>
>> On 11/4/19 15:34, Chris Murphy wrote:
>>> On Mon, Nov 4, 2019 at 7:04 PM pmkellly(a)frontier.com
>>> <pmkellly(a)frontier.com> 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.
Can we please have "Test case for drive dismount" as an official agenda
item for our next QA meeting? Discussing this via the list is not working.
Chris Murphy was the only respondent and he brought up some points that
seem like they would be good for group discussion. The link to the draft is: