OL9.2 Install with EXT4 Fails to Boot

[SteffanCline]

I've been trying to install OL9.2 on a Dell R630. The drives are freshly formatted. I used Rufus on Windows in DD mode to write out the OL9 installer ISO to a thumb drive. In the OL installer UI, I set the locations to use EXT4 rather than XFS. It completed just fine. Upon boot, it fails the same 6x in a row the exact same way every time no matter what I do. I tried manually entering all the following grub options:

set root=(hd0)
set prefix=(hd0)/boot/grub
insmod normal
normal

That failed with the same fs.c:121:unknown filesystem error.

I wiped the drives and reinstalled OL9.2 a 7th time leaving all the defaults as XFS and it finally worked. FWIW, the same thing happens with the 9.1 and 9.0 installers as well.

What needs to happen for OL9 to use EXT4?

[SteffanCline]

This same issue affects RL9, AL9 and RHEL9 too. I've booted into rescue mode from the installer and bind mounted al the dirs and used grub2-mkconfig to ensure grub is correct and then grub2-install /dev/sda and still, same errors. Nothing is working.

[AmedeeBulle]

I can't reproduce here...

[root@localhost ~]# df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  4.0M     0  4.0M   0% /dev
tmpfs          tmpfs     7.6G     0  7.6G   0% /dev/shm
tmpfs          tmpfs     3.1G  8.6M  3.1G   1% /run
/dev/sda2      ext4       42G  1.3G   39G   4% /
/dev/sda1      ext4      974M  231M  676M  26% /boot
/dev/sda3      ext4       21G   24K   20G   1% /home
tmpfs          tmpfs     1.6G     0  1.6G   0% /run/user/0

With UEFI:

[root@localhost ~]# df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  4.0M     0  4.0M   0% /dev
tmpfs          tmpfs     7.6G     0  7.6G   0% /dev/shm
tmpfs          tmpfs     3.1G  8.6M  3.1G   1% /run
/dev/sda3      ext4       41G  1.3G   38G   4% /
/dev/sda2      ext4      974M  225M  682M  25% /boot
/dev/sda4      ext4       20G   24K   19G   1% /home
/dev/sda1      vfat      599M  6.2M  593M   2% /boot/efi
tmpfs          tmpfs     1.6G     0  1.6G   0% /run/user/0

Can you share your exact partitioning scheme? (E.g. with screenshot of the "partition summary" screen of the installer)

[SteffanCline]

The issue is definitely odd. I have 6x Dell R630. The Anaconda installer has acted unexpectedly on four of them. On two, the install worked fine as expected. On the other four, they would not accept the auto partitioning configuration and then changing them from XFS to EXT4. Before continuing the install, I checked the popup window and you could see it was out of order, meaning

1. /home
2. /root
3. /boot

The system wouldn't boot with it like that no matter what I did. The only way I could get the installer to proceed was to carefully manually create each partition in the expected order and set each to EXT4 before going onto the next partition. Then I'd hit done and have to check to ensure they were being created in the expected order

1. /boot
2. /
3. /home

If they weren't in that order, the system wouldn't come up. I wouldn't even get a grub menu, just that error above. Here's where it gets even more odd. If I do the automatic partitioning but select XFS on /boot and EXT4 on / and /home, the partitions would be created in the correct order and the server would boot.

[AmedeeBulle]

Indeed, if the boot partition is too far from the start of the disk, it won't see it and the installer reshuffles the partitions when you change the filesystem type.

Note that you can get /boot back in front by changing back and forth another partition, so you don't have to re-do everything manually...

[SteffanCline]

Surely there's a way to get this fixed in the installer. Where's the best place to report it if not here?

[YoderExMachina]

@SteffanCline, following up on this issue. Is this still a problem? I have also tried to duplicate it and can't. I'd like to close this issue if it's no longer causing problems.

[SteffanCline]

I haven't had to reinstall it again from scratch in a while so I can't confirm anything but if nothing has changed, it's still there in some cases.

[YoderExMachina]

Well, we haven't had any further complaints on this issue and I've searched out internal tickets and have not found anything similar reported.