The bsdlabel utility is deprecated, and gpart should be used instead:
Offset the first 16 sectors, just like bsdlabel did (used for metadata).
Details
Details
- Reviewers
emaste imp - Commits
- rG87e87fecb139: nanobsd: Remove dependency on bsdlabel
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)Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 60676 Build 57560: arc lint + arc unit
Event Timeline
Comment Actions
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)
Comment Actions
Is this perhaps a bug that's been introduced into bsdlabel? I might expect fstype freebsd-ufs?
Comment Actions
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. | |
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.