Hi All,
I use sysupgrade to update to new snapshot versions (of 6.6). Brilliant! At some point I added a second (larger) disk to hold my user data (i.e. home). It seems that this new disk took over the name sd0 and the OpenBSD system disk itself became known as sd1. The OpenBSD OS still boots and runs without issue, however this change seems to have confused sysupgrade. After it downloads and reboots I now get prompted to choose I)nstall, U)grade, etc. If I recall correctly, this step used to run automatically without any intervention. Is that right? At this point I can choose the upgrade option and manually run through the process, normally without issue (very helpful prompting/feedback e.g. with the mount points!). Still, it would be nice if this could be once again automatic ... My first thought was I could fix the issue by using sysctl to reassign the disk name to uuid mapping (i.e. the hw.disknames values) so that the OS was once again on sd0. Unfortunately that didn't seem to work. Is it the case that some of these sysctl/system variables are read-only or cannot be set? Or maybe I did something incorrectly ... also not impossible :) Any other suggestions as to how to fix this? Thinking some more about it, shouldn't sysupgrade just use those very disk uuid values to identify its targets in the first place ... thus avoiding the whole issue in the first place? Thanks in advance for your feedback! Just FYI: storage hardware configuration looks like this: > nvme0 at pci1 dev 0 function 0 "Samsung SM981/PM981 NVMe" rev 0x00: msix, > NVMe 1.3 > nvme0: Samsung SSD 970 EVO Plus 500GB, firmware 1B2QEXM7, serial > S4EVNG0M109821X > sd1 at scsibus2 targ 1 lun 0: <NVMe, Samsung SSD 970, 1B2Q> > sd0 at scsibus1 targ 2 lun 0: <ATA, Samsung SSD 860, RVM0> > naa.5002538e4109632a The NVMe device sd1 has all the OS partitions (/, /usr, etc), the SSD device sd0 was added later to provide more space (too many photos :)). Yours, Robb.
