From owner-freebsd-fs@freebsd.org Tue Mar 7 09:01:53 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82AB4CFAAFE for ; Tue, 7 Mar 2017 09:01:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8081191; Tue, 7 Mar 2017 09:01:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA10027; Tue, 07 Mar 2017 11:01:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1clB0A-000FUd-0g; Tue, 07 Mar 2017 11:01:50 +0200 Subject: Re: svn commit: r308089 - in head To: Lawrence Stewart References: <201610291409.u9TE9WXJ020650@repo.freebsd.org> Cc: freebsd-fs@FreeBSD.org, Toomas Soome From: Andriy Gapon Message-ID: Date: Tue, 7 Mar 2017 11:00:54 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 09:01:53 -0000 On 07/03/2017 07:25, Lawrence Stewart wrote: > I've just taken Allan Jude's & co-conspirators' work for a spin that > allows gptzfsboot to boot from a geli + ZFS partition. Everything is > working amazingly well, but I see the above "failed to read pad2 area of > primary vdev" message on every boot. > > It doesn't appear to cause any problems per se and the system > boots/works fine. I assume that message is printed to signal an > unexpected situation though, so figured I'd get in touch to get your > thoughts. > > > > I installed the KVM-based virtual machine system manually from the live > shell of: > > FreeBSD-12.0-CURRENT-amd64-20170301-r314495-disc1.iso > > > > The partitioning is very simple: > > gpart create -s gpt /dev/vtbd0 > gpart add -t freebsd-boot -a 8 -b 40 -s 512k vtbd0 > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0 > gpart add -t freebsd-zfs -b 2088 vtbd0 > > root# gpart show > => 40 83886000 vtbd0 GPT (40G) > 40 1024 1 freebsd-boot (512K) > 1064 1024 - free - (512K) > 2088 83883952 2 freebsd-zfs (40G) > > > > geli was inited/attached to vtbd0p2 and the zpool was created with command: > > zpool create -o altroot=/tmp/zroot -o cachefile=/tmp/zpool.cache -O > checksum=skein -O compression=lz4 vtbd0p2.eli > > i.e. the entire pool including bootfs is using skein for checksumming > and lz4 for compression. > > > > I hit another boot bug using skein previously which Toomas (CCed) fixed, > and am wondering if this issue might also be related to the skein > implementation. > > I haven't tested if the zfsbootcfg functionality works for fear that the > printf is indicating a low level problem with the zpool. I can test > potentially destructive things and break the pool though if that would > be helpful. > > Any thoughts? I think that Toomas explained the situation rather well. vdev_read_pad2() and vdev_clear_pad2() are not aware of GELI as of now, so the former does not even try to decrypt anything and, obviously, gets some garbage as a result. It's that simple. If it's possible to make it understand that it deals with encrypted data, then it would be great. -- Andriy Gapon