--- Nick Holland <[EMAIL PROTECTED]> wrote: > 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.
Thank you for this magnanimous reply. /juan
