Description of problem: Its not unusual for an arm machine to need kernel parameters to boot properly. When these parameters are provided to the workstation (or other) install disks, they should be preserved and carried over to the installed system. This appears to be happening with the workstation disk for acpi= options, but testing with arm64.XX options they appear to be stripped. This is doubly important on the workstation image because grub is hidden by default. Version-Release number of selected component (if applicable): F43 How reproducible: 100% Steps to Reproduce: 1. Grab aarch64 workstation, and workstation .iso 2. Boot the .iso with an option such as arm64.nosve acpi=nospcr 3. install system. Actual results: 4. after rebooting and getting grub to appear, check the arm64.XX parameter is carried over to the installed system. 5. Notice that acpi=nospcr is in place but arm64.nosve isn't Expected results: arm64, and most !rd.XX inst.text, etc options aren't removed. This should really be more of an exclude list (ex exclude install specific options rather than including a known subset). Additional info:
AFAIK this is a feature, where only selected options are passed to the installed system, see eg. https://issues.redhat.com/browse/RHEL-94243
As Dan mentioned, currently this is indeed a feature. If you need to pass some specific boot options, you may do so explicitly by using 'bootloader --append=' kickstart command/option (see https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#bootloader). This alternative solution, however, only covers kickstart installations and may not be as user-friendly as expected, so I think we may introduce some new Anaconda boot option (e. g. inst.preservecmdline) that would ensure all of the boot options (with exception of those directly consumed by Anaconda) are passed to bootloader configuration in the installed system. Nevertheless, some more related discussion will be probably needed. Also note that if such an option is introduced, the user will be most likely responsible for not specifying any options (not specific to Anaconda) that may cause issues in the installed system.
As I mentioned in the summary, I think that stripping kernel options by default is a mistake in anaconda. I implemented some of this for the systemd boot stuff, and explicitly stripping categories of options used by the install is a much better plan (ex rd.XXX, inst.XXX, root=, etc). If the user has gone to the effort to add kernel boot options there is a good chance they are there to work around a problem. Failing to preserve them means that the installer thinks it knows something about them that the user doesn't, and this is flatly wrong in most cases. Its a violation of separation of concerns at worst. Anaconda should only be manipulating options it is aware of and leaving other layers to strip (or not) options they are consuming. Ideally after stripping anaconda known options, it should really be able to enable a settings line that shows up somewhere in the UI that says something along the line of "We detected the following configuration options not normally found during install, are these correct for the installed system?" and provide a way to acknowledge or modify them.
Hello Jeremy, we can definitely see your point. We had a related discussion within the Installer team and decided we'd likely go the way of introducing a new boot option that would arrange for preserving (almost) all of the installation-time boot options even in the installed system. I can understand that from some point it might be more useful to make Anaconda preserve the options implicitly, however this could be a potentially disruptive change given how things have worked up to now in this regard, so I think we should better choose the safer way and retain the boot options only when asked for by the user. I've created a related Jira ticket to track this new functionality: https://issues.redhat.com/browse/INSTALLER-4409