When I run this command: # "grub2-mkconfig -o /boot/grub2/grub.cfg" i can no longer ssh to Linux after reboot. My system is Bios based.


I followed these commands:


# grub2-mkconfig -o /boot/grub2/grub.cfg

Note: This command will overwrite the existing "initramfs" file.

# dracut -f

Modify the kernel command line of the current kernel in the "grub.cfg" file by adding the following option to the GRUB_CMDLINE_LINUX key in the "/etc/default/grub" file and then rebuild the "grub.cfg" file:

fips=1

Changes to "/etc/default/grub" require rebuilding the "grub.cfg" file as follows:

On BIOS-based machines, use the following command:

# grub2-mkconfig -o /boot/grub2/grub.cfg

I STOPPED HERE TO REBOOT, BECAUSE I WANTED TO FIND OUT WHAT COMMAND WAS CAUSING MY CONNECTION DISCONNECT. BEFORE I WOULD CONTINUE WITH THE REST OF THE COMMANDS BELOW, RESTART, SAME THING. THE COMMAND THAT WOULD CAUSE THE ISSUE IS THIS: # grub2-mkconfig -o /boot/grub2/grub.cfg

If /boot or /boot/efi reside on separate partitions, the kernel parameter boot=<partition of /boot or /boot/efi> must be added to the kernel command line. You can identify a partition by running the df /boot or df /boot/efi command:

# df /boot
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 495844 53780 416464 12% /boot

To ensure the "boot=" configuration option will work even if device naming changes occur between boots, identify the universally unique identifier (UUID) of the partition with the following command:

# blkid /dev/sda1
/dev/sda1: UUID="05c000f1-a213-759e-c7a2-f11b7424c797" TYPE="ext4"

For the example above, append the following string to the kernel command line:

boot=UUID=05c000f1-a213-759e-c7a2-f11b7424c797

Reboot the system for the changes to take effect.

It's a pity the other (duplicate) thread got locked rather than this one - more info there.

Shouldn't you be asking this of your paid Redhat support ?.
Knowing naught of FIPS, I wouldn't think grub itself is the problem, apart from the fact it passed the FIPS parm to the kernel as you told it to. I would suspect the connecting machine isn't using a FIPS compliant ssh client. Putty implies Windows (to me), so maybe you need to enable FIPS system-wide.

All guess-work on my part.

Can you access the system via a console? Do you have network connectivity to the system? What error message if any do you get when trying to ssh into it?

Have you tried alternative booting? E.g. interrupt the boot process, go to the Grub command line and issue rudimentary linux16 and initrd16 commands. Or boot into rescue mode. Or edit the Grub menuentry.

Like svg00, I don't know how FIPS messes with your system, and I doubt Grub is at fault here. Either the firewall closed port 22, or the network is broken, or something disabled or broke the ssh daemon.

I do not have physical access to the system, only remote. After reboot i no longer have network connectivity. Error message: No Network connectivity.Tell you what you try inputing all the commands up to # grub2-mkconfig -o /boot/grub2/grub.cfg then reboot your system, see what happens?

I do wonder how you plan to repair a system that you can't access? If you can't access the server, suggestions for troubleshooting are not very useful.

You need to find a way to get to this server. No remote console facility? All modern servers have that, iLO, Drac etc.