Summary: | RTx86 RTamd64 - X doesn't start: missing /dev/fb0 | ||
---|---|---|---|
Product: | Gentoo Release Media | Reporter: | Simon Stelling (RETIRED) <blubb> |
Component: | LiveCD/DVD/USB | Assignee: | Gentoo Release Team <releng> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Simon Stelling (RETIRED)
2006-08-20 14:20:07 UTC
manually executing 'udevstart' didn't fix the problem Try editing the kernel commandline in grub to include 'vga=791' (or whatever mode you want). I believe /dev/fb0 isn't getting created since there's no vga= option being passed. Indeed, adding 'vga=791' fixed the problem. OK. It looks like the proper "fix" for this is to use a different patch on amd64/x86 than on, say, sparc. Basically, because the "nv" driver sucks so badly, we're replacing it w/ fbdev. This works on the LiveCD because we're using the framebuffer. This would also be a problem if using "gentoo-nofb" on amd64/x86. On all other architectures, they set a framebuffer no matter what, so it isn't an issue. I had only tested it on "gentoo" and never thought about "gentoo-nofb" so I didn't catch it. Kugelfang/agaffney: You can change this in your fsscript to fix the issue. sed -i 's/DRIVER fbdev/DRIVER vesa/' /usr/share/hwdata/Cards I'll change hwdata-gentoo itself, so we don't have the same issue next release. It's in my fsscript for the next build. In my releng data. I'm going to assume that this was FIXED, since I didn't hear otherwise. Also, I updated hwdata-gentoo, so future releases will be using VESA on x86/amd64, and fbdev on everything else. |