Very Computer

My linux system froze when trying to run the 2.0b4 Netscape.  I had to
power cycle to get out of that.  Now the boot fails as follows:

Dec 23 17:20:20 init[1]: version 2.4 booting
init[2]: cannot execute "/etc/rc.d/rc.S"
Dec 23 17:20:20 init[2]: cannot execute "/etc/rc.d/rc.S"
init[1]: Entering runlevel: 5
init[3]: cannot execute "/etc/rc.d/rc.M"
Dec 23 17:20:20 init[3]: cannot execute "/etc/rc.d/rc.M"
_setuent: can't open utmp file: no such file or directory

I get a login - it's in multi-user mode, not single user.  I can log in as
root.  Only the root file system is mounted, and it's read-only.  I cannot
mount any other file systems (/tmp, /usr, /var, /var/spool, /home),
because the mount command wants to write a lock file to the read-only root
file system.  I understand that just about all my symptoms stem from the
fact that the rc.d files were not processed.

I have tried the following:

1. I can read all files in rc.d, they look ok.

2. I can mount all file systems after booting from the emergency boot
floppies.

3. I have repaired all file systems.  Only a couple had errors, and they
were bitmap errors, seemed pretty normal for a power cycle.

4. I cannot remount the root filesystem as read write.  I tried "mount -o
rw -o remount /dev/hda4 /" and only got the usual complaint about not
being able to write the lock file.

5. /tmp is normal, mounted or not; 777 is what I remember.

6. /var/spool is 85% full, all the others are much less.

7. Booting linux from LILO with "single" added has the only affect of
asking for a run level, but still gives the same "cannot execute rc.[SM]"
errors.

8. Find of all files newer than the 2.0b4 netscape tar file found only
/etc/passwd (I added a different root entry from the emergency disk boot),
/dev/tty, /dev/ttyp[1-4], and root's .bash_history.

This is Linux 1.2.13, ELF, X 3.1.2.  16MB RAM, Pentium overdrive on a
486 motherboard.  The upgrade process from the original slackware 2.1 has
been somewhat twisted, but all has functioned that way for several months
before this crash.

I am really lost here.  If you think you know what is going on, PLEASE
call collect 1-510-679-9806.  I don't even care if you use 1-800-COLLECT!
If you want to respond by email with suggestions, I'd rather waste a
dollar or two on a collect call, but try me work email if you have to:

several times a day.  Posting is similar: post if you must, but if you
have anything useful, I WOULD RATHER YOU CALL COLLECT.  I have to post
this from MS-DOG WINDOZE.

I do have backups, maybe a month old, and will spend Wednesday seeing if I
can find some useful differences, maybe restoring.  But I have no real
ideas.

I am even willing to pay consulting fees, based on you fixing my problem.
 And to show how desperate I am, if you call (COLLECT :-) and I think you
have a real good chance at fixing this, I would be willing to drive the
damn box over to you, and still pay some kind of reasonable fee.  I live
halfway between SF and Sacramento.

