Bug 1155026 - Missing addon results in a traceback when %addon header options are specified
Summary: Missing addon results in a traceback when %addon header options are specified
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vratislav Podzimek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Keywords:
Depends On:
Blocks: F21BetaFreezeException 1155955
TreeView+ depends on / blocked
 
Reported: 2014-10-21 09:31 UTC by Vratislav Podzimek
Modified: 2014-10-31 02:42 UTC (History)
11 users (show)

(edit)
Clone Of:
: 1155955 (view as bug list)
(edit)
Last Closed: 2014-10-31 02:42:39 UTC


Attachments (Terms of Use)

Description Vratislav Podzimek 2014-10-21 09:31:05 UTC
Description of problem:
When an Anaconda/Initial Setup addon is missing in the environment and the kickstart file contains an %addon section with some header option specified (like: %addon com_example_foo --argument='example'), parsing such kickstart results in an error. That is a bug because a missing addon shouldn't trigger any tracebacks as its %addon kickstart section can be simply ignored.

Comment 1 Fedora Blocker Bugs Application 2014-10-21 09:40:51 UTC
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.

Comment 2 Martin Kolman 2014-10-22 11:36:16 UTC
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.

Comment 3 Adam Williamson 2014-10-22 17:56:23 UTC
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!

Comment 4 Vratislav Podzimek 2014-10-23 08:54:39 UTC
(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.

Comment 5 Kamil Páral 2014-10-23 14:43:05 UTC
Fixing whiteboard to re-propose per comment 4.

Comment 6 Kamil Páral 2014-10-23 14:46:16 UTC
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.

Comment 7 Kalev Lember 2014-10-23 16:17:51 UTC
+1 FE, makes sense to pull this in as KDE is a release blocking desktop.

Comment 8 Adam Williamson 2014-10-23 16:26:20 UTC
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.

Comment 9 Adam Williamson 2014-10-23 16:56:09 UTC
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).

Comment 10 Matthew Miller 2014-10-23 17:42:08 UTC
Assuming Adam's comment about having fixed anaconda in updates-testing being sufficient is correct, not blocking seems reasonable.

Comment 11 Adam Williamson 2014-10-24 17:16:56 UTC
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.

Comment 12 Adam Williamson 2014-10-25 14:04:24 UTC
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.

Comment 13 Fedora Update System 2014-10-28 18:15:31 UTC
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

Comment 14 Fedora Update System 2014-10-31 02:42:39 UTC
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.


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