Juan Miscaro wrote: > Hello, > > The online upgrade documentation [1] is fairly vehement about its > recommendation regarding the use of the install kernel when upgrading. > I was wondering why? What dangers await someone going down the remote > upgrade path? > > /juan > > [1] http://www.openbsd.org/faq/upgrade42.html#upgrade
IF you follow the remote upgrade process properly, it works. When I write it, I test first on a machine in my lab, then one in my basement, then one across town that is my mail and web server, and then a bunch of other machines. So, by the time I remove the warning notes from the new version of the file, it's ready for use. I don't recall anyone reporting that they followed the upgradeXX.html and their system died because of it. However, I don't get a lot of test reports for the process, a lot more testing goes on for the install kernel process. HOWEVER, there is stuff that can happen. If you are in front of the machine running the install kernel, you have a much better chance of dealing with it. The number of ways things can go right is very finite, typically. The number of ways things can go bad is...big. Really big. Here are just a few things that could go wrong: IF you were doing 4.1 -> 4.2 upgrade and your machine happened to be one of the five that someone estimated might be impacted by the ahci driver change, you would be really unhappy if you had no serial console on the system, as your machine would suddenly refuse to boot, because your HD became "sd(4)" devices instead of "wd(4)" devices. Same goes if you were any of the twenty or so people who guessed their machines would do that, and didn't. If your hard disk developed a bad spot that didn't impact operation and yet prevented booting, you will be unhappy when you reboot (been there, done that. In my case, I saw the warning signs in dmesg, and knew the machine would probably not come back up. You might not be so lucky or observant). You could easily fat-finger something, installing (say) the new kernel in the wrong place and finding out the old kernel doesn't support the new userland. You could be trying to install i386 file sets on your sparc64 system. (been there, done that, too. Works great, until you hit "reboot") Your system will be semi-functional during the upgrade, this may be bad, or may be good, or may be completely indifferent. When you use the install kernel, the system is in a known state: it is DOWN, and it will stay that way until you reboot it AFTER the upgrade. However, there are several "interesting" time periods on the "live system" upgrade -- early on, you are running with the new kernel and old userland. PF doesn't always come up in that situation...so you may be running without any filters for any apps on the machine. Those apps may be running or maybe not. Those apps may start out running, then blow up once you start unpacking the userland files (hello, Sendmail!). Maybe your machine is involved in a CARP set, during the upgrade maybe it is, maybe it isn't, and maybe it shouldn't be while mid-upgrade but maybe it is anyway. In other words, you will get to your destination, but the states in the between start and finish may not be fully understood by you, and you may not be happy with the impact of that interim time. Again, this is not intended to be a complete list of what could go wrong for you. The remote upgrade process is here because a lot of people who understand their systems need it, and I need it, so I spend the time working on it. However, it's not officially recommended process, rebuilding a live system remotely is just not quite as error tolerant as using an install kernel locally. We'd be nuts to try to tell you otherwise. Nick.
