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 1970319 - RHEL 8.4 - Partitioning used in Kickstart not preserved when manually interrupting anaconda at Installation destination
Summary: RHEL 8.4 - Partitioning used in Kickstart not preserved when manually interru...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: Documentation
Version: 8.4
Hardware: Unspecified
OS: Linux
high
high
Target Milestone: beta
: ---
Assignee: Sagar Dubewar
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-10 08:55 UTC by Ameya Patil
Modified: 2021-09-20 12:01 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-09-20 12:01:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Ameya Patil 2021-06-10 08:55:37 UTC 
Description of problem:

In RHEL 8.4 , when using a Kickstart which already has partitioning scheme defined, and during installation in the anaconda GUI if we click on 'Installation Destination' the manual partitioning which we have defined is not retained in the GUI and we need to start building the complete partitioning scheme again. 
It defaults to 'automatic partitioning' here and even if we select 'manual partitioning' it does not retain the scheme defined in the kickstart

However in same scenario in RHEL 7.9 , if we click on 'Installation Destination' it retains the partitioning we have defined in the kickstart and show the partition scheme in the GUI under manual partitioning.
So the user can make minor adjustments to this from here and install the OS. 

The issue can be reproduce with a partial kickstart like suppose we skip setting date and time in our Kickstart and then the installer waits for the user intervention for setting it , and we can browse the 'Installation Destination' to see the difference between RHEL 7.9 and RHEL 8.4

Version-Release number of selected component (if applicable):
anaconda 33.16.4.15
RHEL 8.4

How reproducible:
Every time on RHEL 8.4

Steps to Reproduce:
1. Use a partial kickstart suppose skipping entry for date and time with complete partition layout.
2. Boot with kickstart file inst.ks=<url_to_kickstart_file>
3. When the anaconda stops since the date and time is not set , we can go to the 'Installation Destination' and observe it default to selecting 'Automatic partitioning' and even if we select 'manual partitioning' it does not retain the information from our kickstart.

Actual results:
Anaconda does not retain the data we used for partitioning under installation destination

Expected results:
Anaconda should retain the data processed in the Kickstart under manual partitioning


Additional info:
Comment 3 Jiri Konecny 2021-06-24 13:16:43 UTC 
Hello,

Kickstart partial installations are not supported. In general there could be situations which are possible to set by kickstart but we can't show/configure them in UI. Because of that we can't guarantee that the partial installations will work.
Comment 4 jcastran 2021-07-06 16:18:25 UTC 
if a kickstart installation is stopped for any reason, previously and expectedly we were able to continue the installation by resolving whatever the missing component was. 

Kickstarts are required for the most advanced partitioning, not everything can be done in the GUI. What this bug is requesting is to keep the partitioning layout set by a kickstart, which we previously had. Even if something is missing or incorrect.

If a kickstart is wrong, and "cmdline" is used, the installation should exit immediately.
 - if text or cmdline is used, the installer allows you to make changes and continue the installation

If we're wiping away any manual partitioning, we are taking away this feature of the installer. 


Note:
When we have an option to prevent interaction even in graphical mode:

   --non-interactive - Performs the installation in a completely non-interactive mode. This mode will terminate the installation when user interaction is required.

The the inverse should be true as well. Resetting the partitioning scheme for any kickstart issues is a bug. This should work as it previously has.
Comment 5 Jiri Konecny 2021-08-03 10:20:21 UTC 
I understand the reasoning but it is unfortunately pretty fragile. Kickstart has bigger possibilities than UI is able to show. So, you can get to the situation where the UI will crash because it can't show your kickstart partitioning.
Comment 6 jcastran 2021-08-09 19:06:14 UTC 
RHEL 7 and below allowed this behaviour and we document that this is possible in the installation guides. This includes RHEL 8's installation guide.

~~~~~~~~~~~~~~~~
Items that are not required can be omitted. Omitting any required item results in the installation program changing to the interactive mode so that the user can provide an answer to the related item, just as during a regular interactive installation. It is also possible to declare the kickstart script as non-interactive with the cmdline command. In non-interactive mode, any missing answer aborts the installation process.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/performing_an_advanced_rhel_installation/index#sect-kickstart-file-create
~~~~~~~~~~~~~~~~

If it's not possible to fix this, or we won't fix it, then we should update the documentation:
 - To reflect that you can not continue an installation with custom partitioning defined in the kickstart
 - List this as a deprecated feature? (It was never clearly listed as something that could be done but now it does not work and customers who look for it may not easily identify it's now gone if all we do is update a paragraph to say that an installation can be completed only if the partitioning isn't customized.)
Comment 7 Jiri Konecny 2021-08-17 11:39:03 UTC 
Maybe I read this wrong but it seems correct to me. Your partitioning is not complete/correct so you have to change it. I don't read in the text that we have set the partial partitioning from the KS. I understand that it is change of behavior, however, from my understanding it wasn't documented / supported feature even before. In general we are choosing safe path for future. The partitioning is still changing and there is a lot which can go wrong this way.

What do you think Jan? Should we make this explicit in the documentation?
Comment 8 Jan Stodola 2021-08-17 13:35:41 UTC 
I agree with Jirka.

1) If the partitioning is not fully specified in the kickstart file, we cannot really support showing partially-defined partitioning from the kickstart file in the custom partitioning spoke.
2) If the partitioning is fully specified in the kickstart file, then it's not required to enter the storage spoke at all. If the user enters the spoke, then the same as 1) applies here - we cannot support showing the partitioning defined in the kickstart file.

So, documentation should be extended and mention that entering spokes that are complete (were specified in the kickstart file) could lead to resetting their configurations. The users should only enter the spokes that require any action.

The documentation to update is here:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/performing_an_advanced_rhel_installation/index#kickstart-file-format_kickstart-script-file-format-reference

"Items that are not required can be omitted. Omitting..."
Comment 9 Dave 2021-09-13 14:33:57 UTC 
Hello, this bugzilla was created based on a support ticket I opened.  The behavior we would like to see retained (as it was in RHEL 7 and even some early RHEL 8 editions) is to have the *fully specified* custom partitioning maintained in the GUI as a starting point for end-users to further customize.

In my experience, if the end-user stays out of the partitioning part of the installation GUI, the custom kickstart partitioning works just fine so I can only assume it's fully specified and compliant.  However, if for example the end-user wants to make /var a bit larger in the GUI, the fully specified kickstart partitioning gets reset with default partitioning.
Note You need to log in before you can comment on or make changes to this bug.