Bug 1155026

Proposed as a Freeze Exception for 21-beta by Fedora user vpodzime using the blocker tracking app because:

 This bug causes the Initial Setup to crash not allowing user creation and other things during the first boot.

I'll just ad that due to this bug Initial Setup will not only not be shown on first start after install but it will also never be disabled. This means it will try to start on every boot just to crash, potentially slowing down the boot a bit and maybe also introducing some interruptions to the Plymouth boot screen.

Discussed at 2014-10-22 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-22/f21-blocker-review.2014-10-22-16.03.log.txt . For now we're rejecting this, but we're open to a re-proposal.

It's somewhat unclear from the description whether a typical deployment of any Fedora media are going to hit this, or if it only hits custom use of initial-setup which none of our media do. If you can only hit it by using a custom kickstart that specifies %addon we're inclined to reject it, because we don't think that's a very common thing to do and not worth breaking freeze for at this point.

If you'd like us to re-consider this, please re-propose with more details as to why it's worth breaking freeze to fix this. thanks!

(In reply to Adam Williamson (Red Hat) from comment #3)
> Discussed at 2014-10-22 freeze exception review meeting:
> http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-22/f21-
> blocker-review.2014-10-22-16.03.log.txt . For now we're rejecting this, but
> we're open to a re-proposal.
> 
> It's somewhat unclear from the description whether a typical deployment of
> any Fedora media are going to hit this, or if it only hits custom use of
> initial-setup which none of our media do. If you can only hit it by using a
> custom kickstart that specifies %addon we're inclined to reject it, because
> we don't think that's a very common thing to do and not worth breaking
> freeze for at this point.
> 
> If you'd like us to re-consider this, please re-propose with more details as
> to why it's worth breaking freeze to fix this. thanks!
Okay guys, let me express it more clearly:
Initial Setup doesn't run on default installation where it is supposed to run due to this bug. The kdump anaconda addon has been added to the installation images (and it's UI can be enabled by inst.kdump_addon=on) which results in an %addon section being written out to every installation's /root/anaconda-ks.cfg file which is then processed by the Initial Setup. Due to this bug IS crashes and leaves itself enabled so it runs and crashes on every boot. If no user account is created in the installation process, no user can be created before users get to KDM/XDM/?DM.

This doesn't affect GNOME because Initial Setup is not installed together with GNOME as that provides its own initial setup utility.

Re-proposing as I really think this is worth fixing as FE.

Fixing whiteboard to re-propose per comment 4.

If I understand comment 4 properly, this might be even a blocker per:
https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Expected_installed_system_boot_behavior
"A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system. "
which is violated for KDE image if the user doesn't create a user account during installation.

+1 FE, makes sense to pull this in as KDE is a release blocking desktop.

I just tested this with a KDE live and could not reproduce. vpodzime says it may affect only netinst; I'm testing with TC4 netinst now.

OK, I can reproduce this with a netinst; i-s does not run. However, sddm at least allows login as root, so you're not locked out.

Also - since this only affects netinst (we don't have a DVD with KDE on it), I think it can be fixed with updates, right? the anaconda/i-s which actually gets *installed* will be the one in the u-t repo at the time the user installs, not the one used to compose the netinst. So we don't actually need to put this fix in the frozen package set, unless I miss something.

If this needs fixing during install I'm -1 blocker +1 FE, otherwise -1/-1 (we just need to send a fixed anaconda to updates-testing and things will be fine).

Assuming Adam's comment about having fixed anaconda in updates-testing being sufficient is correct, not blocking seems reasonable.

Discussed at 2014-10-24 Go/No-Go meeting: http://meetbot.fedoraproject.org/fedora-meeting-2/2014-10-24/f21_beta_gono-go_meeting.2014-10-24-17.01.log.txt . Agreed this does not need to block release as the version of anaconda in the installer environment is not significant, but rather the version deployed to the system. As the bug does not affect live images and we no longer ship a DVD with KDE on it, we can't see a scenario where you could run into this bug so long as a fix is available in the repositories - network install will always get the anaconda from the repos.

On the other hand, at the same meeting we accepted it as a freeze exception issue, for mainly process reasons - it's easier for anaconda folks to roll the fix for this into the next build along with other blocker/FE fixes than to do a build that only fixes blockers/FEs, then build the fix for this as a 0-day update.

anaconda-21.48.13-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/anaconda-21.48.13-1.fc21

anaconda-21.48.13-1.fc21, python-blivet-0.61.8-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.