nanobsd: Remove dependency on bsdlabel

[jlduran]

Summary

The bsdlabel utility is deprecated, and gpart should be used instead:

Offset the first 16 sectors, just like bsdlabel did (used for metadata).

Test Plan

Verify gpart producess the same results:

md0=$(mdconfig -s 100m)
md1=$(mdconfig -s 100m)

bsdlabel -w "$md0"

gpart create -s bsd "$md1"
gpart add -t '!0' -b 16 "$md1"

gpart show
=>     0  204800  md0  BSD  (100M)
       0      16       - free -  (8.0K)
      16  204784    1  !0  (100M)

=>     0  204800  md1  BSD  (100M)
       0      16       - free -  (8.0K)
      16  204784    1  !0  (100M)

[imp]

While this is good, and should be committed I think.

Long term, though, I think we want to migrate this to makefs / mkimg with any enhancements to mkimg we might need (years ago, there were some blockers in this area, so I didn't even get started)

[emaste]

Is this perhaps a bug that's been introduced into bsdlabel? I might expect fstype freebsd-ufs?

[imp]

In D47653#1086643, @emaste wrote:

Is this perhaps a bug that's been introduced into bsdlabel? I might expect fstype freebsd-ufs?

Wow! I didn't notice !0 before. That's clearly wrong.
We should use type type freebsd-ufs

tools/tools/nanobsd/legacy.sh

120

This needs to be -t freebsd-ufs.

[emaste]

Note that I think D47652 is OK -- we should allow !0 for gpart, even if it's not what we want for nanobsd in this case.

As @jlduran points out the gpart add -t !0 produces output that matches what happens today with bsdlabel, so there's a bug somewhere. We can either figure out why that's happening, or just switch to freebsd-ufs and mention in the commit that we also fixed a bug with the fs type.

[jlduran]

Yes, we arrived at the same conclusion on Discord (storage), as my experience with bsdlabe is exactly the same size as the type we were trying to add here.
It never occurred to me that it could be an issue with bsdlabel, given its longevity.
I have tested creating NanoBSD (not the full, just the image) images with freebsd-ufs, and they seem to work just fine, so this won't break any upgrades.

Thank you, I'll fix it.

[jlduran]

• Use -t freebsd-ufs

[imp]

Yea. Just switch. Don't fix bsdlabel

[emaste]

Hrm, from bsdlabel(8):

For UFS file systems and ccd(4) partitions, use type 4.2BSD.

and indeed,

#define FS_BSDFFS       7               /* 4.2BSD fast filesystem */

and

if (type == FS_BSDFFS)
        return (g_part_alias_name(G_PART_ALIAS_FREEBSD_UFS));

So maybe bsdlabel has not changed, nanobsd has always done this, and nothing really cares that the fstype is 0. Regardless of the history this change is appropriate.

[jlduran]

In https://github.com/cschuber/freebsd-bsdlabel/blob/main/bsdlabel/bsdlabel.c, I tried adding:

dp->p_fstype = FS_BSDFFS;

to fixlabel() in order to get the desired results. There are no tests, I have no experience with it, it's outside of the tree now, so definitely won't fix it.
I really appreciate your support, these are uncharted waters for me. Thank you!

Expect the commit within a few days.

[imp]

Most likely, one of the rewrites of the awk script to create the label...