Initrd in grub not created automatically in RHEL 7.1

Latest response

I have inherited support responsibilities for a RHEL 7.1 server which is unable to boot into kernel 3.10.0-229.el7.x86_64. I can manually edit grub menu and add in the line initrd /initramfs-3.10.0-229.el7.x86_64.img and it boots fine - but this is not persistent so I need to figure out why this line is not being added automatically.

I have tried manually reinstalling the kernel via yum, no change in results.
I have run dracut --force, with no change in results.

This is a backup server, and the client is understandably concerned about this server loading automatically if it ever powers off.

Help?

Attachments

CC
Log in to join the conversation

Responses

CC Community Member 35 points
17 November 2015 12:46 AM

A little more information:

[root@xxx grub]# grubby --info /boot/vmlinuz-3.10.0-229.20.1.el7.x86_64
index=0
kernel=/boot/vmlinuz-3.10.0-229.20.1.el7.x86_64
args="ro LANG=en_US.UTF-8"
root=/dev/mapper/vg_tch-lv_root
initrd=/boot/initramfs-3.10.0-229.20.1.el7.x86_64.img
title=Red Hat Enterprise Linux Server (3.10.0-229.20.1.el7.x86_64) 7.1 (Maipo)
CC Community Member 35 points
17 November 2015 12:49 AM

And a little more:

[root@xxx grub]# cat /etc/sysconfig/kernel
# UPDATEDEFAULT specifies if new-kernel-pkg should make
# new kernels the default
UPDATEDEFAULT=yes

# DEFAULTKERNEL specifies the default kernel package type
DEFAULTKERNEL=kernel
CC Community Member 35 points
17 November 2015 1:12 AM

Added picture of the trace errors that appear on booting any of the three kernel entries in Grub.

Akemi Yagi's picture Guru 2404 points
17 November 2015 1:22 AM

According to the info provided, you apparently have kernel-3.10.0-229.20.1.el7.x86_64. But are you attempting to boot kernel-3.10.0-229.el7.x86_64 and that's failing? Could you clarify?

CC Community Member 35 points
17 November 2015 5:04 AM

Could this be because the only way to get the server to boot is using the recovery kernel option in grub?

I am remote connected to the machine now, and can verify the currently loaded kernel is

[user@xxx ~]$ uname -r
3.10.0-229.el7.x86_64

The latest installed kernel is as per the grubby commands above.

MM Red Hat Pro 555 points
17 November 2015 8:12 AM

What is the output of "ls /boot" and "uname -a"? And, can you attach /etc/grub2.cfg?

CC Community Member 35 points
18 November 2015 1:54 AM

ls /boot
config-2.6.32-358.11.1.el6.x86_64 initrd-3.10.0.229.20.1.el.img
config-2.6.32-358.el6.x86_64 initrd-plymouth.img
config-3.10.0-229.11.1.el7.x86_64 lost+found
config-3.10.0-229.14.1.el7.x86_64 symvers-2.6.32-358.11.1.el6.x86_64.gz
config-3.10.0-229.20.1.el7.x86_64 symvers-2.6.32-358.el6.x86_64.gz
efi symvers-3.10.0-229.11.1.el7.x86_64.gz
grub symvers-3.10.0-229.14.1.el7.x86_64.gz
grub2 symvers-3.10.0-229.20.1.el7.x86_64.gz
initramfs-0-rescue-0c43f378567a09aad8743b430000001a.img System.map-2.6.32-358.11.1.el6.x86_64
initramfs-2.6.32-358.11.1.el6.x86_64.img System.map-2.6.32-358.el6.x86_64
initramfs-2.6.32-358.el6.x86_64.img System.map-3.10.0-229.11.1.el7.x86_64
initramfs-3.10.0-229.11.1.el7.x86_64.img System.map-3.10.0-229.14.1.el7.x86_64
initramfs-3.10.0-229.14.1.el7.x86_64.img System.map-3.10.0-229.20.1.el7.x86_64
initramfs-3.10.0-229.20.1.el7.x86_64.img vmlinuz-0-rescue-0c43f378567a09aad8743b430000001a
initramfs-3.10.0-229.el7.x86_64.img vmlinuz-2.6.32-358.11.1.el6.x86_64
initrd-2.6.32-358.11.1.el6.x86_64kdump.img vmlinuz-2.6.32-358.el6.x86_64
initrd-2.6.32-358.23.2.el6.x86_64kdump.img vmlinuz-3.10.0-229.11.1.el7.x86_64
initrd-2.6.32-358.el6.x86_64kdump.img vmlinuz-3.10.0-229.14.1.el7.x86_64
initrd-2.6.32-504.23.4.el6.x86_64kdump.img vmlinuz-3.10.0-229.20.1.el7.x86_64
initrd-3.10.0.229.20.1.el7.x86_64.img

