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
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).
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
Created attachment 1551433 [details] initial-setup log
/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.
oh, of course, this won't be anaconda exactly...more appliance-tools...
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...
https://pagure.io/fedora-kickstarts/pull-request/513 (Rawhide) https://pagure.io/fedora-kickstarts/pull-request/514 (F30)
Adam, imgcreate should use systemctl now: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f0050456ba Does that resolve your issue?
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.
(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!).
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.
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/
(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.
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.
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.
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...)