
grml live CD 0.8 final plus "apt-get update; apt-get install grml2hd"
At the xorg.conf step, if I say "yes," part of the screen goes black. The dialogs become impossible, although staying active. (If only they were movable with the mouse.) If I say "no" everything works fine.
The blackness is top to bottom across ~40% of the horizontal, sort of middle of screen. nVidia GeForce card, but without nvidia drivers, just the live CD with no special boot codes (except noswap).
When I ctrl-c out of the script, the screen is still bad, so I have to reboot.
M

* Mark 27e3kk302@sneakemail.com [20060827 09:43]:
grml live CD 0.8 final plus "apt-get update; apt-get install grml2hd"
At the xorg.conf step, if I say "yes," part of the screen goes black. The dialogs become impossible, although staying active. (If only they were movable with the mouse.) If I say "no" everything works fine.
The blackness is top to bottom across ~40% of the horizontal, sort of middle of screen. nVidia GeForce card, but without nvidia drivers, just the live CD with no special boot codes (except noswap).
When I ctrl-c out of the script, the screen is still bad, so I have to reboot.
If you are running grml-x in live-cd mode the X-server starts up without any problems?
Pressing Ctrl-L when the grml-x dialog drives crazy does not help?
regards, -mika-

Testing grml2hd again would be too much work and the problem was reproducible with a live CD test anyway. I used "grml-x fluxbox" as the command.
Just before Fluxbox starts, I observed the blackout in the terminal screen. Fluxbox itself seemed to have no problems. When I quit Fluxbox and X, the terminal showed the same problem, all the way through system shutdown. Basically the screen was wrecked.
There is more. Grml did something to the actual CRT monitor adjustment firmware.
My testing desk has two PCs with identical video cards on a dumb KVM switch. After switching over to the Windows machine, I noticed the Windows screen was wrecked by the grml test. It appears that grml panned the screen firmware out of bounds. I had to power off to restore normalcy. Rebooting showed normal behavior.
The Windows machine normally runs at very high quality video settings with nVidia driver, 1152x864 32-bit 75 Hz. The monitor is extremely capable if old. So it is not a problem with the monitor.
For the live CD grml test I just used your stock CD, nothing else.
M

* Mark 27e3kk302@sneakemail.com [20060828 11:05]:
Testing grml2hd again would be too much work and the problem was reproducible with a live CD test anyway. I used "grml-x fluxbox" as the command.
That's fine.
Just before Fluxbox starts, I observed the blackout in the terminal screen. Fluxbox itself seemed to have no problems. When I quit Fluxbox and X, the terminal showed the same problem, all the way through system shutdown. Basically the screen was wrecked.
Ok.
There is more. Grml did something to the actual CRT monitor adjustment firmware.
My testing desk has two PCs with identical video cards on a dumb KVM switch. After switching over to the Windows machine, I noticed the Windows screen was wrecked by the grml test. It appears that grml panned the screen firmware out of bounds. I had to power off to restore normalcy. Rebooting showed normal behavior.
The Windows machine normally runs at very high quality video settings with nVidia driver, 1152x864 32-bit 75 Hz. The monitor is extremely capable if old. So it is not a problem with the monitor.
For the live CD grml test I just used your stock CD, nothing else.
So the nv driver is used, right? Do you get the same strange behaviour when running:
grml-x -module vesa fluxbox
?
regards, -mika-
Teilnehmer (2)
-
Mark
-
Michael Prokop