On 2020-05-25 10:21, Why 42? The lists account. wrote: ,,, > 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.
yep. Things like that are where the duids came in. > 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? While OpenBSD itself is great about using duids, those are defined in the 'a' partition of the boot disk..which is usually the first disk. But in your case, the "first disk" doesn't include the 'a' partitionand the /etc/fstab file...which is probably causing the upgrade kernel to choke. > 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) ... No, that won't work -- the disks are assigned at boot. > 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? think about that a moment. You are running OpenBSD. You run sysupgrade, it pulls down all the new tgz files. And it ... REBOOTS. I think you are asking that the old kernel passes info to the newly rebooted kernel. It's probably doable, or could fail earlier to let you know you have a problem, but I'm driving myself batty thinking about the multi-platform and edge cases. The best solution for YOU I can think of would be to put a small 'a' partition on your sd0 for root, and have your system boot from that, but use sd1 for all the rest of the system file systems. Or just do traditional upgrades. Nick.
