Date: Tue, 7 Mar 2017 11:00:54 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Lawrence Stewart <lstewart@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, Toomas Soome <tsoome@FreeBSD.org> Subject: Re: svn commit: r308089 - in head Message-ID: <ac200097-a29f-abd5-3401-1a72d8a6e378@FreeBSD.org> In-Reply-To: <c4cc03d0-d26e-f7c0-8399-d65f2aa0c5ef@freebsd.org> References: <201610291409.u9TE9WXJ020650@repo.freebsd.org> <c4cc03d0-d26e-f7c0-8399-d65f2aa0c5ef@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <pool> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ac200097-a29f-abd5-3401-1a72d8a6e378>