On Thu, Feb 2, 2017 at 3:38 AM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
