Jump to content
Forums in Read-Only Mode - Please use Reddit ×
  • 0

Unknown Issue effects FB, prevents non-efi boot entirely


milktoast

Question

Sorry for venting. Thanks for the responses to the "Kernel Advice" thread, which should be considered "solved" for good general advice.

'wising up :0], and getting specific:

I have only been able to boot with either one of the two efi framebuffer configurations (that I know of) enabled. Either EFI Framebuffer outright, or the Simple Framebuffer with Mark VGA/VBE/EFI FB as generic... everything works: mouse, keyboard, internet, wacom, webcam seems detected... It's only after an aparently squeeky clean install of xorg-server, pulling in a masked to appropriate version nvidia-drivers, that the screen goes black at "starting udev"

The terminal functions in the blackness. I'm also very experienced in chrooting in and doing/undoing things. Though I'm taking it slow and easy this time; 'trying to hit the target.

UVESAFB is configured to the best of my knowledge, however it fails to load as I have specified in my kernel commandline options, and "falls back" to simple framebuffer (maybe UVESAFB and NVIDIA-DRIVERS are encountering the same problem? ...further My assumption is the efi does not require efi fbs if it's booting in "legacy mode" assuming I have it. I have setup an install with an efi-grub loader pointing at a "normal" kernel and install; and that did not work (thought it may be that I haven't got those installation methods down).

The kernel would seem to be ...real nice... besides haha. If that even means anything. It's so cerebral (I think maybe I could boot "normally" or maybe it's fundamental failure corrected by efistub options somehow).

I'm now paying closer attention to the dmesg, finding no xorg.0.log (because xorg doesn't run on boot! suprise to me... thinking it was the xorg-server install that triggered the issue... nor is XDM or XFS in the default runlevel anyway... does UDEV trigger X somehow?)

So here is my dmesg, if you care to join me :0]

http://pastebin.com/f5a3yYRf

Link to comment
Share on other sites

5 answers to this question

Recommended Posts

  • 0

This is the Xorg.0.log after the xorg.conf guidance is added:

 

http://pastebin.com/TjXezKUt

 

And the dmesg after the same, just for the hell of it:

 

http://pastebin.com/LwtKRehh

 

It goes black on udev, after install, and during a startx .. Like the hardware framebuffer only wants to cooperate with a very few efi friends. I still have no idea what udev has to do with it.

Link to comment
Share on other sites

  • 0

I second shaman's probe from the other thread: Have you tried building/booting the debian-sources kernel?


 


I've yet to have that kernel fail to boot any of the dozens of boxes (and servers!) I've installed Funtoo (all variety of makes, CPUs and video configurations).


 


Imho, I suggest wasting no more time in menuconfig-land and build/boot the debian-sources kernel and use that as a platform to continue exploring, experimenting and optimizing your hardware.


Link to comment
Share on other sites

  • 0

Np. The debian-sources is a good 'safety' kernel for just getting the box booted and exploring the hardware, imho. Within a few weeks, I usually end up with a lean, non-intramfs vanilla-, git- or ck- sources kernel and keep the debian kernel around for emergency fall back while I'm testing. But once I get a string of reliable lean kernels and a good .config for that particular hardware I go with those and just keep the debian kernel around for just a few weeks longer, then eventually remove it.

 

Still, I'm glad Daniel and the team include it as the suggested 'starter' kernel in the Install doc - I use to always configure vanilla on a new box, but occasionally I'd miss something in menuconfig and it would take a few reboots/chroot cycles to fix, but now I don't even bother - I go right to debian-sources and get the box booted first-shot.

Link to comment
Share on other sites

×
×
  • Create New...