Unfortunately it didn't solve the problem. It looks like xorg-server is very buggy in the current state, or at least not stable on all hardware. If I'm very lucky it boot up, but usually it doesn't.

Actually it took me some time to understand what it was. When I did I removed it. Ha, ha, maybe I'm now cursed by the developers of Pardus!

Update:

Just for fun I plugged in the hd with Pardus once more this evening and expected the same disappointing result as before. Damn it, it did actually boot all the way this time!

I checked the updates available in Pisi and found hal, the abstract layer to be updated, which of course could be an important factor. Let's see if this will correct the situation.

Zorg is shown to be correct and updated.

It seems to be caused by a problem in xorg-server, a bug that was found in for example the 7.2.0 RC1 and RC2 releases. There's quite much about it on the net, but much information is over my head. In Pardus it should be the final 7.2.0 release I suppose, but it looks like I still encounter this problem:

"_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6"
"_XSERVTransOpen: transport open failed for inet6/hardcoreduo:0"
"_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6"

Does anyone know how to correct this and how to explain the procedure for a simple user like me?

I searched bug reports for Pardus but didn't find anything similare.

Following you suggestion I get the following:
"Service 'kdebase' stopped."
"kdebase error: Not starting as zorg returned an error"

I know nothing about kde and how zorg works, so please give me some guidance. A search on google didn't give me anything either.

Is this a bug? I have Pardus running, just for testing, on another P3 machine and nothing like it has never occurred. The hardware specifics for the machine running into problems is so basic and standard so there shouldn't exist any incompatibility.

Edit: Listing services show that all standard and necessary services are running. "kdebase" is running; text marked in red color.

Thanks for the suggestion!

I'm checking the file-system and particular etc/X11/ and now I'm even more confused, because the only files and directories listed are:
 kdm Sessions xkb xorg.conf-backup

I haven't seen this before and assumed that there should be a xorg.conf file. The backup file looks correct. Have some changes been made to how xorg works? Should I look elsewhere or should copy the backup file into xorg.conf?

Help appreciated, because this doesn't look like what I'm used to.

Edit: Sorry, forgot to say that startx doesn't work of course, but at least the keyboard isn't looked up so I can switch to command prompt.

Since Pardus also disables the keyboard, PS/2 or USB no matter, then such a standard procedure obviously doesn't work. However I forgot to mention that when booting in text mode it looks like the main system is functioning. In most cases the system doesn't totally lock up, because if pressing the power button it starts to shutdown processes just as it should. In one of let's say 20 attempts it might even boot up correctly. Of course settings for all this devices will be found in xorgconfig, so I suppose I have to try to get it to stay in init 3 mode, even though my editing of grub hasn't worked as I hoped yet.

Still it confuses me: what on earth can possibly change by itself between two sessions? In the two occasion that I could get the system up running again I see nothing wrong. There must be some incompatible weak link somewhere.

A funny note is that before this installation the machine has been running Fedora 5 - the hd I previously mentioned - and a while ago I added a module of extra RAM and didn't bother to memtest it. Before this installation however I choose to run memtest and that extra module proved to be faulty, spitting out errors like a flood. So I put back another module of less MB and memtested and certified that the system was stable again. So what's funny? The Fedora 5 installation has been running with that faulty module for at least 2 months, been updated, even the kernel, and pushed hard in some applications, and still it hasn't even once failed to boot and no application has crashed. When I now run it it definitely looks like it's totally intact. That's pretty impressive I would say, but therefore even more makes my problem with Pardus a mystery.

I'll try to find some extra time tomorrow, or I move on, because I don't have time enough at this moment.

Hi!

As can be seen in some other posts I've made I decided to install Pardus for an organisation of volunteers. The first computer in question is pretty basic and certainly not new, but still fairly good; it's an IBM Netvista based on a Gigabyte motherboard, Intel chipset, integrated graphic, with a P4 1.8GHz.

The installation goes fine, just as configuration and updating. I've twice now got the system exactly as I wish. Second time, besides installing some needed applications, I only removed games to save hd space. Nevertheless while configuring the system and did reboot a couple of times to see that everything went smooth. No problems so far, but...

After shutting down the system once or twice Pardus fails to boot correctly. If editing grub to see what happens, everything goes fine until it should switch init and start up the login screen, then it fails which results in a "shining" black screen. Unfortunately it also disables keyboard and mouce (tested both PS/2 and USB), so switching init and go back to command prompt doesn't work. Pardus differs from other distros I've tested so I first ask here whether it's a known problem, even though I didn't get any hits while searching the forum.

The following is tested:
- system stability = OK
- monitor refresh rate = OK
- took a harddrive with a previously installed Fedora 5 for this particular computer = OK

Therefore there's evidently some bug bugging me right now. I'm short of time because of work, so let's see if anyone recognize this problem.