Run Anaconda dir/image installations only in non-interactive text mode
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
The Anaconda installer supports installations into a local image (via the --image cmdline option) or a local directory (via the --dirinstall cmdline option, the directory is usually a mount point of a custom image). These types of installations are supported by two user interfaces (text-based and GTK-based) in fully interactive, partially interactive and non-interactive modes. We believe that there is no strong reason for all these options, so we would like to minimize the scope of this functionality and support only the text-based non-interactive mode (specifically the command-line mode). It means that Anaconda will require a fully defined kickstart file and run only in the text-based user interface (during dir and image installations).
Benefit to Fedora
This is a preliminary step for an eventual deprecation and removal of the Anaconda support for dir and image installations. This functionality is being slowly taken over by Image Builder that is explicitly designed for building images and provides a much broader and better support for all kinds of images. Limiting the scope of dir and image installations in Anaconda will allow its developers to focus their resources on more prospective areas.
Proposal owners: Will submit a pull request for anaconda to run dir and image installations only in the non-interactive text mode and update livemedia-creator to reflect these changes if necessary.
Other developers: No impact.
Release engineering: No impact. There should be zero impact on building official Fedora images since these processes are fully automated and use fully defined kickstart files. #Releng issue number
Policies and guidelines: N/A (not needed for this Change)
Trademark approval: N/A (not needed for this Change)
Alignment with Community Initiatives:
How To Test
It will be still possible to use anaconda and livemedia-creator for installations into a local image or a directory with a fully defined kickstart file. Users can notice the following changes:
If a user requests a dir or image installation, the installer runs in the text mode.
If the user doesn’t specify a kickstart file, the installer will report an error and abort.
If the specified kickstart file is incomplete, the installer will report an error and abort.
All options for specifying the user interface will be ignored (for example, --graphical).
Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
Contingency deadline: N/A (not a System Wide Change)
Blocks release? N/A (not a System Wide Change), Yes/No
The best way to do that is to run the installer, see the error messages on the output, modify the kickstart file and run the installer again. We already support this installation mode. It can be enabled with the --cmdline option.
I know that it’s not a very well-known feature, but I find it really handy and I would really rather not see it go away.
I understand that it can be convenient in some cases, but Anaconda developers don’t use this type of installation for development, debugging or testing unless it is related to these use cases. The issue is that Anaconda runs in a completely different environment with a lot of functionality disabled, because it is not desirable to start to reconfigure the host machine and write to its files. Therefore, we would have to eventually re-test everything on boot.iso or Live media anyway.
That does not address the fact that I use this mode to do installations from a running environment to another disk. I know of others who do as well, because it’s incredibly convenient and easy to do so.
Hi @ngompa , you can still do that. You just need a kickstart file. I don’t think that creating a KS file is such a pain in local runs. The biggest issues for not using KS files are reboot of the system and requirement for running a server to server KS for installation. These obstacles are not present for local runs.
I believe that someone is using this functionality but I wouldn’t be surprised if there would be less users than developers who needs to keep that working. In fact, I believe everything around Anaconda is used by someone but unfortunately team working on Anaconda is not able to add all the new functionality without removing some which are not much utilized. Especially when there is reasonable workaround.
While I don’t know about any cases recently, there have been cases in the past where Anaconda doing a dir/image installation (and still running as root) did some changes to the running system instead by mistake. Of course, that is incorrect & all such behavior should be properly conditionalized to prevent this from happening. Still something can be missed & potentially break the running system.
In general, I would not suggest running Anaconda in this mode on a system you care for - its really meant for generating some of the images and containers that are created by Anaconda, with the possible assumption that the environment it is running in is possibly single use or not very long running & its not really well tested in any other scenario (and certainly not explicitly tested for side effect on the host system).
Overall, its adding quite some overhead to the already huge combinatorial matrix that needs to be taken into account for any code changes & testing, so reducing it in scope could help to make the whole thing a bit more sane.
I wouldn’t recommend using this functionality for debugging and development. Honestly, it’s not recommended to even run this on your local system. Reason for that is that it’s not thoroughly tested and it could have bugs and bugs in this functionality could broke your system.
If you want to do such things, I would rather recommend you to use Live media and installation there. It’s safer environment and closer to the usual execution.
It’s extremely annoying right now because Anaconda doesn’t test the package transaction before formatting the disk, even though the current way Anaconda works it could do that. There are even some cases I’ve observed where it’ll be “non-fatal” by ignoring the packages section and just installing only @core without saying anything about it.
Hi Neal! I am sorry for your negative experience, but I don’t think that kickstart installations are a good long-term solution anyway. Anaconda doesn’t want to support dir and image installations in the future. Have you tried the image builder? We would love to provide the image builder team your feedback if you have any.
It’s the only method to make Anaconda filter out all the disks except for the one target disk in an interactive installation. It also guarantees that the bootloader logic only runs on that disk. It’s actually the safest way to do this.
It does not have the same effect for bootloader installation. I’m not entirely sure why it’s different, but without doing it this way, Anaconda will happily silently install the bootloader to the wrong disk (at least, that was my experience in previous releases).