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,