Mark Cullen writes:
> Greg Oster wrote:
> > Mark Cullen writes:
> > 
> >>Mark Cullen wrote:
[snip]
> >>Another question though. With the dump device specified as wd0b in 
> >>fstab, I am still seeing dmesg print this out:
> >>
> >>"root on raid1a dumps on raid1b"
> > 
> > 
> > That's just the "default message" that gets printed... (since it 
> > hasn't been told otherwise at that point, it assumes it'll be dumping 
> > on raid1b since raid1a is where / is...  it'll tell you that even if 
> > you don't have a raid1b...)
> 
> Ah I see, ok. I assume this means that in the unlikely event I get a 
> panic before it's properly set to wd0b, I won't be able to get a kernel 
> dump?

Correct.

[snip]
> > 
> > In your other post you said:
> > 
> >>Unfortunately this appears not to be the case for me. Suppose I remove 
> >>the PM drive with this setup. The PS drive, one of the disks which is 
> >>actually part of the home RAID array, is now wd0 and *NOT* the SM disk. 
> >>I can see this being potentially quite dangerous, especially since I do 
> >>actually have a 'b' partition defined in disk label on one of the drives 
> >>in the home RAID array.
> > 
> > 
> > "don't use 'b' unless you intend to dump/swap to that partition".  
> > You should have 12 other letters to choose from -- pick one
> > other than 'a', 'b', 'c', or 'd' ;)  That goes for picking partitions 
> > on the RAID sets too :)  (yes, one could argue that there shouldn't 
> > be anything special about 'a' or 'b' or 'c' or 'd', but historically 
> > there has been, and it's just easier to "go with the flow" on this...)
> 
> That's actually quite a fantastic suggestion, you know. I was just a 
> little weary of changing anything in disklabel incase it destroyed the 
> other labels, and thus all of my data. It doesn't seem to though.
> 
> I'll go change the letter now just to make sure that, in the now 
> impossible case where wd2 would become wd0 (it is hardwired now so I 
> dont think it can ever happen, but still) *AND *I stumble upon a panic 
> while I am replacing the disk, dump will never manage to destroy the 
> data on that spare partition. If that makes any sense :-)

Yup :) 
> 
> 
> Thanks for answering all of my questions yet again!

No problem :) 

> Actually, while on the subject of kernel dumps, I did a test dump as 
> described by the guide. I tried 'sync' first, and it printed something 
> along the lines of "syncing disks", I think, and then just locked up 
> solid. The 'reboot 0x104' method worked fine though. Any thoughts on 
> this one?

I've always found getting kernel dumps to work reliably has been a 
black art... So is getting a machine to reboot reliably from the ddb> 
prompt... for me, at least, it seems there's always something to make 
the system hang on "syncing disks", whether I'm just trying to reboot 
or trying to get a crash dump...   I wish I could tell you "you need 
to do this" cause then I'd know the answer too :-}

Later...

Greg Oster