On Thu, Feb 2, 2017 at 3:38 AM, David Woodhouse <dwmw2(a)infradead.org> wrote:
I'm not sure the upgrade method matters, does it? In both cases I
think
it was changes to dracut and the way raid was assembled (perhaps moving
from automatically in the kernel to doing it in userspace, or vice
versa).
The upgrade method does matter because fedup had its own dracut
variant. Systemd offline updates (used also by upgrades) uses the
existing initramfs prior to the upgrade and a special, minimalist,
boot target. So if the system boots normally before the update or
upgrade, it should boot and assemble fine for the offline update. It
could fail following a successful upgrade however - if there's some
new previously undiscovered bug.
> > So let's please ensure that we have proper
> > test coverage for existing systems.
>
> Please describe your proposal for ensuring proper test coverage, in
> particular if you personally aren't able to test what is by definition
> a custom layout?
Nono, this *isn't* a custom layout. It's a fairly standard RAID setup.
All RAID setups are custom layouts insofar as they're only created
with custom partitioning. There is only one default layout used by the
installer.
But if we change the defaults, then I suppose that retrospetively
*makes* it a "custom layout"... at least in the sense that we can
reasonably expect it to keep breaking every release or two :(
It suggests it's not getting enough testing and asking someone else to
test it probably will have no effect. Again, if there's a particular
layout you want to make sure is working, you need to test it, or maybe
write up an openQA test for it, so it can get automatically tested by
a bot.
--
Chris Murphy