Open SteffanCline opened 1 year ago
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.
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)
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
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
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.
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...
Surely there's a way to get this fixed in the installer. Where's the best place to report it if not here?
@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.
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.
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.
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:
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?