Recovering from dead NVRAM on a sun4m

These instructions are here as a memory aid for me, and are used to recover from a dead NVRAM in a sun4m system (tested on Sun SPARCstation 4/5/10/20, and SPARCclassic). First, pick numbers XX, YY, and ZZ, each of which are valid two-digit hex values, and where the MAC address 8:0:20:XX:YY:ZZ is unique on your network.

Any line with a leading # should be treated as a comment and NOT TYPED. At the OpenBoot PROM prompt, enter:

set-defaults
setenv diag-switch? false
# Next command optional and tells system not to test all
# memory every reset. It may be the default on your system.
setenv selftest-#megs 1
# Next command invalidates NVRAM checksum
# so following mkpl command works
f idprom@ 1 xor f mkp
8 0 20 XX YY ZZ XXYYZZ mkpl
# After hitting enter on previous command, there is no prompt.
# Now type Ctrl-D Ctrl-R, and 'ok' prompt should appear.

Now you can reset the system (without disconnecting power!) and it will come up with the MAC address 8:0:20:XX:YY:ZZ.

Note: I couldn't find a clean way to set the NVRAM clock from the OBP prompt, meaning that on first boot, your OS will have a wacky time set.

Ancient Sun Hardware FAQ

Many years ago, I mirrored the Sun Hardware FAQ at what was then my work website. I'd forgotten about this until recently, when a Google search I did returned this mirrored copy near the top of the list. Since it's unlikely they'll keep such an old site on-line forever, I've created an additional quick 'n' dirty mirror over at my current site.

For reference, the sections of the FAQ are:

• Overview, CPU/CHASSIS
• FAQ
• Boards
• Boards (continued)
• Disks, keyboards, mice, monitors, floppy drives, tape drives
• Appendices
• Appendices (continued)

Oracle and ZFS shenanigans

With the latest Solaris 10 release or recommended patch cluster, there are significant updates provided for ZFS. By patching or reinstalling with Solaris 10 9/10, you can get close to the zpool version which was previously only available by using Solaris Express Community Edition, now Solaris 11 Express.

But there is a potential catch. Each incremental feature change to zpool capabilities causes the zpool version number to be incremented. You can see what versions are supported on your local install by typing:

zpool upgrade -v

which lists all available features on the current driver, along with their version number. After applying the most recent Solaris 10 patch cluster, you'll see the following:

cara:~> zpool upgrade -v

This system is currently running ZFS pool version 22.

The following versions are supported:

VER DESCRIPTION

--- --------------------------------------------------------

1 Initial ZFS version

2 Ditto blocks (replicated metadata)

3 Hot spares and double parity RAID-Z

4 zpool history

5 Compression using the gzip algorithm

6 bootfs pool property

7 Separate intent log devices

8 Delegated administration

9 refquota and refreservation properties

10 Cache devices

11 Improved scrub performance

12 Snapshot properties

13 snapused property

14 passthrough-x aclinherit

15 user/group space accounting

16 stmf property support

17 Triple-parity RAID-Z

18 Snapshot user holds

19 Log device removal

20 Compression using zle (zero-length encoding)

21 Reserved

22 Received properties

Note that version 21 is 'Reserved'. If you run the same command on a system running the Express kernel, version 21 shows as:

21 Deduplication

22 Received properties

23 Slim ZIL

The whole point of zpool versioning is that a pool with a given version number should be mountable on any system running ZFS where the kernel supports at least that version of the pool. Sun went to great lengths to enable this, even specifying that ZFS was endian-independent, where all writes would be done with the local byte order, but reads would be honored in either big or little endian order. You can move a pool from a SPARC to an x86 platform, and it works.

This was going to be a blog post about the evils of Oracle Corporation breaking this compatibility. Version 21 is deduplication on the Express version, but reserved on the release version. I was going to rant about the dangers of creating a filesystem utilizing deduplication using Solaris Express, then trying to import it into a release version of Solaris 10.

But I can't quite do that.

After performing an experiment, it seems that Solaris 10 can in fact correctly mount pools created on Express which have deduplication enabled. However, 10 won't continue to dedup newly written data, since that's not a supported feature. This at least makes sense as a compromise. Compatibility is preserved across pool versions, to the extent that you won't see any nasty side effects like kernel panics if you accidentally mount a deduped filesystem on a release version of Solaris 10. You won't get any further benefit from this unsupported feature, but it shouldn't kill you either.

So my only question is this: is the dedup feature left out of these updates because Oracle wants to provide a compelling reason to move to Solaris 11 (which may also feature significantly different license terms)? Or are they leaving it out because there's a concern about bugs which impact integrity, availability, or both in the current version of the software?

Time will tell.