On 2020-09-27, Why 42? The lists account. <li...@y42.org> wrote: > > 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..."
The non-interactive upgrade is normal for sysupgrade. If working correctly it should not ask any questions, there should be nothing to type. It just runs through the installer in upgrade mode automatically and reboots at the end. >> > 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. For that you would normally download sets and boot to bsd.rd yourself, the point of sysupgrade is really for non-interactive use. > 2. Figure out how to tell sysupgrade the right answers in advance i.e. > via the auto_upgrade.conf mechanism This is fairly easy: sysupgrade -s -n vi /auto_upgrade.conf, edit "Pathname to the sets" reboot > 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 :) There have been proposals (probably either here or on the tech@ list) to allow changing the path before, but IIRC not a robust diff to do this yet (problems with proposals included removing files that should not be removed under certain bad input).
