ZFS boot inside on the second partition inside a slice
jhb at freebsd.org
Mon Jun 20 13:51:49 UTC 2011
On Saturday, June 18, 2011 5:04:07 am Henri Hennebert wrote:
> On 06/17/2011 19:37, John Baldwin wrote:
> > On Friday, June 17, 2011 1:06:22 pm Henri Hennebert wrote:
> >> On 06/16/2011 19:35, John Baldwin wrote:
> >>> On Thursday, June 16, 2011 8:45:41 am Zhihao Yuan wrote:
> >>>> Exactly. The MFCed ZFSv28 is different from any patch maintained by
> >>>> mm at . Maybe some untested changes involved.
> >>> Can you try reverting this change:
> >>> Author: jhb
> >>> Date: Thu Apr 28 17:44:24 2011
> >>> New Revision: 221177
> >>> URL: http://svn.freebsd.org/changeset/base/221177
> >>> Log:
> >>> Due to space constraints, the UFS boot2 and boot1 use an evil hack where
> >>> boot2 calls back into boot1 to perform disk reads. The ZFS MBR boot blocks
> >>> do not have the same space constraints, so remove this hack for ZFS.
> >>> While here, remove commented out code to support C/H/S addressing from
> >>> zfsldr. The ZFS and GPT bootstraps always just use EDD LBA addressing.
> >>> MFC after: 2 weeks
> >>> Modified:
> >>> head/sys/boot/i386/boot2/Makefile
> >>> head/sys/boot/i386/common/drv.c
> >>> head/sys/boot/i386/zfsboot/Makefile
> >>> head/sys/boot/i386/zfsboot/zfsldr.S
> >> I try with this revision (221177) reverted to no avail:
> >> same error - 'read error'
> > Hmm, ok. No other ideas off the top of my head.
> I make the same test under virtualbox and get:
> A critical error has occurred while running the virtual machine and the
> machine execution has been stopped.
> I attach VBox.log.
> PS - the message 'ZFS: supported version 28' comes from my patch:
> Index: sys/boot/zfs/zfsimpl.c
> --- sys/boot/zfs/zfsimpl.c (revision 212549)
> +++ sys/boot/zfs/zfsimpl.c (working copy)
> @@ -61,6 +61,8 @@
> + printf("ZFS: supported version %u\n", (unsigned) SPA_VERSION);
> zfs_temp_buf = malloc(TEMP_SIZE);
> zfs_temp_end = zfs_temp_buf + TEMP_SIZE;
> zfs_temp_ptr = zfs_temp_buf;
Hmm, can you add printfs and narrow down where the hang happens (or which
reads are failing)? The VBOX log seems to make no sense. It shows the
CPU trying to call into the BIOS from within protected mode in the loader
but that shouldn't ever happen (note a cs of 0x2b (which is the loader's
%cs selector) but an eip that looks like a cs:ip of a BIOS routine).
More information about the freebsd-stable