These are notes on a system I made a couple of months ago but never got around polishing up, but finally kicked it out

At time of writing the Sun Fire v210, a entry-level UltraSPARC IIIi server from around 2003 was already dated, nonetheless I was able to get my hands on such a machine including another Sun box,  T1000. I just wanted to get my hands dirty on some non-x86 machines so that's what I got myself pretty cheaply (being 1U they don't take up too much space). Unfortunately I had to learn the hard way that some older Sun machines can be locked down pretty much so well that you can't unbreak them without more advanced hackery that I currently am able off / want to invest my time -- or with the help of similar/identical unlocked hardware.

The situation the box came to me:

• The onboard system controller ALOM (service/management processor) started correctly but its password was unknown to me.
• OpenBoot PROM (OBP) had both 'security-mode=on' and an active 'security-password', with the following result: Booting from anything else than the default (auto-boot set to the SCSI disk) required entering a "Firmware password" unknown as well. This exluded booting from the network or an optical drive. (for x86 folks like me: OpenBoot is roughly the equivalent to BIOS/UEFI but with some/lots more functionality)
• With the disk inserted the box came up with a Solaris 9 that still seemed booting healthy, yet again: I didn't have the a root password.
• The machine came without a CD or DVD drive...

If you are in this situation lots of posts I found mentioned that you may require another Sun machine with a disk and a known root password that you can yank in and boot the locked system off to fix the issues. I didn't have that luck (the T1000 is SAS based, the v210 U160 SCSI). Also: Mounting a UFS partition from a SPARC system on x86 may to fail because of different endianness. If it had been ZFS, well things would have been easier since it actually handles this for you. Also without any bootable Solarish' OS I currently believe that you are out of luck with such a machine.

I'd also say that access to OpenBoot is the first key in order to get back into a more sane situation, ALOM is useful too but without OpenBoot you're out. It is the key piece that enables you to boot the box from whatever source OpenBoot can boot from.

What didn't work:

• In contrast to x86 systems where you can most often short some jumpers or remove CMOS batteries most values in OpenBoot are stored in persistent storage areas, only the system clock is buffered by a CR2032 battery.
• Modifying OpenBoot with enabled security-mode requires either knowing the firmware password or a bootable Solaris OS with access to command named eeprom(1M)
• Without access to OpenBoot itself no jumper will reset the ALOM config like mentioned for the Sun Fire V100: On the V210 the equivalent jumper only reboots ALOM and that's about it.
• Without the ALOM's password the sole way to modify its config is via the Solaris or illumos-only scadm(1M) command. A bootable OS is required for that. Unlike on the T1000: Hitting the ESC key in early start process of the ALOM startup doesn't offer you the option to reset it to default settings and forget the passwords.

The magical System Configuration Card

While most LOM (LAN on motherboard) on x86 systems have their MAC-adresses burned in, on those Sun machines the MAC address is stored on a Smartcard called "System Configuration Card" (SCC) inserted at the front of the server. I came to learn that a box without this particular card would be pretty much useless as you can't use the onboard NICs it. Also lots of other values of OpenBoot are stored on the SCC, including the (bloody!) firmware password.

At this place : Thanks to helpful explanation about the SCC's functionality from a very kind local UNIX and Solaris consultant (Who said to me ~ "It's my job I should know how to fix that."). Thanks to him I tried powering up the system without any disk drives and the SCC pulled. OBP greeted me with errors on missing IDprom but went straight to a standard 'ok' prompt, now I had something to work with...

How i unbricked my particular machine:

• The SCC card had to be removed (the box was powered off - it is NOT hot-pluggable)
• Next a IDE CD-ROM was connected to the onboard IDE port (thanks to my dad who keept a nice stock of old computer parts)
• With the hard disks pulled I powered the server on and let it boot to OBP, ending up some errors about the IDprom missing but a plain 'ok' prompt
• Insert the disk with the OS and issue 'probe-scsi': The SCSI disk in question was recognized by OBP, ok.
• Issue 'probe-ide' shows that the IDE CD-ROM was recognized (I realized a DVD writer didn't work, thatis why I used the CD-ROM drive)
• Inserted a Solaris 8 CD (9 or 10 should work too, not 11 with the removal of sun4u support) and hit 'boot cdrom -s' (boot cdrom launches the installer, -s goes into single user mode)
• The first attempt without SCC always failed with card not inserted (missing IDprom...) but repeating it boots Solaris from the CD.
• After some waiting a Solaris shell was ready

Without the SCC inserted, there was not network, nonetheless, things got more interesting from there

# List disks and get its name with
format

# Create temporary folder as mount point 
mkdir /mnt/recovery

# Mount the local SCSI disk and switch to its /etc
mount /dev/dsk/c1t0d0s0 /tmp/recover
cd /tmp/recover/etc

Now being in a chroot environment as root allowed me to modify /etc/passwd. Due to the fact that both sed and vi were different on Solaris 8 from what I knew from Linux and the BSDs I opted to make copy of /etc/passwd and /etc/shadow and use sed (there is no -i as in GNU sed) to replace the hash of the root password by nothing. (Source about /etc/passwd)

This resulted in an OS with a an empty root password. Time to exit the chroot environment and shut down the OS booted from the CD. Next I could insert the SCC back since that was the thing blocking the access to the rest of the system. As expected the OS was "kind enough" to accept an empty password for the root user the next time it booted from the hard disk.

Unfortunately I didn't keep notes from that stage but from manpage it says the eeprom binary is platform-specific and located in a platform-specific folder, but anyway:

• 'eeprom' showed that the 'security-mode' was set to 'command'
• 'eeprom security-mode=none' means the system should stop asking for a firmware password
• 'scadm' can also then be used to re-set the ALOM password as well
• Once done, reboot the OS and voilà: OBP is unlocked ! Additionnaly ALOM for remote management was now accessible too.

Was it economical? Nope, but it was a fun brain-twisting experience.

2016.02: Fix specs, the Sun Fire v210 and v240 only have U160 SCSI controllers, not U320 as I initially wrote.