Long late reply, it's ok the issue has been around even longer. On 2025-10-13 15:07:41, Crystal Kolipe wrote: > On Mon, Oct 13, 2025 at 10:52:27AM -0400, obsd()mulh.net wrote: >> I see "restore" and expect all settings to be restored. >> DUID is neither restored nor left unchanged and since >> "fstab depends on the duid" for proper function I think >> it is worth advising the user to check and update fstab. > > I can see your reasoning, but there are some other details that would come up > if the manual page was changed to include a note about not restoring the DUID: > > There are other fields which are not restored, (and for good reason), such > as boundstart, boundend, etc. If the manual was changed to mention DUID > without mentioning the others, anybody reading it could make other > assumptions, (I.E. that everything except DUID is restored). Documenting > everything in the manual page would probably be excessive, since many of > the non-restored fields are obsolete anyway and unlikely to be encountered or > cared about.
disklabel sd0 > /tmp/prototype disklabel -R sd0 /tmp/prototype disklabel sd0 | diff /tmp/prototype - Doing a label backup followed by an immediate restore, only the DUID changes. On 2025-10-13 13:13:12, Crystal Kolipe wrote: > The behavior you are seeing is intentional. > > Refer to the CVS commit message for version 1.163 of disklabel.c. https://cvsweb.openbsd.org/log/src/sbin/disklabel/disklabel.c,v?sort=File#:~:text=revision%201.163 revision 1.163/ (Download) - annotate - Wed, 28 Apr 2010 16:56:01 UTC by jsing Changes since 1.162: +2 -1 (diff) When restoring a disklabel do not restore the uid. Let the kernel allocate a new uid instead. ok krw@ marco@ https://cvsweb.openbsd.org/diff/src/sbin/disklabel/disklabel.c,v?rev=1.163&prev=1.162 Index: src/sbin/disklabel/disklabel.c diff -u src/sbin/disklabel/disklabel.c:1.162 src/sbin/disklabel/disklabel.c:1.163 --- src/sbin/disklabel/disklabel.c:1.162 Wed Apr 28 08:55:55 2010 +++ src/sbin/disklabel/disklabel.c Wed Apr 28 12:56:01 2010 @@ -1,4 +1,4 @@ -/* $OpenBSD: disklabel.c,v 1.162 2010/04/28 12:55:55 jsing Exp $ */ +/* $OpenBSD: disklabel.c,v 1.163 2010/04/28 16:56:01 jsing Exp $ */ /* * Copyright (c) 1987, 1993 @@ -270,6 +270,7 @@ if (!(t = fopen(argv[1], "r"))) err(4, "%s", argv[1]); error = getasciilabel(t, lp); + bzero(lp->d_uid, sizeof(lp->d_uid)); if (error == 0) error = writelabel(f, bootarea, lp); fclose(t); https://marc.info/?l=openbsd-cvs&m=127247396327838&w=2 List: openbsd-cvs Subject: CVS: cvs.openbsd.org: src From: Joel Sing <jsing () cvs ! openbsd ! org> Date: 2010-04-28 16:56:01 Message-ID: 201004281656.o3SGu1XI015806 () cvs ! openbsd ! org [Download RAW message or body] CVSROOT: /cvs Module name: src Changes by: [email protected] 2010/04/28 10:56:01 Modified files: sbin/disklabel : disklabel.c Log message: When restoring a disklabel do not restore the uid. Let the kernel allocate a new uid instead. ok krw@ marco@ The commit messages do not say why this change was needed. I searched misc@, bugs@ and tech@ for around April 2010 and a little earlier and I don't see any messages about DUID, just discussions about the P command. It wasn't until a year later, May 1 2011, with the 4.9 release that new installs will write DUIDs in /etc/fstab by default. https://www.openbsd.org/plus49.html#:~:text=fstab%20entries%20that%20are%20using%20disklabel Changes made between OpenBSD 4.8 and 4.9 . Make installation script create devices for fstab entries that are using disklabel(8) UID. Now it becomes important that the DUID doesn't just blindly and silently change. With it being the default now (and for so long) mounts at boot depend on it. I had to learn the hard way. I was editing my label for something else, rebooted, nothing mounted (except root). Had to figure out what was wrong without access to man pages for help. At least now I know and won't stress for an hour next time. Everything is easier in hindsight. On 2025-10-13 15:07:41, Crystal Kolipe wrote: > But feel free to submit a proposed manual page change for review by others > anyway. So to document the unexpected behavior in CAVEATS here's the diff: --- sbin/disklabel/disklabel.8 Sun Apr 12 12:48:14 2026 1.159 +++ sbin/disklabel/disklabel.8 Tue Apr 21 12:30:00 2026 @@ -609,3 +609,7 @@ .Pp On some machines, such as Sparc64, partition tables may not exhibit the full functionality described above. +.Pp +Restore +.Fl R +will reset the UID, it is neither preserved nor restored. Or maybe the 1.163 change should be reverted???
