Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 2021353

Summary: RHEL 9 beta installer creates unbootable system without separate /home partition.
Product: Red Hat Enterprise Linux 9 Reporter: kkeane
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 9.0CC: jstodola, vtrefny
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-01-10 09:47:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Requested log files, plus a few more that may be useful none

Description kkeane 2021-11-08 23:43:27 UTC
Description of problem:

On RHEL 9 beta, anaconda generates an invalid unbootable system configuration when used with kickstart and the "autopart" option.

In this case, the installer will insert a line referencing a /home partition into fstab even though autopart does not generate such a partition.

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


How reproducible:

Install a system using the below kickstart file snippet.


Steps to Reproduce:
1. Create a kickstart file similar to the below.
2. Install system using the kickstart file
3. Reboot

Actual results:

System drops into emergency shell.
After removing the /home line from /etc/fstab, system will boot normally.

Expected results:

System boots normally.

Additional info:

This is a snippet of the kickstart file I used (irrelevant parts removed). The actual installation was run using Hashicorp packer 1.7.8.

lang en_US
keyboard us
timezone America/Los_Angeles --isUtc
rootpw vagrant --plaintext
# Users are created in the post script.
#platform x86, AMD64, or Intel EM64T
reboot
text
eula --agreed
cdrom
bootloader --location=mbr --append="rhgb quiet crashkernel=auto"
zerombr
clearpart --all --initlabel
autopart
auth --passalgo=sha512 --useshadow
selinux --enforcing
%include /tmp/net-include
firewall --enabled --ssh
skipx
firstboot --disable

Comment 1 kkeane 2021-11-09 00:17:47 UTC
Update: upon reviewing the documentation for autopart, it appears that this problem will only occur on relatively small drives.

The documentation for autopart (for RHEL 7) says: "On large enough drives (50 GB and larger), this also creates a /home partition."

Comment 2 kkeane 2021-11-09 00:51:20 UTC
Workaround:

Using "autopart --nohome" instead of just autopart will generate a correct fstab.

Comment 3 kkeane 2021-11-09 01:12:28 UTC
Upon further investigation, the actual problem is that autopart "forgets" to create the /home partition when it should create it.

Scenario: 80 GB disk.
Kickstart contains "autopart" without any options.

Actual result:
Disk will be partitioned as follows (sorry, I was not able to copy the output from lsblk, so values are approximate):

/dev/sda1  - /boot
/dev/sda2  - LVM, approximately 78 GB.
/dev/mapper/rhel9beta_root - approximately 48 GB.
/dev/mapper/rhel9beta_swap - a few GB
Remaining part of /dev/sda2 remains unused.

Expected result:
Disk should be partitioned as follows:

/dev/sda1  - /boot
/dev/sda2  - LVM, approximately 78 GB.
/dev/mapper/rhel9beta_root - approximately 48 GB.
/dev/mapper/rhel9beta_home - approximately 28 GB.
/dev/mapper/rhel9beta_swap - a few GB

Comment 4 Jan Stodola 2021-11-09 11:34:05 UTC
Thank you for the bug report.
Can you please attach the installation logs? You can find them in /var/log/anaconda on the installed system (or in /tmp during the installation).

Comment 5 kkeane 2021-11-16 22:28:47 UTC
Created attachment 1842207 [details]
Requested log files, plus a few more that may be useful

Comment 6 Jan Stodola 2021-11-18 08:43:30 UTC
I cannot see anything suspicious in the logs, the LV with /home was created and formatted during the installation:

INFO:program:Running... mkfs.xfs -f /dev/mapper/rhel_vagrant--rhel9beta-home
INFO:program:stdout:
INFO:program:meta-data=/dev/mapper/rhel_vagrant--rhel9beta-home isize=512    agcount=4, agsize=1573120 blks
INFO:program:         =                       sectsz=512   attr=2, projid32bit=1
INFO:program:         =                       crc=1        finobt=1, sparse=1, rmapbt=0
INFO:program:         =                       reflink=1    bigtime=1 inobtcount=1
INFO:program:data     =                       bsize=4096   blocks=6292480, imaxpct=25
INFO:program:         =                       sunit=0      swidth=0 blks
INFO:program:naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
INFO:program:log      =internal log           bsize=4096   blocks=3072, version=2
INFO:program:         =                       sectsz=512   sunit=0 blks, lazy-count=1
INFO:program:realtime =none                   extsz=4096   blocks=0, rtextents=0
DEBUG:program:Return code: 0

I was not able to reproduce the problem locally.

Vojto, do you have any idea what could be the problem?

Comment 7 kkeane 2021-11-18 09:12:16 UTC
I notice a few entries in lvm.log that say "Skipping unusable device". I'm not enough of an LVM expert to understand if this may be transient and harmless, or related.

There are entries both regarding the home and the swap partitions (but not for the root partition), so this may not be relevant. The swap partition does show up in lsblk, the home partition doesn't.

Comment 8 Jan Stodola 2022-01-07 16:16:47 UTC
A similar bug 2037905 was reported. It might be the same problem as descrideb here.

Comment 9 Jan Stodola 2022-01-10 09:26:13 UTC
Could you please provide the content of /etc/lvm/devices/system.devices ? Does the system boots successfully with /home mounted if you remove the file?

Comment 10 kkeane 2022-01-10 09:28:40 UTC
Unfortunately, I can't. This was a transient experimental system that has long since been scrubbed.

Comment 11 Jan Stodola 2022-01-10 09:47:21 UTC
OK. My assumption here is that this is the same problem with generating /etc/lvm/devices/system.devices during the installation as we see in bug 2037905 and also in bug 2024100. The problem should be fixed in lvm2-2.03.14-3.el9.
I'm closing this bug, but feel free to re-open if you can still reproduce it with lvm2-2.03.14-3.el9 or later.