On Thu 06 Apr 2017 at 11:50:56 (+0100), Joe wrote: > On Thu, 6 Apr 2017 12:13:06 +0200 > Nicolas George <geo...@nsup.org> wrote: > > > Le septidi 17 germinal, an CCXXV, Joe a écrit : > > > Even if that could be fixed afterwards, then there > > > will be server downtime and a manual procedure involved which will > > > not be part of the upgrade procedure and therefore will not have > > > been tested by the upgrade designers. > > > > Does that mean that apart from the systemd issue you expect > > dist-upgrade to have been tested on your particular setup and to > > finish without downtime and manual procedure? > > > > On the whole, yes. I have only packages from the Debian repositories > installed, plus some of my own scripts. If I follow the upgrade release > notes to the letter, I expect every package to upgrade cleanly, with > possibly some minor problems with scripts. I expect some problems with > web pages from different versions of apache, php, etc., but I don't > consider them to be operating system upgrade issues. > > Granted, there have been more little niggles with each upgrade (this > machine started life as sarge), things get more complicated with each > version.
I thought lenny→squeeze was the most complicated, because lenny's standard kernel was not compatible with the upgrade process and had to be upgraded in a preliminary step. That could then lead to knock-on effects with non-free firmware. And, for safety, udev had to be immediately upgraded because of the new kernel, then the system rebooted to bring them into operation before the upgrade. > I'm not that bothered about downtime (within reason, the > Debian lists get very stroppy when their emails bounce) but some people > are. A few minutes later you posted: > If I was a paid admin looking after multiple servers, yes, that's the > obvious thing to do. But this isn't my job, and I can't afford to buy a > second set of hardware, so the only practical test is to actually do > it. How about getting those freeloading critics to fork out for a new drive so that you can build and test a second system (dual-bootable) during your scheduled downtimes. > What is more worrying is having to wing it through a procedure > which has not been tested fully and described in the upgrade documents, > but it does appear that will not be the case here. Cheers, David.
