SUMMARY: Is "cannot invoke /etc/init" fixable without CD-ROMs?

This has been a long time coming, my apologies for being slack.

This was the original question:

> I have two servers, a backup, and a production server. They
> are both running Solaris 2.6 Intel. On the backup server,
> someone deleted the /etc/init -> /sbin/init symlink. When
> the machine was rebooted, it naturally failed to come up.
> The disks are SCSI, and the / partition mounts correctly.
>
> Digging around for the install CD-ROMs (in order to boot
> into single mode, to restore the symlink) brings to light
> the fact that at some point in the past a contractor walked
> off with them. We should be able to track the person down
> but it will take time.
>
> Is there a way from the boot monitor to mount the /
> filesystem, and either recreate the symlink, or instruct
> whatever is looking for /etc/init to look for /sbin/init
> instead?
>
> Failing that, is there a way to build a rescue floppy from
> the live machine, to resurrect the dead one?
>
> I see in the archives that questions along these lines have
> been posed before, but apparently no-one ever bothered to
> summarize. I do promise that I will summarize. Indeed, I
> also intend to put up a web page explaining how to do this
> (if it is indeed possible) so that someone may be able to
> find the technique easily in the future.
>
> I have so far drawn a blank after several hours of googling
> and reading the Solaris manuals (I can't find any decent
> exhaustive coverage of what can and can't be done from the
> boot prompt).

One category of answers suggested I install the disk in another
machine, mount it and make the changes there, and then put it
back in place. That would have worked, but that would have
meant taking down the production machine, which would have
meant coming in at the weekend. Bleagh.

That said, I have a number of other servers running Linux or
OpenBSD, so I gave that a shot. The Linux box was running in
kitchen-sink mode, i.e., the default kernel with everything
compiled in. It recognised the disk straight of the bat, and
I was able to browse through the filesystem. Unfortunately,
it considered that the disk was dirty and needed to be fscked.
I hunted around for a fsck.ufs but drew a blank. I'm not sure
if I would have been brave enough to have run it even if I
found it, but it's nice to know that a dead Solaris disk
could be salvaged via Linux.

The OpenBSD box didn't know what to make of the disk. Then
again, the kernel has been recompiled several times. Each time
I strip a little more out, so by now it doesn't understand
much more than its own hardware.

I spoke to my Sun salesdroid, and they said that 2.6 is
obsolete, but they could ship me 2.8 disks free of charge. So
I said yes. Unfortunately they sent me 2.8 Sparc instead of
Intel.

In the meantime, I downloaded 2.8 from their site. I have a
fat pipe, so it only took 30 minutes or so. I then burnt a CD
and booted from that.

The install process is pretty easy to fathom. Fairly early in
the process it asks you if you want to run a shell prompt. I
said yes, and found myself staring at a #. Everything is read-
only, of course, since the files are on the CD-ROM. Some
thoughtful Sun engineer burnt a blank /a directory (which I
suppose is a handy mount point for a floppy). I mounted my
dead disk with something like

	mount -F ufs /dev/dsk/c1t0d0s0 /a

and I was up and running. IIRC, I didn't even need to fsck it
first. I replaced the symbolic link for /etc/init to /sbin/init,
unmounted the disk, quit out of the installation, removed
the CD,
rebooted... and the machine booted successfully.

The moral of the story? Know what devices your filesystems
are mounted on. I don't know why I had noted that
information in our system documentation, but it sure came in
handy that day.

The end.

Mac.

______________________________________________________
Bonte aux lettres - Caramail - http://www.caramail.com
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers