Just a warning to those who may be inclined to follow the line in the handbook that reads:
DON'T DO IT!!! I installed my system, then spent the better part of a week compiling/installing various ports. There were issues, like when libreoffice crashes and the KDE screensaver crashes - I was really hoping that a standalone video card would help clear up these problems. I shut down the system, installed an nVidia PCI video card, and booted back up. Everything was going well until I decided to believe that line in the handbook...
Knowing my old /etc/X11/xorg.conf wouldn't work because the onboard video was based on a radeon chipset, I deleted the file. Then I foolishly decided to see if I could bypass the X11 configuration that I went through last time by simply typing startx from a user account, figuring the worst that could happen was that X/KDE would fail to start and that I'd have to break out from a different console. How wrong I was!
I got a fast clicking/buzzing noise from my speakers after the screen went black. I knew something had gone wrong, but figured it was no big deal - I'll just Control-Alt-F1 to get to the root shell I had open on the first console and kill the process from there. No such luck. Nothing I did was able to get the screen to do anything but stay black (not no signal, but black) and nothing aside from unplugging the speaker would stop that annoying buzz. Tried switching to different consoles, tried using control-alt-delete to reboot, tried accessing over the network (before realizing I hadn't set that up yet
), and still couldn't get any response. Tapping scroll lock twice to switch to another machine on my KVM didn't even work. I let it sit for about 20 minutes in the hope it'd eventually respond. It never did and I ended up having to hold down the power button 4 seconds to get it to shut off.
Powered back on and what a surprise - the file system check complained that / wasn't properly dismounted and started a check. After the file system check completed (with the below lines resulting), it continued booting. Unfortunately, it went extremely slowly and eventually stalled out, refusing to boot any farther. Again the keyboard was frozen and I had to do a hard power-off.
The same process repeated itself twice more. Then tried booting from both other drives in the mirror with the same result. One interesting point is that it doesn't freeze up at the same point every time - one time the last line shown will be the start of inetd, the next when hald is starting, etc. There's no pattern that I can determine. Even left the system sit on overnight in the hopes that the fsck was still running and somehow blocking the boot process and hence would eventually complete allowing the boot to continue, but to no avail - still froze up in the same spot when I got in this morning.
I can get into single user mode, but because the boot process doesn't stop/lock up in any consistent way, don't really know what to do in order to repair whatever damage was done. The file system check completes at boot time, so I don't see where that would help. Since the mirror was active at the time this happened, all 3 copies of my system were taken down. (Already made a mental note to have one drive be a static backup that is not in the mirror; I'll write something that will mirror the root file system once a week or so if/when the system gets back up & running.) I thought that disabling one or more startup daemons might help, but it doesn't seem to. At this point, I'm about ready to wipe it and start over, which I REALLY hate to do after putting so much time & work in on it, but I really don't see what other option I have.
I guess the point of this post is to not believe what it says in the handbook about startx working without configuration first. This is exactly what I did as a normal user and it nuked the system somehow. If anybody has ideas of how I could troubleshoot or isolate or repair what was screwed up, I'd appreciate them. If a developer reads this, you might want to look at how something that a normal user does makes a system unbootable. (I'm willing to provide any information you ask in the way of log files and such, but unless I figure something out, the system's getting wiped and reinstalled so it can compile over the weekend.)
Code:
As of version 7.3, Xorg can often work without any configuration file by simply typing at prompt:
startxDON'T DO IT!!! I installed my system, then spent the better part of a week compiling/installing various ports. There were issues, like when libreoffice crashes and the KDE screensaver crashes - I was really hoping that a standalone video card would help clear up these problems. I shut down the system, installed an nVidia PCI video card, and booted back up. Everything was going well until I decided to believe that line in the handbook...
Knowing my old /etc/X11/xorg.conf wouldn't work because the onboard video was based on a radeon chipset, I deleted the file. Then I foolishly decided to see if I could bypass the X11 configuration that I went through last time by simply typing startx from a user account, figuring the worst that could happen was that X/KDE would fail to start and that I'd have to break out from a different console. How wrong I was!
I got a fast clicking/buzzing noise from my speakers after the screen went black. I knew something had gone wrong, but figured it was no big deal - I'll just Control-Alt-F1 to get to the root shell I had open on the first console and kill the process from there. No such luck. Nothing I did was able to get the screen to do anything but stay black (not no signal, but black) and nothing aside from unplugging the speaker would stop that annoying buzz. Tried switching to different consoles, tried using control-alt-delete to reboot, tried accessing over the network (before realizing I hadn't set that up yet
), and still couldn't get any response. Tapping scroll lock twice to switch to another machine on my KVM didn't even work. I let it sit for about 20 minutes in the hope it'd eventually respond. It never did and I ended up having to hold down the power button 4 seconds to get it to shut off.Powered back on and what a surprise - the file system check complained that / wasn't properly dismounted and started a check. After the file system check completed (with the below lines resulting), it continued booting. Unfortunately, it went extremely slowly and eventually stalled out, refusing to boot any farther. Again the keyboard was frozen and I had to do a hard power-off.
Code:
INCORRECT BLOCK COUNT I=1885000 (4 should be 0) (CORRECTED)
INCORRECT BLOCK COUNT I=2802692 (4 should be 0) (CORRECTED)
INCORRECT BLOCK COUNT I=2826427 (4 should be 0) (CORRECTED)The same process repeated itself twice more. Then tried booting from both other drives in the mirror with the same result. One interesting point is that it doesn't freeze up at the same point every time - one time the last line shown will be the start of inetd, the next when hald is starting, etc. There's no pattern that I can determine. Even left the system sit on overnight in the hopes that the fsck was still running and somehow blocking the boot process and hence would eventually complete allowing the boot to continue, but to no avail - still froze up in the same spot when I got in this morning.
I can get into single user mode, but because the boot process doesn't stop/lock up in any consistent way, don't really know what to do in order to repair whatever damage was done. The file system check completes at boot time, so I don't see where that would help. Since the mirror was active at the time this happened, all 3 copies of my system were taken down. (Already made a mental note to have one drive be a static backup that is not in the mirror; I'll write something that will mirror the root file system once a week or so if/when the system gets back up & running.) I thought that disabling one or more startup daemons might help, but it doesn't seem to. At this point, I'm about ready to wipe it and start over, which I REALLY hate to do after putting so much time & work in on it, but I really don't see what other option I have.
I guess the point of this post is to not believe what it says in the handbook about startx working without configuration first. This is exactly what I did as a normal user and it nuked the system somehow. If anybody has ideas of how I could troubleshoot or isolate or repair what was screwed up, I'd appreciate them. If a developer reads this, you might want to look at how something that a normal user does makes a system unbootable. (I'm willing to provide any information you ask in the way of log files and such, but unless I figure something out, the system's getting wiped and reinstalled so it can compile over the weekend.)
), so I'm not going to argue the point. However, while I understand that a hard reset without having soft updates/journalling enabled is what was most likely the ultimate cause of the system dying, the auto-config of X causing a hard lockup is what precipitated the whole mess.