Bug 871161 - Fedora Upgrade Tool for F18 (fedup) requires systemd-195
Fedora Upgrade Tool for F18 (fedup) requires systemd-195
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
AcceptedNTH
:
Depends On:
Blocks: F18Beta/F18BetaBlocker F18Beta-accepted/F18BetaFreezeExcept
  Show dependency treegraph
 
Reported: 2012-10-29 15:14 EDT by Tim Flink
Modified: 2012-11-01 13:50 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-01 13:50:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Flink 2012-10-29 15:14:45 EDT
In order for the new upgrade tool for Fedora 18 (fedup) to work, systemd-195 is required as stated in the fedup and fedup-dracut documentation:

 - https://github.com/wgwoods/fedup-dracut
 - https://github.com/wgwoods/fedup

There is currently an update available in updates-testing (195-2) and a newer build in koji without an update in bodhi (195-4).
 - https://admin.fedoraproject.org/updates/FEDORA-2012-16709/systemd-195-2.fc18
 - http://koji.fedoraproject.org/koji/buildinfo?buildID=362115

Since this blocks the building of the initramfs needed for fedup to function, proposing as a blocker due to violation of the following F18 beta release criterion [1]:

For each one of the release-blocking package sets ('minimal', and the package sets for each one of the release-blocking desktops), it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria.

[1] http://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
Comment 1 Adam Williamson 2012-10-29 15:22:03 EDT
It would be useful to know exactly how this initramfs building step is supposed to work. Is it supposed to be done on the fly during the upgrade process or are we going to be somehow serving out the kernel/initramfs for the upgrade? I don't think anyone outside of Will and possibly you has a clear understanding of how this whole mechanism is planned to work.
Comment 2 Tim Flink 2012-10-29 15:34:10 EDT
Obviously Will knows more about this than I do, but I'll attempt to explain my current understanding of the current process and the planned process - highlighting the parts that I'm not 100% sure of.

The current upgrade process:
 - build upgrade initramfs on an F18 machine
   * Requires systemd-195
   * Requires non-standard dracut module for upgrade
   * Includes plymouth theme specifically made for fedup
   * Produces upgrade.img used for upgrading to F18 from F17

 - run fedup-cli on the target F17 machine
   * pulls packages from various repos 
      - seems to use f18 and f18-updates by default
 
 - Download prebuilt upgrade.img and matching vmlinuz
   * manually put them in /boot/upgrade

 - Reboot and select 'System Upgrade' from grub menu

The eventual online upgrade process:
 - Lorax includes the required upgrade modules in the initrafs built for the   
   installer
 - fedup pulls initramfs and vmlinuz from f18 repo (similar in spirit to what 
   pxe would do when grabbing initramfs and vmlinuz from a repo)

I'm not 100% clear on what is planned for F18 beta as far as lorax and stable repo integration is concerned or what level of functionality will be acceptable for beta.

I know that Will has started on work to pull the initramfs and kernel from a side repo - it isn't done yet but I assume that it will be done shortly.

I have no idea what the status of the required lorax work is or how much effort that entails.
Comment 3 Lennart Poettering 2012-10-30 12:51:56 EDT
Note that 195-2 has now been pushed to stable.
Comment 4 Adam Williamson 2012-10-30 14:47:42 EDT
No it hasn't. I don't even see that it's been submitted, actually, but even if you submit it for stable, it won't go to stable unless releng pushes it through the freeze, and they will only do so if a bug it fixes is accepted as a blocker or NTH issue. This is the process during freezes.

https://admin.fedoraproject.org/updates/FEDORA-2012-16709/systemd-195-2.fc18 says "Status:	testing" and there is no comment indicating a submission for stable; there would be one if it had been submitted for stable. If it had been pushed stable there would be a comment stating this, and Status would be 'stable'.
Comment 5 Jóhann B. Guðmundsson 2012-10-30 16:51:33 EDT
This kinda is automatic blocker since fedup is depend on [1] thus it breaks 

"For each one of the release-blocking package sets ('minimal', and the package sets for each one of the release-blocking desktops), it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria."

+I dont think we need any kind of specific vote on this since we discussed this very issue on last QA meeting...


1.https://github.com/wgwoods/fedup-dracut/blob/master/fedup-dracut.spec
Comment 6 Jóhann B. Guðmundsson 2012-10-30 16:59:41 EDT
Filed [1] with releng requesting it to be pushed through...

1,https://fedorahosted.org/rel-eng/ticket/5385
Comment 7 Adam Williamson 2012-10-30 18:03:50 EDT
Johann: I mostly agree, except that it hasn't really been made clear yet that the updated systemd actually needs to be in the frozen package set. But if I'm interpreting Tim's post correctly, it seems to suggest that we want to build the 'upgrade.img' file for upgrades as part of the Fedora build process, and host it on our servers where it will be downloaded by people doing upgrades - as opposed to the upgrade.img generation step happening on-the-fly as part of the upgrade process. If that's the case, it probably does make sense that we should do the upgrade.img generation from the frozen package set, and so this ought to be a blocker. If that's a correct understanding of how we mean this process to work, I vote +1 blocker.

There's nothing wrong with filing a ticket with rel-eng, but just FYI, how we usually do this is just that every so often someone (usually me) drops into #fedora-releng and lists out the updates that fix accepted blocker/NTH bugs and have sufficient karma to be pushed stable, and someone (usually nirik or dgilmore) does a stable push. It happens sufficiently often that filing a ticket for it is kind of a pain. =) Feel free to do this yourself any time you notice updates that fix blocker/NTH issues are sufficiently karma'ed to be pushed stable, of course.
Comment 8 Jóhann B. Guðmundsson 2012-10-30 19:35:33 EDT
FYI you yourself said that Dennis was unavailable for what 2 and half day or so so it was safer to file a ticket...
Comment 9 Adam Williamson 2012-10-30 19:40:08 EDT
yeah, point. nirik is around, though.
Comment 10 Jóhann B. Guðmundsson 2012-10-30 19:47:38 EDT
Btw has the proposed solution what you mentioned there cleared security review ( think hacked update.img deployed on nearest server ) and infrastructure as in we distributing update images instead of the host generating itself locally?
Comment 11 Adam Williamson 2012-10-31 13:24:49 EDT
Discussed at 2012-10-31 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-31/f18beta-blocker-review-6.2012-10-31-16.00.log.txt . Agreed that as the process by which upgrade.img will be built and shipped(?) is still not clear we cannot be sure if this actually needs to block the Beta release, but there is a possibility that it might, and in that case, we should pull the fix immediately so we have time to test it, rather than realizing we need it later on and not having time to test it properly.

Therefore the issue is accepted as NTH and we leave the blocker question open, to be determined later if required. This gives us flexibility to take the systemd update now, but back it out again if testing indicates it is broken and we determine we don't actually need it for fedup.
Comment 12 Adam Williamson 2012-11-01 13:50:49 EDT
Update was pushed stable, closing.

Note You need to log in before you can comment on or make changes to this bug.