# Can't boot with newer than 4.1.15-r1 and nvidia drivers

## lue

This problem has been bugging me for a long time, and it sucks because I'd like to not be stuck on a progressively older kernel. Basically, I can't seem to boot on newer kernels, and the problem seems to be related to nvidia.

I don't have any logs from the failed boots (and I don't have any kind of ssh setup for this computer, which I read elsewhere could maybe help in these situations), so I can only provide an approximation of the console output as I remember it, using a portion of a good boot for the text:

```

[    0.684988] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A

[    0.686227] Non-volatile memory driver v1.3

[    0.686527] Linux agpgart interface v0.103

                                                                                      [    0.760210] uvesa

fb: NVIDIA Corporation, BIOS-P/N@N10590, Chip Rev   , OEM: NVIDIA, VBE v3.0           [    0.824561] uvesa

fb: VBIOS/hardware supports DDC2 transfers                                            [    0.868026] uvesa

fb: monitor limits: vf = 76 Hz, hf = 93 kHz, clk = 160 MHz                            [    0.868638] uvesa

fb: scrolling: redraw

```

That is, the lines of output suddenly go to the right hand side of the screen, and list a bunch of lines that visually start with "fb:" (judging from good boot logs I'm assuming these lines really start with uvesafb:) and mention nVidia, hence my thoughts that it's related to those drivers. I also recall the weird printing behavior after the agpgart line, as shown.

Some additional info presented as bullet points:

 Running a ~amd64 system.

 Have an AMD dual-core Athlon CPU.

 Using gentoo-sources in all cases

 Good kernel: 4.1.15-r1

 Proven "bad" kernels: 4.4.6, 4.6.0, 4.6.2

 Using proprietary nvidia drivers, since they offer much better 3D support than nouveau last I tried.

 Card is nVidia GeForce GT 610

 Using uvesafb for decent TTYs when needed.

 Initramfs made with genkernel-next for uvesafb, though I'm not convinced it's actually necessary for me.

 Currently on systemd, though this also happened when on OpenRC.

 Once in a blue moon, this won't happen and I'll get a bit farther in booting, furthest ever being the computer locking up while logging into Plasma.

 Latest "blue moon" behavior:

 Systemd waits for wireless card to start (most likely unrelated, I did switch from module to yes for the wireless card, since I never wanted to keep it a module in the first place).

 Segfault in Qt5 stuff upon trying to start up sddm.

 I do recall modifying an ebuild a while back related to kernel stuff to get it to pull a more recent kernel, so it'd work with gcc 5. Unfortunately I don't remember what package needed this modification (some kind of halfway for things that needed more than linux-headers but couldn't rely on the presence of a user-compiled kernel, I think?)

I more thing that might be related is that, for a long time now, even on good kernels, I've been unable to switch back-and-forth between TTYs and X11. That is, I can switch to a TTY, but if I try switching back to X11 again, the computer will lock up.

I'll be happy to provide any information that's needed, especially I imagine the .config files for the good kernel and the last bad kernel I tried (4.6.2). I just want to know why it's all busted past 4.1.15-r1.

----------

## Jaglover

Get rid of framebuffers in kernel, new nvidia has its own KMS.

----------

## lue

Really? If that's the case, then I wonder why the earlier kernel is able to work with the same nvidia drivers. Also, I believe I disabled uvesafb before, but I think that was only modifying the boot options to the kernel, and not actually leaving it out of compilation. I'll give it a try regardless.

If not even uvesafb should be installed anymore, then I'd like to point out that https://wiki.gentoo.org/wiki/NVidia/nvidia-drivers definitely needs to be updated (since after telling you to disable the in-kernel framebuffer, it explicitly mentions uvesafb can be used alongside nvidia-drivers).

EDIT: It seems nvidia doesn't provide a high-resolution framebuffer for TTYs, so I'm afraid disabling uvesafb is not an option for me (since I do, on occasion, need to just work from the console without any GUI stuff getting in the way). Are you sure this is the only choice to make nvidia work with newer kernels?   :Sad: 

----------

## lue

Well, totally disabling DRM in the kernel seems to have done it (remains to be seen if this is just a really lucky boot-up or not). In any case, if I can't have a high-resolution framebuffer anymore, which seems to be the case, I might as well switch to nouveau. Worst case I'll have to contribute to improving it   :Very Happy:  .

----------

## The Doctor

This may not be a viable solution for you, but if you really just want to be able to drop to a shell without GUI elements in the way you might want to consider using i3 as a window manager in those cases with something like rxvt-unicode for a terminal. i3 adds no window decorations or borders so it is about as simple as you can get.

When you start a terminal i3 will expand it to fill the entire screen, assuming no other applications running, and rxvt-unicode is very easily configured to have nothing except a command prompt.

----------

## lue

That's definitely an interesting solution. Since me going into console mode is pretty much only when I want or need to leave as much CPU/RAM free for e.g. system updates, it's nice to do it in a way that doesn't eat up too much of that. From the looks of it i3 wouldn't be too demanding in that respect.

In any case, it does seem like it was a lucky fluke when I was able to boot into the latest kernel, so I'm really lost now. I've decided to go about installing nouveau, and if that doesn't let me use new kernels consistently, then it's really a puzzle. I can always try to keep the old kernel around for cases where I need the proprietary driver, or as mentioned "just" contribute to nouveau to fix it.

----------