uname -a (note: is the rescue boot option)
Linux encore.anu.edu.au 3.10.0-229.el7.x86_64 #1 SMP Thu Jan 29 18:37:38 EST 2015 x86_64 x86_64 x86_64 GNU/Linux

grub2.cfg added to ticket - note this is output of cat /etc/grub2.cfg copied into a text editor

MM Red Hat Pro 555 points
18 November 2015 5:06 AM

In grub2.rtf:
menuentry 'Red Hat Enterprise Linux Server 7.1 (Maipo), with Linux 3.10.0-229.20.1.el7.x86_64' --class fedora ...

I saw "--class fedora" in it, maybe /etc/system-release had the string including 'Fedora'.
Are you trying to install rhel 7.1 kernel on Fedora?
Was the grub2 of RHEL7 used for the boot loader?
grub2.cfg has the initrd16= line in it for 3.10.0-229.20.1.el7.x86_64, which looks the latest kernel on the system. And, it doesn't have the configuration for 3.10.0-229.el7.x86_64.

In /boot, initramfs-3.10.0-229.el7.x86_64.img is available, which is for 3.10.0-229.el7.x86_64. But, vmlinuz-3.10.0-229.el7.x86_64 is not available. How was the initramfs created without installing the kernel of the version?

CC Community Member 35 points
23 November 2015 6:10 AM

Not sure, but that fedora entry might have been put in place but someone before me. No idea why - this is a RHEL 7 server.

I have tried to run some commands to manually force reinstall of the correct kernel and associated initrd/initramfs.

As per this link: https://access.redhat.com/solutions/1645

new-kernel-pkg -v --mkinitrd --depmod --install 3.10.0.229.20.1.el7.x86_64 initrdfile is /boot/initrd-3.10.0.229.20.1.el7.x86_64.img
new-kernel-pkg -v --mkinitrd --depmod --install 3.10.0.229.20.1.el7.x86_64
initrdfile is /boot/initrd-3.10.0.229.20.1.el7.x86_64.img
running depmod for 3.10.0.229.20.1.el7.x86_64
depmod: FATAL: could not load /boot/System.map-3.10.0.229.20.1.el7.x86_64: No such file or directory
creating initrd: mkinitrd --allow-missing -f /boot/initrd-3.10.0.229.20.1.el7.x86_64.img 3.10.0.229.20.1.el7.x86_64
Kernel version 3.10.0.229.20.1.el7.x86_64 has no module directory /lib/modules/3.10.0.229.20.1.el7.x86_64
kernel for 3.10.0.229.20.1.el7.x86_64 does not exist, not running grubby

and when that didn't work:

yum reinstall kernel-3.10.0-229.20.1.el7
Loaded plugins: langpacks, product-id, subscription-manager
Resolving Dependencies
--> Running transaction check
---> Package kernel.x86_64 0:3.10.0-229.20.1.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package     Arch        Version                  Repository               Size
================================================================================
Reinstalling:
 kernel      x86_64      3.10.0-229.20.1.el7      rhel-7-server-rpms       31 M

Transaction Summary
================================================================================
Reinstall  1 Package

Total download size: 31 M
Installed size: 131 M
Is this ok [y/d/N]: y
Downloading packages:
No Presto metadata available for rhel-7-server-rpms
kernel-3.10.0-229.20.1.el7.x86_64.rpm                      |  31 MB   00:04     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : kernel-3.10.0-229.20.1.el7.x86_64                            1/1 
  Verifying  : kernel-3.10.0-229.20.1.el7.x86_64                            1/1 

