So, I'm working along happily from home, when the vpn driver I'm using panicks my Solaris box. Fine, no problem; I'm used to this from the vpn driver by now, although it doesn't happen all that often. So, the system crashes and when it comes back up, shortly after the obpsym messages, the system goes into a loop trying to read an obviously corrupt /etc/path_to_inst file.

Great.

Well, now I have to boot from cdrom. But my media's at the office. I don't have another Sun I can stick this disk into, and I don't have a boot server either. Sooooo, to the office, to bring back a cd. I come back home to find that my cdrom won't read the cd. I now remember that it gave me some hassle about the last cd I tried to read, but I shrugged it off at the time. Now I have media, but no way to use it.

Great.

OK. This isn't a terrible tragedy, I do have backups, and other computers I can use while I wait for a replacement cd drive, but it irks me that I can't fix this. A few minutes later, I've booted the system under kadb, and I'm looking at the area of memory that holds the string with the path_to_inst filename. It's 17 bytes long, and followed by 7 bytes all zero. This is a lucky alignment for me. Using the /v modifier in kadb, I tack on a ".old" to the filename, and continue past the initial breakpoint. (Note: I wouldn't ever recommend doing this on a system that had anything important on it, but I was prepared to reinstall and restore from backup, so I figured why not? It's not like my system could get less bootable...) For the morbidly curious, the memory layout from mdb on my recovered system looks like this:

> *instance_file,20::dump
           0 1 2 3  4 5 6 7 \/ 9 a b  c d e f  01234567v9abcdef
144ccc0:  68650000 00000000 2f657463 2f706174  he....../etc/pat
144ccd0:  685f746f 5f696e73 74000000 00000000  h_to_inst.......
144cce0:  726f6f74 6e657800 00000000 00000000  rootnex.........

Anyway, once past the breakpoint, the system comes up, and I'm back in business.

Great.

The point here? There are several:

• Backup the data you don't want to lose.
• Backup the data you don't want to lose.
• Deal with inconsequential HW problems while they still are.

Oh, and one more: upgrade to Solaris 10! If I'd been running 10, and not 9 at home, this problem would have been found and fixed automagically and even if it hadn't, doing what I wound up doing would have been far easier.

(2004-06-20 23:42:00.0) Permalink

No, I'm not going to tell you to switch to a different window manager or anything like that. Alan Coopersmith's blog had a nice piece about how to nuke Xsun with a given key combination. It reminded me of some of the CDE tweaks that make it cool enough that I'm still using it over newer, spiffier software that's out now. First, take back some of your screen real estate by ditching the front panel. To do so, add this to your ~/.Xdefaults:

  Dtwm*useFrontPanel: False

Then, bind the apps and workspace navigation that you use frequently to< keystrokes. This is what I've got in my ~/.dt/user.dtwmrc

  Keys DtKeyBindings
  {
    F1      root|icon|window f.goto_workspace One
    F2      root|icon|window f.goto_workspace Two
    F3      root|icon|window f.goto_workspace Three
    F4      root|icon|window f.goto_workspace Four

    AltF1   root|icon|window f.exec "~/bin/f1a.sh"
    AltF2   root|icon|window f.exec "~/bin/f2a.sh"
    MetaF1  root|icon|window f.exec "~/bin/f1.sh"
    MetaF2  root|icon|window f.exec "~/bin/f2.sh"
  ...
  }

Next time you restart your window manager, these settings will take effect, Later on, if you decide meta-f4 should be mozilla, and not dtterm, you can just change the script, and don't need to restart CDE

(2004-06-11 23:32:00.0) Permalink

My name is John Wren Kennedy, and I've been working for SUN since 1998. I've spent the better part of that time looking at crashdumps from systems that have panicked. Most of my days are spent using SolarisCAT or mdb or both.

The main point of this post is really to see what it looks like on the web.

(2004-06-10 01:10:53.0) Permalink