Recovering Solaris 8 root password

Hello everyone, i'm trying to recover my root password on a Solaris 8 O.S.

I've been trying the next steps(obviously in order) on and on:

  1. Inserting the CD-ROM
  2. Typing boot cdrom -s
  3. Trying to execute fsck -y /dev/dsk/c0t0d0s0. When executing this, I get the following error: can't stat c0t0d0s0.
  4. After this I run the following statement: ls /tmp/dev/dsk and a'lot of c10* files are displayed. I finally "fscked" one and mounted it on /a. But the shadow file located in etc is not displaying the users with the encrypted passwords, instead it only shows a path which is "../var/run/sys_logd" or something.

Any ideas? Any help will be fully appreciated :smiley:

Are you sure /dev/dsk/c0t0d0s0 is the disk/slice your root filesystem is on?

1 Like

hello fpmurphy, first of all, thanks for replying.

I'm not sure if /dev/dsk/c0t0d0s0 is the slice in which my root file system resides. How can I find the slice in which my file system resides in?

Any ideas or comments? :slight_smile:

Hi,
Follow the procedure to " Delete and Reset a Lost Root Password" --

1) Insert the Solaris[TM] 2.x Operating System CD-ROM into the
CD-ROM drive. For the Solaris 8 Operating System (Solaris 8 OS),
this CD-ROM is disk 1 of 2.

2) Once the CD-ROM is in the drive, perform a stop-a. This brings
the system down to the "ok" prompt.

3) From the "ok" prompt, perform a single-user boot from the Solaris OS CD-ROM.

ok boot cdrom -s

4) At the "#" prompt, determine which disk is the system's boot
disk (containing the root file system). There are several Sun
architectures and various configurations of systems when it
concerns a boot disk. As a general rule, most boot disks are
attached to controller 0 (c0). Usually, their SCSI target is
either 3 (t3) or 0 (t0). However, Sun machines are very flexible,
and the boot disk could be at a different location. If
you are not sure which disk is your boot disk, perform the
following steps to determine the location of the boot device:

a) # eeprom boot-device

The output might appear to be simple, such as "disk" or "disk1" or more complicated, such as a pathname

  "/iommu/sbus/espdma@4,8400000/...../sd@3,0:a".  

b) Make note of the boot-device. If the boot-device is a pathname, it is beyond the scope of this information to provide the location of the customized boot disk. However, for most configurations, finding the customized boot disk is an easy task. The "Format" command shows all available disks:

  \# format
  Searching for disks...done
  AVAILABLE DISK SELECTIONS:
          0. c0t0d0 <ST34321A cyl 8892 alt 2 hd 15 sec 63>
             /pci@1f,0/pci@1,1/ide@3/dad@0,0
  Specify disk \(enter its number\):                  

c) Enter <cntrl>d to exit format.

Now, you will have an idea what disks are on the system. Therefore, if the boot-device is "disk" and format shows "c0t0d0" (on some systems "c0t3d0") then that is the boot device. If boot-device shows "disk1" and format shows "c0t1d0," then that is the boot device. If format shows multiple disks, then based on what the "eeprom boot-device" command shows, the system's boot disk would be:

boot-device format

disk c0t0d0 or c0t3d0 (machine dependent)

disk1 c0t1d0

disk2 c0t2d0

disk3 c0t3d0 or c0t0d0 (machine dependent)

and so on ....

5) Because the system was not brought down gracefully (no root password means having to use the Stop-a keystroke to "crash" the system), you need to run "fsck" to clean the root partition (slice). The fsck also confirms that you selected the proper slice.

# fsck /dev/rdsk/cXtYd0s0

where the X and Y are determined by the previous procedure.

It is also possible to have a root partition which is not on slice 0 (s0), but, again, that is not a standard configuration.

The output of "fsck" looks like this:

** /dev/rdsk/c0t0d0s0
** last mounted on /
** Phase 1 .....
.....                  

The second line in the output of "fsck" ("** Last mounted on /")
confirms that this is the correct root filesystem partition. Answer "y" to any questions fsck asks. There shouldn't be too many items needing repair. If there are, there is a possibility of a corrupted root filesystem. After fsck is finished, mount the root partition:

# mount /dev/dsk/cXtYd0s0 /a

Again, X and Y are the same as for the fsck command.

For example:

# mount /dev/dsk/c0t0d0s0 /a

6) From the root prompt, set the proper TERM type command
(such as vt100, dtterm, sun, and so on) by entering this command:

# TERM=sun; export TERM

7) Use the VI text editor to edit the /etc/shadow file:

# vi /a/etc/shadow

1 Like

hello sunadmin, thanks for replying.

I executed the format command, and displayed the following:

eeprom boot-device displayed the next info:

eeprom information matches with the first disk1 showed by the format command, so this means that my file system resides on disk1.

I did a fsck on /dev/rdsk/c1t0d0s0 and mounted in on /a:

I also set my TERM variable to sun and exported it:

I opened the /a/etc/shadow file but it is not displaying any information about passwords. It displays the following:

Any suggestions? :slight_smile:

Your /etc/shadow file got corrupted. Do you have backups?

1 Like

First check that the passwd and shadow files look like files:

ls -lad /a/etc/passwd
ls -lad /a/etc/shadow

Just in case vi is misbehaving, just check whether the file is readable:

head -1 /a/etc/shadow

Just in case this is a Sunos without /etc/shadow, please look at the first line of /a/etc/passwd:

head -1 /a/etc/passwd

If the field after root: contains several random characters, that's the password to remove. Do save a copy of the passwd file first.

1 Like

Thanks everyone for replying, I finally solved mi issue doing the following:

1.As my shadow file was corrupted by someway, I had to stop my O.S. from booting.

  1. Boot from disk:
  1. Executed the pwconv command, so a new shadow file could be created and also synchronized with my passwd file.
  1. Changed root password
  1. Had a booze and felt "Like a Boss" Meme

Thanks everyone :slight_smile: I appreciate your help very much

Thanks for the update. Glad you were able to solve your problem.