Monthly Archives: April 2006

April 26th, 1986, Pripyat, USSR, 1:25:58 AM local time

I’ve had an opportunity to dinner with a nuclear scientist on Saturday. He works as one of the technical safety managers (or somesuch) for Atomic Energy of Canada Limited at Chalk River in Deep River, Ontario.

We ended up talking about reactor safety, and I’ve mentioned a curious paragraph from RMBK-1000 (Реактор Большой Мощности Канальный) design document (it has some pictures for English speakers).

The manual says (and I translate):

Энергоблоки с реакторами РБМК электрической мощностью 1000 МВт (РБМК-1000) находятся в эксплуатации на Ленинградской, Курской, Чернобыльской АЭС, Смоленской АЭС. Они зарекомендовали себя как надежные и безопасные установки с высокими технико-экономическими показателями. Если их специально не взрывать.

Energy blocks with RBMK reactors with energy capacity of 1000 MWt (RBMK-1000) are in use in Leningrad, Kursk, Chernobyl, Smolensk nuclear power plants. They demonstrated themselves are reliable and safe devices with high technologically-enonomical characteristics. If they are not made critical on purpose.

I’ve cited that paragraph, and asked what was the opinion of the esteemed scientist on the last sentence. He told me that what the manual says is basically true – he is familiar with design and operation of RMBK-1000, was in a control room of Kurst nuclear power plant, and indeed, if you don’t make one go critical on purpose, they are perfectly safe, if not as energy efficient as pressurized water types.

I were refered to a publication titled Chernobyl – A Canadian Perspective, by Dr. Victor Snell, Director of Safety and Licensing at AECL, on the exact reasons why Chernobyl happened.

Personally, I am not interested in laying blame. Who is there to blame? One of the theories is that the operators were poorly trained or that they bypassed safety mechanisms on purpose (either due to poor training or due to political pressures). Maybe, however after reading a book (rus) on what really happened by former deputy operating engineer A.S. Dyatlov, I am not so sure. Another theory was a design flaw. Could be. Was it on purpose? I doubt it.

Inventor of RBMK style reactors, and chief theme leader was a full member of Academy of Sciences of USSR Professor A. P. Allexandrov (rus). Chief Designer of RBMK was Nikolai Dollezhal.

Nuclear power should not be feared. Most of the time, fear is there from lack of understanding. It should be respected, and proper safety procedures built into it. Decisions like this should not be made by politicans (“Build it faster, who cares about safety, prestige of the nation is at stake”), Bible (or Quaran) Thumpers (“For the glory of $DEITY, we will power our homes, and charge up our nukes, and rain fire and brimstone from above on anyone who disagrees with us!”), or hillbillies with loud voices (“Not in my backyard”). They should be made by folks who actually know what they are doing, and care about things like safety, and

Personally, I fully realize that there are things I know nothing about. I can play a scientist on interweb (because anyone can be anyone on interweb, and if you sound reasonably competent, most of the time people will think that you are an authority), but I should not be in charge of a nuclear plant design (or should run a government, etc). However, there are folks out there who actually dedicated their lives to nuclear energy.

If Patrick Moore one of Greenpeace original founer now thinks that nuclear is the way to go, maybe he actually knows what he is talking about. If Stewart Brand, original publisher of “Whole Earth Cataloguethinks that folks should all read Rad Decision, maybe he is right.

So for a few moments, please remember all the folks who died while harnessing nuclear energy. Not only those who died from tyroid cancer in a Chernobyl aftermath, but Hiroshima and Nagasaki victims, even Marie Sadovski-Curie.

Some links to photos:

Special project of on 20th Annaversary of Chernobyl Nuclear Incident (with photos).

More photos of Chernobyl

Небо на Земле

Юрий Шевчук, солист DDT, с альбома Акустика
Jurij Shevchuk, lead singer of rock group DDT, in live solo acoustic concert. (Rest of album is here)

This song actually taxes my Engrish. I am looking at it, and scratching my head, as I have no idea even how to start translating it. I’ve fed this text to Babelfish, but systran choked on it too. I guess it does not only tax me….

Россия (Небо на Земле)
Rossija (Sky on Earth) (mp3)

Там, где тьма стоит до света,
Где небритые умы
В смысл неверья, от завета
Чтут наказы из тюрьмы.

На спине таскают время,
Да ссыпают на весы.
Чистят мраморное темя,
Кормят Спасские часы.

Днем кряхтят под образами,
Воют в небо по ночам.
Не в свои садятся сани,
А потом всё по врачам

Сколько буйных с плеч срубили,
Не пришили ни одну.
Тянут песнь как деды жили,
Сами мрачно да по дну.

