[Persian]

I'm running linux mandrake 9.1 with the KDE 3.1 desktop environment. Everything was working fine, then one day I tried to log in, and my computer "hung" Upon reboot I got this error message after the LILO Bootloader screen:
/etc/rc.d/rc.sysinit: line 41 22 Segmentation fault mount -n -t proc none /proc"
and
"/etc/rc.d/rc.sysinit: line 44 22 Segmentation fault grep -q quiet /proc/cmdline"
No idea what it means, cant get in through failsafe either. Same error. Can anyone help? Thanks in advance.
-Persian

[codejockey]

Looks like your /proc filesystem may be missing. Line 41 attempts to mount /proc and fails, which is why line 44 also fails when it attempts to search /proc/cmdline for information (if the filesystem is not mounted, there won't be anything to search). Now, the question is why wouldn't your proc filesystem mount properly? You might check to see if you have a directory named /proc (if you don't, that's at least part of the problem). It may be empty, but it should be there. If it isn't, try re-creating the directory; on my (slackware) system, the directory is mode 555, owned by root, group root:

ROOT: 10 /etc/rc.d-> ls -ld /proc
dr-xr-xr-x 74 root root 0 Oct 27 15:26 /proc

There's nothing critical in this directory; it is, in fact, a "pseudo" filesystem that provides an interface into the kernel. You may have to boot from a rescue floppy or your original installation media and mount your root filesystem to create the directory.

Hope this helps.

[Persian]

ok, i dont know how the heck this could've happened, but I'm a bit of a noob So can you tell me how I would go about mounting my root directory once I've gone into my rescue disk console?

[codejockey]

I don't have any good ideas how your /proc directory might have gotten removed; it could be a filesystem error or a hard drive problem. It would not be a bad idea to run fsck on your root filesystem before attempting any repairs/alterations. Assuming your root filesystem is of type reiserfs on /dev/hda6, you would use a command such as the following from a command prompt:

reiserfsck --check /dev/hda6

This will perform a read-only check of the filesystem and alert you to any errors. Note that /dev/hda6 should be unmounted at the time of the check. If you receive errors, you can run:

reiserfsck --fix-fixable /dev/hda6

This will fix most errors, except the most severe. You will know you need this option because the output from the first reiserfsck command will suggest re-running reiserfsck with the --fix-fixable option. If the output from the first command suggests using --rebuild-tree, you can do that with the command:

reiserfsck --rebuild-tree /dev/hda6

This command rebuilds the entire filesystem from the leaf nodes present, and should only be needed for significant or extensive filesystem damage. If you have data in your root filesystem that has not been backed up, you should try backing everything up before running with the --rebuild-tree option (I've never had a problem using this option, but it never hurts to be careful ...). Note that these commands/options apply only to a reiserfs filesystem, and not to ext2 or ext3, for example.

To backup or explore your root filesystem, use the command:

mount /dev/hda6 /mnt

from the command prompt. This assumes the /mnt directory already exists; if it doesn't, you can create it or another directory for this purpose:

mkdir /mnt

If mount complains that it can't figure out the filesystem type, you may need to use:

mount -t reiserfs /dev/hda6 /mnt

Once your root filesystem is mounted, you can explore it at will ... note that you will be looking for a directory named /mnt/proc, not /proc (since /proc refers to your current root filesystem, not the one on /dev/hda6, which you are attempting to explore/repair).

cd /mnt
ls -ld proc
mkdir /mnt/proc
chmod 555 /mnt/proc

If you have modified your /dev/hda6 filesystem at all, you should issue the command:

sync;sync

before rebooting. Although not strictly necessary, it provides an extra measure of assurance that all filesystem changes have been written to disk.

Hope this helps -- feel free to post any additional info or results that don't appear to match expectations, and we'll go from there.

[Persian]

ok, i was able to mount my system and look at it, but it turns out that my root filesystem was on hda1 and my home directory was on hda6. Unfortunately, i believe mandrake uses and ext2 or 3 or something type of file system, so I couldn't use reiserfsck. Another thing is that the /proc directory existed but was completely empty.. i changed permissions to your specifications but it didnt make a difference. I'm going to trying copying the proc directory of my resuce disk into my hda1 proc directory if this fails, i'm going to try the same thing except on hda6. I'll post again soon with an update. ((I have a feeling it wont work though ))

[Persian]

bleh, no go. Is there anything else you can suggest? If not, is it possible for me to somehow reinstall mandrake on a different partition so I can save what I have on my hard drive right now? Then burn it to cds then reinstall from scratch? or something along those lines? Thanks again

[codejockey]

Since you're using ext2/ext3 filesystems, you should be able to substitute fsck for reiserfsck. So, for example, you might try:

fsck -n /dev/hda1

which will check the hda1 filesystem but not perform any modifications. If you decide to go ahead and repair any problems, you can use either:

fsck /dev/hda1 (interactive, one-by-one repair)
or
fsck -y /dev/hda1 ("batch" mode, assume "yes" to all repairs).

The /mnt/proc directory on your mounted root filesystem should be empty; it gets filled at boot-time with information from the kernel being booted. Since you are not booting a kernel in your hda1 root filesystem, the /mnt/proc directory should be empty. Don't mess with hda6; there's nothing there that should affect your ability to boot.

Another thought: try mounting your hda1 root filesystem, and looking in /mnt/var/log for files named messages and syslog. Either or both of these files could contain clues about the problem.

Hope this helps.

[Persian]

my rescue disk doesn't have the 'fsck' command
i looked at my messages and syslog files and they are absolutely huge
but I sifted to the bottom and i think I found an error. According to the log it happened the day my computer stopped working, the 26th, so this likely is the problem. I can't make heads or tails of it though. It looks something like this:

"[time stamp & my computers name] smbd[4517]: [timestamp] lib/fault.c:fault_report(38)"

-> this line shows up ALOT after this point except the number 38 is sometimes 39 or sometimes 41. Then theres something along the lines:

"[time stamp & my computers name] smbd[4517]: INTERNAL ERROR: Signal 11 in pid 4517 (2.2.7a)
[time stamp & my computers name] smbd[4517]: Please read the file BUGS.txt in the distribution"

then:

"[time stamp & my computers name] smbd[4519]: [timestamp] lib/util.c:smb_panic(1094)
[time stamp & my computers name] smbd[4519]: PANIC: internal error
[time stamp & my computers name] smbd[4519]:"

then basically all this stuff is repeated through the file for a while except the number [4519] changes. As I said before, I have no clue what it all means

[codejockey]

Do you know if you were running samba? smbd and nmbd are the two samba daemons that would typically be running if you wanted to make Linux resources (files, printers, etc.) available to Windoze machines. At first blush, I don't see why samba problems should prevent your machine from booting completely, but perhaps there's a connection. One possibility: you mention that your logfiles were very large -- have you run out of space in your hda1 filesystem? If so, this could cause problems at boot time. Try booting from your rescue disk and mount your /dev/hda1 partition:

mount /dev/hda1 /mnt

Then issue the command: df -k and review the output. Check the Use% column for /mnt; if it's close to 100% (like 98% or above), you could have a problem, and will need to compress or delete files to create some space.

Also (and apologies if you have already tried this), you may need to provide the full pathname for the fsck command (typically, root has a restricted path for security reasons). On my system, fsck is in /sbin, so you might try a command such as: /sbin/fsck /dev/hda1. Although your rescue disk may not have the fsck utility, it is likely on your original installation CD. Try booting from your CD and see if you can get to a command prompt; you can use these instructions from distro.ibiblio.org:

You can also use a text mode installation if, for any reason, you have
trouble with the default graphical installation. To use it, press [F1]
at Mandrake Linux welcome screen, then type "text" at the prompt.

If you need to rescue your existing Mandrake Linux system, insert your
Installation CDROM (or any relevant boot floppy), press [F1] at
Mandrake Linux welcome screen, then type rescue at the prompt.

See http://www.linux-mandrake.com/drakx/README for more technical
information.

Hope this helps.

[Persian]

I am 95% sure my distribution uses samba.
Also, my harddrive is only at 33% capacity, so that can't be it.
I finally figured out fsck. The command actually was fsck.ext3, I ran the check and it says its clean. Nothing wrong with the filesystem. So what else could be causing this problem

[Persian]

I tried booting up normally again and this time there was another line added to the error. Now it looks something like:

"
/etc/rc.d/rc.sysinit: line 41 22 Segmentation fault mount -n -t proc none /proc
/etc/rc.d/rc.sysinit: line 44 24 Segmentation fault grep -q quiet /proc/cmdline
/etc/rc.d/rc.sysinit: line 97 33 Segmentation fault grep - q '^LIBSAFE=yes$' /etc/sysconfig/system
"
dunno if that means anything different or not, and sometimes it only prints the first two lines as errors.. it seems pretty random. So on bootup I either get just the first two or all three.

[codejockey]

Only a couple of ideas at this point (both long shots):

(1) can you boot into single-user mode? If so, you may be able to try using the mount and grep commands from the command line and see if you have similar results. If grep and mount blow up on you, it seems that you may have corrupt executables. You can try replacing them with another copy from the same distribution (backup the current versions first) and compare checksums of the old and new versions of each executable. They should match; if they don't, and you're certain that the new executables are from your distribution, you can try using the new executables during boot and see if you get farther.

(2) any recent hardware changes? You might try removing and reseating your memory stick(s) to see if that improves things at all. I doubt this is the problem, simply because your results are so consistent, but it's a quick, cheap fix if it works.

Like I said, both long shots.

Hope this helps -- additional info appreciated.

[Persian]

I really appreciate all the help. But I finally broke.
I ended up reinstalling mandrake on a new partition, then mounted the old partitions and burned all my music and important files and reinstalled from scratch and now I'm back at 100%
If it happens again though I'm giving up on mandrake, maybe I'll try slackware
Anyways, thanks again

-Persian

[codejockey]

Glad to hear that you're up and running again. I think you probably made the right decision to reinstall -- fortunately, you were able to save the things you really needed. Good job ( ).