Re: [CentOS] Kernel updates do not boot - always boots oldest kernel
Here is the contents of the entire
cat /etc/default.grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=0
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto
rd.md.uuid=066ffecb:69137a0b:4e579b4f:dfbf1696
rd.md.uuid=bd87f682:e6df10e2:d2a6e247:834133f7 rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
I have only changed GRUB_DEFAULT from "saved" to "0"
I have also run
/usr/sbin/grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
and seen the grub.cfg and grubenv updated in /boot/efi/EFI/centos
At this point I think I have grub doing its stuff in the correct folder
/ destination used by UEFI for booting.
When I look at grub.cfg there is some stuff I cannot understand
there are five menuentry in this file, like:
menuentry 'CentOS Linux (3.10.0-1160.88.1.el7.x86_64) 7 (Core)' --class
centos --class gnu-linux --class gnu --class os --unrestricted
$menuentry_id_option
'gnulinux-3.10.0-1160.81.1.el7.x86_64-advanced-7276336b-d2f2-4b94-b491-ad8c5662acb3'
{
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod part_gpt
insmod diskfilter
insmod mdraid1x
insmod xfs
set root='mduuid/bd87f682e6df10e2d2a6e247834133f7'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='mduuid/bd87f682e6df10e2d2a6e247834133f7'
f12be7f3-a6c6-4b90-8c51-286c32d11d12
else
search --no-floppy --fs-uuid --set=root
f12be7f3-a6c6-4b90-8c51-286c32d11d12
fi
linuxefi /vmlinuz-3.10.0-1160.88.1.el7.x86_64
root=UUID=7276336b-d2f2-4b94-b491-ad8c5662acb3 ro crashkernel=auto
rd.md.uuid=066ffecb:69137a0b:4e579b4f:dfbf1696
rd.md.uuid=bd87f682:e6df10e2:d2a6e247:834133f7 rhgb quiet LANG=en_US.UTF-8
initrdefi /initramfs-3.10.0-1160.88.1.el7.x86_64.img
}
the above is the latest kernel - doesn't boot as the console tells me it
cannot load the vmlinuz file
the kernel that boots looks like:
menuentry 'CentOS Linux (3.10.0-1160.36.2.el7.x86_64) 7 (Core)' --class
centos --class gnu-linux --class gnu --class os --unrestricted
$menuentry_id_option
'gnulinux-3.10.0-1160.36.2.el7.x86_64-advanced-7276336b-d2f2-4b94-b491-ad8c5662acb3'
{
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod part_gpt
insmod diskfilter
insmod mdraid1x
insmod xfs
set root='mduuid/bd87f682e6df10e2d2a6e247834133f7'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='mduuid/bd87f682e6df10e2d2a6e247834133f7'
f12be7f3-a6c6-4b90-8c51-286c32d11d12
else
search --no-floppy --fs-uuid --set=root
f12be7f3-a6c6-4b90-8c51-286c32d11d12
fi
linuxefi /vmlinuz-3.10.0-1160.36.2.el7.x86_64
root=UUID=7276336b-d2f2-4b94-b491-ad8c5662acb3 ro crashkernel=auto
rd.md.uuid=066ffecb:69137a0b:4e579b4f:dfbf1696
rd.md.uuid=bd87f682:e6df10e2:d2a6e247:834133f7 rhgb quiet
initrdefi /initramfs-3.10.0-1160.36.2.el7.x86_64.img
}
I see that the first line names the kernel in brackets (correctly) but
the $menuentry_id_option '.' doesn't make sense to me.
For the kernel that boots (3.10.0-1160.36.2) the entry is
'gnulinux-3.10.0-1160.36.2.el7.x86_64-advanced-7276336b-d2f2-4b94-b491-ad8c5662acb3'
For kernels that don't boot, e.g (3.10.0-1160.88.1) we see
'gnulinux-3.10.0-1160.81.1.el7.x86_64-advanced-7276336b-d2f2-4b94-b491-ad8c5662acb3'
and this entry just seems wrong
firstly the kernel version doesn't match - it has been set to ... 81.1
... rather than 88.1
secondly the last part of the line is the same for every menuentry, namely
-advanced-7276336b-d2f2-4b94-b491-ad8c5662acb3
where does this come from? what is this part for? doing?
Thanks
Rob
On 15/03/23 05:05, Leon Fauster via CentOS wrote:
Am 14.03.23 um 12:30 schrieb Rob Kampen:
OK,
found out the problem as to why it doesn't boot any kernel except 36.2
the system reports that it cannot find
vmlinuz-3.10.0-1160.88.1.el7.x86_64
or any one of the others, except for vmlinuz-3.10.0-1160.36.2.el7.x86_64
hence a manual selection from the grub menu when in front of the
machine will only load the 36.2 kernel
I found that under /boot/grub2 there were two .rpmnew files that
mucked up the symbolic link to the grubenv file - so fixed that and
did a reinstall of the latest kernel.
Now all the grub and efi files appear to update correctly - progress.
Now just need to work out why the efi boot process can see the old
(original) kernel (36.2) but none of the later ones.
Any ideas of where to look for this? seems a much more fundamental
problem related to kernel install and efi booting
Whats the _complete_ output of cat /etc/default/grub ?
--
Leon
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
[CentOS] PHP error message when running yum update on CentOS 7
Running yum update on a CentOS 7.9 server today I encountered the following error: PHP Warning: PHP Startup: Unable to load dynamic library 'imap.so' (tried: /usr/lib64/php/modules/imap.so (/usr/lib64/php/modules/imap.so: cannot open shared object file: No such file or directory), /usr/lib64/php/modules/imap.so.so (/usr/lib64/php/modules/imap.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0 How do I handle this error? Thank you. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] vault.centos.org down ?
On 14/03/2023 17:22, James Pearson wrote: I'm getting 'Forbidden You don't have permission to access this resource.' when accessing https://vault.centos.org/ Is it down ? Thanks James Pearson ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos We have one server with a corrupted FS but it was removed from the origin nodes used by AWS cloudfront Investigating though ... -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org] OpenPGP_signature Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] vault.centos.org down ?
It works for me. On 3/14/2023 11:22 AM, James Pearson wrote: I'm getting 'Forbidden You don't have permission to access this resource.' when accessing https://vault.centos.org/ Is it down ? Thanks James Pearson ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos -- Christopher Wensink IS Administrator Five Star Plastics, Inc 1339 Continental Drive Eau Claire, WI 54701 Office: 715-831-1682 Mobile: 715-563-3112 Fax: 715-831-6075 cwens...@five-star-plastics.com www.five-star-plastics.com ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] vault.centos.org down ?
I'm getting 'Forbidden You don't have permission to access this resource.' when accessing https://vault.centos.org/ Is it down ? Thanks James Pearson ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel updates do not boot - always boots oldest kernel
Am 14.03.23 um 12:30 schrieb Rob Kampen: OK, found out the problem as to why it doesn't boot any kernel except 36.2 the system reports that it cannot find vmlinuz-3.10.0-1160.88.1.el7.x86_64 or any one of the others, except for vmlinuz-3.10.0-1160.36.2.el7.x86_64 hence a manual selection from the grub menu when in front of the machine will only load the 36.2 kernel I found that under /boot/grub2 there were two .rpmnew files that mucked up the symbolic link to the grubenv file - so fixed that and did a reinstall of the latest kernel. Now all the grub and efi files appear to update correctly - progress. Now just need to work out why the efi boot process can see the old (original) kernel (36.2) but none of the later ones. Any ideas of where to look for this? seems a much more fundamental problem related to kernel install and efi booting Whats the _complete_ output of cat /etc/default/grub ? -- Leon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel updates do not boot - always boots oldest kernel
I had something like this happen some years ago on a workstation with 2-disk (software/Linux) RAID 1. Turns out one of the disks had been ejected from the raid array. It was that ejected disk that was getting the updates, but since it was no longer in the array it wasn't being booted, but rather the other one that wasn't getting the updates. Fred On Tue, Mar 14, 2023 at 7:31 AM Rob Kampen wrote: > OK, > > found out the problem as to why it doesn't boot any kernel except 36.2 > > the system reports that it cannot find > > vmlinuz-3.10.0-1160.88.1.el7.x86_64 > > or any one of the others, except for vmlinuz-3.10.0-1160.36.2.el7.x86_64 > > hence a manual selection from the grub menu when in front of the machine > will only load the 36.2 kernel > > I found that under /boot/grub2 there were two .rpmnew files that mucked > up the symbolic link to the grubenv file - so fixed that and did a > reinstall of the latest kernel. > > Now all the grub and efi files appear to update correctly - progress. > > Now just need to work out why the efi boot process can see the old > (original) kernel (36.2) but none of the later ones. > > Any ideas of where to look for this? seems a much more fundamental > problem related to kernel install and efi booting > > Thanks > Rob > > On 14/03/23 22:41, Petko Alov wrote: > > Change it to > > > > GRUB_DEFAULT=0 > > > > (I encountered the same issue week ago with a workstation booted for > > three month with an older kernel because of > > https://bugzilla.redhat.com/show_bug.cgi?id=2143438 , and solved it > > this way) > > > > Regards, > > > > Petko > > > > > > > > On 3/14/23 10:51, Rob Kampen wrote: > >> Can I edit /etc/default/grub and change > >> > >> GRUB_DEFAULT=saved > >> > >> to something else? > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Mount removed raid disk back on same machine as original raid
On 3/8/2023 4:08 PM, Chris Adams wrote: Once upon a time, Bowie Bailey said: What is going to happen when I try to mount a drive that the system thinks is part of an existing array? I don't _think_ anything special will happen - md RAID doesn't go actively looking for drives like that AFAIK. And RAID 1 means you should be able to ignore RAID and just access the contents directly. However, the contents could still be a problem. If LVM was in use on it, that will be a problem, because LVM does auto-probe and will react when it sees the same UUID (IIRC LVM will only block access to the newly seen drive). I don't think any filesystems care (I know I've mounted snapshots of ext4 and IIRC xfs on the same system, haven't touched btrfs). I'm not using LVM on this drive, so that won't be an issue. My concern is that since the raid info on the drive will identify itself as part of the active raid, the system will try to add it to the raid (probably as a spare) when it comes online. I don't think that would be destructive, but I would have to figure out how to separate it out if that happens. I'm hoping that it won't be an issue since there are no missing drives in the existing raid. I know I will have to bring the drive online as a broken array, but I've done that from other systems. The only question there is can I simply rebuild it with a different name. I assume I can just do "mdadm -A --run /dev/md0 /dev/sdc1" (possibly with "--force" due to the broken array) even if sdc1 was originally part of the existing md127 array? The system in question is in a data center, so I'm trying to get ahead of any possible problems to avoid having to deal with unexpected issues while I'm there. -- Bowie ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel updates do not boot - always boots oldest kernel
OK, found out the problem as to why it doesn't boot any kernel except 36.2 the system reports that it cannot find vmlinuz-3.10.0-1160.88.1.el7.x86_64 or any one of the others, except for vmlinuz-3.10.0-1160.36.2.el7.x86_64 hence a manual selection from the grub menu when in front of the machine will only load the 36.2 kernel I found that under /boot/grub2 there were two .rpmnew files that mucked up the symbolic link to the grubenv file - so fixed that and did a reinstall of the latest kernel. Now all the grub and efi files appear to update correctly - progress. Now just need to work out why the efi boot process can see the old (original) kernel (36.2) but none of the later ones. Any ideas of where to look for this? seems a much more fundamental problem related to kernel install and efi booting Thanks Rob On 14/03/23 22:41, Petko Alov wrote: Change it to GRUB_DEFAULT=0 (I encountered the same issue week ago with a workstation booted for three month with an older kernel because of https://bugzilla.redhat.com/show_bug.cgi?id=2143438 , and solved it this way) Regards, Petko On 3/14/23 10:51, Rob Kampen wrote: Can I edit /etc/default/grub and change GRUB_DEFAULT=saved to something else? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel updates do not boot - always boots oldest kernel
Change it to GRUB_DEFAULT=0 (I encountered the same issue week ago with a workstation booted for three month with an older kernel because of https://bugzilla.redhat.com/show_bug.cgi?id=2143438 , and solved it this way) Regards, Petko On 3/14/23 10:51, Rob Kampen wrote: Can I edit /etc/default/grub and change GRUB_DEFAULT=saved to something else? -- Petko Alov Department of QSAR & Molecular Modelling Institute of Biophysics and Biomedical Engineering, BAS 21 G. Bontchev Str 1113 Sofia, BULGARIA phone: +359 2 9793647 mobile: +359 87 7294336 e-mail: petko.a...@biophys.bas.bg ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Kernel updates do not boot - always boots oldest kernel
This issue has been around for some months, but other things keep crowding out a fix. uname give me 3.10.0-1160.36.2.el7.x86_64 #1 SMP Wed Jul 21 11:57:15 UTC 2021 yet I have 3.10.0-1160.76.1.el7.x86_64 3.10.0-1160.81.1.el7.x86_64 3.10.0-1160.83.1.el7.x86_64 3.10.0-1160.88.1.el7.x86_64 loaded. The system uses UEFI to boot. sudo ls -l /sys/firmware/efi gives: total 0 -r--r--r--. 1 root root 4096 Feb 19 16:47 config_table drwxr-xr-x. 2 root root 0 Feb 19 16:47 efivars -r--r--r--. 1 root root 4096 Mar 14 17:57 fw_platform_size -r--r--r--. 1 root root 4096 Feb 19 16:47 fw_vendor drwxr-xr-x. 2 root root 0 Mar 14 17:57 mok-variables -r--r--r--. 1 root root 4096 Feb 19 16:47 runtime drwxr-xr-x. 9 root root 0 Feb 19 16:47 runtime-map -r. 1 root root 4096 Feb 19 16:47 systab drwxr-xr-x. 65 root root 0 Mar 14 17:57 vars and sudo efibootmgr gives: BootCurrent: 000F BootOrder: 000F,000D,000B,000E,0008,,0002,0003,0004,0005,0006,0007 Boot* CD/DVD Rom Boot0002* PXE Network Boot0003 Enter Setup Boot0004 Boot Devices Boot0005 Boot Manager Boot0006 Setup Boot0007 Diagnostics Boot0008* Embedded Hypervisor Boot000B* CentOS Linux Boot000D* CentOS-AltDrv Boot000E* Hard Disk 3 Boot000F* CentOS-MainDrv This is a remote server, thus I need a sure fire fix. My previous attempts have either had no impact - the old kernel boots or machine hangs and I need to do a trip to the site. Now this issue could be a residual from my initial setup when I installed 2 by 3.x TB SSD and needed to manually change from bios/grub2 boot to UEFI. I have already spent 10's of hours on this system, just want to have it run the latest kernels - for obvious reasons. Some other items: sudo grep "^menuentry" /boot/grub2/grub.cfg | cut -d "'" -f2 gives: CentOS Linux (3.10.0-1160.88.1.el7.x86_64) 7 (Core) CentOS Linux (3.10.0-1160.83.1.el7.x86_64) 7 (Core) CentOS Linux (3.10.0-1160.81.1.el7.x86_64) 7 (Core) CentOS Linux (3.10.0-1160.76.1.el7.x86_64) 7 (Core) CentOS Linux (3.10.0-1160.36.2.el7.x86_64) 7 (Core) CentOS Linux (0-rescue-a39773847cf34651bc34d0566f53) 7 (Core) indicating that .88.1 should boot. sudo grub2-editenv list gives: saved_entry=CentOS Linux (3.10.0-1160.88.1.el7.x86_64) 7 (Core) also as expected. /etc/default/grub exists and contains GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="crashkernel=auto rd.md.uuid=066ffecb:69137a0b:4e579b4f:dfbf1696 rd.md.uuid=bd87f682:e6df10e2:d2a6e247:834133f7 rhgb quiet" GRUB_DISABLE_RECOVERY="true" the /boot/grub2/grubenv contains # GRUB Environment Block saved_entry=CentOS Linux (3.10.0-1160.88.1.el7.x86_64) 7 (Core) ### All these point to the correct version of the kernel but always boots the old .36.2 version. Just realized these files only relate to BIOS boot, and my system is UEFI boot. Now documentation seems to get scarce. seems like the boot files are now residing in /boot/efi/EFI/centos AND /boot/efi2/EFI/centos although looking at timestamps the latter directory is not being updated. /boot/efi/EFI/centos contains total 7028 -rwx--. 1 root root 134 Aug 1 2020 BOOT.CSV -rwx--. 1 root root 134 Aug 1 2020 BOOTX64.CSV drwx--. 2 root root 4096 Dec 23 22:01 fonts -rwx--. 1 root root 8589 Mar 14 17:51 grub.cfg -rwx--. 1 root root 1024 Aug 26 2021 grubenv -rwx--. 1 root root 1125704 Dec 17 06:13 grubx64.efi -rwx--. 1 root root 1154640 Aug 1 2020 mmx64.efi -rwx--. 1 root root 1154640 Aug 1 2020 MokManager.efi -rwx--. 1 root root 1243864 Aug 1 2020 shim.efi -rwx--. 1 root root 1237824 Aug 1 2020 shimx64-centos.efi -rwx--. 1 root root 1243864 Aug 1 2020 shimx64.efi and we see that the grub.cfg is being updated. However, here the grubenv file contains # GRUB Environment Block saved_entry=CentOS Linux (3.10.0-1160.36.2.el7.x86_64) 7 (Core)
