Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
udev causes black screen on boot after xorg-server install
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
milktoast84
n00b
n00b


Joined: 03 Oct 2014
Posts: 17

PostPosted: Sat Oct 04, 2014 7:02 pm    Post subject: udev causes black screen on boot after xorg-server install Reply with quote

I am trying to finish off an install with a custom kernel using uefi stub boot (no Grub).

Everything seems okay except startx causes the screen to go black after the official nvidia install script has run; And when this is replaced with the gentoo official ebuild (the other method having been uninstalled), the same problem occurs during boot up (goes black).

An interactive boot reveals that it happens when udev starts. I was expecting some sort of xorg-server service to come up. Does udev start xorg-server?

I hope there is still a possibility that it is just a simple matter of a configuration file; Though people seem to immediately start talking about the kernel in other contexts when they run into udev problems. I remember leaving some kind of simple frame buffer enabled.

Here is my kernel configuration file just in case:

http://pastebin.com/45cYS69w

I'm using a 2010 macbook air with a Geforce320m
I've messed with the .xinitrc as well, adding "xterm" and "dwm" on thier own line--after emerging both--to what is a new blank file besides.

The terminal continues to run, and I can login and enter commands while blind, most notably "reboot".

I played with the xorg.conf file as well, when this was only a startx problem. I gave the device entry an identifier of "nvidia"(same as the driver name) and put the same in the appropriate spot in the Screen entry. I don't know if that identifier should come from or has meaning outside of xorg.conf. I tried adding a preferred mode value with the native resolution of the device, but then commented it out when it had no effect. I have no idea what the refresh rate is, or how to find it/customize the Monitor entry. I also commented out various module values in the module entry, then commented them back in, while troubleshooting.

Everything should now be as it would be automated to be besides the device identifier, and possibly unreverted edits that nvidia-config applied. I also deleted the xf86config assuming only xorg.conf was needed (a remnant of the nvidia script?)

Any help would be much appreciated :]
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 42587
Location: 56N 3W

PostPosted: Sat Oct 04, 2014 7:21 pm    Post subject: Reply with quote

milktoast84,

Please post your /var/log/Xorg.0.log file. It will tell what Xorg actually did when it started.

What did you expect instead of a black screen?
You need to give Korg sonething to do when it starts, or it will wait forever for commands that never arrive.

For testing, run
Code:
emerge -1 tmw xterm xclock
Thats what the Xorg startup scripts try to run when you have not installed/configured anything else.
Its a good test. The -1 prevents the packages being added to your world file.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
milktoast84
n00b
n00b


Joined: 03 Oct 2014
Posts: 17

PostPosted: Sat Oct 04, 2014 7:54 pm    Post subject: Re: udev causes black screen on boot after xorg-server insta Reply with quote

milktoast84 wrote:

...
I've messed with the .xinitrc as well, adding "xterm" and "dwm" on thier own line--after emerging both--to what is a new blank file besides.
...


So during that trial I was expecting xterm and dynamic window manager to run. I deleted that .xinitrc after that failed to solve the problem, and also because I believed I had encountered other files that would handle a session after comparing notes with the xsession and xstart man pages. Does the merge of xterm and a window manager handle that? Also is a Display Manager *required?

Also what is running when I use the terminal with a blank screen, xterm?

Here is my Xorg.0.log, though I do recollect consulting this file before, finding nothing (assuming that meant their were no x errors during that attempt), but I may have just misspelled the file while opening (several times):

http://pastebin.com/NTnz06xx
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 42587
Location: 56N 3W

PostPosted: Sat Oct 04, 2014 8:19 pm    Post subject: Reply with quote

milktoast84,

A Display Manager is not required. It provides a GUI login. If you don't use a display manager, you need to to use a command like startx to get into your GUI.
To use startx, you need to populate ~/.xinitrc if you want anything other than twm.

Pastebin tells me that your paste has been removed
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
milktoast84
n00b
n00b


Joined: 03 Oct 2014
Posts: 17

PostPosted: Sat Oct 04, 2014 9:38 pm    Post subject: Reply with quote

Coupled with the magically dissapearing pastebin post, this is a little like talking with Director Kersch on X-files. But I do assume you've acknowledged the more pressing and mysterious questions as well (Thank you, by the way :) ) Like what is really going on when I boot up into darkness and successfully interact with terminal. Here's another go at the paste in. I'm using my tablet (with blasted autocorrect) I'll check the link after posting:

http://pastebin.com/8j7USa95
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 42587
Location: 56N 3W

PostPosted: Sat Oct 04, 2014 10:10 pm    Post subject: Reply with quote

milktoast84,

Booting into a black console means you have black text on a black background. The kernel won't mind.
Everything works, its just a little difficult to read the screen.

Your Xorg.0.log is truncated. That usually means something nasty happened and the system could no longer write the log.
Please check the pastebin is complete.

Since you are using the nVidia binary blob, you are not supposed to use a framebuffer console at all.
You will get dire warnings at boot time. However turning on
Code:
# CONFIG_FB_VESA is not set
works for me.
You also have the old VGA console driver.

I'm guessing from your log that you are using EFI and GPT?
How you get the kernel loaded doesn't really matter.

Rebuild your kernel with VESA Framebuffer support.
It looks like the kernel switches to the framebuffer console but you don't have one that works, so all the lights go out.
Thats not udev related - it just happens to be the last console message you get to see.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
milktoast84
n00b
n00b


Joined: 03 Oct 2014
Posts: 17

PostPosted: Sun Oct 05, 2014 12:54 am    Post subject: Reply with quote

I recompiled with vesa, debating whether to use uvesa per the nvidia gentoo wiki instructions (having read that part about frame buffers conflicting with x86 installations--my x86_64 installation?-- the first time, I wanted to make sure that didn't happen to me, and didn't check off any. I also assumed--wrongly?--that nvidia-drivers would take over frame buffer activity.)

The installation behaves no differently with the new kernel in place. Should I have used uvesa? It says it requires a user space helper application.

Also, assuming you're right, that this is only some intermediate console fb, I tried to "startx" ... with no change. However my console interaction ceased to function, as if something new was going on in the blackness; perhaps as if I was running startx in my original perdicament(with the nvidia script installation). Whether it initiated some new level of blackness or DWM/xterm is unknown, but most likely a new level of blackness unless change of focus would have been needed for my commands to have effect in some hypothetical xterm; all happening behind the original unknown veil of darkness.

All terminal functionality remains when "startx" is not attempted: login, "reboot," "shutdown -h now"; 'while in the dark.

The Xorg.0.log doesn't appear to be altered. Though you can see the latest incarnation in the new paste in link below. I get the feeling it is only altered when something goes wrong, so those messages could be a remnant of entirely different configuration I attempted. For example, I have run "startx" where it tells me "no screen found" this was when the config file had a stupid mistake, or when I had the really old version of nvidia-drivers installed (having taken the mask command in the gen too nvidia wiki too seriously). I get the feeling that these were the times that it would output to Xorg.0.log.

This is what Xorg.0.log looks like after running "startx" in a blind environment:

http://pastebin.com/CmyN340x

