Black screen after GRUB menu

[MoonBlossom]

ls -al /lib/modules

total 24
drwxr-xr-x  6 root root 4096 Oct 24 02:08 .
drwxr-xr-x 27 root root 4096 Oct 26 22:46 ..
drwxr-xr-x  4 root root 4096 Oct 24 02:08 3.13.0-24-generic
drwxr-xr-x  6 root root 4096 Oct 24 02:08 3.13.0-37-generic
drwxr-xr-x  6 root root 4096 Oct 26 22:47 3.16.0-23-generic
drwxr-xr-x  3 root root 4096 Jun  7 03:48 3.8.0-31-generic

ls -al /lib/modules/*/build

lrwxrwxrwx 1 root root 40 Oct 21 11:47 /lib/modules/3.16.0-23-generic/build -> /usr/src/linux-headers-3.16.0-23-generic

ls -al /usr/src

total 56
drwxr-xr-x 14 root root 4096 Oct 26 22:46 .
drwxr-xr-x 12 root root 4096 Oct 23 14:54 ..
drwxr-xr-x 24 root root 4096 Jun  7 00:18 linux-headers-3.13.0-24
drwxr-xr-x 24 root root 4096 Jun  7 00:16 linux-headers-3.13.0-29
drwxr-xr-x 24 root root 4096 Jul  9 14:23 linux-headers-3.13.0-30
drwxr-xr-x 24 root root 4096 Aug 13 14:02 linux-headers-3.13.0-33
drwxr-xr-x 24 root root 4096 Aug 17 15:36 linux-headers-3.13.0-34
drwxr-xr-x 24 root root 4096 Aug 31 02:54 linux-headers-3.13.0-35
drwxr-xr-x 24 root root 4096 Sep 23 07:29 linux-headers-3.13.0-36
drwxr-xr-x 24 root root 4096 Oct  8 16:23 linux-headers-3.13.0-37
drwxr-xr-x 24 root root 4096 Oct 23 14:29 linux-headers-3.16.0-23
drwxr-xr-x  7 root root 4096 Oct 23 14:29 linux-headers-3.16.0-23-generic
drwxr-xr-x  3 root root 4096 Oct 26 22:46 nvidia-331-updates-331.89
drwxr-xr-x  3 root root 4096 Oct 26 22:46 nvidia-331-updates-uvm-331.89
lrwxrwxrwx  1 root root   32 Oct 10 12:11 vboxhost-4.3.18 -> ../share/virtualbox/src/vboxhost

[SteveRiley]

You're missing the package linux-headers-3.13-0-37-generic...that's why DKMS is failing to build for that kernel. And at this point I'm not sure it's worth the not insignificant hassle of trying to get it.

My usual approach to take when we reach this stage -- where the included NVIDIA drivers won't work -- is to use an alternate set of drivers from a PPA. Let's resume this tomorrow, OK? I'd also like to work you through a couple clean-up steps... you have a fair number of old packages on your system, and also some left-over package configuration files.

[SteveRiley]

Hold on... are you familiar with editing kernel modules in GRUB's configuration? I have an idea...

[MoonBlossom]

I have kde-config-grub2 on my system settings. I can modify Grub options this way.

[MoonBlossom]

If you are tired tomorrow is fine Thank you so much for helping me out

[SteveRiley]

Alright. I don't use GRUB, and I'm not familiar with how that KDE control module works. The objective is add the boot parameter nox2apic to the kernel. Is editing the kernel boot line something you can do with this utility? If so, please make the requested change. Then in the firmware re-enable the NVIDIA graphics. Now boot to the 3.16 (Utopic) kernel. Does it work?

On my ThinkPad T520 with NVIDIA graphics, nox2apic is required, otherwise it won't boot. This has been necessary for several releases now.

[MoonBlossom]

I added nox2apic and I enabled the Nvidia drivers. I still got a black screen

[MoonBlossom]

I noticed that going into recovery mode on the 3.16 kernel and selecting resume boot does work! but if I allowed the system to boot normal it doesn't

[SteveRiley]

Rats. I'm out of ideas for now. Need to think for a bit. Sorry for taking so much time.

[MoonBlossom]

No need. Thank you so much for your help!!!

[andrewsimpson]

So, from what I understand you get a Grub screen, then a blank screen (no Plymouth) during boot, then the normal KDM login screen. After that KDE as normal. Well, I've just had that and fixed it.

Googling around suggested that the kernel parameter 'vt_handoff' in the Grub command line could be problematic. At the Grub screen, I chose 'e' for temporary edit and the removed the variable $vt_handoff (Yes, it's a variable). Saved and booted from Grub. Voila! Nice normal graphical boot!

O.K., the problem is $vt_handoff. Turns out that this is a kernel parameter added by Ubuntu that is meant to ensure a smoother, more flicker free transition to Plymouth, but it can be a bit unreliable. The code in /boot/grub/grub.cfg sets the variable $vt_handoff to either 'vt_handoff=7' or '' (null), at boot depending on the boot state.

I wanted $vt_handoff = '' (null), because this worked for me, but grub.cfg states 'DO NOT EDIT THIS FILE'. After a while I found the rules in /etc/grub.d which create the grub.cfg file...

/etc/grub.d/*10linux

prefix="/usr"
exec_prefix="/usr"
datarootdir="/usr/share"
ubuntu_recovery="1"
quiet_boot="1"
quick_boot="1"
gfxpayload_dynamic="1"
vt_handoff="1"

...

if [ "$vt_handoff" = 1 ]; then
  for word in $GRUB_CMDLINE_LINUX_DEFAULT; do
    if [ "$word" = splash ]; then
      GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT \$vt_handoff"
    fi
  done
fi

Changing this line...

vt_handoff="1"

to this...

vt_handoff="0"

gets rid of $vt_handoff. Now just need to reconfigure...

sudo update-grub
sudo update-initramfs -u

Worked for me.

[jlittle]

Modifying /etc/grub.d/10_linux is problematic in that it is a file distributed with grub, and either an update will overwrite your change, or you'll not get a new version.

For $vt_handoff problems, also known as gfxmode=keep problems, /boot/grub/gfxblacklist.txt suggests adding
GRUB_GFXPAYLOAD_LINUX=text to /etc/default/grub (and running sudo update-grub of course). That will cause $vt_handoff to be blank. Just tried it, and the resulting grub.cfg does indeed make $vt_handoff blank, but I don't know what other effects it might have.

Another way is to remove "splash" from the setting of GRUB_CMDLINE_LINUX_DEFAULT; some of us here like seeing all the boot messages, but maybe you find it ugly, or off-putting for ordinary users.

[andrewsimpson]

Modifying /etc/grub.d/10_linux is problematic in that it is a file distributed with grub, and either an update will overwrite your change, or you'll not get a new version.

Agreed, that is the downside of fiddling.

For $vt_handoff problems, also known as gfxmode=keep problems, /boot/grub/gfxblacklist.txt suggests adding GRUB_GFXPAYLOAD_LINUX=text to /etc/default/grub (and running sudo update-grub of course).

Hmmm... yes, but I think that will give a text boot, instead of a graphical boot?

Really though, I made this reply because I was so surprised to see another Kiwi, and another Jaffa to boot!

[jlittle]

...suggest adding GRUB_GFXPAYLOAD_LINUX=text to /etc/default/grub...

Hmmm... yes, but I think that will give a text boot, instead of a graphical boot?

I'm not sure... my reading of the grub.cfg produced is that it only affects the vt_handoff thing. I tried it but my old hardware needs nomodeset so the splash is not very graphical anyway. I suggest you try it. Myself, I got fed up with different installs fighting over grub and use a separate boot partition just for grub and hand edit my own grub.cfg there. It doesn't matter if it gets years out of date as long as it can boot at least one install.

Really though, I made this reply because I was so surprised to see another Kiwi, and another Jaffa to boot!

Rod J is active here, and the member search lists a few more... though I imagine not many people bother to update their profile much. This is a very helpful, friendly, and tolerant forum; some other Linux forums can seem snooty and formal and intolerant of newbieness in comparison. There are members that don't run Kubuntu any more but stay for the community.

[MoonBlossom]

I tried all those solutions and I'm still not able to boot on the new kernels (got 2 kernel updates since starting this post). I even tried to boot from the live Kubuntu and Ubuntu Utopic discs and got the same result. Maybe it is a problem with my video card having both Nvidia and Intel chips I don't know what else to do at this point other than keep using the old kernel