Introduction
I gave away another Sun Ultra 10 today.
As I invariably get questions about Solaris, Sun systems in general, etc, I figure I’ll document some things about caring and feeding for a Sun system.
My experience with Sun systems is somewhat dated – I’ve started with Sun 3 (3/260), and progressed through Sun4, sun4c, sun4m, sun4d (SS1000), onwards to sun4u architecture. However “biggest” sun4u box I’ve played with would be an Enterprise 6500, and biggest I own is an E4K. Thus asking me about domains on an E10K or bigger/newer would not get one far. As I’ve been out of of the workforce and in school for the last 3 years, my knowledge of Solaris 8 is very solid, and I can get by in Solaris 9, but know next to nothing about Solaris 10 changes – Containers, iSCSI, NFSv4, clusters, and other shiny new things that Sun introduced.
But basics are basics, and most of this is either OS independent, or can be transfered over to current versions of Solaris.
So keeping Ultra 5/10 in mind….
Ultra 5/10 hardware
Why am I calling it a 5/10? Because Ultra 5 and Ultra 10 share the same motherboard. Ultra 5 was coming in a pizza case, while Ultra 10 is a mini tower.
Modern Sun systems are very similar to PCs. Ultra 5/10 was one of the first mainstream Sun systems to support IDE (there were others at around the same time – SPARCengine2 comes to mind for some reason). So talking about IDE….
Both Ultra 5 and 10 were designed to operate with a smart card reader. Personally I’ve never seen one with a card reader installed (Maybe University of Ottawa has some), so all U5s and U10s I’ve encountered have a small “trap-door” in the front, with nothing behind it. On a U5 (which is small, crampled, and not very upgradable), you can install a second internal IDE hard drive in the space designed for the smart card. I had to do that once for an outfit called ResponseLogic around 2000, and from what I remember, it was doable, however you might need longer IDE cables to replace the ones system ships with (or maybe ones that have 3 IDE headers, instead of just 2), and only two screwholes would match the hard drive. Solution to that is either a dremel tool and drill to make the necessary holes, or just general contentment with being able to install a second hard drive. 🙂 Inside U10 there is space to mount additional hard drive, so space is less of a concern.
IDE bus on a U5/10 is seriously broken from performance point of view. I remember benchmarking an Ultra 2 with a 300 MHz UltraSPARC II CPU, and U10 with 440Mhz UltraSPARC IIi (?) CPU and a Symbios UW SCSI controller, both driving a multipack of 36 gig SCSI drives in software RAID under Solaris 8. Both had half a gig of RAM. U2 would generally perform ~10% better in IO operations, because U10 was booting from IDE, and IDE interrupts were killing the system performance.
With that in mind, if you have a SCSI drive and a PCI SCSI controller with FCode (that U10 can boot off of), it would make sense to convert the system to a whole SCSI system. Follow this link for good instructions. Plextor SCSI CD-Rom drives and burners are cheap used, and make really good CD-Rom drives in Sun systems in general.
IDE bus in U5/10 doesn’t support addresses wider then 40 bit. In practice that means that IDE hard drives larger then about 128 gig would not be recognized as such. I’ve never tried to put such a large hard drive into a U10, but I’d speculate that one can’t access the space beyond the 40 bit boundry, but otherwise drive works.
Sun systems are using OpenBoot (or Open Firmware) firmware for BIOS.
Primary language of OpenFirmware is Forth, which is of the same family as Common Lisp, Scheme, etc.
Some people are obsessed with Forth, and write crypto or play Tower of Hanoi using it.
OpenBoot used to be on track to become IEEE 1275 standard, but AFAIK standard wasn’t re-affirmed by the Open Firmware Working Group (politics, I guess), lapsed, and now a days Sun, Apple, IBM and whoever are just doing their own thing. Wikipedia has more, so I’ll just throw a bunch of links at the curious:
OpenFirmware Working Group site
OpenFirmware Working Group site (mirror, sometimes more up to date then the main site)
FirmWorks generic Open Firmware Quick Reference
Sun OpenBoot Collection – Contains reference books for OpenFirmware 2.x (Book P/N 806-2907) , 3.x (P/N 806-1377) and 4.x (P/N 816-1177) and Writing FCode (P/N 806-1379))
The following are Apple’s Technotes on Fundamentals of OpenFirmware (There are many Apple specific bits on OpenFirmware (such as setting up kernel debugging over ethernet) at the above link):
TN1061: Part I: User Interface
TN1062: Part II: The Device Tree
TN1044: Part III: PCI Rom Expansion Choices for Mac OS
More Apple specific bits on OpenFirmware (such as setting up kernel debugging over ethernet) at the above link
Eclectic List of OpenFirmware commands
After playing with OpenBoot on Sun workstations/servers, on modern PPC Apple systems, and NetApp filer (F760, at least, had firmware writting for NetApp by FirmWorks), I can say that Sun’s implementation is the nicest, not the least because it includes on line help.
Nothing substitutes reading docs above, and while OpenFirmware is the “same” each vendor defines their own commands, etc. Some commands that return pretty pictures on a Sun (banner for example) return nothing on a mac.
There are a bunch of hidden settings that can sometimes be found by typing words at OpenBoot Prompt. words just dumps all the known words – ie commands that were defined.
Here are a couple of suggestions for investigation at the OK prompt:
probe-ide and probe-scsi-all – Will list IDE and SCSI devices (will return nothing or an error if you don’t have IDE or SCSI, or the words are undefined
.speed – returns the speed of the processor(s). eg (on an a dual CPU 300Mhz Ultra II, {1} prompt refers to second CPU)
{1} ok .speed
CPU Speed : 296.00 MHz
UPA Speed : 098.66 MHz
SBus Speed : 025.00 MHz
{1} ok
test-all – test all hardware that has diagnostics. Might take a while. Can be used in conjunction with setenv diag-switch? true to troubleshoot hardware. Hardware or trouble might or might not shoot back.
show-devs to list avialble devices (another option might be cd / followed by ls to look at device tree natively. If you end up cd’ing to a device in a device tree, you can try .properties if it’s listed by ls, to see what words that particular device recognizes. *shrug*. Sun has an example of use
printenv to look at all the variable settings
setenv foo bar – to set environment variable foo to bar.
Most common settings that I use for debugging are:
setenv diag-switch? true setenv auto-boot? false
This enables firmware diagnostics output on a Sun, and in conjunction with serial console logs lots and lots of interesting information about the state of hardware. Note that on big iron, such as E4K coming from cold to warm state, full diag might take
a good chunk of an hour (5×400 MHz CPUs, 6.5 gigs of RAM in my E4K takes ~15 minutes to test. This is when you start playing with setenv diag-level min (or max) to balance between more hardware tests taking longer, or minimal hardware tests taking less time). auto-boot? variable tells the system if it should try to boot OS right away, or drop to OpenFirmware after power-on, and wait for boot command.
Undoing the damage above is done thusly:
setenv diag-switch? false setenv auto-boot? true reset
and you probably want to do the above before removing that serial cable from console, and rebooting the system unattended.
Note: boot command can take arguments that get passed to the kernel. Most common Solaris ones are:
-v Verbose boot – Kernel tells you what it does.
-r Reconfguration boot – Kernel instructs drivers to look for new devices added/removed since last boot and a bunch of scripts gets triggered on boot-up to re-populate the device tree. I’ll refere you to /etc/init.d/drvconfig and /etc/init.d/devalias on a Solaris system for more info. Oh, and drvconfig has a man page.
-s Boot into single user mode
-a Ask. When you really really screwed up your system by editing /etc/path_to_inst, /etc/system, etc, BUT made a backup before hand. If you are lucky, you might be able to get system back to bootable state at this point, and undo whatever you did. However, if you need to use -a option, you might be better off booting off CD into single user, mounting drive, and undoing the damage that way.
Folks are Princeton have some notes on troubleshooting Solaris boot sequence.
Oh, and from inside Solaris there is access to the nvram variables using eeprom utility (eeprom variable setting), and you can trigger reconfiguration boot by touch /reconfigure followed by init 6 or reboot
OpenBoot Firmware Updates
I guess I should mention that firmware on Sun systems is flashable.
If you have Solaris installed, you should consider updating the firmware to the latest version, by going to Sunsolve, and in patchfinder, finding the right patch for your system.
Patch generally includes install.info file, that documents that installation procedure, and README file, that documents the list of bugs that got fixed by the patch. OBP patches generally require one to reboot, and boot from a particular file included in the patch.
Prior to doing this, one might be requires to open the system up, and move a jumper on the motherboard from write-protect into write-enable state.
Locations of the jumpers, etc can be looked up either in the print version of Sun Field Engineer Handbook, or at Sun Systems Handbook online
Here are some systems, and their corresponding patchIDs for OpenBoot updates (Search term is “Standalone Flash PROM Update”)
Ultra 1 (not Enterprise, 10bt) – patch# 104881
Ultra 1E (Enterprise, 100bt) – patch# 104288
Ultra 2 – patch# 104169
Ultra 5/Ultra 10 – patch# 106121
Ultra 60 / E220 – patch# 106455
Ultra 80 /E420R – patch # 109082
Ultra 450/E450 – patch # 106122
E250 – patch # 106503
E3x00, E4x00, E6x00 – patch# 103346
Breaking your Sun box, at OBP
And, to close off this section…. two quick “hacks”
Changing the MAC/hostid of your Sun box for fun and profit.
If for some reason you need to change the hostid or MAC of your Sun system, please refer to the great Sun NVRAM/hostid FAQ by Mark Henderson. I don’t want to fall into trap of discussing why you’d want to do it, but if your OBP has mkp command (ie AFAIK anything older then a SunBlade should work, and I’ve tested this on SS10, SS20, U1, U2, U10, U60, E4K myself)….
01 0 mkp 80 1 mkp < = System type. For sun4u arch 80. For sun4m arch - 72. Anything else - read the FAQ 08 2 mkp <= Sun AUI is is always 08:00:20, which are the next three settings for MAC 0 3 mkp 20 4 mkp c0 5 mkp <= c0:ff:ee to generate 08:00:20:c0:ff:ee as MAC ff 6 mkp ee 7 mkp 0 8 mkp 0 9 mkp 0 a mkp 0 b mkp c0 c mkp ff d mkp ee e mkp 0 f 0 do i idprom@ xor loop f mkp <= Calculates the checksum of what you did, and stores it
The above should generate a hostid of 80c0ffee and MAC of 08:00:20:c0:ff:ee.
Oh, and if you have a dead battery in your NVRAM chip, and system comes up with corrupt settings error on bootup, and refuses to boot, this will at least get it bootable.... until you yank the power and NVRAM loses settings again. It helped me a couple of times, while I were waiting for a new clockchip to arrive.
Note: for sum4m and sun4d arch, if the above doesn't work, there is a second way (c!) to do it, documented in FAQ.
Note to self: if playing with multi-board big iron, might need to follow up with copy-clock-tod-to-io-boards to synchronise NVRAM contents between the clock board (that you just edited) and I/O boards that still have old data. Reverse (if replaced the clock board, and are pushing settings from I/O board boardnum to clock, boardnum copy-io-board-tod-to-clock-tod. tod is, of course, Time Of Day 😛
Kind folks at PCI Alternatives mention that there is a way to overclock US-II chips at least from OBP. Their example is U5/10, and I've never done this myself, but....
also hidden nnn at-speed with nnn will change the clockspeed to nnn
.speed to verify, of course
Sun SPARCengine CP1500-440 Thermal Considerations (page 6) states that d# must be in front of the CPU speed, however as this is an undocumented setting, YMMV. Sun's documentation also has instructions on saving the command to nvram to be executed at each boot-up.
ok setenv auto-boot? false ok reset ok also hidden ok d# 297 at-speed ok .speed
PCI Alternatives folks claim that 270Mhz U10 can be pushed to 297Mhz (+10%), and 333Mhz U10 can be pushed to 370Mhz (+11%).
Can 440Mhz be pushed up to 480? I’ll test it some time, and follow up, I guess.
“Safe” approach for something like this would be to run this without saving in NVRAM starting at +10% clock speed, and run SunVTS on a system to check if it’s stable. If it is, either increase the speed by another couple of ticks, and run SunVTS again, or just be happy, and save it in NVRAM.
Oh, and as a bonus to the patient reader….
Entering obdiag, extended diagnostic mode present in U5/10 and newer is performed by setting the following environment variables:
ok setenv diag-switch? true diag-switch? = true ok setenv auto-boot? false auto-boot? = false ok setenv mfg-mode on mfg-mode = on ok reset-all [system resets at this point] ok obdiag
obdiag should return a bunch of loading messages followed by:
OBDiag Menu
0 ..... PCI/Cheerio
1 ..... EBUS DMA/TCR Registers
2 ..... Ethernet
3 ..... Keyboard
4 ..... Mouse
5 ..... Floppy
6 ..... Parallel Port
7 ..... Serial Port A
8 ..... Serial Port B
9 ..... NVRAM
10 ..... Audio
11 ..... EIDE
12 ..... Video
13 ..... All Above
14 ..... Quit
15 ..... Display this Menu
16 ..... Toggle script-debug
17 ..... Enable External Loopback Tests
18 ..... Disable External Loopback Tests
Enter (0-13 tests, 14 -Quit, 15 -Menu) ===>
14 bails one out (setenv mfg-mode off might be a good idea at that point). 16 enables verbose mode. 13 tests everything.
For more information, refer to Sun Ultra 5 Service Manual (P/N 805-7763) Section 4: Troubleshooting procedures (Page 4-12 in rev 12 of the above manual, page 84 of the PDF)
Expantion options
I’ve had great luck with Symbios made PCI scsi controllers based around NCR chipset. In one case a PCI controller (not Sun branded and without OBP FCode in the PROM) was not recognized by the OBP in an Ultra 60, however was recognized by Solaris 8 once OS booted. Turned out that updating OBP to the latest version made OBP to recognize SCSI controller.
According to http://pci.unsupported.info/, the NCR53c875 chipsets are generally recognized by the OBP and NCR53c810 is recognized by the glm driver in Solaris. Their experience is with Compaq branded cards.
Now that Solaris source code is freely available, and driver developement kit is available, it should be reasonably simple to port any Intel drivers from Solaris Intel to Solaris SPARC. I toyed with this in Solaris 7 (when Sun first released a stripped down version of the source code to great unwashed under a general NDA), but it probably is even easier now.
Note that if the PCI card doesn’t have it’s own FCode in ROM, and is not amongst the devices supported by the OBP out of the box (built-in drivers), you won’t be able to use them before system boots and driver loads. This means no netbooting on cheap network controllers, or no booting from cheap SCSI controller. Or, I guess, no video on that Matrox or ATI video card before Solaris loads and X starts.
Installing Solaris
Oldest version of Solaris that would install on an Ultra 5/10 is 2.6 HW 3/98. Newest is what ever is current as of this writing. Personally, I’d recommend 8 for now, as it’s solid, still supported and well understood (at least by me), although that depends on the purpose – it one wants to learn the latest and greatest, of course Solaris 10 is the way to go. If one wants to be nostalgic, Solaris 2.6 was a very solid release.
Latest version of Solaris is downloadable from Sun. In addition, Solaris Express which is arguably more “bleeding-edge”, is also downloadable. Lastly there exists Solaris Express: Community Release. Confused yet? Solaris Express is the basis for Solaris 11, and Community Release is as bleeding edge as it gets. Older versions of Solaris used to be downloadable, but are no-longer. If you don’t have a friend with a CD (or CD image), your Solaris choices might be limited.
Depending on the version of Solaris you run, and the disk type you use, you might run into problems with the disk size and size of the root partition. Solaris 2.6 and 7 SPARC on IDE devices has some interesting features, that prevent it from booting or even accessing the disk. Certain versions of Solaris (2.6 SPARC on Tadpole SPARCbook comes to mind) had issues with IDE disks being larger then 8 gigs. Certain versionf of Solaris (7 SPARC comes to mind) had issues with root partition on IDE disk being set too large. Thus root partition on an IDE disk should probably be less then 2 gigs just to be on a safe side. Please refer to questions 5.63 and 5.64 of the Solaris FAQ for more information.
Normally with Solaris 8 I don’t bother with the graphical “Web Start” installation method. Booting from the 2nd CD (the ones that is labeled as 1 of 2, not WebStart) I would get dropped into the old style installation process.
Partitioning
The following is by no means exhaustive or “correct”, but will arguably cause you less grief then the auto-layout that Sun recommends.
Sun partitioning supports “slices”, which used to refer to partitions on SCSI drives. While SCSI drives support up to 8 partitions, IDE drives physically support only 4 partitions, so on IDE drives Solaris writes to a single physical partition, and then inside it creates 8 logical ones (even if you don’t use a slice, doesn’t mean it’s not there). But this is all boring hardware stuff that OS abstracts away any way, and chances are that the only time you’ll encounter this is if you are trying to multi-boot a Sun box between Solaris and Linux, or install Solaris on an x86 box. But this is not a paragraph about multi-booting, but a paragraph about partitioning, so….
The following partitioning works for me (format output of a 9 gig SCA drive)
partition> p Current partition table (original): Total disk cylinders available: 4924 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 root wm 0 - 584 1.00GB (585/0/0) 2100735 1 swap wu 585 - 1169 1.00GB (585/0/0) 2100735 2 backup wm 0 - 4923 8.43GB (4924/0/0) 17682084 3 unassigned wm 1170 - 1171 3.51MB (2/0/0) 7182 4 usr wm 1172 - 1756 1.00GB (585/0/0) 2100735 5 unassigned wm 0 0 (0/0/0) 0 6 unassigned wm 0 0 (0/0/0) 0 7 unassigned wm 1757 - 4923 5.42GB (3167/0/0) 11372697 partition>
slice 0 – root partition. Mounts as /, and I usually go for between 1 and 2 gigs in size.
slice 1 – swap partition. Rule of thumb is 2x RAM in a system, although this is flexible, and if the system has gigs and gigs of RAM, maybe 1xRAM + 200 megs is good enough. Rationale is that in event that you end up with a kernel panic, or force a system dump at the OBP, swap is where the dump gets written to. swap is also used by the system as it boots up before it recovers the dump, and writes it to file. Yes, in theory there is compression of the dump as it’s written. But if your system died, and nothing is going right, do you think that compression will be effective?
slice 2 – whole disk. Used by things like fsck, format, mount, etc to address entire drive, and is never accessed directly by a user. Well, by a user that doesn’t know what he’s doing. Sun sets slice 2 up by default, so just leave it alone.
slice 3 – unmounted, unformatted partition of 5 – 10 megs in size, used to store the metadb replicas. What are metadb replicas, I hear you ask. metadb replicas are small databases of metadevice information, used by software raid, mirror, etc tools that used to be called Solstice DiskSuite and are part of the OS as of Solaris 8. Even if you think that you’ll not use disksuite, do create the slice, as it’s a small investment into disk space, and saves you lots and lots of hairpulling later. Each replica is ~2 megs in size, so 5 megs is a good number, as you’ll want a couple of databases per disk.
slice 4 – usr. Sun mounts if as /usr, and that’s fine. Under Solaris 2.6 – 8, one gig might be enough, but 2 gigs is probably better if you have the disk space, just to be on the safe side.
slice 5 and slice 6 – You can create a slice holding /var here. In fact, I do recommend either creating a /var slice, or running dumpadm, and changing the default savecore directory into which kernel crash dump gets placed from /var to /opt (or wherever you have lots of disk space).
root@llewella:/usr/exim[02:09pm]# dumpadm
Dump content: kernel pages
Dump device: /dev/md/dsk/d20 (swap)
Savecore directory: /var/crash/llewella
Savecore enabled: yes
root@llewella:/usr/exim[02:10pm]#
dumpadm has a man page.
slice 7 – This is the rest of the disk that you still haven’t fully allocated. I mount it in /opt, symlink /home to /opt/home, and kill automounter (that tries to automount /home by default).
/opt is where things live in my world:
root@llewella:/opt[02:14pm]# ls SUNWapcy bind gpg ncftp SUNWconn db-4.2.52.2 home ncftp-3.1.3 SUNWits exim ipf patchdiag-1.0.4 SUNWppro fetchmail lost+found perl SUNWsdb gcc lsof perl-5.8.4 apache gcc-2.95.3 maker soma archive gdb mc audioctl-1.1 gnu mp3 root@llewella:/opt[02:14pm]#
My world is not perfect, but it works 😛
Patches
For the longest time patching Suns was simple. Every once in a while (once a month was the norm where I worked), sysadmin would schedule downtime for reboot, etc, and a day or so before ftp over to sunsolve.sun.com/patchroot/clusters, grab the jumbo patch cluster from there that corresponds to the release of the OS he runs, and uncompress it. If sysadmin is worth his salt, and has time, he’d read the READMEs for each patch, and check for incompatibilities. If sysadmin was optimistic, he’d just run install_patch, and hope that Sun QAed the jumbo cluster properly (hint: Sun doesn’t QA jumbo clusters, only individual patches, so there are times when one patch breaks the other. Bad sysadmin. Bad!). This all worked until Solaris 9. By Solaris 10, patch clusters are no-longer there:
ncftp /patchroot/clusters > dir 9* -rw-r--r-- 1 130 14540 Mar 31 23:45 9_Recommended.README -rw-r--r-- 1 130 186986848 Mar 31 23:46 9_Recommended.zip -rw-r--r-- 1 130 17253 Sep 27 2005 9_SunAlert_Patch_Cluster.README -rw-r--r-- 1 130 168473046 Sep 27 2005 9_SunAlert_Patch_Cluster.zip -rw-r--r-- 1 130 13279 Mar 30 20:59 9_x86_Recommended.README -rw-r--r-- 1 130 116337317 Mar 30 20:59 9_x86_Recommended.zip -rw-r--r-- 1 130 15596 Oct 7 2005 9_x86_SunAlert_Patch_Cluster.README -rw-r--r-- 1 130 105728719 Oct 7 2005 9_x86_SunAlert_Patch_Cluster.zip ncftp /patchroot/clusters > dir 10* -rw-r--r-- 1 130 10594 Apr 3 22:51 10_Recommended.README -rw-r--r-- 1 130 9860 Oct 12 17:24 10_SunAlert_Patch_Cluster.README -rw-r--r-- 1 130 11426 Mar 31 23:53 10_x86_Recommended.README -rw-r--r-- 1 130 10110 Oct 14 19:51 10_x86_SunAlert_Patch_Cluster.README ncftp /patchroot/clusters >
So off one goes to http://sunsolve.sun.com/, logs in, accepts a long license agreement, and selects patch finder.
There used to be a patchdiag tool to analyze the patches on a current system versus what is the latest and greatest. patchdiag required one to download the latest patch cross-reference database, patchdiag.xref from Sun each time you’d want to run it (required in a sense that you’d want to compare against the latest patches, right?). Latest database is at http://patches.sun.com/reports/patchdiag.xref
Aternatives to patchdiag are Patch Check Advanced, vxpref, or patchfetch2 All use the patchdiag.xref file, some are pertier then others. I use patchdiag, but maybe I am a traditionalist.
Some of the patches patchdiag will report are “free”, while most are paid. So the solution is either to pay for a support contract, or sigh and be out of date.
So for Solaris 10 the way to stay up to date is to start by downloading the latest free jumbo cluster from patch finder, and using a paid SunUpdate service.
root@llewella:/opt/patchdiag-1.0.4[02:39pm]# ./patchdiag -l ====================================================================================== System Name: llewella.NotBSD.org SunOS Vers: 5.8 Arch: sparc Cross Reference File Date: Apr/05/06 PatchDiag Version: 1.0.4 ====================================================================================== Report Note: Recommended patches are considered the most important and highly recommended patches that avoid the most critical system, user, or security related bugs which have been reported and fixed to date. A patch not listed on the recommended list does not imply that it should not be used if needed. Some patches listed in this report may have certain platform specific or application specific dependencies and thus may not be applicable to your system. It is important to carefully review the README file of each patch to fully determine the applicability of any patch with your system. ====================================================================================== INSTALLED PATCHES Patch Installed Latest Synopsis ID Revision Revision ------ --------- -------- ------------------------------------------------------------ 108434 17 21 SunOS 5.8: 32-Bit Shared library patch for C++ 108435 17 21 SunOS 5.8: 64-Bit Shared library patch for C++ 108528 29 CURRENT SunOS 5.8: kernel update and Apache patch 108569 06 08 X11 6.4.1: platform support for new hardware 108605 22 37 SunOS 5.8: Creator 8 FFB Graphics Patch 108606 18 39 SunOS 5.8: M64 Graphics Patch 108652 83 97 X11 6.4.1: Xsun patch 108693 24 26 Solstice DiskSuite 4.2.1: Product patch 108714 05 08 CDE 1.4: libDtWidget patch 108723 01 CURRENT SunOS 5.8: /kernel/fs/lofs and /kernel/fs/sparcv9/lofs patch 108725 16 24 SunOS 5.8: st driver patch 108727 26 CURRENT Obsoleted by: 116959-05 SunOS 5.8: /kernel/fs/nfs and /kernel/fs/s 108773 12 23 SunOS 5.8: IIIM and X Input & Output Method patch 108806 18 20 SunOS 5.8: Sun Quad FastEthernet qfe driver 108808 42 44 SunOS 5.8: Manual Page updates for Solaris 8 108813 17 CURRENT Obsoleted by: 117000-05 SunOS 5.8: Sun Gigabit Ethernet 3.0 108820 01 03 SunOS 5.8: nss_compat.so.1 patch 108823 01 02 SunOS 5.8: compress/uncompress/zcat patch [...]
Oh my. I guess I’ve been slacking in patching.
One thought to “Care and feeding of a Sun Ultra 5/10”
Comments are closed.