Bug 2057600
| Summary: | Initial Setup startup failed due to invalid kickstart file | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Paul Whalen <pwhalen> |
| Component: | oz | Assignee: | Chris Lalancette <clalancette> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 36 | CC: | awilliam, clalancette, jkonecny, mkolman, robatino, rvykydal, v.podzimek+fedora, vponcova |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | AcceptedBlocker | ||
| Fixed In Version: | oz-0.18.1-2.fc36 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-03-10 07:04:01 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 245418, 1953783 | ||
Created attachment 1863045 [details]
journalctl
Proposing as a blocker for F36 Beta, "Release-blocking ARM disk images must boot to the initial-setup utility." Ah, so, this broke when we actually started using that change, I think. It landed in oz 0.18.0, and the update for oz 0.18.0 for F35 went stable on 2022-02-14: https://bodhi.fedoraproject.org/updates/FEDORA-2022-b19b6bee99 . That seems to more or less tie in - the builders could easily have got the update between 20220216.n.0 and 20220217.n.1. We kinda dropped the ball on the original bug here - https://bugzilla.redhat.com/show_bug.cgi?id=2015490 - it looks like. We got as far as doing a scratch build of oz with the change and building an image, and then...we stopped updating the bug and I don't recall what happened. Did we test the image? I guess we didn't, because looking at the initial-setup code, this issue is pretty obvious...it does expect the kickstart to be there... I guess for a short-term fix we should just put the kickstart back, because "i-s can let you through without an admin user" is less bad than "i-s does not work at all". Then we need to figure out a solution that'll solve the original bug without causing this one... Hi, we can definitely skip the kickstart file parsing when the file is not available, but I cannot promise you it won't cause other issues. Well, leaving the kickstart out to fix the other bug was your suggestion :) So, either we figure out any issues on that path, or we come up with a different fix for the other bug, I guess. I see. Martin, can you take it over, please? I sent an oz PR to revert the change: https://github.com/clalancette/oz/pull/297 this would put us back to square 1 (i-s will run again, but you'll still be able to get out without setting root password or creating an admin account). +4 in https://pagure.io/fedora-qa/blocker-review/issue/628 , marking accepted. I'm going to backport the oz change and send updates today. FEDORA-2022-c263b25459 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c263b25459 FEDORA-2022-8676b991f3 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-8676b991f3 FEDORA-2022-8676b991f3 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-8676b991f3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8676b991f3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-c263b25459 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-c263b25459` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c263b25459 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. mboddu is updating the builders to the new oz build. Hopefully this should solve the problem for future composes. openQA catches this bug, so we'll see in the openQA results whether it's fixed. Alright, this is confirmed fixed for the last three days in openQA testing. I'll get the update pushed stable and this can be closed out. FEDORA-2022-8676b991f3 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2022-c263b25459 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. |
Description of problem: Since Fedora-36-20220217.n.1, initial-setup has been failing in OpenQA. Last successful was Fedora-36-20220216.n.0. Feb 16 12:26:10 Fedora-Minimal-36-20220222.n.1.armhfp.raw initial-setup[1673]: parsing input kickstart /root/anaconda-ks.cfg Feb 16 12:26:10 Fedora-Minimal-36-20220222.n.1.armhfp.raw initial-setup[1673]: kickstart parsing failed: The following problem occurred on line 0 of the kickstart file: Unable to open input kickstart file: Error opening file: [Errno 2] No such file or directory: '/root/anaconda-ks.cfg' Feb 16 12:26:10 Fedora-Minimal-36-20220222.n.1.armhfp.raw initial-setup[1673]: Initial Setup startup failed due to invalid kickstart file Version-Release number of selected component (if applicable): anaconda-36.16.1-1.fc36 How reproducible: Everytime Steps to Reproduce: 1. Boot recent arm/aarch64 disk images Actual results: Boots to login Expected results: Initial-setup Additional info: The disk images no longer include the anaconda generated kickstart due to this change - https://src.fedoraproject.org/rpms/oz/pull-request/4#