Quentin Garnier <cube%cubidou.net@localhost> writes: > On Tue, Dec 01, 2009 at 05:35:49PM +0000, Steve Blinkhorn wrote: >> Three years ago I got badly bitten trying to upgrade a remote colo >> server from 1.6 to 3.0. There were two sources of difficulty: the >> first was to do with the introduction of PAM; but what really did it >> was the system call incompatibility introduced that meant that 3.0 >> binaries would not interoperate with a 1.6 kernel, so I ended up >> unable to finish the business of copying all the 3.0 files (including >> pam.d) into place. So I had to go to the server farm and install >> manually. > > Are you really saying that you're upset that 3.0 binaries were not > meant to be run with a 1.6 kernel? The problem is that it's tricky/hard to do a remote upgrade. Even if you install the new kernel, you can have trouble if you don't reboot first. That's fair, except that sometimes the old ipfilter userland commands have not worked with the new kernel. >> The time has come to do another round of upgrades, so I'm >> understandably concerned not to run into any similar issues. Is >> there a document somewhere that lists potential issues of this kind? > > Well, I'm pretty sure everything that describes how to update a system > include booting a new kernel first... True, but this can be trouble. > And then running etcupdate of course; you probably wouldn't have been > hit so hard with PAM if you had done that. Steve: This is not written down as well as perhaps it should be. The basic worries are: bootblocks of $OLD may not boot $NEW kernel $NEW kernel and $OLD firewall may not work, leaving you in default pass $NEW libc/sbin and $OLD kernel may not work (due to new system calls) Things that are almost always ok $NEW kernel will implement $OLD system calls, so $OLD binaries run fine So my advice is: only try to do upgrades from one version to the next. If you are at 3, and want to go to 5, go to 4 first. takes longer, but seems lower risk. Use INSTALL-NetBSD and etcmanage from pkgsrc/sysutils/etcmanage. I have developed this to do upgrades w/o touching the console. If nothing else read it through to understand it. Do an 'installkernel' and reboot, and then installuser (which runs etcmanage to update /etc). Before upgrading to N+1, update to the latest along netbsd-N and install updated boot blocks from N. IMHO it should be a rule that head of N bootblocks have to boot N+1, and I think that's true, but it's not formal. updates along N, from 3.0 to netbsd-3 branch, are almost always very safe, even if you violate the user/kernel rules grab a spare box and install the matching $OLD, write out your upgrade procedure, and then try it out. Your odds of trouble are higher than you think if you don't do this all the time. If you are talking i386, I think 3->4 has a new syscall, and 4->5 is not so bad. I don't think there are bootblock issues, but it could be that your 3 system is booting with 1.6 bootblocks, and those won't boot a 4 kernel. For sparc I think 3->4 has new bootblocks. installing bootblocks on a live system is another tricky thing that's good to practice on a test system. If you do it right it's pretty safe, but if you haven't done it 5 times before it's easy to get confused.
Attachment:
pgpIN9aGDSauh.pgp
Description: PGP signature