Bug #1970
closed
Boot fails from an rpool on Hitachi 4k sector drives
0%
Description
The drives are two Hitachi Desktar 7K1000 D drives in a mirrored pool. They are novel in that they have a single platter, but I do not see why that should make a difference.
The reason I do not think that this is the same problem as bug 1772 (OI cannot import a data zpool created by S11X) is that installation of OI fails on this drive. The drive is recognized by the installer and can be selected, but creation of a pool fails. I was able to create a pool and write to it however by using zpool(1) and zfs(1) while running OI from the live CD.
The way I got OI BEs on these drives was that I had a mirrored pool of Seagate drives with both OI and S11E BEs on it. When one of the drives failed, I replaced it with a Hitachi drive and allowed a resilver to proceed under S11. (Before doing this, I upgraded from S11E to S11.) Then I replaced the other Seagate drive with an identical Hitachi drive in the pool. Needless to say, I can mount the OI BEs under S11. I am at zpool version 28.
This is the error message produced when trying to boot OI:
NOTICE: zfs_parse_bootfs: error 22 Cannot mount root on rpool/588 fstype zfs panic[cpu0]/thread=fffffffffbc2f260: vfs_mountroot: cannot mount root Warning - stack not written to the dump buffer fffffffffbc718e0 genunix:vfs_mountroot+33e () fffffffffbc71910 genunix:main+136 () fffffffffbc71920: unix:_locore_start+90 () panic: entering debugger (no dump device, continue to reboot)
By using kmdb, I was able to determine that what is failing is vdev_open. The calling order is zfs_parse_bootfs (zfs_vfsops.c) -> dsl_dsobj_to_dsname (dsl_dataset.c) -> spa_open (spa.c) -> spa_open_common -> spa_load_best -> spa_load -> spa_load_impl -> vdev_open (vdev.c).
Related issues
Updated by 
Updated by 
Updated by