Should a working fedup in Fedora N's stable repository be a release criterion for N+1?

[Andrew Lutomirski]

On Wed, Dec 18, 2013 at 12:24 PM, Adam Williamson <awilliam at redhat.com> wrote:
> On Wed, 2013-12-18 at 11:22 -0800, Andrew Lutomirski wrote:
>> OK, so I'll re-ask my original question.  Fedora 20 was released with
>> a broken update path from F19.  Should the release criteria be
>> amended?  This particular issue would have been avoided if F19's fedup
>> were frozen along with F20 and if all of the destined-for-stable
>> versions were tested together as a release criterion.
>
> It really isn't that simple. There are more working parts to this than
> you realize.
>
> fedup uses a custom initramfs. A kernel and initramfs that are used for
> all fedup runs are built as part of repo compose. See:
>
> https://dl.fedoraproject.org/pub/fedora/linux/releases/20/Fedora/x86_64/os/images/pxeboot/
>
> When you run fedup, its first stage downloads all packages, and
> downloads the vmlinuz and upgrade.img from there (well...not ALWAYS from
> there, see below) and puts them in /boot. The 'System Upgrade'
> bootloader menu entry uses that vmlinuz and upgrade.img (renamed); the
> upgrade.img is an initramfs with a special upgrade environment in it,
> implemented by the 'fedup' dracut module which is shipped in the
> fedup-dracut package.
>
> So the question of 'what version' you're using to do a fedup upgrade
> isn't as simple as 'rpm -q fedup'. It is significant - sometimes very
> significant - what version of the upgrade kernel and initramfs you're
> using.
>
> fedup-dracut has bugs and needs fixes just like any other bit of
> software. As well as the relatively late bump of fedup to 0.8, we got a
> relatively late bump of fedup-dracut to 0.8.
>
> When we're testing fedup, there's three significant pairs of
> kernel/initramfs to keep in mind: the one from the last milestone (so,
> when we're testing Final, Beta), the one in the current day's Branched
> compose, and the one in the current TC/RC (which will also be the one
> that goes to release). Each of these could potentially be different.
>
> fedup asks mirrormanager which location to get the kernel and initramfs
> from, if you don't tell it with --instrepo . Usually, during a
> pre-release period, it'll go and get the one from the last milestone if
> you don't pass it --instrepo . The test case currently instructs you to
> override it with the one from the current development branch.
>
> So why am I bringing up this morass? Because it's significant. We *did*
> test fedup 0.7 prior to release, and it *did* work. Multiple times, for
> multiple testers. You seem to be making the assumption that we never
> tested 0.7 because the test case says to use updates-testing and u-t
> currently has 0.8, but in practice we did (I know I did, personally) -
> 0.8 wasn't sent to updates-testing until quite late, so tests before
> that were with 0.7, and some of us do intentionally test without u-t,
> whatever the test case says. But it matters which kernel and initramfs
> you test with, too.
>

Hmm.

I wonder if fedup (the program) should bail, or at least warn, if the
kernel/initramfs version doesn't match.  If I had gotten a message
that said something like "You are trying to use fedup 0.7.0 to upgrade
to a release that was composed with fedup-dracut 0.8.0.  This may be
unreliable.", then I might have grumbled, but I wouldn't have spent a
bunch of time wondering why the upgrade silently failed.

I certainly understand that this stuff is *hard*, especially when you
factor in the combinatorial blowup of having multiple version to
upgrade from and to at the same time.

--Andy