[rescue] Potential SVM issue in Solaris 10; anybody got a spud?

[Skeezics Boondoggle]

> On 6/4/06, Bryan Gurney <arb_npx42 at comcast.net> wrote:
> > What are the best practice rules on logging with UFS, for root
> > and other partitions?  I booted up the U60 on the 18 GB disk
> > install of the initial Solaris 10 release, and it only has logging
> > on the slice I used for /export/home.  One of my other Solaris-
> > savvy friends says that ideally, logging should be enabled on
> > all partitions, because otherwise the filesystems aren't
> > journaled in case of a power outage or spontaneous reboot.
>

well, in general, yeah... but how much are you _writing_ to your / or 
/etc?  turning off journaling for partitions that are largely readonly 
shouldn't be much of a loss... but then, i'm still used to the pre-bloat 
solaris 7 era, where i could mirror a pair of 9gb drives, create a 1gb /, 
a roomy swap and /var, and still have room left over for a local copy of 
/usr/local if i wanted to (rather than nfs mounting that).  i suppose if 
folks are doing the "modern" thing and creating a swap slice and lumping 
the rest into /, then yeah, you'll probably want to journal it.

sigh.

i've been stuck in suse hell at my new job, and the last _significant_ 
solaris work i got to do (for money, anyway :-) was solaris 7.  i've been 
slogging through solaris 8/9/10 and trying to come up with a clean, 
minimal, efficient installation - fully characterized by jumpstart 
profiles and cfengine rules that cut out all the fat i don't need... it's 
slow going.  i'm still not convinced i shouldn't go ahead and update all 
of my solaris rpms that were so carefully and _consistently_ built for 
solaris 7; everyone says "just use the companion cd" or "one of the 
pre-built freeware sites" to save time... but none of them get it right. 
still.  /opt/wtf?  /usr/sfw?  are you fscking kidding me?  puke.

uh, anyway, back to the point:  if you still keep a separate /var 
partition (where you should enable journaling) and a small, basically 
read-only / (and you're using cfengine or something similar to manage your 
config files, right? :-) then any sun4u or relatively recent x86 box 
should be able to fsck that in no time flat, and you still can boot from 
either half of the mirror without grief, patch or no patch.

but that's just my $0.02.  i'm just a cranky old solaris 7 guy managing 
boxes with 600+ days of uptime, i should probably force a fsck on reboot 
on some of those machines anyway!  :-)

> On Mon, 5 Jun 2006, velociraptor wrote:
> 
> Speaking of which, does anyone know of a reliable way to install Sun
> firmware onto a non-Sun disk?  We had similar trouble at last $ork
> when we tried to put some of the cast-off 18G Compaq disks into our
> Suns.  They'd work for a while, then crap out.  Fortunately we
> mirrored them against Sun disks, as we thought we might have trouble.
> 
> I've read that trying to do this kind of firmware hackery is
> difficult, but figured that some of the rescuers may have tried, given
> our predilections for repurposing hardware.
>

y'know, i remember doing this in the past but not having it be an issue... 
it was auspex-labeled seagate disks (520-byte formatted!?) that i updated 
and reformatted first on a sun, then later moved off to a netapp which 
couldn't use the auspex disks directly (possibly because i was running an 
old ontap release that didn't yet support 520-byte "bcs" disks?) but 
_could_ after my intermediate steps.  of course, upon detection, the 
netapp immediately put its _own_ new firmware on each drive!  i've used 
netapp disks on a sun before with no problems... got an old filer around? 
it has the advantage of letting you run disk_fw_update against a whole 
shelf of drives at once! :-)

as i recall, the particular drives in question had a sun-provided firmware 
updater available; almost all of their disks have an associated patch that 
can download sun's latest recommended firmware.  (sadly, those _might_ be 
in the contract-only section?)  i don't recall that step being difficult 
or remarkable... so even if the inquiry returns "COMPAQblah", if the 
underlying "STblah" (or ibm, fujitsu, whatever) disk is supported, i think 
the firmware patch will usually find it.

but it's been a while, and i could be talking out of my... hat. ;-)

-- chris