Installed:
  kernel.x86_64 0:3.10.0-229.20.1.el7                                           

Complete!

This still hasn't resolved the issue.

Again - I am only able to connect now to rescue kernel.

I'd really like to remove any erroneous junk and get this back to a pure RHEL 7 server running the latest kernel - but need some help on how to do that.

SW Red Hat Guru 4017 points
23 November 2015 9:35 AM

Hello,

If you use the grubby command to make changes to the GRUB 2 menu then they will be persistent. It is the preferred way as mentioned d here Making Persistent Changes to a GRUB 2 Menu Using the grubby Tool.

Ignore the "--class fedora" for the moment, I have that too on my test VM.

I noticed you have set default="0" rather than set default="${saved_entry}", but that could be because you were trying to change the default kernel as explained here Changing the Default Boot Entry.

LL Community Member 90 points
4 August 2017 7:19 PM

I just saw this blog because I am looking for answers to my problem with the initramfs file not being found after kernel update. This happens for 7.1 7.2 7.3 & now 7.4 but it not consistence . Sometimes it works, sometimes it doesn't I have had a case open with redhat but have been unable to solve the problem as of yet. One of the road blocks i am running into is that we have the Linux servers running on Hypr-V host. I have permissions to load iso but do not as of yet have permissions to take a snapshot of the server prior to update, so that if it fails I can drop back to previous version and test with redhat. And it is not just with VM's, it also happens on physical servers as well. and also I have a couple of CentOS VM's that have the same issue. So sometimes it works no problem after update. Sometimes it goes straight to grub prompt> and sometimes it will go to the grub menu and then have a kernel panic. I know that RHEL 7 default FS is xfs. I have set the /boot to xfs and the rest of the filesystems are ext4. But I did have the same issues with a server where all filesystems were xfs. What I have noticed is that I can mount the rescue iso and let it boot to rescue mode. I can see the initramfs file in the /boot directory. From the boot prompt i could not see the initramfs file. so when I exit out of rescue mode I notice that as it is unloading everything is say that it is running a repair job. Then it reboots, and since I have the rescue iso still mounted i tell it to boot from local disk. it will come up with grub menu sometimes it boots cleanly, sometimes it is fixing a filesystem then gets sent for another reboot. reboot from local drive. Server comes up okay. No issues.
I have done various options of updating packages where I exclude the dracut*, kernel* microcode* update everything else. but going from 7.3 to 7.4 there are other dependencies associated with dracut.
I always reboot after updating other packages, prior to updating the kernel. and there are no issues with the reboot. It only happens after the kernel update. It appears that the initramfs image file may get corrupted when initially being created. Is there a way to check this after the update before reboot?

SM Guru 3716 points
7 August 2017 6:36 PM

Even I too trying to find out if there is any way to verify if the new kernel installed has got enough modules as compared with previous (working one) to successfully boot, but not any straight forward answers there. Using "lsinitrd" modules could be verified and compared with other one, and commands like "gunzip" could be used to dump the initramfs file, but could not help much. There are a few initial steps documented here https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sec-Verifying_the_Initial_RAM_Disk_Image.html but not extensive. Recently, we had upgraded a few RHEL6.8 virtual systems due to security compliance and now they were stuck with kernel panic, we had tried option of re-creating initramfs image, no go. Installing new kernel went well without any errors or warnings, after reboot systems goes into panic. Not sure if there is any other options/ways to check if newly loaded kernel/initramfs images are good enough to come back alive after a reboot.

KJ Newbie 5 points
10 August 2017 8:41 AM

Hey there,

Same happened to me. One instance running on KVM (one kernel) and one instance on XEN (two recent kernels) failed. Solution is simple - reinstall kernel, but there is nothing in the logs. Initramfs is not in /boot and it's not added to grub.

Anyone managed to dig deeper into that?

Best regards :)

SH Newbie 5 points
26 September 2017 2:36 PM

I'm also seeing this issue. Any updates?

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.