[OpenIndiana-discuss] Boot crash

[Matt Connolly]

Thanks, Richard, that helped a little, but this is starting to look quite tricky.

My system has three 2TB drives formatted , like so:

+---------------------------+--------------------------------+
| rpool on c8t0d0s0 , 64 GB | zpool on c8t0d0p1 , 1.9TB      | <- #1 mobo sata 1
+---------------------------+--------------------------------+
| rpool on c8t1d0s0 , 64 GB | zpool on c8t1d0p1 , 1.9TB      | <- #2 mobo sata 2
+---------------------------+--------------------------------+
| rpool on c3t1s0 , 64 GB   | zpool on c3t1p1 , 1.9TB        | <- #3 PCI sata (SiI3114 cmdk driver) 1
+---------------------------+--------------------------------+

rpool is a 3-way mirror, setup as bootable slice in a solaris partition of 100GB
zpool is a Raid-Z formatted with blocksize=4096 in a second partition (not solaris partition type, since there can only be one, using the remaining 1.9TB of the drive)


I'm 99% sure that one of the drives has failed, but I don't think it's a catastrophic failure, because I booted into GParted, which shows that all 3 drives pass their short SMART tests.

I tried to boot with only #1 connected and it booted. Rpool is up, no zpool obviously with only 1 drive.

I'm hesitant to try same with the other drives in case I end up with three "branches" of rpool that diverge and can't be repaired back into a mirror again. Is that a possibility for data loss there?? Or is zpool scrub smart enough to figure it out??

I also tried booting with both Oi148 and Solaris Express 11 live cd's to see if they could make any sense of it. Unfortunately, both hang during boot, right after the SunOS 5.11 heading, where (iirc) normally you see the zfs file systems then mounted.


Note that this motherboard can only boot from the onboard sata ports, so to boot from a live cd, I move a sata drive from the motherboard sata port to the pci sata port. Would that further complicate the issue? Or is zfs smart to recognise one of its drives were moved?


In any case, it's quite frustrating that the whole system is unbootable because of this error, completely defeating the intended purpose of having redundancy protecting from data loss in case of a drive failure.


Can anyone see anything glaringly wrong with the setup?? Or if I'm barking up the wrong tree?


-Matt



On 12/07/2011, at 8:28 AM, Richard Lowe wrote:

> If you're crashing, you want to add '-k' to the boot arguments as well
> as -v, etc.  to load the debugger, which should give you time to read
> panic messages etc.
> 
> If with -k it stops at the debugger, the most useful thing is probably
> to include the panic-related output from the debugger's $<msgbuf
> command.
> 
> It's somewhat common (unfortunately) for a particularly damage boot
> archive to look like this, and crash before even the debugger is
> loaded, if this is the case the below should let you rebuild it.
> 
> Boot either an older boot archive or from a live CD (if from live CD,
> import the rpool etc).
> Mount the boot environment which will not boot:
> 
>   beadm mount <be name> /mnt
> 
> Update the boot archive on it
> 
>   bootadm update-archive -vR /mnt
> 
> -- Rich
> 
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss