F40 Change Proposal: Run Anaconda dir/image installations only in non-interactive text mode (Self-Contained

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.

Wiki
Announced

:link: Summary

Anaconda will require a fully defined kickstart file for installations into an image or a directory and these installations will run only in a non-interactive text-based user interface.

:link: Owner

:link: Detailed Description

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).

:link: Feedback

:link: 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.

:link: Scope

  • 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:

:link: Upgrade/compatibility impact

:link: How To Test

:link: User Experience

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).

:link: Dependencies

:link: Contingency Plan

  • 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

:link: Documentation

N/A (not a System Wide Change)

Please do not drop this functionality. This is something I use for three purposes:

  • Interactive installations for debugging Anaconda weirdness
  • Anaconda development and testing
  • Interactive installations for custom multi-boot setups

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.

1 Like

Are you going to provide, or is there currently a tool to verify kickstart file correctness?

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.

Hello @vponcova ,
Welcome to :fedora: !
Thanks for the current state clarification.

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.

1 Like

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.

There is also no method of using a local mirror of repositories. There is no reliable way to force a particular disk via kickstart as a source. There is no auto-detection mechanism for local mirror volumes. There is no way to capture the downloaded package set for creating a reproducible installation. Finally, there is no reliable way to select a specific target disk at kickstart.

These are the issues offhand that I can somewhat work around by being able to do graphical interactive installs from a running system.

1 Like

This change proposal has now been submitted to FESCo with ticket #3142 for voting.

To find out more, please visit our Changes Policy documentation.

This is a wrong approach. We should focus on fixing these issues instead of resolving these by workaround with Graphical input.

Kickstart should be the most powerful way to do the installations and this is the first time I’m reading about the opposite.

About your filed RFEs, I replied to some and I honestly not sure how GUI mitigate: 2257912 – Please add a way to preserve and archive the dnf cache for reproducibility and debugging

In any way, our future goal is to not build ISO files. For that purpose we have better tooling which is focused on a good user experience. Anaconda team does not even test this use-case properly.

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.

When running it in a real system to install another system via specifying the disk, I can just copy the results somewhere after everything is done.

I am not building ISO files. I’m installing real systems. For the “image” installation method, I just point Anaconda to a disk device on a real system.

This was never supported nor tested :D. I’m surprised it works. Please don’t expect us to support this type of installation. We can’t cover that with resources we have.

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.

Ehm, this use case is really unusual. If you select the disk in the UI, or specify ignoredisk --only-use in your kickstart file, you should achieve the same results. See: Kickstart Documentation — Pykickstart 3.51 documentation

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).

That sounds like a bug to me. GUI shouldn’t behave differently to kickstart otherwise the output kickstart will be broken.