In my mind I can imagine a scenario where that second level blackness (startx) is still the result of a session not starting. But none of the tutorials mention editing .xinitrc for testing, and I assumed that emerging xterm and dwm would cover that. Besides the fact that this is independent of even being able to see that transition in the first place('not being my first problem here).
Back to top
View user's profile Send private message
DONAHUE
Watchman
Watchman


Joined: 09 Dec 2006
Posts: 7550
Location: Goose Creek SC

PostPosted: Sun Oct 05, 2014 6:29 am    Post subject: Reply with quote

https://wiki.gentoo.org/wiki/NVidia/nvidia-drivers

Is the machine in question a laptop with dual vga cards, one intel and one nvidia?
if not, for nvidia-drivers, edit menuconfig to:
Quote:
Device Drivers --->
Graphics support --->
<*> /dev/agpgart (AGP Support) --->
< > AMD Opteron/Athlon64 on-CPU GART support
<*> Intel 440LX/BX/GX, I8xx and E7x05 chipset support
< > SiS chipset support
< > VIA chipset support
-*- VGA Arbitration
(2) Maximum number of GPUs
[ ] Laptop Hybrid Graphics - GPU switching support
< > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)
<*> Support for frame buffer devices --->
--- Support for frame buffer devices
[*] Enable firmware EDID
[ ] Framebuffer foreign endianness support ----
[*] Enable Video Mode Handling Helpers
[*] Enable Tile Blitting Support
*** Frame buffer hardware drivers ***
< > Cirrus Logic support
< > Permedia2 support
< > CyberPro 2000/2010/5000 support
< > Arc Monochrome LCD board support
[ ] Asiliant (Chips) 69000 display support
[ ] IMS Twin Turbo display support
< > VGA 16-color graphics support
< > Userspace VESA VGA graphics support modprobe -r nvidia
emerge xorg-server nvidia-drivers xf86-input-evdev twm xterm xclock
modprobe nvidia
nvidia-xconfig
reboot
[ ] VESA VGA graphics support
[ ] EFI-based Framebuffer Support
< > N411 Apollo/Hecuba devkit support
< > Hercules mono graphics support
< > Epson S1D13XXX framebuffer support
< > nVidia Framebuffer Support
< > nVidia Riva support
< > Intel740 support
< > Intel LE80578 (Vermilion) support
< > Matrox acceleration
< > ATI Radeon display support
< > ATI Rage128 display support
< > ATI Mach64 display support
< > S3 Trio/Virge support
< > S3 Savage support
< > SiS/XGI display support
< > VIA UniChrome (Pro) and Chrome9 display support
< > NeoMagic display support
< > IMG Kyro support modprobe -r nvidia
emerge xorg-server nvidia-drivers xf86-input-evdev twm xterm xclock
modprobe nvidia
nvidia-xconfig
reboot
< > 3Dfx Banshee/Voodoo3/Voodoo5 display support
< > 3Dfx Voodoo Graphics (sst1) support
< > VIA VT8623 support
< > Trident/CyberXXX/CyberBlade support
< > ARK 2000PV support
< > Permedia3 support
< > Fujitsu carmine frame buffer support
< > SMSC UFX6000/7000 USB Framebuffer support
< > Displaylink USB Framebuffer support
< > Goldfish Framebuffer
< > Virtual Frame Buffer support (ONLY FOR TESTING!)
< > E-Ink Metronome/8track controller support
< > Fujitsu MB862xx GDC support
< > E-Ink Broadsheet/Epson S1D13521 controller support
< > AUO-K190X EPD controller support
[ ] Simple framebuffer support
[ ] Exynos Video driver support ----
[*] Backlight & LCD device support --->
--- Backlight & LCD device support
<*> Lowlevel LCD controls
< > Platform LCD controls
<*> Lowlevel Backlight controls modprobe -r nvidia
emerge xorg-server nvidia-drivers xf86-input-evdev twm xterm xclock
modprobe nvidia
nvidia-xconfig
reboot
< > Generic (aka Sharp Corgi) Backlight Driver
< > Apple Backlight Driver
< > Tabletkiosk Sahara Touch-iT Backlight Driver
< > Backlight Driver for ADP8860/ADP8861/ADP8863 using WLED
< > Backlight Driver for ADP8870 using WLED
< > Backlight Driver for LM3630A
< > Backlight Driver for LM3639
< > Backlight driver for TI LP855X
< > Sanyo LV5207LP Backlight
< > Rohm BD6107 Backlight
Console display driver support --->
-*- VGA text console
[*] Enable Scrollback Buffer in System RAM
(256) Scrollback Buffer Size (in KB) modprobe -r nvidia
emerge xorg-server nvidia-drivers xf86-input-evdev twm xterm xclock
modprobe nvidia
nvidia-xconfig
reboot
<*> Framebuffer Console support
[ ] Map the console to the primary display device
[ ] Framebuffer Console Rotation
[*] Bootup logo --->
--- Bootup logo
[ ] Standard black and white Linux logo
[ ] Standard 16-color Linux logo
[*] Standard 224-color Linux logo
You can try adding [*] EFI-based Framebuffer Support to this, It has worked occasionally with nvidia-drivers. And frequently not, preventing X from running. With the kernel recompiled:
Code:
modprobe -r nvidia
emerge xorg-server nvidia-drivers xf86-input-evdev twm xterm xclock
modprobe nvidia
nvidia-xconfig
reboot

_________________
Defund the FCC.
Back to top
View user's profile Send private message
milktoast84
n00b
n00b


Joined: 03 Oct 2014
Posts: 17

PostPosted: Sun Oct 05, 2014 9:47 am    Post subject: Reply with quote

