“Recovery mode” is akin to Windows’s “Safe Mode,” (though exactly what it does depends on the distro). It will attempt to boot the OS with most non-essential features disabled (potentially including networking, graphics, and multi-user mode). It doesn’t do anything to automatically diagnose or repair problems. It’s more of a Hail Mary to get a (one) working terminal so you can diagnose and repair the problem yourself without needing to fetch another computer to flash a bootable USB.

Many distros also keep the previous 1-3 kernel versions around to try if the most recent one doesn’t boot. These options will usually be labeled “fallback” and have a lower version number. These options should boot normally (with full functionality), assuming there are no other problems, but the oldest one will be removed each time a new one is installed, so this is not a permanent solution either.

I’m not exactly sure what the root cause is here, but like others mentioned, non-specific random problems like this often indicate a hardware issue. Random delays in completely unrelated software like this can be triggered by disk IO blocking, which could be a hardware thing or (disk) memory exhaustion. Could also be filesystem corruption, though this is exceedingly rare with “modern” (of this millennium) journaling filesystems. Or it could be (RAM) memory exhaustion if you are using a swap partition - when there is not enough RAM, lower priority processes begin having their memory shuffled back and forth between RAM and the disk. This will effectively grind your system to a standstill as long as its ongoing, even with fast disks. If you don’t have swap enabled, the system will instead just kill arbitrary processes, which is bad, but at least it isn’t slow :)

VFS: Unable to mount root fs typically indicates a problem with the initramfs. There are a million different ways to configure the kernel, but what most modern distros do is ship a highly modular kernel. Instead of building thousands of drivers into a single kernel binary, they are stored on the disk as thousands of separate modules which can be loaded if / when needed. This creates a chicken-and-egg problem though. Like if you need the NVMe driver to read an NVMe disk, but the NVMe driver is stored on the NVMe. To work around this, an extra (normally invisible) boot-strapping step takes place. An initramfs image is created after installing a kernel containing a minimal bootable filesystem which includes the drivers and utilities which are essential to boot your system, and the bootloader loads it into memory along with the kernel. The kernel mounts the initramfs as root, begins to boot, and the early-init system will do what it needs to mount your real root filesystem and transfer control to your real PID 1 init process. If the initramfs image corresponding to the specific kernel you’re booting is missing (or damaged) from your boot directory, this will not function correctly. A lot of times problems can occur from an undersized ESP or boot partition filling up with old kernels. This should not impact performance at all if the system is booting normally, though, so it doesn’t answer original question.

You can probably select the recovery mode next boot too, and hope that some future update does the the necessary things that ends up fixing it. But besides that, I don’t think so.

ⓘ This user is suspected of being a cat. Please report any suspicious behavior.