Date: Wed, 28 Mar 2018 15:58:42 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-doc@FreeBSD.org Subject: [Bug 226714] zfsboot(8) erroneously suggests creating a BSD label Message-ID: <bug-226714-9-K5fAGWgspc@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-226714-9@https.bugs.freebsd.org/bugzilla/> References: <bug-226714-9@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226714 --- Comment #25 from Warner Losh <imp@FreeBSD.org> --- Leaving vestiges of a bsdlabel around is asking for trouble. What I'm worri= ed about is that we don't actually handle the nesting case in general. Also, if the bsdlabel looks valid, the boot blocks have to honor it. Otherwise it's a laying violation. zfs isn't immune from properly labeling disks, so we won'= t be adding a weird exception for that. We could add additional checks to make s= ure that the bsdlabel is sane and ignore it if it isn't. The current checks are pretty minimal. I'm surprised that gpart destory of the MBR doesn't recursively destroy the nested things. The man page is silent, though it has a -F to force destroyi= ng a non-empty one. This sounds more like a pilot error, however. If the BSD lab= el is indeed stale, there's little that we can do. We have similar issues with things converted from MBR to GPT sometimes if the old labels aren't properly cleared out. I spent an hour on the plane staring at the code, and we should handle it properly with. I know it's the design point to disallow opens for nested containers, but I couldn't find where in the code that actually happened. I= t's spring break this week, so I'll take a look at it when things are over. I also agree, btw, that gpart installboot should just work rather than the crazy dd stuff... --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-226714-9-K5fAGWgspc>