I have a macbook air with an nvidia geforce320m and an Intel core2duo processor. Does that qualify? (Are you commenting on my .config above, because there is a good chance I missed something there. It's a gentoo sources workstation setup with all the active modules that were detected from a mod probe script with a working Debian linuxmint install, plus the only reasonable settings I knew of/wacom, plus the efi stub)

I've had efi frame buffer enabled from the start, could that be the problem?

To clarify, your giving me five *seperate kernel recipes to try? Mutually exclusive/inclusive?

'Preparing for it regardless, but I'll wait for your "go ahead."


Last edited by milktoast84 on Sun Oct 05, 2014 9:55 am; edited 1 time in total
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5588
Location: Removed by Neddy

PostPosted: Sun Oct 05, 2014 9:55 am    Post subject: Reply with quote

out of curiosity... can you press CTRL-ALT-F1

do you get to a virtual console?
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 42587
Location: 56N 3W

PostPosted: Sun Oct 05, 2014 10:01 am    Post subject: Reply with quote

milktoast84,

What does your lspci show?
Does it also list an Intel VGA device?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
milktoast84
n00b
n00b


Joined: 03 Oct 2014
Posts: 17

PostPosted: Sun Oct 05, 2014 10:05 am    Post subject: Reply with quote

Naib,

No that never worked on this setup. This is a very minimal system so far(intentionally) I'm just trying to get an even simpler level of x interaction at this point. I assumed virtual consoles were part of certain display manager/desktop setups. Though I'm no expert.

My goal is to do graphics work with a DWM setup (my Goodness, does that setup make more sense than any desktop for using Gimp without three monitors), a side-goal is to create a larger doctordos console font for myself and nick name it: TOSATUfont The Only Sensible Alternative To Unity.

NeddySeagoon,

I'll get you the results of that as soon as I boot back up in the "morning" (6am w/no sleep}
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 6968

PostPosted: Sun Oct 05, 2014 10:36 am    Post subject: Reply with quote

Code:
[   136.863] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   136.882] (II) Module glx: vendor="X.Org Foundation"


It shouldn't be a problem with stock Xorg, but running it with composite enable will do, your glx provider should also be nvidia as
Code:
grep -A2 libglx /var/log/Xorg.0.log
[    89.945] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[    90.051] (II) Module glx: vendor="NVIDIA Corporation"
[    90.051]    compiled for 4.0.2, module version = 1.0.0


ps : this might help you while testing
Code:
startx & sleep 10 && killall X


edit: and btw, i didn't check, so do it yourself, but i'm pretty sure a
Code:
[   385.729] (II) NVIDIA dlloader X Driver  340.32  Tue Aug  5 20:13:04 PDT 2014

Quote:
I'm using a 2010 macbook air with a Geforce320m

doesn't handle a 320m chipset.
Back to top
View user's profile Send private message
milktoast84
n00b
n00b


Joined: 03 Oct 2014
Posts: 17

PostPosted: Sun Oct 05, 2014 6:25 pm    Post subject: Reply with quote

Thanks for that 'sleep' tip!

Geforce320m is supported by 340.32. It's the version I received after doing the online download walkthrough, and the version I masked to. It's also the version that runs with no problems on any other distribution despite/or perhaps because of their more complicated setups.

I ran the uninstall script, and did a deep clean after uninstalling xorg-server, before installing xorg-server again with the appropriate 340.32 dependency pulled in. So I'm not sure how a module could be out of place unless it was the direct result of the ebuild or a xorg.conf that ended up hanging around (I don't even think that would do it? glx is listed in the modules section... They both have the same module name...).

I'm not interested in composite effects on the desktop. Do I have that enabled? That is the only topic that comes up when I search "composite enable" though I suppose having a proper driver and kernel (capable of composite desktops?) takes precedence.

I also noted the timestamp on the X0rg.log, that is the most recent blind xstart, apparently no different.

NaddySeagoon,

Here is the output of lspci:

http://pastebin.com/BHRL03ZZ
Back to top
View user's profile Send private message
milktoast84
n00b
n00b


Joined: 03 Oct 2014
Posts: 17

PostPosted: Sun Oct 05, 2014 6:32 pm    Post subject: Reply with quote

Come to think of it, some time before the most recent setup, I ran "glxinfo" to test a set up. It said such n such package was not installed. So, I emerged such n such package naturally still wanting to test my card (lol). Still didn't work.

But you think that could be the misplaced glx module? What package would that of been, and should I even go down this road?

_______________
EDIT:

