shouldn’t sysupgrade default to use the disk where bad.rd launched from? I assume it’s the same disk that was running the system before boot. This would be ideal default behaviour since this is an upgrade.
regards > On 25 May 2020, at 18:26, Nick Holland <[email protected]> wrote: > > 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. >
