[Closed] RHEL 9 - single kernel option at boot

[TrevorH]

Also, I believe the kernel install updates /etc/grub2.cfg or /etc/grub2-efi.cfg which should be symlinks to their /boot/grub2 equivalents. IF the symlink is broken and the /etc files are real files then it'll update the real files in /etc but not the ones in /boot... which are the ones that grub readsw, not the ones in /etc.

[root@here ~]# ls -la /etc/grub*.cfg
lrwxrwxrwx. 1 root root 22 Jan 15 00:00 /etc/grub2.cfg -> ../boot/grub2/grub.cfg
lrwxrwxrwx. 1 root root 22 Jan 15 00:00 /etc/grub2-efi.cfg -> ../boot/grub2/grub.cfg

To fix that, if it is the problem, you'd need to copy the updated file from /etc to /boot then fix the symlink.

[lightman47]

My etc files are symlinks as you show above. The /boot/grub2 shows:

Code: Select all

 sudo ls -la /boot/grub2
total 16
drwx------. 3 root root   50 Mar 12 10:40 .
dr-xr-xr-x. 5 root root 4096 Mar 12 08:28 ..
drwx------. 2 root root   25 Mar 12 08:21 fonts
-rw-------. 1 root root 7762 Mar 12 10:33 grub.cfg
-rw-------. 1 root root 1024 Mar 12 10:40 grubenv

Your question about mdadm ... I wonder if it "gets stuck" on the kernel under which it was installed (the one it still boots to!).

[lightman47]

/etc/fstab (raid at bottom)

Code: Select all

 sudo cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Sun Nov  6 20:09:47 2022
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
/dev/mapper/rhel_wjoe-root /                       xfs     defaults        0 0
#UUID=2878fa72-9f4b-4a1c-813d-5d2557031fde /boot                   xfs     defaults        0 0
#UUID=BCDA-47F0          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
/dev/mapper/rhel_wjoe-home /home                   xfs     defaults        0 0
/dev/mapper/rhel_wjoe-swap none                    swap    defaults        0 0
wlinux:/mnt/4tb1/ /mnt/wlinux.4tb1 nfs defaults 0 0
wlinux:/mnt/4tb2/ /mnt/wlinux.4tb2 nfs defaults 0 0
wlinux:/mnt/4tb3/ /mnt/wlinux.4tb3 nfs defaults 0 0
wlinux:/var/www /mnt/wlinux.www nfs defaults 0 0
## UNcomment the following if the system has Windows and that drive is labeled 'Win'.
LABEL=Win /mnt/Win ntfs defaults 0 0
/dev/md/name /mnt/RAID-1 ext4 defaults 0 0

also:

Code: Select all

sudo ls -la /dev/md/name
lrwxrwxrwx. 1 root root 8 Mar 12 10:37 /dev/md/name -> ../md127

which leads to:

Code: Select all

sudo ls -la /mnt/RAID-1
total 32
drwxrwxr-x.  6 root family  4096 Oct 12 13:29 .
drwxr-xr-x.  9 root root     125 Aug  9  2021 ..
drwxrwxr-x.  3 root family  4096 Dec 11  2022 backup
drwxrwxr-x.  3 root family  4096 Aug 24  2022 joe
drwx------.  2 root family 16384 Aug 24  2022 lost+found
drwxr-xr-x. 11 root family  4096 Dec 21 06:01 Pictures

[TrevorH]

The question about mdadm is only applicable if /boot (or / if /boot is part of that) is on an mdadm device. It has been know that an mdadm aray can lose one of its members so the drive that has dropped out no longer gets updated. If the non-updated drive is the one that the BIOS is set to boot from then it will pick up the old config file and old kernel and boot that because it's the only thing it knows about. If /boot isn't on an mdadm array then it will not be that.

Oh, wait, I just spotted your fstab has /boot and /boot/efi commented out. That means it's busy updating the /boot *directory* on your root filesystem with the changes and NOT /boot. You need to copy everything out of /boot on the root filesystem to somewhere else, mount both filesystems that shouldbe mounted then copy the files back so they end up in the right filesystem.

[lightman47]

OH - I wonder if I did that - or something else ... hmm.

I could get the proper UUIDs and edit them in, then uncomment and see what happens

Code: Select all

 sudo lsblk -o NAME,SIZE,UUID