I'm at loss. I appreciate the help, but I still can't make heads or tails of those kernel instructions above. Did you mean to enter that emerge sequence that many times, or was that a typo? Only to be done when all changes were made?
Back to top
View user's profile Send private message
milktoast84
n00b
n00b


Joined: 03 Oct 2014
Posts: 17

PostPosted: Sat Oct 18, 2014 12:05 am    Post subject: Reply with quote

So. Having attempted variations of the kernel options suggested above, I've discovered that my being able to boot at all hinges on the activation of the EFI framebuffer (!) When not active, the Macbook Air hangs out on the white screen indefinitely.

I went through the Gentoo UVESA tutorial with the software and alternative initramfs option, crossed my fingers really hard... And ...white screen again.

I'm hoping that narrowing down the EFI fb as a culprit will be an " aha "moment.

My running theory is that EFI fb is both required and may interfere with (according to the above) the nvidia-drivers at the same time.

My only other thought is to try some more FBs.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 42587
Location: 56N 3W

PostPosted: Sat Oct 18, 2014 9:09 pm    Post subject: Reply with quote

milktoast84,

nvidia-drivers is what is politely referred to as a 'binary blob' because the soucre code is not available..
When it breaks, only nVidia can fix it.

The next step for you is to stop using nvidia-drivers and try either vesa, which works with any video card made after 1998 or nouveau.
vesa is easient as it does nat require any kernel changes, its also slowest.

Code:
emerge -C  nvidia-drivers
emerge -1 x11-drivers/xf86-video-vesa
mv /etc/X11/xorg.conf /etc/X11/xorg.conf_nvidia


This is just a get you going test.
Reboot and it should just work. Xorg will use the vesa driver without a xorg.cont.
You will get a USA keymap
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Deathwing00
Bodhisattva
Bodhisattva


Joined: 13 Jun 2003
Posts: 4087
Location: Dresden, Germany

PostPosted: Thu Oct 23, 2014 9:57 pm    Post subject: Reply with quote

Moved from Installing Gentoo to Desktop Environments.
Back to top
View user's profile Send private message
milktoast84
n00b
n00b


Joined: 03 Oct 2014
Posts: 17

PostPosted: Sat Oct 25, 2014 6:33 pm    Post subject: Still at it. Reply with quote

This would appear to be more than a nvidia issue. I've been around and through this install several times since last being here;So I'll give an update of the circumstance:

Apparently flawless UEFI Stub install, with plural deliberate successful moves. This time Simple Framebuffer is in use with the associated kernel option, rather than the explicit EFI Framebuffer. ... So I am assuming only efi works/efi is needed for an efi system. I have not been able to get my kernel to boot with a Grub efi loader pointing to my understanding of "normal" boot setup, with VESA or UVESA fbs. This could mean I haven't mastered a normal install (anything other than stub), or there is a fundamental problem with my kernel--that stub magically fixes, or that an efi machine needs an efi frame buffer regardless.

After doing a pristine xorg-server/nvidia-drivers emerge with the appropriate mask (no fiddling with the nvidia provided installer .. No touchy) The same error occurs as udev starts, with everything going black ( not to much of a surprise )

What is a surprise: X is never started during the error. I must startx manually in the darkness to get a Xorg.0.log

Also a surprise.. X.orgs glx driver is in use (so now we know that was not my direct doing) I was told nvidia's glx driver should be in use.

This is the blind Xorg.0.log: http://pastebin.com/uYayUjB6

What's more interesting is the initial dmesg which may contain more clues to the problem (potential kernel issues):
http://pastebin.com/f5a3yYRf

Also of interest in the dmesg. Uvesa fails. I put in a uvesafb kernel command line option embedded in the kernel, trying to get anything other than an efi buffer, but you can see it "falls back" to Simple FB. Maybe the two problems are related? Uvesa is configured according to the Gen too tutorial with the two emerged packages and the initramfs specified in the kernel. I have had a hankering to re-emerge those packages, but I'm not feelin' the odds of that being useful.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 42587
Location: 56N 3W

PostPosted: Sun Oct 26, 2014 12:49 pm    Post subject: Reply with quote

milktoast84,

