> Date: Mon, 14 Nov 2022 09:22:13 +0000
> From: Klemens Nanni <[email protected]>
>
> On Tue, Sep 06, 2022 at 01:16:47AM +0000, Klemens Nanni wrote:
> > 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?
>
> I'd like to get on with this, can also add sysctl.2 bits to document
> those before sending diffs using them.
>
> Mark asked whether CTLTYPE_QUAD would be more suited, but I still don't
> understand how that is supposed to work and there was no answer in this
> thread's other mail.
So my thinking there was that DUIDs are 64-bit integers. But it seems
they are always interpreted as an array of 8 bytes. That probably
means that presenting it as a 64-bit integer (which is what
CTLTYPE_QUAD does) isn't a good idea.
> Anyone?
It is somewhat unfortunate that we are exporting binary data as a
string since it means that userland code will have to parse that
string again and turn it into an array of bytes. We could export it
as CTLTYPE_STRUCT but then we'd need additional code to make sysctl(8)
display the data.
so ok kettenis@
> Index: sys/sys/sysctl.h
> ===================================================================
> RCS file: /cvs/src/sys/sys/sysctl.h,v
> retrieving revision 1.231
> diff -u -p -r1.231 sysctl.h
> --- sys/sys/sysctl.h 7 Nov 2022 14:25:44 -0000 1.231
> +++ sys/sys/sysctl.h 9 Nov 2022 12:06:31 -0000
> @@ -946,7 +946,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 }, \
> @@ -976,6 +978,8 @@ struct kinfo_file {
> { "smt", CTLTYPE_INT }, \
> { "ncpuonline", CTLTYPE_INT }, \
> { "power", CTLTYPE_INT }, \
> + { "bootduid", CTLTYPE_STRING }, \
> + { "rootduid", CTLTYPE_STRING }, \
> }
>
> /*
> Index: sys/kern/kern_sysctl.c
> ===================================================================
> RCS file: /cvs/src/sys/kern/kern_sysctl.c,v
> retrieving revision 1.408
> diff -u -p -r1.408 kern_sysctl.c
> --- sys/kern/kern_sysctl.c 7 Nov 2022 14:25:44 -0000 1.408
> +++ sys/kern/kern_sysctl.c 9 Nov 2022 12:06:30 -0000
> @@ -770,6 +770,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);
>
>
