FinalBlocker -1

This bug is unfortunate, but it affects an installation path that we expect to be used only by experienced technical users, who can presumably reinstall after realizing they messed up. Typical Fedora users will never wind up here.

I agree with @catanzaro. We can also describe this behaviour in the Common Bugs to make the users know they should pay more attention.

FinalBlocker -1

FinalBlocker +1

This would affect everything but Workstation.

This would affect everything but Workstation.

Most spins would not have this problem because they run anaconda. afaik this only affects fedora-arm-image-installer?

This would affect everything but Workstation.

Most spins would not have this problem because they run anaconda. afaik this only affects fedora-arm-image-installer?

It would affect all arm and aarch64 spins- they run initial-setup on first boot.

This would affect everything but Workstation.

Most spins would not have this problem because they run anaconda. afaik this only affects fedora-arm-image-installer?

This is unrelated to arm-image-installer. The initial-setup is also run as part of anaconda, it's the piece that allows creation of users, setting root password, setting timezones etc. I believe it's use by everything except GNOME which has gnome-initial-setup which is the same equivalent but different codebase.

This bug is unfortunate, but it affects an installation path that we expect to be used only by experienced technical users, who can presumably reinstall after realizing they messed up. Typical Fedora users will never wind up here.

No, the initial-setup code is also used by the anaconda installer and the initial user setup wizard on all desktops that aren't gnome so it's not just "experienced technical users". Looking at the kickstarts it's included in all but Workstation.

Anaconda doesn't allow to perform an installation, if you don't create an admin user first (mostly). So this problem affects installations which are performed without the anaconda.

No, the initial-setup code is also used by the anaconda installer and the initial user setup wizard on all desktops that aren't gnome so it's not just "experienced technical users". Looking at the kickstarts it's included in all but Workstation.

Do I understand correctly: you are saying that anaconda somehow uses initial-setup as a library in order to handle its account creation spokes, so this bug in initial-setup also directly affects anaconda's account creation? But we also have #557 tracking an extremely similar problem in anaconda, and our understanding is that the impact seems much more limited in anaconda than in initial-setup.

I'm now confused by the scope of this bug. My -1 vote assumes this bug only matters when anaconda is not run, or if anaconda is run but fails to enforce admin account creation under the conditions tracked in #557.

Right. initial-setup code is shared with anaconda, but not in a way which would result in most x86_64 deployments encountering this bug. initial-setup can be encountered on a non-Workstation x86_64 install if it's in the deployed package set and you don't create a user during installation, but it's only there to let you create a user account in that case, logically speaking you must have a root password at that point.

Having said that, obviously ARM image deployments are a significant and release-blocking case. So I'm not -1 on the basis that this is a particularly 'unusual' or 'advanced' scenario. I am:
FinalBlocker -1
though, for the simple reason that the criteria don't really require this to work. They specify that we must offer the chance to create user accounts, but they don't require that the 'don't let the user through without admin rights' safety mechanism works. I do see the argument that you could see this as a conditional violation of any criterion which requires a user account and/or admin rights, but conditional violations are judgment calls and this isn't really that terrible of a case.

It's a fresh install, worst case, just run it again and create the account this time.

FinalFE +1
though.

@catanzaro initial-setup and anaconda share a lot of code, initial-setup is really a kind of limited and special-purpose anaconda hub, conceptually. But each has its own 'when to let you out' logic, as @kparal explained, so indeed anaconda is not impacted in the same way here.

It's a fresh install, worst case, just run it again and create the account this time.

How do you run initial-setup again?

FinalBlocker -1

How do you run initial-setup again?

I believe Adam meant to run the installation again.

I believe Adam meant to run the installation again.

That will significantly increase requests for support. I really don't like that solution.

i'm weakly

FinalBlocker -1

I also am
FinalBlocker -1

Do we know if this was also the case in previous releases?

The code referred to in the bug hasn't changed for 18 months. The other moving part would be whether we have always written the installer kickstart to the ARM images.

This is unfortunate, but I am -1 since normal fedora users wouldn't end up here but I am FE +1

FinalBlocker -1

FinalBlocker +1

Release F35 is no longer tracked by BlockerBugs, closing this ticket.