On Seg, 2013-12-30 at 00:05 -0800, Adam Williamson wrote: > Hi, folks. Now things have calmed down a bit in Fedora 20 and Rawhide, I > have time to write this mail! > > Many of you may already know that there was a significant issue with > upgrades to Fedora 20 around release day - 2013-12-17. > > Summary of the issue > -------------------- > > Upgrading to Fedora 20 using version 0.7 of the FedUp tool does not > work. Upgrading with version 0.8 works (in the main - of course there > are bugs, there are always bugs). > > At the time Fedora 20 was released, version 0.7 of FedUp was present in > the Fedora 18 and Fedora 19 'updates' repositories. Version 0.8 of FedUp > was present in 'updates-testing' for both Fedora 18 and Fedora 19 at the > time. > > Immediate response to the issue > ------------------------------- > > We realized quite quickly during the course of release day support that > this was the case, though at first we thought perhaps only some upgrades > were failing. Once it became clear that all 0.7-based upgrades would > fail, several folks worked hard at communicating this to as many users > in as many places as possible, including via IRC, mailing lists, the > Common Bugs page > (https://fedoraproject.org/wiki/Common_F20_bugs#fedup-07-fail ), the > forums, and social network sites like G+. We advised using fedup 0.8 > from updates-testing to upgrade. > > We rapidly ensured 0.8 was submitted for stable push for both F18 and > F19. It was submitted for F19 at 2013-12-17 21:12:18 (I believe Bodhi > timestamps are UTC, so that was mid-afternoon on release day in NA) and > for F18 at 2013-12-18 11:51:47 (early morning on the day after release). > > However, release engineering complications (there were some problems > with stable pushes at the time) meant it wasn't finally pushed until > 2013-12-19 07:23:09 UTC for F19 (late on the day after release NA time) > and 2013-12-19 14:05:50 UTC for F18 (early morning two days after > release) and wouldn't have made it to most mirrors until 2013-12-19, two > days after release, and probably 2013-12-20 in 'early' timezones in > Europe and Asia. > > Proximate cause of the issue > ---------------------------- > > We have not yet identified the direct (proximate) cause of the bug; > doing so did not seem especially important in comparison to ensuring > news of the issue was spread as widely as possible, ensuring 0.8 was > sent stable as soon as possible, and resolving some related issues (see > later). However, QA's current inference is that there is some > incompatibility between how fedup 0.7 modifies the initramfs used by the > upgrade process and/or how it configures the upgrade boot environment, > and the expectations of the upgrade environment as it exists within the > final shipped upgrade initramfs. The upgrade initramfs is generated as > part of the release compose process, and is dependent on factors > including the versions of dracut and fedup-dracut used to build it. > Broadly, we suspect that an upgrade run with fedup 0.7 which uses an > upgrade initramfs generated with fedup-dracut 0.8 will not work, for > reasons not yet identified. A few day before fedup-0.8 appears I upgrade some systems to F20 (in pre releases ) without problems ... 1 - So one solution could be not update fedup to 0.8 in F20 , can't we exclude some package from fedup update ? repoquery --disablerepo=updates\* fedup fedup-0:0.7.3-7.fc20.noarch 2 - why fedup-dracut still 0.7 in F19 ? Thanks, -- Sérgio M. B. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
