Manually booting a Linux Kernel

After updating a server, rebooting it to load the new Kernel, removing the old Kernel and rebooting again, I got the GRUB minimal BASH-like prompt (I still can’t understand why, honestly), as if GRUB wasn’t able to see any info on how it should load the Kernel and the OS.

I know I could be very distracted but deleting all the Kernels seemed a little too much so I tried to manually boot the Kernel.

First, I checked what GRUB could see:

grub> ls
(hd0) (hd0,msdos1) (hd0,msdos2)

Listed the content of the disks to see what files were present and determine which one was the root filesystem:

grub> ls (hd0,1)/
lost+found/ vmlinuz-5.10.21-200... initramfs-5.10.21-200....img vmlinuz-0-rescue... initramfs-0-rescue....img

Set it as boot volume:

grub> root=(hd0,msdos1)

Loaded the Kernel image and RAM disk:

grub> linux /vmlinuz-5.10.21-200... root=/dev/sda1
grub> initrd initramfs-5.10.21-200....img

And finally booted the system:

grub> boot

Just in case, I also created a new GRUB config based on the currently running system:

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

SMB/CIFS connection timeout kernel-3.10.0-957.21.3.el7

After upgrading to kernel-3.10.0-957.21.3.el7 on a CentOS server, I experienced connection timeout issues on Windows servers trying to access SMB shares. On the contrary, I was able to access the share using a Linux system without any problem.

The bug was reported in CentOS Bug Tracker and it’s caused by one of the patches applied to address CVE-2019-11478.

Some applications set tiny SO_SNDBUF values and expect TCP to just work.
Recent patches to address CVE-2019-11478 broke them in case of losses, since re-transmits might be prevented.

To (temporarily) fix this issue, I increased SO_SNDBUF value in /etc/samba/smb.conf:

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=65536 SO_SNDBUF=65536