Boot process stuck at 'Loading initial ramdisk'

Question

I've installed Elementary OS 0.4.1 Loki (64 bit) on a Lenovo with Intel Corporation Sky Lake Integrated Graphics. The install process went fine and it generally works great with kernel Linux 4.13.0-32-generic. With any newer kernel there's a graphics issue that causes the screen to simply be black, not allowing the decryption password prompt to ever appear (graphically). That, however, is not my problem - since, as I said, kernel 32 generally works well. But there is something that has happened twice now. The first time it happened I wasn't able to find a solution and ended up reinstalling the OS. But I would really, really prefer not to do that again. So any help would be appreciated.

For some reason, which I've haven't determined yet, the system will very randomly freeze, and when I perform a hard reset (holding down the power button), once it boots again it simply shows the glowing elementary logo. I've gone into grub and edited the boot parameters to remove quiet splash and add nomodeset but the only thing that gets printed isLoading Linux 4.13.0-32-generic and Loading initial ramdisk, at which point it hangs. I've even also added debug and ignore_loglevel to the boot parameters but no other information gets printed to the screen during boot. Further, it doesn't seem like it's just a specific kernel issue because even when I attempt to boot with the other kernels I have installed it hangs at the same place.

I've also tried to use boot-repair but the problem persists. For brevity, here's the log created by it:

https://pastebin.com/raw/3wW2YTv0

I've looked through the logs of my system and they don't reveal much.. but it does seem that this was logged just before the system froze the last time:

[drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A

Also, it seems like this isn't simply an issue with the kernel, as when I try to select different kernels that are installed via the grub menu they all get stuck at the same point noted above.

Further, I've made timeshift backups and restoring to such backups achieves nothing. The boot still hangs at the same point.

Note that I can successfully boot into recovery mode, which is how I'm writing this message now. But of course, I would prefer to be able to boot and for the system to operate normally.

Has anyone encountered this as well (& solved it)? Thanks!

Answer 1

In case anyone faces this same issue, try removing the variable $vt_handoff from the boot command of whichever kernel your trying to boot in /boot/grub/grub.cfg (or alternatively remove all instances). This can be done via the following script (taken from https://www.thefanclub.co.za/how-to/how-fix-ubuntu-boot-splash-screen-after-grub-updates):

#! /bin/bash
# Fix Ubuntu Plymouth Boot Splash 
# if entry exists for $vt_handoff use sed to search and replace
# write to tmp file - move to original 

checkVT=$(grep -c "\$vt_handoff" /boot/grub/grub.cfg)

if [ ! "$checkVT" -eq "0" ] 
   then
     echo "> Found vt_handoff removing ..."
     sudo sed 's/$vt_handoff//g' /boot/grub/grub.cfg > /tmp/.grub.cfg
     sudo mv /boot/grub/grub.cfg /boot/grub/grub.cfg.backup
     sudo mv /tmp/.grub.cfg /boot/grub/grub.cfg
   fi

echo "> Done"

What happened in my case was that I would install a fresh instance of Elementary and everything would be fine. Then a kernel update would come along and I would install that, which would then in turn run update-grub. Part of the outcome of running this command adds the $vt_handoff variable to every kernel boot command in /boot/grub/grub.cfg, which explains why I was seeing the same behavior no matter which kernel I attempted to boot. Then, since I don't typically restart my computer often, I wouldn't notice any issues until I was forced to restart it (due to it freezing because of a completely unrelated issue), resulting in the boot hanging at the splash screen.

Ironically, $vt_handoff is meant to provide a better, smoother boot experience, that displays a fancier screen other than just simply a black one. Unfortunately in many cases it simply just causes the boot process to hang.