Re: Use of disklabel, MBR and GPT

[Bruce Lilly <bruce.lilly+nbsd%gmail.com@localhost>]

Some clarification and additional comments/suggestions:

On Thu, Oct 22, 2020 at 7:38 PM Michael van Elst <mlelstv%serpens.de@localhost> wrote:

> The kernel choses a default for the dump partition. It might be
> necessary before something could read fstab. That default can
> be overriden by fstab, since there is only one dump partition
> the last entry with type 'dp' is set.

I noted it because it could be troubling or confusing to some who use
dump.  It would be clearer if the dmesg line indicated that the
assignment is "tentative" or "default" or something similar, rather
than the final-sounding "dumps on".

> >to be no facility for reporting or setting some GPT partition
> >attributes (hidden, diag, etc.).
>
> There are only 3 common attributes defined. The tool has some
> additions where needed, but it should probably also allow to
> manage all 64 bits.

I'd be happy with at least reporting the flags; gpt appears to do
the right thing e.g. when creating an ESP, but there's no
indication of the boot amd esp flags; worse, `gpt show -a`
reports "Attributes: none", which is misleadingly inaccurate.

> >`gpt` is the most usable and stable part of the NetBSD installer;
>
> The NetBSD installer is called 'sysinst'. You can use the gpt tool when
> you exit the installer.

What I was referring to is the whole kit-and-kaboodle that is on the
installation media (CD-ROM or USB).

> The disklabel command handles the disklabel.
> The gpt commands handles GPT.
> The fdisk command handles MBR.
[...]
> Sure. It's a metric that might be used by a filesystem when allocating
> blocks on spinning media. It had little to do with hardware for
> quite some time and the filesystem isn't using it either. It's
> also from a time where drivers wouldn't reveal such parameters,
> instead you used the disklabel to inform the drivers (and filesystems).

One big problem is that much of the documentation (man pages,
How-To, NetBSD Guide) is woefully outdated,  Half-jokingly,
most of the man pages (etc.) related to MBR and/or disklabel
should include a disclaimer such as:

"Warning! Warning! Danger, Will Robinson!
If you are too young to recognize the context or your hardware
doesn't date from when Bill Mumy was a child actor, you
probably shouldn't use this utility."

> >If a GPT label name (up to 36 UTF-16LE characters per Wikipedia)
> >contains no whitespace
> >characters, NetBSD's /etc/fstab can use the label, as in
> >NAME=data       /media/dk11     ntfs-3g rw,noatime      0 0
>
> The fstab parser understands \ as an escape, so you can specify
> white space too.

Good to know, but better if it were documented; I see no mention
of that in fstab(5) or the getfsent(3) or getfsspec(3) or
getfsspecname(3) that it references.  The examples in fstab(5)
for gpt, viz.

     For a gpt(8) disk, use:

     NAME=firstpartition     /       ffs     rw,log           1 1
     NAME=secondpartition    none    swap    sw,dp            0 0

don't specify whether "firstpartition" etc. are label names or some
magic referring to partition indices, whether or not UUIDs can
be used, and no mention of escapes for whitespace (or raw
or translated UTF...)

> On the other hand, that's not the GPT label name, but the wedge
> name, which is the GPT label name re-encoded as UTF-8 or the GPT
> entry UUID if no label is set.

And therein lies a potent source of confusion, as a GPT disk doesn't
have any citrus-y "wedges" (or "slices"), so it's unclear where such a
"wedge name" would come from.

Compare e.g. to fstab on PCLinuxOS, where
UUID=
and
LABEL=
are pretty clear about what's being used.

> Mounting on /media/dk11 might be misleading, as it might not be
> the dk11 device next time.

It's just a directory name (as a mountpoint)...
You are of course correct that the device numbering might change,
which is why the ability to use a UUID or GPT label is
preferable, as those are much less likely to change.

> >and mounting an NTFS partition read/write on OpenBSD doesn't work using
> >fstab (it winds up being read-only, and getting R/W NTFS mounts
> >requires some trickery to handle automatically at boot time).
>
> The NTFS code doesn't support writing.

That's true for the plain "ntfs" driver, but not ntfs-3g (or ntfs_3g)
via fuse (or PUFFS).  Works fine on all of the systems mentioned,
but (other than MS Windows and Linux) requires a bit of finagling.
For NetBSD in particular, the default kern.sbmax is too small for
the default perfused/puffs/libperfuse buffer (i.e. kernel and PUFFS
subsystem are incompatibly configured as delivered), so either
kern.sbmax has to be increased or PERFUSE_BUFSIZE has
to be decreased.
FreeBSD was a bit easier to get working and OpenBSD a bit
trickier (ntfs-3g can be spec'ed in fstab with some work
(making an appropriate mount_ntfs-3g link), but writing
doesn't work, even though all indications are that the fs is
mouted R/W; the key to getting an automatically-mounted
R/W NTFS partition on OpenBSD is putting a delayed
ntfs-3g command in /etc/rc.local).