Hi, The issue here was using DKIOCGMEDIAINFOEXT by ZFS introduced in changeset 12208. Forcing DKIOCGMEDIAINFO solved that.
On Tue, Sep 7, 2010 at 4:35 PM, Gavin Maltby <gavin.mal...@oracle.com> wrote: > On 09/07/10 23:26, Piotr Jasiukajtis wrote: >> >> Hi, >> >> After upgrade from snv_138 to snv_142 or snv_145 I'm unable to boot the >> system. >> Here is what I get. >> >> Any idea why it's not able to import rpool? >> >> I saw this issue also on older builds on a different machines. > > This sounds (based on the presence of cpqary) not unlike: > > 6972328 Installation of snv_139+ on HP BL685c G5 fails due to panic during > auto install process > > which was introduced into onnv_139 by the fix for this > > 6927876 For 4k sector support, ZFS needs to use DKIOCGMEDIAINFOEXT > > The fix is in onnv_148 after the external push switch-off, fixed via > > 6967658 sd_send_scsi_READ_CAPACITY_16() needs to handle SBC-2 and SBC-3 > response formats > > I experienced this on data pools rather than the rpool, but I suspect on the > rpool > you'd get the vfs_mountroot panic you see when rpool import fails. My > workaround > was to compile a zfs with the fix for 6927876 changed to force the default > physical block size of 512 and drop that into the BE before booting to it. > There was no simpler workaround available. > > Gavin > -- Piotr Jasiukajtis | estibi | SCA OS0072 http://estseg.blogspot.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
