Date: Wed, 28 Mar 2018 05:11:21 +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-LWpXGnvYJD@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 #15 from Eugene Grosbein <eugen@freebsd.org> --- (In reply to Warner Losh from comment #14) > So I'm not so sure that's the bug. I do not insist that's the bug, a mis-feature may be :-) > So if we can't open the s1 device (which we prohibit currently), then we = return. If we can't open the device, we should just not probe zfs on the sl= ice, but we should probe it for the BSD partitions. That bug is easy enough= to fix. The bug is here, not in libsa. It's behavior is working as designe= d. ptable_open should recurse properly though. Not agreed. Perhaps, you missed the point: the problem manifests if=20 there is a slice without real BSD label inside containing its own partition table but ZFS pool and BSD label magic number in the second block. Everyone that: - tries to migrate from traditional UFS-only system having MBR+BSD label to ZFS-only bootable pool, - does "gpart destroy -F ada0" then re-creates MBR and slice having same offsets, - installs boot code and creates ZFS pool without creating BSD label using instructions from zfsboot(8) before my last change will have mentioned ZFS pool without rea; BSD label inside but with its mag= ic number in the second block. Been there, seen that. --=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-LWpXGnvYJD>