Bug 1695637 - initial-setup doesn't start
Summary: initial-setup doesn't start
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: appliance-tools
Version: 30
Hardware: armv7hl
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Neal Gompa
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On: 1696064
Blocks: F30FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2019-04-03 13:24 UTC by Alessio
Modified: 2019-04-09 00:26 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-08 22:44:41 UTC


Attachments (Terms of Use)
journalctl -xe (205.26 KB, text/plain)
2019-04-03 13:24 UTC, Alessio
no flags Details
initial-setup log (41.83 KB, text/plain)
2019-04-03 15:47 UTC, Paul Whalen
no flags Details

Description Alessio 2019-04-03 13:24:25 UTC
Created attachment 1551383 [details]
journalctl -xe

On a fresh burned SD card, the boot process reach the login prompt without presenting the initial-setup spokes.

Command used to burn the SD card:

sudo arm-image-installer --image=Fedora-Minimal-armhfp-30-20190330.n.3-sda.raw.xz          --target=rpi3 --norootpass --resizefs --media=/dev/mmcblk0 -y --addconsole

Please note: initial-setup doesn't appear on serial console, and it doesn't start using an HDMI display as well.

Same issue using Fedora-Server-armhfp-30-20190330.n.3-sda.raw.xz


The problem is not present using Fedora-Minimal-armhfp-30_Beta-1.8-sda.raw.xz

Comment 1 Fedora Blocker Bugs Application 2019-04-03 13:29:39 UTC
Proposed as a Blocker for 30-final by Fedora user alciregi using the blocker tracking app because:

 I think that it violates this criteria: "The installer must be able to complete an installation using all supported interfaces. "
The initial-setup doesn't start, so the installation is incomplete (no user creation, no timezone selection and so on).

Comment 2 Paul Whalen 2019-04-03 15:46:13 UTC
Service wasnt enabled, but attempting to start manually also fails. Checking the logs:


Apr 03 11:43:12 localhost initial-setup[861]: 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'
Apr 03 11:43:12 localhost initial-setup[861]: Initial Setup startup failed due to invalid kickstart file

Indeed there is no /root/anaconda-ks.cfg

Comment 3 Paul Whalen 2019-04-03 15:47:52 UTC
Created attachment 1551433 [details]
initial-setup log

Comment 4 Adam Williamson 2019-04-03 16:31:05 UTC
/root/anaconda-ks.cfg should have been written out by anaconda - it's basically a record of the install process. initial-setup obviously reads it to be figure out what anaconda did. So I suspect this is probably an anaconda bug.

+1 blocker for me.

Comment 5 Adam Williamson 2019-04-03 18:36:47 UTC
oh, of course, this won't be anaconda exactly...more appliance-tools...

Comment 6 Adam Williamson 2019-04-03 18:54:37 UTC
So at least one thing that's going on here is that imgcreate uses 'chkconfig' to enable services, but chkconfig isn't in the payload any more. That's probably why the service wasn't enabled, and why there are errors about chkconfig in the logs. (Also note that the fedora-arm-base.ks kickstart itself calls chkconfig to do stuff, which isn't going to work if it's not there).

I can't immediately see that that would prevent the kickstart getting written, but in any case we should fix that, so I'll send a pull request for it (just adding the chkconfig package to fedora-arm-base.ks I think), and I guess we can see if it *does* also result in the kickstart getting written again...

Comment 8 Neal Gompa 2019-04-06 13:18:08 UTC
Adam, imgcreate should use systemctl now: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f0050456ba

Does that resolve your issue?

Comment 9 Adam Williamson 2019-04-06 14:24:45 UTC
Neal: no it doesn't, because we already fixed it in the kickstarts, see above. I was just waiting for a new compose to see the results. Both composes since the change was made have failed.

Comment 10 Neal Gompa 2019-04-06 14:53:43 UTC
(In reply to Adam Williamson from comment #9)
> Neal: no it doesn't, because we already fixed it in the kickstarts, see
> above. I was just waiting for a new compose to see the results. Both
> composes since the change was made have failed.

So... I don't know what you want from me then? There's no longer an implicit dependency on initscripts from imgcreate, and no one uses ec2convert anymore (thankfully!).

Comment 11 Adam Williamson 2019-04-06 14:58:30 UTC
Sorry, I didn't mean that wasn't a good idea, just that we can't tell what's going on with this bug till we get a new rawhide :)

The chkconfig thing being the cause is only a guess - it looks roughly proximate, but there's no completely obvious causation link between 'chkconfig not there' and 'no kickstart'. It seems *possible* but I'm not gonna be sure until we actually have a compose where the chkconfig problem is solved and we can see what happens there.

Comment 12 Adam Williamson 2019-04-08 15:57:54 UTC
We did get a new Rawhide...on x86_64 it seems to have major issues, but it's possible the ARM images are good enough to at least test this...can someone grab one and try? https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190408.n.0/compose/Spins/armhfp/images/

Comment 13 Paul Whalen 2019-04-08 19:07:05 UTC
(In reply to Adam Williamson from comment #12)
> We did get a new Rawhide...on x86_64 it seems to have major issues, but it's

Testing Fedora-Minimal-armhfp-Rawhide-20190408.n.0-sda.raw.xz it appears ARM has other issues as well. Initial-setup is started/enabled but hanging at completion and no network to ssh in. anaconda-ks.cfg is also there (and included in todays f30 image).

================================================================================
================================================================================
1) [x] Language settings                 2) [x] Time settings
       (English (United States))                (America/New_York timezone)
3) [ ] Network configuration             4) [x] Root password
       (No network devices available)           (Password is set.)
5) [x] User creation
       (Administrator pwhalen will be
       created)

Please make a selection from the above ['c' to continue, 'q' to quit, 'r' to
refresh]: 
c

The hang might be related to BZ#1695967 and is also documented there. I think this can be closed.

Comment 14 Adam Williamson 2019-04-08 22:44:41 UTC
The network issue is what x86_64 is running into as well, I think - I'll need to dig into that and figure out what's going on. But if Rawhide and F30 both have anaconda-ks.cfg now let's call this one fixed at least.

Comment 15 Adam Williamson 2019-04-09 00:07:29 UTC
For the record I believe the network issue (and several other issues) is due to SELinux: https://bugzilla.redhat.com/show_bug.cgi?id=1697667 . Booting with enforcing=0 makes it go away, so maybe use that to test anything else you need to test.

Comment 16 Adam Williamson 2019-04-09 00:26:34 UTC
Discussed at 2019-04-08 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2019-04-08/ . Accepted as a blocker as a violation of "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" for ARM Xfce disk image. (Yes, this is closed already, but just in case we got something wrong and need to re-open it...)


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