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.

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.

Note that 195-2 has now been pushed to stable.

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'.

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

Filed [1] with releng requesting it to be pushed through...

1,https://fedorahosted.org/rel-eng/ticket/5385

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.

FYI you yourself said that Dennis was unavailable for what 2 and half day or so so it was safer to file a ticket...

yeah, point. nirik is around, though.

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?

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.

Update was pushed stable, closing.