Subject: Re: RAIDFrame booting from RAID-1 & kernel dumps
To: None <firstname.lastname@example.org>
From: Greg Oster <email@example.com>
Date: 06/30/2006 12:47:26
Mark Cullen writes:
> Greg Oster wrote:
> > Mark Cullen writes:
> >>Mark Cullen wrote:
> >>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
> > 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 :-)
> 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 :-}