Root on ZFS/GPT: unexpected object set type lld on load

hi everyone
i have some weird issue, and have no idea how to fix that.
let me tell whole story in time order:
1) i have 8.0-rel on oldstyle ufs partition, but decided to move into zfs. after few pax'ing attempts i realized that it'll be nice to try 8.0 zfs from scratch
2) armed with wiki.freebsd/zfsrootgpt i've installed 8.0 to zfs mirror onto 80gb seagate sata drive. both mirror parts were on that drive
3) during last week everything was fine, but one day i've found that one part of mirror is damaged. so i made two things:
a) zpool replace zroot disk0 (as i understand, it is simple "just reformat that partition and use it again")
b) zpool replace zroot disk0 ad4s3
ad4s3 - slice on 160gb ide seagate drive. delay between operations was about 1hr and 'zpool status zroot' shown "resilvered <usedspace>Gb" near disk0 just before 2nd replace
ofc some 'zpool scrub zroot' operations were made
4) after 3-4hrs i caught pwr fail and after that loader sent me some msgs:
Code:
ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS
ZFS: unexpected object set type lld
ZFS: unexpected object set type lld

googling around led me to some pathes for zfsldr.S and zfsboot.c, but loading into old 8.0, rebuilding loader with them and applying into boot partition with 'gpart bootcode ...' didn't help
as i understand, it is not unique error with zfs root partition
 
Myself just had a problem with zfs and power cut and also nobody answered for long enough. Sorry I cannot help and just want to show that you are not ignored simply ZFS is new and it's very likely that nobody has a clue yet.
 
some russian freebsd-related forums have info that patches must help.
maybe i made something wrong, maybe missed something.
now i'm beginning to think that afterpatch actions were cut. i've just installed loader via gpart bootcode, leaving /boot dir on that malfunctioned zfs untouched. maybe i should set DESTDIR to that mounted pool and perform that actions again?
 
Back
Top