Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Mar 2018 04:51:59 +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-zkZgQSsi4W@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 #14 from Warner Losh <imp@FreeBSD.org> ---
(In reply to Eugene Grosbein from comment #12)

So I'm not so sure that's the bug.

The bug appears to be here:
         pa.fd =3D open(devname, O_RDONLY);
        if (pa.fd =3D=3D -1)
                return (0);
        ret =3D zfs_probe(pa.fd, ppa->pool_guid);
        if (ret =3D=3D 0)
                return (0);
        /* Do we have BSD label here? */
        if (part->type =3D=3D PART_FREEBSD) {
                pa.devname =3D devname;
                pa.pool_guid =3D ppa->pool_guid;
                pa.secsz =3D ppa->secsz;
                table =3D ptable_open(&pa, part->end - part->start + 1,
                    ppa->secsz, zfs_diskread);
                if (table !=3D NULL) {
                        ptable_iterate(table, &pa, zfs_probe_partition);
                        ptable_close(table);
                }
        }

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 f=
ix.
The bug is here, not in libsa. It's behavior is working as designed.
ptable_open should recurse properly though.

It's kind of a moot distinction, though, because while we support non-zero
offsets for the zpool partition, we can't really boot off such partitions
because zfsboot assumes that the bootable zpool is in a partition that is at
offset 0 (need not be the first one, it appears). The current instructions
assume that zfsboot is installed in the ZFS boot zone, which also assumes t=
hat
the uber block is where it would be if the sliced started at location zero.

I think the following fix is the right one, but I'm not sure yet:
diff --git a/stand/zfs/zfs.c b/stand/zfs/zfs.c
index 0050bbe0056..f51c5c1efaa 100644
--- a/stand/zfs/zfs.c
+++ b/stand/zfs/zfs.c
@@ -488,15 +488,19 @@ zfs_probe_partition(void *arg, const char *partname,
                return (0);

        ppa =3D (struct zfs_probe_args *)arg;
-       strncpy(devname, ppa->devname, strlen(ppa->devname) - 1);
-       devname[strlen(ppa->devname) - 1] =3D '\0';
-       sprintf(devname, "%s%s:", devname, partname);
+       sprintf(devname, "%s%s:", ppa->devname, partname);
        pa.fd =3D open(devname, O_RDONLY);
-       if (pa.fd =3D=3D -1)
-               return (0);
-       ret =3D zfs_probe(pa.fd, ppa->pool_guid);
-       if (ret =3D=3D 0)
-               return (0);
+       if (pa.fd !=3D -1) {
+               /*
+                * Only probe the slice if there's no BSD label
+                * on it. When we have a nested scheme, we'll not
+                * be able to open the slice, but we will be able
+                * to open the ptable.
+                */
+               ret =3D zfs_probe(pa.fd, ppa->pool_guid);
+               if (ret =3D=3D 0)
+                       return (0);
+       }
        /* Do we have BSD label here? */
        if (part->type =3D=3D PART_FREEBSD) {
                pa.devname =3D devname;

Oh, and I agree we should stop telling people to create a BSD partition, bu=
t we
should support it because sometimes it's necessary for a swap or a dump
partition.

--=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-zkZgQSsi4W>