| View previous topic :: View next topic |
| Author |
Message |
Shoaloak
n00b
Joined: 05 Nov 2016
Posts: 48
|
 Posted: Mon Feb 26, 2018 8:33 pm Post subject: [SOLVED] Black screen after fresh kernel compilation |
 |
|
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.
| Code: | | =sys-kernel/linux-firmware-20180103-r1 |
in /etc/portage/package.mask/firmware
_________________
Happy hacking.
Last edited by Shoaloak on Fri Mar 09, 2018 11:01 am; edited 1 time in total |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54216
Location: 56N 3W
|
| Posted: Mon Feb 26, 2018 8:53 pm Post subject: |
|
|
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 output, so we can see your hardware.
Put your kernel .config onto a pastebin site and post the link.
wgetpaste makes this easy.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Jaglover
Watchman
Joined: 29 May 2005
Posts: 8291
Location: Saint Amant, Acadiana
|
|
| Back to top |
|
|
Shoaloak
n00b
Joined: 05 Nov 2016
Posts: 48
|
| Posted: Mon Feb 26, 2018 9:31 pm Post subject: |
|
|
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
_________________
Happy hacking. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54216
Location: 56N 3W
|
| Posted: Mon Feb 26, 2018 9:45 pm Post subject: |
|
|
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?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Shoaloak
n00b
Joined: 05 Nov 2016
Posts: 48
|
| Posted: Mon Feb 26, 2018 9:48 pm Post subject: |
|
|
| 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.
_________________
Happy hacking. |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Tue Feb 27, 2018 11:09 am Post subject: |
|
|
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?
_________________
Regards,
sakaki |
|
| Back to top |
|
|
Shoaloak
n00b
Joined: 05 Nov 2016
Posts: 48
|
| Posted: Wed Feb 28, 2018 11:59 am Post subject: |
|
|
| 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.
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? |
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. 
_________________
Happy hacking. |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Wed Feb 28, 2018 1:43 pm Post subject: |
|
|
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?
_________________
Regards,
sakaki |
|
| Back to top |
|
|
beguiledfoil
n00b
Joined: 23 Jan 2011
Posts: 48
|
| Posted: Thu Mar 01, 2018 5:28 am Post subject: |
|
|
| Sorry if I'm missing the obvious - but what video driver are you using? What video hardware? |
|
| Back to top |
|
|
Shoaloak
n00b
Joined: 05 Nov 2016
Posts: 48
|
| Posted: Thu Mar 01, 2018 10:13 pm Post subject: |
|
|
| 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? |
| Code: | # 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. 
| 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
_________________
Happy hacking. |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Sat Mar 03, 2018 8:47 pm Post subject: |
|
|
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.
_________________
Regards,
sakaki |
|
| Back to top |
|
|
Shoaloak
n00b
Joined: 05 Nov 2016
Posts: 48
|
| Posted: Tue Mar 06, 2018 6:34 pm Post subject: |
|
|
| 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.
_________________
Happy hacking. |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Wed Mar 07, 2018 4:14 pm Post subject: |
|
|
| Shoaloak wrote: | | I already posted the emerge --info output, it's in the Dropbox URL. |
Apologies, I missed that ><
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.
_________________
Regards,
sakaki |
|
| Back to top |
|
|
Shoaloak
n00b
Joined: 05 Nov 2016
Posts: 48
|
| Posted: Thu Mar 08, 2018 11:12 pm Post subject: |
|
|
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.
_________________
Happy hacking. |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Fri Mar 09, 2018 1:51 am Post subject: |
|
|
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.))?
_________________
Regards,
sakaki |
|
| Back to top |
|
|
Shoaloak
n00b
Joined: 05 Nov 2016
Posts: 48
|
| Posted: Fri Mar 09, 2018 10:54 am Post subject: |
|
|
| 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!
_________________
Happy hacking. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
