Re: system call incompatibilities across releases

[steve%prd.co.uk@localhost (Steve Blinkhorn)]

 Quentin Garnier wrote:
> 
> 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?

No, I'm not saying anything at all concerning how I felt, I'm
describing a sequence of events, briefly, which was a source of real
difficulty and which I wouldn't like to have to handle again.  There's
a lot of implicit knowledge held by people whose lives are more
entangled with the detail than is the case for those of us for whom
computing is just an enabling technology, and it doesn't always shine
through the documentation. 

> 
> > 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...
> 
> And then running etcupdate of course;  you probably wouldn't have been
> hit so hard with PAM if you had done that.
> 

And if I had booted a new kernel first, I would have been unable to
log in remotely because of PAM, so I wouldn't have been able to run
etcupdate, a fortiori.   That's precisely the sort of gotcha I want to
avoid.   See what I mean?

At the time, I got a lot of willing help and advice from this list
which, taken in aggrgate, would have enabled me to avoid the problem.
But none of the contributions covered all the the issues I
encountered, and it was only in retrospect that I was able to piece
together what had gone wrong.

-- 
Steve Blinkhorn <steve%prd.co.uk@localhost>