I had big plans for my computer this holiday, and they have sure
evaporated :-(.

                                       Felix Finch
                                       1-510-679-9806

Seemes like something is screwed up.
Some hints:
1- you can remove the /etc/mtab~ file manually
2- there is an option to mount (I believe -n) to not write
        in /etc/mtab.
3- To avoid the /etc/mtab stuff you can do
        a cat /dev/null >/etc/mtab in an appropriate place
        (*BEFORE* you mount anything RW ) in your rc.d/rc.1 - script
        (carefull editing is advisable)
        you can remove the lockfile at the same place.
4- Ensure that the /etc/rc.d/*/rc.[SM] file exists and is executable
        (chmod 744 rc.XXXX )

5- It is a good thing to save a copy of the /etc directory somewhere,
        perhaps even on a different FS. (but you 'll know that by now :-) )

Happy Hacking,
Adriaan van Kessel.

It means that these scripts, rc.S, is not executable (does not have the 'x'
attribute for the owner, root) or, that the directory /etc or /etc/rc.d
is not searchable to the owner, root.

Quote:>init[1]: Entering runlevel: 5
>init[3]: cannot execute "/etc/rc.d/rc.M"
>Dec 23 17:20:20 init[3]: cannot execute "/etc/rc.d/rc.M"
>_setuent: can't open utmp file: no such file or directory
>I get a login - it's in multi-user mode, not single user.  I can log in as
>root.  Only the root file system is mounted, and it's read-only.  I cannot
>mount any other file systems (/tmp, /usr, /var, /var/spool, /home),
>because the mount command wants to write a lock file to the read-only root
>file system.  I understand that just about all my symptoms stem from the
>fact that the rc.d files were not processed.
>I have tried the following:
>1. I can read all files in rc.d, they look ok.

You have 'read' access, but not necessarily 'execute' access.

Quote:>2. I can mount all file systems after booting from the emergency boot
>floppies.

non-sequitar.

Quote:>3. I have repaired all file systems.  Only a couple had errors, and they
>were bitmap errors, seemed pretty normal for a power cycle.

non-sequitar.

Quote:>4. I cannot remount the root filesystem as read write.  I tried "mount -o
>rw -o remount /dev/hda4 /" and only got the usual complaint about not
>being able to write the lock file.

non-sequitar.

Quote:>5. /tmp is normal, mounted or not; 777 is what I remember.

non-sequitar.

Quote:>6. /var/spool is 85% full, all the others are much less.

non-sequitar.

Quote:>7. Booting linux from LILO with "single" added has the only affect of
>asking for a run level, but still gives the same "cannot execute rc.[SM]"
>errors.

That is to be expected.

Quote:>8. Find of all files newer than the 2.0b4 netscape tar file found only
>/etc/passwd (I added a different root entry from the emergency disk boot),
>/dev/tty, /dev/ttyp[1-4], and root's .bash_history.
>This is Linux 1.2.13, ELF, X 3.1.2.  16MB RAM, Pentium overdrive on a
>486 motherboard.  The upgrade process from the original slackware 2.1 has
>been somewhat twisted, but all has functioned that way for several months
>before this crash.

non-sequitar.

Quote:>I am really lost here.  If you think you know what is going on, PLEASE
>call collect 1-510-679-9806.  I don't even care if you use 1-800-COLLECT!

You can be letting yourself in for a very large telephone bill.

Do this:

chmod o+x /etc /etc/rc.d /etc/rc.d/*

--

My fault entirely.  Several days before, I had installed a new bash.
It installed into /usr/local/bin, where most stuff goes, yet when I
tried the new shell, I got the old one.  Tracing showed the old one
was in /bin, no doubt with a symlink from /usr/local/bin/bash to
/bin/bash.  The easy way out was the wrong way out, so of course
that's what I did.  I changed the /bin/bash binary into a symlink to
/usr/local/bin/bash.  Then, several days later, when Netscape crashed
and I had to reboot, the first line of rc.S says - are you ready for
this? can you see it coming? --- #!/bin/sh --- boom! couldn't follow
that symlink across the file systems - thus the message: "cannot
execute, no such file or directory".  Duhh, it's so obvious now, eh?

I suppose the real m*is to understand why things are the way they
are before changing them.  But that's been an ongoing battle for 25
years and altho the failure rate may approach zero, I doubt if it will
ever get there.  The easier lesson is that when a file cannot be
executed, if it begins with a #!  line, that could be a clue.

Thanks to all who emailed, altho I had specifically said NO email,
since the system was down, and I wouldn't be able to read it until the
system was fixed.  You folks were close, and helpful, but I feel a bit
less silly, since no one else knew the real cause either.  I know I've
been caught by this in other circumstances, where I typed in the #!
line wrong.

I expect I will be kicking myself about this for some time to come.
It may be to me as "that woman" was to Sherlock Holmes.

--

     ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.

     PGP = 9D 93 1E 78 5B D7 42 1C   95 4E 9E DD 3F 6F 21 98
I've found a solution to Fermat's Last Theorem but I see I've run out of room o