Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"

On Mon, 2009-11-16 at 17:26 +0100, Emil Smolenski wrote:
> After installkernel/installworld my machine stops booting with the  
> following error message:
> 
> ZFS: i/o error - all block copies unavailable
> ZFS: can't read MOS
> ZFS: unexpected object set type lld
> 
> FreeBSD/i386 boot
> Default: pgpool:/boot/kernel/kernel
> boot:
> ZFS: unexpected object set type lld
> 
>   This is 7.2-STABLE, amd64, zpool on single logical device (ciss(4),  
> hardware RAID5), root on ZFS (using zfsboot). After the failure I booted  
> the server from an external device with UFS and then I did rollback of  
> /usr and / datasets. The machine was still not bootable. Scrub went  
> without errors.
>   Then I read this thread and applied Robert Noland's and Matt Reimer's  
> patches -- and they didn't help. Then I grabbed following files from  
> -CURRENT (svn rev. 198420):

Matt's patch only effects raidz volumes.

> /sys/boot/i386/zfsboot/zfsboot.c
> /sys/boot/zfs/zfs.c
> /sys/boot/zfs/zfsimpl.c
> /sys/cddl/boot/zfs/zfsimpl.h
> 
> and I did:
> 
> # cd /usr/src/sys/boot/
> # make obj ; make depend ; make
> # cd i386/loader
> # make install
> # cd /usr/src/sys/boot/i386/zfsboot
> # make install
> # sysctl kern.geom.debugflags=16
> # dd if=/boot/zfsboot of=/dev/da0 count=1
> # dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024
> # reboot
> 
>   (is this procedure of updating zfsboot correct?)

This should be correct for updating the first stage bootstrap code.  The
loader (boot/loader) is actually updated during installworld.

>   After that, an error was slightly different (printf was fixed):
> 
> ZFS: i/o error - all block copies unavailable
> ZFS: can't read MOS
> ZFS: unexpected object set type 0

This has my patch applied, which fixes the printf's so that they work
correctly among other things.

> FreeBSD/i386 boot
> Default: pgpool:/boot/kernel/kernel
> boot:
> ZFS: unexpected object set type 0
> 
>   Additional information:
> 
> # zpool list
> NAME     SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
> pgpool  4.06T  2.17T  1.89T    53%  ONLINE  -
> 
> # zpool status
>    pool: pgpool
>   state: ONLINE
>   scrub: none requested
> config:
> 
>          NAME        STATE     READ WRITE CKSUM
>          pgpool      ONLINE       0     0     0
>            da0       ONLINE       0     0     0
> 
> errors: No known data errors
> 
> # zfs list pgpool/ROOTFS
> NAME           USED  AVAIL  REFER  MOUNTPOINT
> pgpool/ROOTFS  568M  1.80T  55.3M  legacy
> 
> # zpool get all pgpool
> NAME    PROPERTY       VALUE          SOURCE
> pgpool  size           4.06T          -
> pgpool  used           2.17T          -
> pgpool  available      1.89T          -
> pgpool  capacity       53%            -
> pgpool  altroot        -              default
> pgpool  health         ONLINE         -
> pgpool  guid           3920915583055727184  -
> pgpool  version        13             default
> pgpool  bootfs         pgpool/ROOTFS  local
> pgpool  delegation     on             default
> pgpool  autoreplace    off            default
> pgpool  cachefile      -              default
> pgpool  failmode       wait           default
> pgpool  listsnapshots  off            default
> 
>   loader.conf:
> usb_load="YES"
> uplcom_load="YES"
> umass_load="YES"
> ugen_load="YES"
> ukbd_load="YES"
> random_load="YES"
> loader_color="YES"
> vfs.root.mountfrom="zfs:pgpool/ROOTFS"
> zfs_load="YES"
> autoboot_delay="2"
> 
> FreeBSD 7.2-STABLE #0: Fri Jun 19 13:27:29 CEST 2009
> (as I mentioned above, there was the rollback)
> 
> ciss0: <HP Smart Array P400> port 0xe800-0xe8ff mem  
> 0xdef00000-0xdeffffff,0xdeeff000-0xdeefffff irq 35 at device 0.0 on pci4
> ciss0: [ITHREAD]
> da0 at ciss0 bus 0 target 0 lun 0
> 
>   I would rather not to upgrade the whole system to -CURRENT. What should I  
> do in this situation? Is there any other patch that I could apply or any  
> workaround for this issue? Is there possibility to switch from zfsboot to  
> gptzfsboot without loosing data? Or maybe I did something wrong?

I don't think that you can switch to gptzfsboot as that would require
repartitioning the device.

A little more context though, was this working before?  Or is this a new
install?

robert.

-- 
Robert Noland <rnoland_at_FreeBSD.org>
FreeBSD