Re: Link to test case for drive dismount
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.
--
Chris Murphy