Bug List: (4 of 8)
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 2037905 - RHEL 9 beta installer creates unbootable system when custom partitioning is used.
Summary: RHEL 9 beta installer creates unbootable system when custom partitioning is u...
Keywords:
Status: CLOSED DUPLICATE of bug 2024100
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: lvm2
Version: 9.0
Hardware: aarch64
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: LVM and device-mapper development team
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-01-06 19:38 UTC by Jeff Putsch
Modified: 2022-01-10 15:18 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-01-10 15:18:43 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Tarball with debug files described in Initial description. (653.50 KB, application/x-tar)
2022-01-06 19:38 UTC, Jeff Putsch 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-107013 0 None None None 2022-01-06 19:40:16 UTC

Description Jeff Putsch 2022-01-06 19:38:27 UTC 
Created attachment 1849337 [details]
Tarball with debug files described in Initial description.

Description of problem:

On RHEL 9 beta, anaconda generates an invalid unbootable system configuration when used with the graphical installer and custom disk partitioning.

In this case, the installer inserts lines referencing a the partitions into fstab but the system fails to initialize the /dev/mapper/* entries for those partitions on bootup.

In addition no /var/log/anaconda directory exists on the booted system.


How reproducible:

Every time.

Steps to Reproduce:
1. Boot system using the rhel-baseos-9.0-beta-0-aarch64-dvd.iso image
2. Select Custom Partitioning
3. Select "Click here to create them" to create initial partions.
4. Adjust /home to 1 GiB
5. Adjust / to 10 GiB
6. Leave /boot, /boot/efi, and swap alone
7. Add /var (3 GiB), /var/tmp/ (1 GiB), /var/log/audit (512 MiB), /var/log (1 GiB), and /tmp (1 Gib) partitions.
8. Proceed with installation.

Actual results:

System drops into emergency shell.

Expected results:

System boots normally.


Additional info:

I've attached a tarball with containing the following files:

1. rhel-9-beta-install-logs.tar.gz - tarball of the log files in /tmp immediately before reboot.
2. anaconda-ks.cfg - "/root/anaconda-ks.cfg" file after reboot.
3. journalctl-xb.log - output of "journalctl -xb" from the emergency shell.

NOTEs: 

1. There is no /var/log/anaconda directory after the reboot.
2. "rpm -qa" after reboot lists no packages.
Comment 1 Jan Stodola 2022-01-07 16:14:21 UTC 
(In reply to Jeff Putsch from comment #0)
> NOTEs: 
> 
> 1. There is no /var/log/anaconda directory after the reboot.
> 2. "rpm -qa" after reboot lists no packages.

I assume these problems are caused by /var not being mounted during boot.


From journalctl:
...
Jan 06 11:32:24 localhost systemd[1]: dev-mapper-rhel_rhel\x2d\x2d9beta\x2d\x2daarch64\x2dhome.device: Job dev-mapper-rhel_rhel\x2d\x2d9beta\x2d\x2daarch64\x2dhome.device/start timed out.
Jan 06 11:32:24 localhost systemd[1]: Timed out waiting for device /dev/mapper/rhel_rhel--9beta--aarch64-home.
░░ Subject: A start job for unit dev-mapper-rhel_rhel\x2d\x2d9beta\x2d\x2daarch64\x2dhome.device has failed
░░ Defined-By: systemd
░░ Support: https://access.redhat.com/support
░░ 
░░ A start job for unit dev-mapper-rhel_rhel\x2d\x2d9beta\x2d\x2daarch64\x2dhome.device has finished with a failure.
░░ 
░░ The job identifier is 173 and the job result is timeout.
Jan 06 11:32:24 localhost systemd[1]: Dependency failed for /home.
...

This looks like the LV block devices were not created. I'm reassigning this bug to lvm2 for further review.
I tried to reproduce this problem on RHEL-9.0-Beta, but I was not successful, the system booted fine.
Also, this bug reminds me bug 2021353, where LV with /home was not created during boot.
Comment 2 David Teigland 2022-01-07 17:14:59 UTC 
Jan 06 11:30:55 localhost lvm[685]: /dev/sda3 excluded by filters: device is not in devices file.

The device needed for the LVs is not included in the lvm devices file, so lvm ignores it.  I don't know how this version of anaconda is setting up the devices file, the most recent design is to add all visible PVs to the devices file.
Comment 3 Jan Stodola 2022-01-07 20:09:18 UTC 
Jeff, is the file /etc/lvm/devices/system.devices present on the installed system? What is the content of the file? Would the system boot correctly if you (re)move the file?
Comment 4 Jeff Putsch 2022-01-07 22:05:18 UTC 
Answer questions:

1. The file /etc/lvm/devices/system.devices IS present.
2. The content of the file:

# LVM uses devices listed in this file.
# Created by LVM command vgimportdevices pid 45507 at Thu Jan  6 11:24:43 2022
VERSION=1.1.1
IDTYPE=sys_wwid IDNAME=t10.ATA     rhel-9beta-aarch64-0 SSD                QZ8CSQE08TN4FFMGFBY2 DEVNAME=/dev/sda3 PVID=sgPsILPY8ppc5s4z6YGABslwh8vm62cm PART=3

3. Does the system boot correctly if I remove the file?

   YES!

   All partitions specified during setup are there, properly sized and appear to have correct contents.

Jeff.
Comment 5 Jan Stodola 2022-01-10 09:16:54 UTC 
David,
IDNAME in comment 4 doesn't look correct and it might be the same problem as reported in bug 2024100. Reassigning back to lvm2.
Comment 6 David Teigland 2022-01-10 15:18:43 UTC 
(In reply to Jan Stodola from comment #5)
> IDNAME in comment 4 doesn't look correct and it might be the same problem as

Thanks for finding that...

IDNAME=t10.ATA     rhel-9beta-aarch64-0 SSD                QZ8CSQE08TN4FFMGFBY2

That's a dubious WWID, any idea where that's created (i.e. was it set by a user or some automation?)

> reported in bug 2024100. Reassigning back to lvm2.

Yes, it's the same problem and same fix as bug 2024100, so I'll close this as a duplicate.

*** This bug has been marked as a duplicate of bug 2024100 ***
Note You need to log in before you can comment on or make changes to this bug.
Bug List: (4 of 8)