From owner-freebsd-fs@freebsd.org Sun Jan 14 23:22:47 2018 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 00E75E634CA for ; Sun, 14 Jan 2018 23:22:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB9D0726A0 for ; Sun, 14 Jan 2018 23:22:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id B857F14807 for ; Sun, 14 Jan 2018 23:22:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w0ENMkDt009374 for ; Sun, 14 Jan 2018 23:22:46 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w0ENMkRf009373 for freebsd-fs@FreeBSD.org; Sun, 14 Jan 2018 23:22:46 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 221075] geom_flashmap(4) exposes race rendering / on ZFS unbootable Date: Sun, 14 Jan 2018 23:22:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: seschwar@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 23:22:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221075 --- Comment #17 from Sebastian Schwarz --- I tried a few more things: I zfs send/recv-ed the affected dataset the previously created new FreeBSD 11.1-RELEASE installation. It booted with the GENERIC kernel. Then I used the FreeBSD installer to try to get a non-booting configuration= . I succeeded when using diskids for the ZFS pool. If I used /dev/ada0 the GEN= ERIC kernel would boot fine. Also while creating a ZFS pool on /dev/diskid/... I fiddled a bit with the GPT. I tried both 4K and 1M alignment. It made no difference. I tried different partition indices. It made no difference. Then I took the booting configuration (ZFS pool on /dev/ada0) and dd-ed the individual backed up partitions from my original setup (containing a ZFS po= ol on /dev/diskid/...) over the working ones (the partitions had the same size= and locations). The system still booted fine with the GENERIC kernel. So what difference did the initial ZFS pool on /dev/ada0 really make? Then I fiddled with the GPT again, trying different types, labels and numbe= r of entries, but it made no difference. The system remained bootable. Then I dd-ed the original GPT back into place (the partitions had the same = size and locations). But now the GENERIC kernel was unable to find my ZFS pool again. I tried fiddling with the GPT again. But it made no difference. Then I zeroed all space outside of the partitions (GPT & unused space due to alignment) and manually recreated the partition table. Now the GENERIC ker= nel was able to boot again. I attached the output of "gpart backup" of both the good and bad GPT. They only differ in two places. The partition type of the ZFS partition and the amount of entries (is that the number in the fist line?). The type doesn't matter. I can change it to both values and it doesn't make a difference. = That number in the first line is more interesting. When I first recreated the G= PT it was 128. After a reboot it was 152. The original GPT was create on Lin= ux using fdisk. I'm not really sure what's going on. Creating the ZFS pool with /dev/ada0 = like a fix but doesn't hold up to verification. Changing the partition table doesn't matter until it is was zeroed before. Maybe someone can make sense= of this... --=20 You are receiving this mail because: You are the assignee for the bug.=