From: Alexei_Roudnev (Alexei_Roudnev_at_exigengroup.com)
Date: Sat Dec 22 2007 - 01:50:32 CET
Message-ID: <095101c84434$a84ff660$7031a8c0@exigengroup.com> From: "Alexei_Roudnev" <Alexei_Roudnev@exigengroup.com> Date: Fri, 21 Dec 2007 16:50:32 -0800 Subject: Re: [suse-sles-e] Upgrade to SLES9 SP4 results in non-bootable systems when using SATA
No, it is not really possible to run old kernel in ALL cases.
Examples:
- if ocfs2-tools changed, you can't run old kernel and new ocfs2-tools;
- if iscsi is changed, you can't run old iscsi module in the kernel and new
iscsi daemon.
- other examples do exists.
Such cases are not common - in most cases, you can run old kernel on the new
system, at least as a last resort mode (with some restrictions).
And yes, most Linux distros allows to revert to the previous kernel after
the upgrade (or keep all kernels available
until explicit removal). I love such behaviour much more then existing (in
SuSe) one.
It require, of course, to keep all, kernel, initrd, modules in /lib/modules,
and source in /usr/src .
Ideally I should configure _## of back kernels_ and/or configure _I'd like
to keep this one kernel for a safe mode_.
----- Original Message -----
From: "Eberhard Moenkeberg" <emoenke@gwdg.de>
To: <suse-sles-e@suse.com>
Sent: Friday, December 21, 2007 3:59 PM
Subject: Re: [suse-sles-e] Upgrade to SLES9 SP4 results in non-bootable
systems when using SATA
Hi,
On Sat, 22 Dec 2007, Robert Scheck wrote:
> On Fri, 21 Dec 2007, Rasmus Plewe wrote:
> > On Fri, Dec 21, 2007 at 11:55:51AM -0800, Alexei_Roudnev wrote:
> > > It is a bad thing, because it is VERY
> > > EASY to maintain previous kernel in Linux(es).
> >
> > Unfortunately that is not so in every case.
>
> Hum? Then you IMHO should fix something at your distribution - sorry. If
> such a thing would happen on another Enterprise distribution (okay, they
> never delivered a broken kernel yet as Novell did today), I easily can
> even
> advise a non-technical customer to select the older Linux kernel from the
> boot menu and wait for a working fix. Or did you ever tell a secretary via
> phone how to change a grub entry on the boot prompt to even have a chance
> that the system maybe boots again?
The old kernel(s) have to get conserved somehow.
But you surely do not want to have your /boot partition exploded by old
kernels...
I do this always with the first kernel from a release, and again from time
to time:
cd /lib/modules/
mkdir x
cp -a <kernel-number>* x
cd /boot
mkdir x
cp -a *<kernel-number>* x
cd /usr/src
mkdir x
cp -a linux-<kernel-number>* x
and after "the next" kernel upgrade via YOU, I just move the files back to
their place.
This way I always have a boot alternative which will never get touched
again by anyone but me.
> > If we wouldn't do proper testing we wouldn't have had all this mess,
> > because we wouldn't have discovered the issue before the release. ;-)
>
> If there would be IMNSHO really proper testing, I wouldn't have to replace
> /dev/sda5 by /dev/hdc5 and /dev/sda6 by /dev/hdc6 this afternoon. And I
> bet
> there's a day where I've to change this the other way round in order to
> get
> the system booting again...
Surely, they are all by far not as proper as we and you have the most
usual environment at all.
Viele Grüße
Eberhard Mönkeberg (emoenke@gwdg.de, em@kki.org)
--------------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com
> For additional commands, e-mail: suse-sles-e-help@suse.com
---------------------------------------------------------------------
To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com
For additional commands, e-mail: suse-sles-e-help@suse.com
This archive was generated by hypermail 2.1.7 : Fri Dec 21 2007 - 14:50:58 CET