On Sun, Sep 27, 2020 at 04:25:58PM -0400, Ian Darwin wrote:
> > ...
> > after the download of the new sets and the reboot, I would have been
> > prompted as to what to do i.e. Install, Upgrade, or Shell. Then for a
> > keyboard layout (e.g. de) and for the name of the disk containing OpenBSD
> > (i.e. the system root partition) or "/").
>
> Something is wwrong here. That is not how sysupgrade works. Probably you
> didn't install updated boot blocks and it has been failing to "switch
> to bsd.upgrade" when rebooting after the download, and your latest
> change installed the updated boot blocks, and now it is working.
I am not sure about that.
IMO probably the something wrong here is/was that after installing
OpenBSD as a proof of concept (of a new desktop "daily driver" system) I
subsequently added a second disk to provide more space, for my /home.
At that time this new disk (an ssd) then became know as, or inherited,
the name sd0, and the pre-existing nvme device with the OS became sd1.
Since that time I have been able to sysupgrade many times without issue,
other than that I had to manually respond to sysupgrade e.g. to specify
which disk device held the OS.
> Here you describe how sysupgrade normally works.
Right, although what is new for me (I think) is to see this message:
"Performing non-interactive upgrade..."
> > 2. The upgrade then proceeds, however it fails to identify the
> > location of the newly downloaded sets. The error is: "The directory
> > '/home/_sysupgrade/' does not exist."
>
> I've never tried using a symlink to /home. Can you mount /home properly
> and see if that works?
Over many sysupgrades it has always been sufficent to manually respond
that the sets are on disk, the disk is mounted and that the path to them
is "/mnt/space/home/_sysupgrade".
Sysupgrade does a nice job presenting the information needed e.g. what is
mounted where.
I'm not sure what you mean by "Can you mount /home properly". At the
point were I am having the issue, sysupgrade is in charge, has rebooted
the system and mounted things where it wants them. Unfortunately, it
doesn't find the sets and then apparently promptly reboots the system.
What I would like would be able to do (one of):
1. Interrupt the "non-interactive upgrade" somehow, so as to provide my
own answers.
2. Figure out how to tell sysupgrade the right answers in advance i.e.
via the auto_upgrade.conf mechanism
3. Have sysupgrade just do the right thing. For example, there could be
a _sysupgrade user in the systems /etc/passwd, whose $HOME would
indicate the preferred location for sets ... But best understand the
problem before designing a solution :)
I guess that is reverse order of preference :)
Cheers,
Robb.
FYI: From the normal running system:
mjoelnir% sysctl hw.disknames
hw.disknames=sd0:7a1775fef773535e,sd1:281ef747da03afe7,sd2:67c92dad63883338
mjoelnir% dmesg | grep targ
...
scsibus0 at mpath0: 256 targets
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 2 lun 0: <ATA, Samsung SSD 860, RVM0> naa.5002538e4109632a
scsibus2 at nvme0: 2 targets, initiator 0
sd1 at scsibus2 targ 1 lun 0: <NVMe, Samsung SSD 970, 1B2Q>
scsibus3 at umass0: 2 targets, initiator 0
sd2 at scsibus3 targ 1 lun 0: <WD, Elements 2620, 1018>
serial.1058262039344E4B4E5A
scsibus4 at vscsi0: 256 targets
scsibus5 at softraid0: 256 targets
mjoelnir% df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/sd1a 1005M 314M 640M 33% /
mfs:6361 7.7G 201K 7.4G 0% /tmp
/dev/sd1e 58.3G 92.6M 55.3G 0% /var
/dev/sd1f 2.0G 1.2G 686M 64% /usr
/dev/sd1g 1005M 251M 703M 26% /usr/X11R6
/dev/sd1h 19.7G 11.0G 7.7G 59% /usr/local
/dev/sd1k 5.9G 2.0K 5.6G 0% /usr/obj
/dev/sd1j 2.0G 2.0K 1.9G 0% /usr/src
/dev/sd1l 295G 10.0G 271G 4% /fast
/dev/sd0h 1.8T 964G 758G 56% /space
(sd2 is just a USB attached external Western Digital hard disk for
backup.)
