On Wed, Dec 18, 2013 at 12:24 PM, Adam Williamson <awilliam@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