Code:
[    5.286010] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
[    5.286016] uvesafb: vbe_init() failed with -22
[    5.286028] uvesafb: probe of uvesafb.0 failed with error -22
[    5.286092] simple-framebuffer simple-framebuffer.0: framebuffer at 0x80010000, 0x600000 bytes, mapped to 0xffffc90000780000
[    5.286101] simple-framebuffer simple-framebuffer.0: format=a8r8g8b8, mode=1366x768x32, linelength=8192
[    5.290848] Console: switching to colour frame buffer device 170x48
[    5.295027] simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!

shows that uvesafb failed. Google doesn't seem to know what error 22 is. simple-framebuffer worked, so something (not the kernel) set it up. The kernel is just drawing on it.
That may upset the nVidia binary blob later.

Your Xorg.0.log shows
Code:
[   120.363] (II) LoadModule: "nouveau"
[   120.364] (WW) Warning, couldn't open module nouveau
[   120.364] (II) UnloadModule: "nouveau"
[   120.364] (II) Unloading nouveau
[   120.364] (EE) Failed to load module "nouveau" (module does not exist, 0)
[   120.364] (II) LoadModule: "nv"
[   120.364] (WW) Warning, couldn't open module nv
[   120.364] (II) UnloadModule: "nv"
[   120.364] (II) Unloading nv
[   120.364] (EE) Failed to load module "nv" (module does not exist, 0)
[   120.364] (II) LoadModule: "modesetting"
[   120.364] (WW) Warning, couldn't open module modesetting
[   120.364] (II) UnloadModule: "modesetting"
[   120.364] (II) Unloading modesetting
[   120.365] (EE) Failed to load module "modesetting" (module does not exist, 0)
[   120.365] (II) LoadModule: "fbdev"
[   120.365] (WW) Warning, couldn't open module fbdev
[   120.365] (II) UnloadModule: "fbdev"
[   120.365] (II) Unloading fbdev
[   120.365] (EE) Failed to load module "fbdev" (module does not exist, 0)
[   120.365] (II) LoadModule: "vesa"
[   120.365] (WW) Warning, couldn't open module vesa
[   120.365] (II) UnloadModule: "vesa"
[   120.365] (II) Unloading vesa
[   120.365] (EE) Failed to load module "vesa" (module does not exist, 0)
[   120.365] (EE) No drivers available.
that Xorg tried all the open source drivers for your nVidia card but none were found.
The binary blob will only be loaded in you create a xorg.conf file with a Section Device ... to load the nvidia driver.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
milktoast84
n00b
n00b


Joined: 03 Oct 2014
Posts: 17

PostPosted: Sun Oct 26, 2014 7:19 pm    Post subject: Reply with quote

This is the new Xorg.0.log after putting in a xorg.conf . Everything is still black. But that was also suspected, having been in this scenario.
I'm assuming this is also truncated, implying "something bad." There is no terminal response (to "reboot") There is an .xinitrc (probably also not the issue)

http://pastebin.com/TjXezKUt

.xinitrc:

Quote:
xterm geometry 80x24+1+35 -sb &
xclock -update 1 -geometry 100x100+822+1 &
xterm -geometry 80x24+1+1 -sb -T Vaxb -e telnet vaxb &
xsetroot -solid lightskyblue4 &

twm


xterm, clock, and twm are all emerged. The .xinitrc was just snatched from the web after looking up "sample .xinitrc"

When I had my previous setup using EFI Frambuffer, I did attempt nouveau once. I got a bunch of xorg errors. My dilemma being it would only have been an exploration for posterity's sake. It's not worth it for my purposes to use nouveau because it causes a stream of pixels on the right hand border to trickle; and besides I know I can get a faster setup with a functioning nvidia-driver by letting their install script run wild on a Debian flavor install, and installing the DWM package.

This is why I'm taking it focused and deliberate now. I will attempt nouveau as a last resort. But I will also probably be tempted to completely reinstall depending on the results (you may laugh, but I just want it clean so I know what's going on).

You see why I suspect the kernel? Because Debian has always pulled it off. However they may have just been able to get a legacy boot to work.

Am I right to assume that I NEED these efi frame buffer options and/or I NEED the stub? There has to be a way for even an efi grub loader to recognize and run a kernel successfully on here. Which I have not been able to do with my kernel; another reason I suspect the kernel.

I am currently operating under the assumption that I don't have to abandon the benefits of the stub. That the advice--that the means of boot "does not matter"-- is correct. Because gosh darn I hope it's true, lol.

The latest dmesg:
http://pastebin.com/LwtKRehh
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
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