On Tue, Sep 06, 2022 at 10:14:02AM +0200, Mark Kettenis wrote:
> > Date: Tue, 6 Sep 2022 01:16:47 +0000
> > From: Klemens Nanni <[email protected]>
> >
> > The installer considers a disk a root disk if 'a' is FFS and contains
> > expected files.
> >
> > Furthermore, unattended upgrades will always install to the first root
> > disk that is found.
> >
> > This works fine on machines with only one root disk, but it quickly
> > behaves unexpectedly when having multiple disks/installations in one
> > machine.
> >
> > I run such machines, esp. since fiddling with softraid and installboot.
> >
> >
> > The installer/sysupgrade experience can definitely be improved here, but
> > that takes some consideration.
> >
> > One requirement, imho, is knowing
> > 1. which disk we booted from, i.e.
> > from which disk the kernel (/bsd.rd or /bsd.upgrade) was loaded
> > 2. which disk the root filesystem is on, i.e.
> > likely the same disk holding /home where sysupgrade put the sets
> >
> >
> > The boot disk could be helpful inside installer, e.g. to check if
> > /bsd.ugpraded was booted from a valid root disk -- a good indicator for
> > rebooting from the same disk the user just ran sysupgrade on.
> >
> > The root disk is of no help inside the installer as that will always be
> > the ramdisk. But it could be used by sysupgrade to perhaps prefill
> > /auto_upgrade.conf to decide up-front which disk to upgrade.
> > This answer to the 'Which disk is the root disk' question is currently
> > answered inside the installer during unattended upgrades... and it will
> > always be the first valid root disk, which is not always correct.
> >
> > So to make progress, here's a diff that exports readily available
> > disklabel DUIDs:
> >
> > # disklabel sd0 | grep duid
> > duid: 98c0c47c3ffddeb4
> > # sysctl hw | grep duid
> > hw.bootduid=98c0c47c3ffddeb4
> > hw.rootduid=98c0c47c3ffddeb4
> >
> > Having that, working out the installer/sysupgrade bits should be easier.
> >
> > I'm testing this on arm64 with two disks/installations.
> >
> > Feedback? Objection? OK?
>
> Wouldn't it make more sense to export these as CTLTYPE_QUAD? Or does
> that bring endian-ness issues that we'd rather avoid?
Not sure I understand. You want to export u_char bootduid[8] as int64_t
and then... do what in user-space?
Am I missing something?
As read-only string, we can simply use the printf helper to get a value
that's immediately comparable against disklabel output, fstab entries,
etc.
>
> > Index: kern/kern_sysctl.c
> > ===================================================================
> > RCS file: /mount/openbsd/cvs/src/sys/kern/kern_sysctl.c,v
> > retrieving revision 1.406
> > diff -u -p -r1.406 kern_sysctl.c
> > --- kern/kern_sysctl.c 16 Aug 2022 13:29:52 -0000 1.406
> > +++ kern/kern_sysctl.c 5 Sep 2022 09:51:38 -0000
> > @@ -762,6 +762,12 @@ hw_sysctl(int *name, u_int namelen, void
> > case HW_SMT:
> > return (sysctl_hwsmt(oldp, oldlenp, newp, newlen));
> > #endif
> > + case HW_BOOTDUID:
> > + return (sysctl_rdstring(oldp, oldlenp, newp,
> > + duid_format(bootduid)));
> > + case HW_ROOTDUID:
> > + return (sysctl_rdstring(oldp, oldlenp, newp,
> > + duid_format(rootduid)));
> > default:
> > return sysctl_bounded_arr(hw_vars, nitems(hw_vars), name,
> > namelen, oldp, oldlenp, newp, newlen);
> > Index: sys/sysctl.h
> > ===================================================================
> > RCS file: /mount/openbsd/cvs/src/sys/sys/sysctl.h,v
> > retrieving revision 1.229
> > diff -u -p -r1.229 sysctl.h
> > --- sys/sysctl.h 16 Aug 2022 13:29:53 -0000 1.229
> > +++ sys/sysctl.h 5 Sep 2022 09:53:13 -0000
> > @@ -931,7 +931,9 @@ struct kinfo_file {
> > #define HW_SMT 24 /* int: enable SMT/HT/CMT */
> > #define HW_NCPUONLINE 25 /* int: number of cpus being
> > used */
> > #define HW_POWER 26 /* int: machine has wall-power
> > */
> > -#define HW_MAXID 27 /* number of valid hw ids */
> > +#define HW_BOOTDUID 27 /* string: DUID of boot disk */
> > +#define HW_ROOTDUID 28 /* string: DUID of root disk */
> > +#define HW_MAXID 29 /* number of valid hw ids */
> >
> > #define CTL_HW_NAMES { \
> > { 0, 0 }, \
> > @@ -961,6 +963,8 @@ struct kinfo_file {
> > { "smt", CTLTYPE_INT }, \
> > { "ncpuonline", CTLTYPE_INT }, \
> > { "power", CTLTYPE_INT }, \
> > + { "bootduid", CTLTYPE_STRING }, \
> > + { "rootduid", CTLTYPE_STRING }, \
> > }
> >
> > /*
> >
> >
>
