Re: An old box running Debian 8
On Tue 17 Nov 2020 at 17:43:43 (+0200), Andrei POPESCU wrote:
> On Ma, 17 nov 20, 09:24:05, David Wright wrote:
> > On Sun 15 Nov 2020 at 10:41:55 (+0200), Andrei POPESCU wrote:
> > > On Sb, 14 nov 20, 16:36:03, Miroslav Skoric wrote:
> > > > On 11/13/20 9:29 PM, David Wright wrote:
> > > >
> > > > > I would have thought that Debian has made kernel testing just about as
> > > > > easy as they can since:
> > > > > jessie installs with 3.16 but 4.9 is also available,
> > > > > stretch installs with 4.9 but 4.19 is also available,
> > > > > buster installs with 4.19
> > > > > so there's full overlap. (I've not looked at backports.)
> > > >
> > > > That's actually what I also thought about.
> > > >
> > > > Btw, when you say 'installs', do you mean a fresh installation only, or it
> > > > includes a 'forced' kernel update during a distribution upgrade? My old box
> > > > was installed for the first time in squeeze, then upgraded to wheezy, then
> > > > to jessie.
> >
> > By "installs with", I meant the former, ie the version supplied with
> > the debian-installer. Once you're happy with that version, it's
> > possible to install the newer version, leaving the old one as a
> > fallback (assuming the usual things like enough room in /boot, etc).
> >
> > > It depends on whether you have the corresponding linux-image-<sub-arch>
> > > package installed or not.
> >
> > I'm not sure what difference this would make. Looking at all
> > the linux-image-X86* packages in stretch, they all depend on
> > linux-image-4.9-* packages.
>
> That was meant for the dist-upgrade case. Without the corresponding
> linux-image-<sub-arch> meta-package the kernel will be left as is and
> the user has to manually install a newer kernel from the next
> distribution.
Oh, I see what you're pointing out: that the minor¹ upgrades won't
take place automatically unless linux-image-<sub-arch> meta-package
is installed. Sure. I wasn't concerning myself with that, but only
with trying to avoid an irreversible upgrade followed by inability
to boot.
To spell out what I have been suggesting, the idea is to test the
OP's jessie distribution with the newer kernel, 4.9. If there are
problems, they can fall back to 3.16. Once any problems are sorted,
and it's running 4.9 smoothly, they can upgrade to stretch.
Because the major number (AIUI, the kernel's ABI) doesn't change in
moving to stretch, this should be relatively trivial as far as the
kernel is concerned. In fact, IIRC the Release Notes usually
recommend upgrading the kernel (its minor version upgrade) early
in the distribution upgrade process. These two paragraphs can then
be repeated for stretch and buster.
I don't recall seeing a safer process posted for upgrading a machine
running a single system. I would post detailed logs of my doing it
for myself, but for the fact that I have had the habit (for two
decades) of configuring two root filesystem partitions on my systems,
and alternating between them with fresh installations, ie:
part_A: squeeze → overwritten by → jessie → overwritten by → buster
part_B: lenny → overwritten by → wheezy → overwritten by → stretch
The two systems share their /home and swap. With this structure in
place, I'm a lot more gung-ho about distribution upgrades.
> Depending on when in the release cycle the dist-upgrade is done the
> newer kernel image may not even be available yet
All the kernels listed above are available now. The OP is playing
catch-up. This is not a strategy being advertised for the future.
> The linux-image-<sub-arch> also depends on the default kernel for the
> distribution, e.g. in case of stretch it depends on a
> 4.9 linux image, for a 4.19 image one has to install
> linux-image-4.19-<sub-arch> (or the linux image package itself).
Yes. IIRC, the newer one would typically be included as what was
termed a "technology preview". What you're describing here is the
"intra-distribution", major upgrade of the kernel, and its safety
is ensured because the older, working kernel is left installed
and still available.
None of this is rocket science; it's just trying to move one
step at a time with maximum ability to either hold the new
configuration or retreat (like a rock-climber's "three points
of contact" rule).
¹ ie in x.y.z-ppp numbering, y would be major, z would be minor.
Cheers,
David.
Reply to: