# [SOLVED] Black screen after fresh kernel compilation

## Shoaloak

Hi all,

Recently I updated my system, using

 *Quote:*   

> emerge --sync
> 
> emerge -avuDU --with-bdeps=y @world --exclude=chromium

 

Everything went well, so I continued to move to a new kernel (4.15.4)

Unfortunately, when booting I got a black screen and my laptop just froze up.

So, I moved back to my old kernel, namely 4.14.12.

However, after fiddling around with different kernels (all of which black screened), I recompiled 4.14.12 to see if the same kernel would boot.

This also gives a black screen, leaving me kinda in the dark (pun intended).

Things i tried:

do a clean, make distclean

rebuild modules, emerge --ask @module-rebuild

TL;DR; Kernel builds suddenly wont boot after updates, looking for help.

SOLUTION

Roll back to sys-kernel/linux-firmware-20170314 by masking.

```
=sys-kernel/linux-firmware-20180103-r1
```

in /etc/portage/package.mask/firmware

----------

## NeddySeagoon

Shoaloak,

Tell us how you build your kernel.

Tell us when the screen goes black and what is the last message you see?

Post your 

```
lspci
```

 output, so we can see your hardware.

Put your kernel .config onto a pastebin site and post the link.

wgetpaste makes this easy.

----------

## Jaglover

Your emerge --info may provide some clues, too.

----------

## Shoaloak

I build my kernel using Sakaki's buildkernel tool. (yeah i'm a lazy bastard)

I don't see anything after booting. After my Bios Vendor logo my screen just goes black and stays black.

I'm suspecting  nouveau or GCC that got updated...

Information:

https://www.dropbox.com/sh/ot5iojbz63lmkbj/AACnDgp9ZDP6nANVdZCVEyT7a?dl=0

----------

## NeddySeagoon

Shoaloak,

Do you use an EFI system with a EFI stub kernel so that there is no boot loader, or do you use a boot loader that fails to start?

----------

## Shoaloak

 *NeddySeagoon wrote:*   

> Shoaloak,
> 
> Do you use an EFI system with a EFI stub kernel so that there is no boot loader, or do you use a boot loader that fails to start?

 

I use an EFI system with a EFI stub kernel, no GRUB or anything.

My boot process is as follows (copied from Sakaki's guide):

The UEFI BIOS starts up, and initializes the hardware. It looks for, and finds, an executable .efi program (my stub-loadable kernel) on the USB key, so it loads this and passes off control to it.

The kernel starts up and initializes. It unpacks its bundled initramfs into memory, and activates it, which provides a root directory containing a skeleton set of system files.

The kernel then looks for a special 'init' program in the initramfs and starts it (as the first userspace process).

This initscript, which is actually provided by a Gentoo utility called genkernel, prompts the user to enter a password, unlocks the .gpg keyfile (also on the USB key), and uses the resulting binary plaintext to unlock the LUKS partition. It next activates the LVM volume group on that partition (vg1 in our case), and mounts any logical volumes (LVs) within it, as dictated by the file /etc/fstab. This mounts the swap, root and home LVs.

At this point the 'real' filing system is in place, and the initramfs (apart from /proc, /dev and /sys) is discarded, using switch_root. The init script ends by invoking systemd on this newly mounted root.

----------

## Sakaki

Shoaloak,

did you keep a 'known good' backup of one of your working kernels, as suggested in my guide here? If so, you can simply rename this on your boot USB key and boot from that. By default, buildkernel packages all the modules in the kernel initramfs, so you should be able to get a running system even if the /lib/modules on your root don't match version-wise.

Otherwise, on a failed boot, if you haven't run buildkernel again, you can fall back to the previous kernel automatically stored on the boot key (procedure here) unless you have run buildkernel again, which sounds like is the case here.

I use nouveau myself on 4.15.1-gentoo on one of my dev systems, so I doubt its the kernel itself, although it could be something in the configuration, if you have changed that. Sounds like you are able to use buildkernel on another system to create the gentoo.efi stub, so have you tried disabling the plymouth graphical boot splash, so you can at least see a textual console? Can you successfully boot e.g. a gentoo minimal install system on your laptop?

----------

## Shoaloak

 *Sakaki wrote:*   

> Shoaloak,
> 
> did you keep a 'known good' backup of one of your working kernels, as suggested in my guide here? If so, you can simply rename this on your boot USB key and boot from that. By default, buildkernel packages all the modules in the kernel initramfs, so you should be able to get a running system even if the /lib/modules on your root don't match version-wise.
> 
> Otherwise, on a failed boot, if you haven't run buildkernel again, you can fall back to the previous kernel automatically stored on the boot key (procedure here) unless you have run buildkernel again, which sounds like is the case here.
> ...

 

It appears I haven't expressed myself clearly.

I do have a known good backup of my 4.14.12 kernel, so i can still access my Gentoo system, which I use to (re)build kernels.

I have tried disabling the Plymouth graphical boot splash, build the same kernel version I have working now, with the config file taken from the USB to make sure there are no config changes.

This STILL gives me a black boot screen.   :Crying or Very sad: 

----------

## Sakaki

Shoaloak,

if you can boot your system with your archived 4.14.12 kernel and userspace, but not with a 4.14.12 kernel rebuilt using the same kernel configuration, that would suggest something is amiss with your kernel build system.

When you say 'black screen' - do you get the LUKS prompt OK, and then the screen goes black, or do you not even get that?

One other thought - are you using systemd? If so, note that buildkernel changed at version 1.0.29, to use /lib/systemd/systemd as the initsystem path, rather than /usr/lib/systemd/systemd - so if you are having an issue after the LUKS passphrase entry, it is just possible this is the cause.

Otherwise, have you recently upgraded your gcc or anything like that? If so, did you re-emerge libtool etc, as recommended here?

Does the 'blackscreening' 4.14.12 gentoo.efi differ markedly in size from your archived, working version of the same kernel?

----------

## beguiledfoil

Sorry if I'm missing the obvious - but what video driver are you using? What video hardware?

----------

## Shoaloak

 *Sakaki wrote:*   

> 
> 
> When you say 'black screen' - do you get the LUKS prompt OK, and then the screen goes black, or do you not even get that?

 

I mean a black screen, I get nothing. My fans just starts spinning mad and everything freezes.

 *Sakaki wrote:*   

> 
> 
> Otherwise, have you recently upgraded your gcc or anything like that? If so, did you re-emerge libtool etc, as recommended here?

 

GCC did get updated during that emerge, and forgot to re-emerge libtool, but unfortunately this still does not fix the problem.

 *Sakaki wrote:*   

> 
> 
> Does the 'blackscreening' 4.14.12 gentoo.efi differ markedly in size from your archived, working version of the same kernel?

 

```
# ls -lh

-rwxr-xr-x 1 root root  92M  1 mrt 23:04 not-working-gentoo.efi

-rwxr-xr-x 1 root root  69M  1 mrt 23:04 working-gentoo.efi
```

It does differ somehow. (same config)

 *Sakaki wrote:*   

> 
> 
> if you can boot your system with your archived 4.14.12 kernel and userspace, but not with a 4.14.12 kernel rebuilt using the same kernel configuration, that would suggest something is amiss with your kernel build system.

 

I guess so, but what is the question.   :Shocked: 

 *beguiledfoil wrote:*   

> 
> 
> Sorry if I'm missing the obvious - but what video driver are you using? What video hardware?

 

Nouveau and Intel modesetting. i7 and Nvidia GeForce GTX 965M

----------

## Sakaki

Shoaloak,

buildkernel, via genkernel, by default adds the contents of /lib/firmware and all kernel modules into the integral initramfs. That explains the change in size of your 4.14.12 kernels I think, as linux-firmware has grown in size recently (I've just built and booted a 4.14.12 and 4.15.4; both were around 90 MiB).

What profile are you using (apologies for the questions, this is why people ask you to post the output of "emerge --info"...)? If 17.0, did you follow the instructions to rebuild your toolchain, and then then emerge -e @world?

If you can post your kernel config, I can try building a 4.15.4 gentoo.efi from it, and post that somewhere you could download and try it.

Alternatively, try rebuilding your toolchain (gcc, binutils and glibc), possibly dropping your compiler back to 6.4.0 if still on profile 13.0, and try again.

----------

## Shoaloak

 *Sakaki wrote:*   

> buildkernel, via genkernel, by default adds the contents of /lib/firmware and all kernel modules into the integral initramfs. That explains the change in size of your 4.14.12 kernels I think, as linux-firmware has grown in size recently (I've just built and booted a 4.14.12 and 4.15.4; both were around 90 MiB).

 

Ah that explains.

I was also thinking, I'm currently running sys-firmware/intel-microcode-20171117-r1. Until recently, I (think) was running 20180108(-r1?) This version is masked, but I didn't have any problems with it.

Could this firmware downgrade perhaps be responsible for my troubles?

 *Sakaki wrote:*   

> What profile are you using (apologies for the questions, this is why people ask you to post the output of "emerge --info"...)? If 17.0, did you follow the instructions to rebuild your toolchain, and then then emerge -e @world?

 

default/linux/amd64/17.0/desktop/gnome/systemd (stable)

I already posted the emerge --info output, it's in the Dropbox URL.

No, I didn't need to since I was running hardened 13.0 profile with PIE already enabled.

I did rebuild toolchain now to make sure it wasn't effecting my build, but to no avail.

 *Sakaki wrote:*   

> If you can post your kernel config, I can try building a 4.15.4 gentoo.efi from it, and post that somewhere you could download and try it.

 

https://www.dropbox.com/s/n7zvil3cv41a6wb/config-4.14.12.txt?dl=0

 *Sakaki wrote:*   

> Alternatively, try rebuilding your toolchain (gcc, binutils and glibc), possibly dropping your compiler back to 6.4.0 if still on profile 13.0, and try again.

 

I followed steps as mentioned here. So this unfortunately doesn't work.

----------

## Sakaki

 *Shoaloak wrote:*   

> I already posted the emerge --info output, it's in the Dropbox URL.

 Apologies, I missed that ><

 *Shoaloak wrote:*   

>  *Sakaki wrote:*   If you can post your kernel config, I can try building a 4.15.4 gentoo.efi from it, and post that somewhere you could download and try it. 
> 
> https://www.dropbox.com/s/n7zvil3cv41a6wb/config-4.14.12.txt?dl=0

 I've built the 4.15.4 based on your config now: you can download the gentoo.efi and config from: https://github.com/sakaki-/resources/releases/tag/1.0.0

Obviously you'll need to turn secure boot off to try it, as it is signed with my private key.

----------

## Shoaloak

 *Sakaki wrote:*   

> I've built the 4.15.4 based on your config now: you can download the gentoo.efi and config from: https://github.com/sakaki-/resources/releases/tag/1.0.0
> 
> Obviously you'll need to turn secure boot off to try it, as it is signed with my private key.

 

Tried it, it doesn't work unfortunately.

Spend the entire night trying out things, such as comparing config's and kernel command line arguments to make sure everything is the same as when I build the working 4.14.12.

But (any?) new build doesn't appear to be working.

The only thing i still haven't tried is reverting to my old (the newer/buggy) intel-microcode from 2018.

Or reverting my GCC version, but that seems a bit overkill...

Please, does anybody have ideas, tips, or tricks? I'm starting to get a bit desperate over here.   :Crying or Very sad: 

----------

## Sakaki

Shoaloak,

I can get the 4.15.4 gentoo.efi I posted to boot (to the LUKS prompt, anyhow) on my nVidia-based desktop machine, if I trick up the partition UUIDs appropriately.

Thinking about this, given that you have a working 4.14.12 and a non-working 4.14.12, the only remaining issue I can see is the version of linux-firmware in the integral initramfs (either that or your toolchain has got really messed up somehow).

Have you tried rolling back to e.g. sys-kernel/linux-firmware-20170314, and running buildkernel again (on 4.14.12, with everything else held the same (.config etc.))?

----------

## Shoaloak

 *Sakaki wrote:*   

> Shoaloak,
> 
> Thinking about this, given that you have a working 4.14.12 and a non-working 4.14.12, the only remaining issue I can see is the version of linux-firmware in the integral initramfs (either that or your toolchain has got really messed up somehow).
> 
> Have you tried rolling back to e.g. sys-kernel/linux-firmware-20170314, and running buildkernel again (on 4.14.12, with everything else held the same (.config etc.))?

 

You are right, the firmware is at fault. After rolling back to 20170314 my fresh kernels boot again!

Thank you!

----------

