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.
Anyone?
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);
