Make it possible to run with no kickstart #144
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Regularly Initial Setup expects the /root/anaconda-ks.cfg file created by Anaconda to exists, so that it can resolve which screens to show. This works well for the regular use-case where Initial Setup runs after a regular installation, to configure additional settings, such as a user account. But Initial Setup is also used in the so-called reconfig-mode, usually on ARM SBCs or IoT devices, where it is started from a static image that has been dd-ed to the system and Initial Setup is then used to customize it. In this case the idea of kickstart describing the state of the system breaks down, as the /root/anaconda-ks.cfg if present could describe the image creation settings and not the desired action for this scenario - which is essentially "configure what you can". This is how bug 2015490 came to be - the kickstart used to build the ARM installation image has root password set to be locked. This is correct - the image should have no default root password & the user is expected to set one (or create an admin user) via Initial Setup. Unfortunately the Initial Setup/Anaconda logic dictates that if root password is mentioned in kickstart, it is considered as set and user is then not required to set one during the Initial Setup run. This way if user forgets to set a root password or setup an admin user account, the resulting customized system might end up inaccessible. To solve this issue, make it possible to run Initial Setup without an input kickstart - this will result in default behavior of requiring a root password or admin user to be created. Also as mentioned in bug 2015490, there is a known way how to assure the ARM installation image has no kickstart on it. That together with this fix should fix the bug. Resolves: rhbz#2015490
M4rtinK
force-pushed
the
master-no_input_kickstart
branch
from
cfa5d7c
to
9ec548d
Compare
|
|
|
COPR build of Initial Setup with the change: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Regularly Initial Setup expects the /root/anaconda-ks.cfg file created by Anaconda to exists, so that it can resolve which screens to show.
This works well for the regular use-case where Initial Setup runs after a regular installation, to configure additional settings, such as a user account.
But Initial Setup is also used in the so-called reconfig-mode, usually on ARM SBCs or IoT devices, where it is started from a static image that has been dd-ed to the system and Initial Setup is then used to customize it.
In this case the idea of kickstart describing the state of the system breaks down, as the /root/anaconda-ks.cfg if present could describe the image creation settings and not the desired action for this scenario - which is essentially "configure what you can".
This is how bug 2015490 came to be - the kickstart used to build the ARM installation image has root password set to be locked.
This is correct - the image should have no default root password & the user is expected to set one (or create an admin user) via Initial Setup.
Unfortunately the Initial Setup/Anaconda logic dictates that if root password is mentioned in kickstart, it is considered as set and user is then not required to set one during the Initial Setup run. This way if user forgets to set a root password or setup an admin user account, the resulting customized system might end up inaccessible.
To solve this issue, make it possible to run Initial Setup without an input kickstart - this will result in default behavior of requiring a root password or admin user to be created. Also as mentioned in bug 2015490, there is a known way how to assure the ARM installation image has no kickstart on it. That together with this fix should fix the bug.
Resolves: rhbz#2015490