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.