Берегут до первой смерти,
Отпевают до второй.
Всех святых распяли черти
Бог – он видно выходной.

Все не в масть, да все досада,
Света тьма, а света нет
Завели хмыри в засаду
Да пытают столько лет.

Днем со свечками искали
Выход в мир, где все не так
Дырок много, все слыхали
А не выскачить никак.

Там где тьма стоит у света
Там где свет всегда у тьмы
От завета до Советов
Бродят странные умы

Волосатыми глазами
Шьют дела, куют детей
Запрягают летом сани
И похожи на людей

Эй прокашли вша живая
Спой негромко под луной
Как я на груди сарая,
Спал счастливый и хмельной.

Снились времена другие
Мир без дури и войны.
Девы стройные, нагие
Парни – трезвые умы.

Что принес благие вести
Пьяный ангел на крыле.
Все мы на перине с песней
Строим небо на земле

Update: Do read comments, as my sister beautifully translated this to English.

Spamcop lists gmail SMTP servers as spam servers

A while ago I ranted about automated spam filtering.

Here is yet another example of utter idiocy of some people.

Spamcop report for, aka currently states: listed in (

If there are no reports of ongoing objectionable email from this system it will be delisted automatically in approximately 2 hours.

Same thing for,,,,,, (all resolve to, and all are addresses in used to send email as listed by Ironport). I am sure rest of gmail is also reported as source of spam by SpamCop, I just can’t be arsed to keep on checking.

*sigh* Anyone needs any more convinient arguments for not using SpamCop? I am really really tempted to write a log parser that would automatically submit IP addresses of folks who use SpamCop back to SpamCop.

Oh, and at this point, when I talk about “utter idiocy of some people”, I am not even sure who I am refering to – SpamCop folks for listening to anyone reporting gmail (or hotmail, or yahoo mail, or any other “free” mail server) as source of spam instead of just whitelisting them, idiots who get a spam through a free gmail account, and report it to SpamCop as spam, or idiots who configure spamcop checks as default reject reason in their MTA.

Estonian Punk-Rock

One of the more musically advanced comrades introduced me to Estonian punk-rock today. Well, what passes for punk-rock in Estonia.

Vennaskond. People who are interested in what “anarchist resistance” sounds like in Estonian should click on “SISENE” on the index page to actually load the site, and then on “MP3″ to get to the list of mp3s.

I wonder if it would sound any better sped up 200%.

Off to chase these with Ramones’ “I don’t want to grow up

Once I’ve expressed my surprise at lack of drive in this particular sample of Estonian punk-rock, I were pointed at J.M.K.E.’s album “Sputniks PECTOPAH”, issued in 1995.

So, without any further ado, J.M.K.E. “Sputniks in PECTOPAH”.

Song links should work, they did for me.

Update: J.M.K.E. site. Sputniks in PECTOPAH.


Just in case I need to analyze kernel crash dumps under Solaris SPARC ever again, this is CTEact, the infamous act tool.

Dave doesn’t let me upload anything but the pictures and movies (heh!), so this will have to be renamed apropriately.
CTEact 7.17 SPARC, covers Solaris 2.5 through to 8
CTEact 8.2 SPARC, covers Solaris 2.8 through to 10.


Just some JTAG related randomness, considering that I’ve touched on it in previous post.

Linksys WRT54Gx

Linksys WRT54G and WRT54GS have JTAG headers on motherboard. It is possible to solder on the pins into the header on the motherboard, and build a Wiggler style cable to re-flash the bootloader, if you ended up hoseing it.

Personally I’ve done it on two WRT54GSes, and one of the main changes I’ve done was to set the boot_wait variable to on by default in the boot loader.

As Wiggler hooks up over parallel port, and thus is slow as sin, reflashing anything but the bootloader (ie flashing in actual firmware over JTAG) would take days.


CS6400 had an Sbus based JTAG interface for hardware tests. CS6400 was a Cray Research Superservers Inc.’s Cray Superserver 6400. If I remember correctly, it had up to 8 XDBuses, and up to 64 either 75 or 85Mhz SuperSPARC II mBus based CPUs (same ones that could be used in Sun SPARCstations 10s and SparcStation 20s).
These were rather elusive beasts, and while I used to own a SPARCserver 1000 (12.5 amp/hr space heater, that sounded like a jet taking off), and there was SPARCserver 2000 (rackfull of 3-phase joy) that I played with, I’ve never touched a CS6400.

In fact, I suspect that few people at Sun even knew what one was – there were some parts schematics and option lists printed in the paper versions of Sun Field Engineer Handbooks, but as CS6400 was a product that Sun inherited when Sun bought Cray Research Superservers/Floating Point Systems from SGI. Sun used the Cray technology to build shiny things like Enterprise xx00 (Campfire) and Enterprise 10000 (Starfire) product lines.

JTAG was the primary way of hardware diagnostics on E10K, and was connected to System Service Processor (SSP, commonly an Ultra 5)

P.S. Sun, why did you block off wast majority of useful FEH content to subscribers only? On, and Sun, will you sue me if I dig out an older version of FEH that you guys used to ship on a CD, and make it available on the interweb?

I distinctly remember using JTAG to recover something else in the past, however my memory fails me. Might have been Nokia cell phone, might have been some sort of uPCI x86 system.


In my previous post I’ve waxed lyrical about IEEE 1275 standard, also known as Open Firmware.

Comrades in the field pointed me towards OpenBIOS project, a GPL licensed implentation of Open Firmware. Currently, it seems like it is almost useful by mere mortals, as long as mere mortals have supported motherboard, and want to boot up Linux 2.2 or newer on it.

Sadly, average consumer doesn’t look for a “JTAG header” on a feature list, while shopping for a new motherboard, nor is he particularly interested in a socketed BIOS flash chip (which also would allow one to re-flash BIOS). Average users (those mythical beasts) also probably don’t have the experise on hand on how to use JTAG if they flashed in a broken OpenBIOS image, and ended up up the creek without the paddle.

I’ll take Open Firmware (and Open BIOS) over EFI any time of the day, because EFI is essentially a black box controlled by Intel, and without vendor consent end user doesn’t really control his PC (for a close to home example see recent efforts to get Windows XP running on x86 based Macintosh systems, that ended up with Apple releasing EFI extention implementing PC BIOS compatibility as part of Boot Camp package). My fear is that hardware is essentially just another black box, and without vendor consent, implementing free BIOS replacement is nearly impossible. That is, supporting hardware ends up being a process of reverse engineering hardware, which is not simple, and which few people want to do for free.

I hate to sound like Richard Stallman, but with EFI locking one’s PC functionality away at the BIOS level, and with recent trend of OS kernels running only signed kernel modules (Microsoft claims that admin will still be able to load unsigned drivers in Vista, but anyone willing to bet that this functionality will get depreciated, and eventually removed?), are you really in control of your computer?

Care and feeding of a Sun Ultra 5/10


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

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 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 :-P

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, 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.


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


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

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-      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

My world is not perfect, but it works :-P


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, 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
-rw-r--r--   1 130        17253   Sep 27  2005   9_SunAlert_Patch_Cluster.README
-rw-r--r--   1 130    168473046   Sep 27  2005
-rw-r--r--   1 130        13279   Mar 30 20:59   9_x86_Recommended.README
-rw-r--r--   1 130    116337317   Mar 30 20:59
-rw-r--r--   1 130        15596   Oct  7  2005   9_x86_SunAlert_Patch_Cluster.README
-rw-r--r--   1 130    105728719   Oct  7  2005
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, 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

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:         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.
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: patch
108823    01        02    SunOS 5.8: compress/uncompress/zcat patch

Oh my. I guess I’ve been slacking in patching.


My first Sun system was a Sun 3/260, that was surplus from DND. Based on what I understand, it was a screw-up on DND’s part, as while the system lacked hard drives, it still was Tempest shielded (and general public is not supposed to gain access to Tempest shielded gear). It wasn’t a “normal” Sun3 – chassis was made out of 2.5mm think steel, each edge had a copper ribbon glued to it, and parts that weren’t openeable in day to day maintenace were kept together by screws every inch or so.

Oh, and it was protected by 3 Medeco locks.

I’ve had lots of fun with it, back in 1993.

But why am I bringing it up?

If you are morbidly fascinated by Sun3 arch and have a bunch of Sun3/60s kicking around, you can get them going.

Some people still maintain an archive of SunOS software for Sun3 arch, and a bunch of pre-built packages. Perl 5.8.8 and OpenSSH 4.2 are some of the things pre-packaged and available for download (which makes the people who run the Sun3 archive officially obsessed). Install instructions are available.

So grab that 12 VME chassis from Sun3/260, and drop in a bunch of Sun3/60 boards, netboot them all, and turn them into a SunOS cluster. You know you want to, and your local electrical utility wants you to too :-)

P.S. On the subject of Tempest shieded gear – Sun made at least SPARCstation T2, which was SS2 in Tempest shielded chassis, with a weird round connector on the back for the serial port. It was explained to me at the time (many years ago), that a shielded serial cable could be attached to those, to provide serial console.