NAME                 SIZE UUID
sda                  7.3T 0abfb277-93ee-704f-d658-15195767bd0e
└─md127              7.3T b2ea0c39-ea07-497d-b7ed-112c16f0416a
sdb                  7.3T 0abfb277-93ee-704f-d658-15195767bd0e
└─md127              7.3T b2ea0c39-ea07-497d-b7ed-112c16f0416a
sr0                 1024M 
nvme0n1              1.8T 
├─nvme0n1p1          100M 8C57-1BB2
├─nvme0n1p2           16M 
├─nvme0n1p3        912.6G EA7072F67072C8B9
├─nvme0n1p4          505M C4E89629E89619AE
├─nvme0n1p5            1G fedfb33a-2c41-4552-9640-da2106f8b40b
└─nvme0n1p6        948.8G BCkAYc-AnIr-eTNr-2eda-1MEx-iKjf-IkGmq0
  ├─rhel_wjoe-root    70G 21cef98c-3b76-4138-95c9-35415f1279c5
  ├─rhel_wjoe-swap  31.5G d547fbd7-9cda-4d83-88c3-c1730c8ce529
  └─rhel_wjoe-home 847.3G 26963065-4067-4b34-8fad-477d780e26b9
  

will check & edit in a bit other chore at the moment

[lightman47]

OK - starting to come back to me now, in bits & pieces:

That was when I swapped out the initial 1TB nvme for a 2tb, then dual booted it - Windows 10 first, then RHEL9. As I recall, I had a heck of a time getting it to boot RHEL! I don't recall commenting them out.

As there is no "/boot" partition I am lost and hesitant to change anything.

(I wonder if nvme0n1p5 is /boot, and perhaps nvme0n1p1 is /boot/efi)

[TrevorH]

Looking at your lsblk I'd say 8C57-1BB2 is most likely /boot/efi and fedfb33a-2c41-4552-9640-da2106f8b40b is /boot but if you mount those manually on something like /mnt then you can check the contents and see if they look like they are. /boot/efi should contain just an EFI directory and /boot will contain vmlinuz* and initramfs* files.

At present since you do not have /boot or /boot/efi mounted, there is a plain directory on your / filesystem called /boot and the kernel updates will have been putting their updated files into that directory (and subdirs). You will need to copy the contents of the /boot directory into the filesystyem that they should be in. You can either copy those files elsewhere and then mount the right filesystems in the right places and copy them back or mount those filesystems elsewhere and recursively copy the files to them from the /boot directory. Once copied, fix up fstab to mount the right things in the right places.

[lightman47]

OK - edited to:

Code: Select all

 sudo cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Sun Nov  6 20:09:47 2022
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
/dev/mapper/rhel_wjoe-root /                       xfs     defaults        0 0
UUID=fedfb33a-2c41-4552-9640-da2106f8b40b /boot                   xfs     defaults        0 0
UUID=8C57-1BB2          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
/dev/mapper/rhel_wjoe-home /home                   xfs     defaults        0 0
/dev/mapper/rhel_wjoe-swap none                    swap    defaults        0 0
wlinux:/mnt/4tb1/ /mnt/wlinux.4tb1 nfs defaults 0 0
wlinux:/mnt/4tb2/ /mnt/wlinux.4tb2 nfs defaults 0 0
wlinux:/mnt/4tb3/ /mnt/wlinux.4tb3 nfs defaults 0 0
wlinux:/var/www /mnt/wlinux.www nfs defaults 0 0
## UNcomment the following if the system has Windows and that drive is labeled 'Win'.
LABEL=Win /mnt/Win ntfs defaults 0 0
/dev/md/name /mnt/RAID-1 ext4 defaults 0 0

and rebooted just fine. I then ran

Code: Select all

sudo grub2-mkconfig -o /boot/grub2/grub.cfg  --update-bls-cmdline

and rebooted again in hope of getting more menuenrty items, but alas! I suppose I'll have to wait until RH releases another kernel.
----------------------
and just saw you last post about copying files - I will look into that.

[lightman47]

Looking at your lsblk I'd say 8C57-1BB2 is most likely /boot/efi and fedfb33a-2c41-4552-9640-da2106f8b40b is /boot but if you mount those manually on something like /mnt then you can check the contents and see if they look like they are. /boot/efi should contain just an EFI directory and /boot will contain vmlinuz* and initramfs* files.

That IS the case - except that /boot/EFI also contains the 'System Volume Information' file from Windows.
- currently re-installing kernel\*.\*. As I am running the old one I don't have to worry about it failing.

[lightman47]

BINGO!!!

Now it's just a matter of setting the boot order and running mkconfig again.

Thank you much to both of you!