RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1883224 - [RFE] The kickstart option --leavebootorder does not "leave boot order" on UEFI systems
Summary: [RFE] The kickstart option --leavebootorder does not "leave boot order" on UE...
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: anaconda
Version: 8.2
Hardware: All
OS: Linux
Target Milestone: rc
: 8.0
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
Depends On:
Blocks: 2025953
TreeView+ depends on / blocked
Reported: 2020-09-28 14:06 UTC by Parikshit Khedekar
Modified: 2022-01-14 20:09 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2025953 (view as bug list)
Last Closed: 2021-11-23 16:32:44 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

Description Parikshit Khedekar 2020-09-28 14:06:14 UTC
Description of problem:

The --leavebootorder option adds Red Hat Enterprise Linux X to the top of the list of installed systems in the boot loader, and preserve all existing entries as well as their order so as its description does not "leave boot order".

This shouldn't happen and it should completely leave the bootorder as it is or strictly shouldn't touch it.

As per the current documentation it says it would add a entry at the top for the install being done which somehow contradicts with the option and usage.

We would expect the option to strictly "Not to touch" existing boot entries / "should leave boot order as it is"

A workaround like bootloader --location=none  does the trick but this is not maintainable in the long term due to the aforementioned limitations nor it is it documented. If we chose this option it disables the installation of the package containing the boot loader and hence an additional postscript to have the grub configs generated is needed, overall not a feasible workaround.

Version-Release number of selected component (if applicable):


Red Hat Enterprise Linux ( all release)


How reproducible:

Everytime installing RHEL on UEFI system.

Steps to Reproduce:
1. Install with kickstart having --leavebootorder option included.
2. Upon install it will add the latest entry to top of the order.

Actual results:

It add's entry to install at top of the bootorder.

Expected results:

It shouln't be touching anything there and leave it as it is.

Additional info:

We have following BZ alrady running for corrections to the documentation but again they do not tend to serve actual usage or cause behing using the option.


Referce doc upstream doc mentions it as,


.. leavebootorder:

Boot the drives in their existing order, to override the default of booting into
the newly installed drive on Power Systems servers and EFI systems. This is
useful for systems that, for example, should network boot first before falling
back to a local boot.

So the current documentation we have contradicts with it.

Comment 2 Daniel Juarez 2020-09-28 14:22:31 UTC
As a reference, this is the upstream documented behaviour: https://github.com/rhinstaller/anaconda/blame/master/docs/boot-options.rst#L680

i.e. No changes from installing in a BIOS or UEFI machine.

The issue is that when you specify no boot loader location, the autopart and reqpart operations will no longer validate HW specific requirements and therefore it will not create the an efi partition, meaning you have to manually partition it yourself.

Not altering bootorder after an installation and having network first, just as the documentation previously linked states, is a quite usual setup for datacenters. It is not a matter of UEFI, it is a matter of the bootloader Anaconda module.

Comment 8 Jiri Konecny 2021-09-21 12:17:07 UTC

I'm not honestly sure if this bug is about to not add the boot menu entry at all, or to set it as the last item to avoid change of the order. Could the reporter please make this clear?

Also, I have to say that I'm worried about changing this in the minor release. This is a big change of behavior. In both situations current kickstart with --leavebootorder will change the installed system boot menu which could break plenty of use-cases. I'm more inclined to have this as a next major RHEL change than switching it now if we want to implement this.

Comment 12 Parikshit Khedekar 2021-12-08 09:49:34 UTC
Hello @Jiri , Thank you! I have shared same to customer and 
will keep tracking the BZ for RHEL 9

Note You need to log in before you can comment on or make changes to this bug.