From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 12 15:30:09 2012 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 462EE106566C for ; Sun, 12 Feb 2012 15:30:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 152908FC16 for ; Sun, 12 Feb 2012 15:30:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1CFU88E047656 for ; Sun, 12 Feb 2012 15:30:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1CFU8fH047653; Sun, 12 Feb 2012 15:30:08 GMT (envelope-from gnats) Date: Sun, 12 Feb 2012 15:30:08 GMT Message-Id: <201202121530.q1CFU8fH047653@freefall.freebsd.org> To: freebsd-sparc64@FreeBSD.org From: Gavin Mu Cc: Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gavin Mu List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 15:30:09 -0000 The following reply was made to PR sparc64/165025; it has been noted by GNATS. From: Gavin Mu To: Marius Strobl Cc: bug-followup@freebsd.org Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64 Date: Sun, 12 Feb 2012 22:59:12 +0800 >> Known Limitations: >> 1. only zpool on a whole disk is supported, zfs boot from zpool in VTOC8 partitions may not work. > > Uhm, are you sure you didn't have (the remnants) of a VTOC label on > the disk? I'd expect the firmware to refuse to boot from a disk not > having one. Sorry, it is my fault not writing this here. A fake VTOC8 label is still required, and it is not conflict with zpool on the whole disk, since ZFS reserved the first 8KB block unused. the VTOC8 table and boot1 (or zfsboot) code can be in this 8KB block. command `zpool create` will not destroy the VTOC8 table and the boot1 code. > >> 2. boot from mirror/raidz is not supported due to limited dev environment. > > Could you also tackle these remaining bits or at least describe what > it would take to support booting from a zpool in a VTOC label, mirror > and raidz? I do not have enough hardware to test booting from mirror/raidz disks, so I focus only on booting from one single disk in this PR. The default zfs_dev.dv_init() traverse all possible disks and slices/partitions to find all zpool vdev, I simply changed the behavior to read from one single disk only then it is easy to know which zpool should be used to boot (there will be only one). To support booting from mirror/raidz, all disks/slices must be traversed and it is needed to decide which zpool to boot. booting from a zpool in VTOC8 label should be possible for me to do dev/test, I need a little more VTOC8 knowledge and will try it later. > >> >> >How-To-Repeat: >> NA. >> >Fix: >> generic steps: >> 1. build zfsboot and zfsloader >> 2. create zpool on your disk >> # zpool create tank /dev/ >> 3. export the zpool >> # zpool export tank >> 4. install zfsboot >> # dd if=boot1 of=/dev/ bs=512 skip=1 oseek=1 conv=notrunc > > Assuming there is a VTOC8 label, this could also be done using `gpart -b`, > no? Yes, but I think we should keep the zpool exported, otherwise this command may fail. > >> 5. install zfsloader to ZFS Book Block location >> # dd if=zfsloader of=/dev/ bs=512 oseek=1024 conv=notrunc > > I think to vaguely remember there being a zfs command/way of writing > a loader to that 3.5MB boot block area following the uberblock. Do > you know what it is? I am also finding this.:) without such command, it will not be able to update the zfsboot and zfsloader on the disk (dd will report error since zpool is being used). Maybe we need some other code changes. > > In any case, nice work so far! > > Marius > Cheers, Gavin Mu