GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies
unavailable"
Robert Noland
rnoland at FreeBSD.org
Thu Oct 29 10:36:49 UTC 2009
On Thu, 2009-10-29 at 10:44 +0100, alteriks at gmail.com wrote:
> On Wednesday 28 October 2009 21:43:07 Robert Noland wrote:
> > If you hit a key very early then you will land in boot2, where you can
> > type "status" and it will list the zfs pool.
>
> I haven't tried it yet. Would it allow me to mount root?
> I tried to install from fixit once again, but I've made a script to eliminate
> all typo's I could made. I amde script using most of:
> http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1
This seems pretty accurate. I've never tried to do this with labeled
disks though. For my current setups, I create the pools using ada0p3,
etc... And once they get imported after boot, they end up using gpt
id's.
balrog% zpool status test
pool: test
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
test ONLINE 0 0 0
raidz2 ONLINE 0 0 0
gptid/c56f3303-be79-11de-813c-002215ea6216 ONLINE 0 0 0
gptid/c70a07c6-be79-11de-813c-002215ea6216 ONLINE 0 0 0
gptid/c915d03c-be79-11de-813c-002215ea6216 ONLINE 0 0 0
gptid/0e4cf049-c0ce-11de-8c99-002215ea6216 ONLINE 0 0 0
gptid/0ff739a0-c0ce-11de-8c99-002215ea6216 ONLINE 0 0 0
gptid/10f4e873-c0ce-11de-8c99-002215ea6216 ONLINE 0 0 0
errors: No known data errors
This pool continues to boot fine under qemu, and with my hacks to the
BIOS drive detection, it boots under VBox as well.
> After rebooting it could even load bootloader:
> > 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
Ok, if you are getting this... It may be helpful if you can run "zdb
-uuu zroot", so I can see what is going on with the root block pointer.
I think you should be able to do that from fixit. Also note that you
don't have the latest version of the loader if it is printing "lld",
though as long as all of the drives are detected it likely won't make a
difference. The "can't read MOS" error is the first attempt to read
from the pool after probing all of the devices to sort out the
configuration. Everything up to this point reads data directly from the
vdev labels on each drive, so this is the first time that it tries to
read from the pool.
> So in my opinion increasing number of sectors for first slice containing
> bootcode, helped at least in my case.
-rw-r--r-- 1 rnoland rnoland 25671 Oct 24 13:56 gptzfsboot
Even with all the debugging that I have enabled at the moment,
gptzfsboot still only requires 51 sectors, so the usual 128 (64k) should
be more than enough.
robert.
> I'll try to install FreeBSD in tuesday with new iso, as I suspect that
> something went wrong during burning dvd, also I didn't check md5. So maybe
> those problems are only related to defuncted dvd, I hope so.
--
Robert Noland <rnoland at FreeBSD.org>
FreeBSD
More information about the freebsd-current
mailing list