I didn’t notice any relevant complaints regarding 11.2 in the archives. The bootup & shutdow may be different problems.
Randomly my recent install boots up fine or hangs with a blank black screen. A Ctl Alt F2 gets me to a prompt. Startx returns a lockfile comment that X is already running.
From here I can shut 11.2 down and restart it OK. There must be a bootlog kept in /var somewhere.
I haven’t tried the non-automatic bootup.
The shutdown randomly drops back to the logout screen. Usually a shutdown command from there will shut it down. Sometimes shutdown doesn’t work, but restart will finish the shutdown.
Is the 11.2 autoboot function with gnome solid? Heboland
Try booting in failsafe from the boot menu
Then post the result of this from a terminal
zypper lr -d
Thank you for your response caf4926!
The output response to your command is so nicely formatted, I hope to capture it here.
Can I attach a text file? Will this do? Heboland
frank zypper lr -d
| Alias | Name | Enabled | Refresh | Priority | Type | URI | Service
1 | openSUSE 11.2-0 | openSUSE 11.2-0 | Yes | No | 99 | yast2 | cd:/// |
2 | repo-debug | openSUSE-11.2-Debug | No | Yes | 99 | NONE | Index of /debug/distribution/11.2/repo/oss |
3 | repo-non-oss | openSUSE-11.2-Non-Oss | Yes | Yes | 99 | NONE | Index of /distribution/11.2/repo/non-oss |
4 | repo-oss | openSUSE-11.2-Oss | Yes | Yes | 99 | NONE | Index of /distribution/11.2/repo/oss |
5 | repo-source | openSUSE-11.2-Source | No | Yes | 99 | NONE | Index of /source/distribution/11.2/repo/oss |
6 | repo-update | openSUSE-11.2-Update | Yes | Yes | 99 | NONE | Index of /update/11.2 |
Is your system up to date.
su - terminal
Personally I recommend not using auto login. I am not really a gnome user, though I have just recently installed gnome to test it. It seems fine, though slower to boot than kde.
Log files are in /var/log
Thanks again caf4926.
I’m on dial-up, so I have to choose my updates frugally! Does the zypper up get me an update list or does it attempt the update also.
In previous experience the dial-up link won’t last until the repositories get synced up. That makes the SW management mad!
I poked around in /var without finding anything. Boot didn’t reveal anything. On this install I switched to gnome hoping to ease the size of the updating required. Mostly I want to update security only.
will list the updates, but expect it as long as your arm.
If it’s a Laptop, get it to a internet cafe if you can
will veryfy everything
No, I have a desktop. I see there is a manpage for zypper.
One thing that may be useful is how to start gnome if I get to the black screen. I thought that ctl alt F2 killed the X server, but it still seems to be running.
There is probably a command I could enter at the prompt that would tell me what level of booting I was at.
Another step I could take from the black screen prompt might be to look at a log file. Heboland
then type: init 3
hit enter again
then try: startx
Replying to myself, I just recovered from a black screen!
Using the ctl alt F2 to get a prompt, I logged in as root. Runlevel gave N 5. I tried init 3 which started by killing gdm (gnome display manager)?
Runlevel then gave me 5 3. From here I executed gdm and gnome loaded.
Regarding the boot logs in /var, is the boot.omsg the previous boot.msg? Heboland
Thanks caf4926 - I just noticed your post to try startx.
I’ll give that a try, but I have some questions about gdm you may be able to help me with.
gdm --help shows a gdm --debug option and I tried that once from runlevel3. That must write a log somewhere, but I couldn’t find it.
What would be neat would be to invoke that debug option so the autoboot SW would record the whole autoboot process.
One of the autoboot hangs actually displayed the login menu on the black screen with the word autoboot as the user.
Another outcome displayed some of the gnome taskbar icons, but they were inactive.
I know your help time is limited and that a manual login would probably work. Do you think the gnome forum would be interested in this behavior or does this belong here?
Bringing you problem here is fine.By all means try other places too if you like.
You didn’t tell me if you tried the Failsafe boot from the menu.
I suspect a hardware conflict. What graphics device do you have?
Do you have any strange peripherals attached?
Or SB Hubs?
I’m at the library now, but I think this reply will work.
Yes, I booted from failsafe OK the only time I tried it, when I followed you instructions requiring it.
Please note however, that more then half the time, normal boot works fine. The problem seems to be in the handoff from startx to gdm or in the gdm invocation.
If I could configure startx to invoke gdm --debug and then know how to expose the debug results, this might be easy to track down.
For peripherals, I have an epson RX500 printer/scanner that works OK, two PCI modems unconfigured and a serial port external modem.
The monitor is a Chinese copy of something like a DB-77? Video card is an ATI rage 128 something. It’s set to run the 1152x876? resolution.
There is still an random shutdown/restart from the gnome gui, sometimes stopping at the login prompt instead of shutting down.
When 11.2 hangs at the black screen gdm is running. If I kill the five or so processes from the level 5 root login, I can type gdm and get the gnome gui to start successfully.
Let me leave this here for now! Heboland
Replying to myself to provide more input, my first boot after leaving the library was a black screen.
I poked around as root at level 5 to find startx. It’s apparently a front end script for init. Even an invocation of startx --help starts a process with no return to the root shell.
With ctl-Z to background it and then a kill -9 of %1, I can get the prompt back. Init 3 then stops gdm and drops the state back to level 3.
startx from level 3 hangs the root shell as X is already running there. With the same bg and kill proceedure, I got the prompt back and invoked gdm --debug.
There’s a clot of output to the screen following that invocation that next time I will redirect to a file in /root.
The other result is this gnome environment that I am writing this reply from. I should clarify that the black screen boots using the standard 11.2 are less than 10% of normal boots.
Do you know where gdm is invoked from? Heboland
Before I get to your question, I have a diff between the top of ~/.xsession-errors and ~/.xsession-errors.old.
< chown: changing ownership of
/dev/xconsole': Operation not permitted < chmod: changing permissions of /dev/xconsole’: Operation not permitted
< gnome-session: WARNING: Could not parse desktop file /etc/xdg/autostart/ksmolt-autostart.desktop: Invalid key name: X-KDE-autostart-condition$e]
< gnome-session: WARNING: could not read /etc/xdg/autostart/ksmolt-autostart.desktop
> gnome-session: WARNING: Could not parse desktop file /etc/xdg/autostart/ksmolt-autostart.desktop: Invalid key name: X-KDE-autostart-condition$e]
Notice the chown problem with /dev/console in the .xsession-errors file generated by the black screen boot.
I think that the failsafe boot is a sample of one compared to maybe 5% of a sample of twenty normal boots.
One difference with the normal boot is a narrower display on the monitor screen by maybe 10-15%.
This is a long post, so I will end this here. What do you think about the diff file? The GDM manual says it writes the .xsession-errors file.
You may want to run a serous session with the memory test on the install media. This sounds like more a hardware problem then a software one.
Thanks wise penguin!
I think the media/DVD drive is OK. The original DVD was copied on the gnome box and the copy was media checked before the install on the kde box. I used the same media copy to install the 11.2/gnome on this box.
Gnome has a nice gdm user manual which I read last night. It told me where the log files are as well as the bootup sequence.
If there is a HW problem, it may lie with the different display resolutions: 1280x1024 used by failsafe Vs 1152 x 864 used by ll.2.
11.2 boots with splash=off and vga=317. Failsafe boots with vga=x31a which is 1280x1024 and never changes resolution.
As far as I know there is no vga number for the 1152x864. This lower resolution is perfect for my 17" screen.
Probably I’ll have to continue my debug on my own since I can’t expect much more of your time, but thanks a million for your help to this point!
One thing I didn’t mention that may be significant is that the mouse works on the black screen, tho there isn’t anything to click on!
It’s probably beyond the scope of this forum, but what I think will expose my malady would be to have gdm invoked with the --debug option by then normal boot procedure.
Some of the gdm commands are described as scripts, but they are binary files. I can’t edit them to insert the option string.
The scripts are run as root. Is it possible that I could give root an alias for gdm=‘gdm --debug’?
Last, does it make sense if I find a cure that isn’t a real bug, to add the solution to this thread? Heboland
My point is that you may have flaky memory in the machine. Run the memory test from the install media that is different then the media check. Let it run over night at least. Not everything is a software problem.
Thanks Wise Penguin,
I understand what you were thinking now.
Since I last responded here, I reloaded 11.2 with kde. If your theory is correct, the autologin should be flakey with kde also.
The new install created at least one other problem. When I checked the archives, I didn’t find a hit on the topic, so I’ll start a new thread.
Replying to myself, with kd34-3-1 on this Pentium 4 box, the autologin works flawlessly.
I did run the memory test on the 11.2 install DVD. It completed two passes in about an hour of testing there were no errors.
gnome was nice, but kde looks more promising! Heboland