On Fri, 2008-10-31 at 02:13 -0500, David C. Rankin wrote:

Rajko M. wrote:

...

On Thursday 30 October 2008 06:39:42 pm Andrew Joakimsen wrote:

...

How can I do Kernel updates but keep the old kernel as an option in the GRUB menu? I just looked at systems recently updated and in /boot all the files for the previous kernel are no longer there.

For now download kernel and run 'rpm -i <kernel>' , this will not delete older kernel. Though, I would check is old kernel still listed in grub boot menu.

Yep, it still works like a charm. I downloaded and reinstalled 2.6.25.16 after update to 2.6.25.18 to test a graphics issue and I just collected the rpms into a single directory like:

02:08 nirvana/srv/www/download/openSUSE_11.0/x86_64/kernel> ls -1 | grep 16 kernel-default-2.6.25.16-0.1.x86_64.rpm kernel-source-2.6.25.16-0.1.x86_64.rpm kernel-syms-2.6.25.16-0.1.x86_64.rpm

Then installed them with:

rpm -ivh --force kernel*.rpm

The installed worked just as it should and properly updated /boot/grub/menu.lst preserving the 2.6.25.18 kernel entries.

NOTE: Above, the --force option was required due to installing an older kernel. As a general rule _never_ _ever_ use the --force option unless you know exactly what your are doing. It is the quickest way to thrash your entire rpm database.

David? I'm wondering if you're running virtual box and have seen any problems with it under the new kernel? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, Oct 31, 2008 at 12:32:48PM +0100, Carlos E. R. wrote:

On Friday, 2008-10-31 at 10:06 +0100, Lars Müller wrote:

...

For the zypper approach as it is in 11.1 and newer see the multiversion setting in /etc/zypp/zypp.conf Here you define which packages are allowed to be installed multiple times.

## ## Packages which are parallel installable with ## diffent versions ## # multiversion = kernel-default,kernel-smp

How many versions will that keep :-?

I don't know. I expect this will keep all versions which includes the risk to run out of disk space in /boot. To me it would be a good default to have the currently running kernel - which is know to work - and the new one installed and to remove any other version. Fictional output of "rpm -qf /boot/vmlinuz-* --last" after the last available kernel update got installed: kernel-default-base-2.6.27.1-2.1 kernel-pae-base-2.6.27.1-2.1 kernel-default-base-2.6.27.1-1.1 kernel-pae-base-2.6.27.1-1.1 It would be great to have to opportinuty to define the nunber of kernel package per flavour to keep. The open or a different question is how to display this state ot the opportinities to the user at the grub screen. Here the help of usebility experts might be the most promising approach. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2008-11-01 at 18:52 +0100, Lars Müller wrote:

The open or a different question is how to display this state ot the opportinities to the user at the grub screen. Here the help of usebility experts might be the most promising approach.

I believe that simply it adds an entry to the menu with the kernel name and version, probably sorted by age. This is done by a script in the kernel rpm. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkMtWcACgkQtTMYHG2NR9W1BQCfcF8TGIauRuENpA134HDB5yot 5cQAn09hHJKyYLjFJcTk/qGk8YJVu/3r =iM+G -----END PGP SIGNATURE-----

On Sunday 02 November 2008 07:05:45 Lars Müller wrote:

On Sat, Nov 01, 2008 at 09:00:37PM +0100, Carlos E. R. wrote:

...

On Saturday, 2008-11-01 at 18:52 +0100, Lars Müller wrote:

...

The open or a different question is how to display this state ot the opportinities to the user at the grub screen. Here the help of usebility experts might be the most promising approach.

I believe that simply it adds an entry to the menu with the kernel name and version, probably sorted by age. This is done by a script in the kernel rpm.

This is _currently_ all done with the help of the script hooks (preinstall,postinstall,preuninstall,postuninstall) of the kernel RPM.

The question I had in mind was: How to make the install of several kernels _useable_. [...]

Yum already does all of this, so it is possible. Yum is also configurable as to how many versions to keep (defaults to 2). Regards, -- =================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ===================================================

On Sun, Nov 02, 2008 at 02:29:13AM +0100, Carlos E. R. wrote:

On Saturday, 2008-11-01 at 21:35 +0100, Lars Müller wrote:

...

...

...

The open or a different question is how to display this state ot the opportinities to the user at the grub screen. Here the help of usebility experts might be the most promising approach.

I believe that simply it adds an entry to the menu with the kernel name and version, probably sorted by age. This is done by a script in the kernel rpm.

This is _currently_ all done with the help of the script hooks (preinstall,postinstall,preuninstall,postuninstall) of the kernel RPM.

The question I had in mind was: How to make the install of several kernels _useable_.

I don't understand, there is no problem. When you boot, you will see a menu like (invented numbers):

title openSUSE 11.1 - 2.6.27.4-2 title openSUSE 11.1 - 2.6.27.4-1 title openSUSE 11.1 - 2.6.27.3-5

What's the problem with that? Because that's the way it is handled, AFAIK.

A new user might not know how to handle three different offers. Therefore it might be useful to "hide" the opportunities but have them available on request. That's why I gave the example with KDM and the opportunity to decide which window manager to use for the next login session. The alternatives (KDE3,KDE4,gnome,...) aren't visibile by default in KDM. On the other side one additional line at the grub menu shown for 8 seconds shouldn't be too confusing. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

Another one bites the dust... Here's the exact procedure.. Did an install via SSH. After the install completed I ran online update. "Packages for software management were updated, restarting now" and ran online updates again which did the Kernel update. Restarted the system and it does not come back online. This is not acceptable. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

----- Original Message ----- From: "Rajko M." To: Sent: Monday, November 03, 2008 10:49 PM Subject: Re: [opensuse] Safer Kernel Updates

On Monday 03 November 2008 07:04:37 pm Andrew Joakimsen wrote:

...

Another one bites the dust... Here's the exact procedure..

Did an install via SSH. After the install completed I ran online update. "Packages for software management were updated, restarting now" and ran online updates again which did the Kernel update. Restarted the system and it does not come back online.

This is not acceptable.

So, what to do?

Kernel didn't load. It could be that computer is sitting with oops message waiting for reset, or waiting on root password, or running something to keep CPU warm, or all fine except network module.

GRUB prompt can be accessed from serial line, but that requires another computer that has network access.

I guess that Brian described what he is using for remote servers to prevent problems like your's.

Heh, indeed. This is a case of: If "This is not acceptable.", then "Don't do that". You don't get to blame Browning for the hole in your foot when you deliberately loaded in ammo, disengaged the safety, pointed the gun at your foot and pulled the trigger. It's not opensuse's fault for failing to _garantee_ to boot all the way to network connectivity and network services starting. Nothing can ever garantee that. It's the admin's fault for installing a server remotely that must stay up, yet not providing himself the means to deal with a broken system. It's especially, doubly, quadruply, the admins fault for allowing even the slightest change to happen to such a delicate and precarious systems' boot and core os files after it is by some miracle up and running to begin with. -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

...

How can I do Kernel updates but keep the old kernel as an option in the GRUB menu? I just looked at systems recently updated and in /boot all the files for the previous kernel are no longer there.

I used yum or smart for older SUSE products (pre 11.1).

For the zypper approach as it is in 11.1 and newer see the multiversion setting in /etc/zypp/zypp.conf Here you define which packages are allowed to be installed multiple times.

## ## Packages which are parallel installable with ## diffent versions ## # multiversion = kernel-default,kernel-smp

I wonder, could this be made easier (for newer users) than having to edit the conf file? Could it be set to keep 1 or 2 kernel versions by default? To compare to a competing Linux distro... Ubuntu keeps previous versions, and that has been a major lifesaver for me when an update went "wrong" on a friend's computer (uses Ubuntu 8.04)... when video drivers stopped working or sound stopped working after a new kernel was installed. I was able to tell the user how to roll back to the previous working kernel, and it gave me time to find out what went wrong, and arrange an ssh session to log in and tweak what needed tweaking. This friend wants to roll over to openSUSE with the 11.1 release, and... although I could go edit the conf file, I can't expect him to be comfortable with that just yet... he is very new to Linux. Having multiversion enabled by default would help a lot. On the other side of the proverbial coin though... what are the risks and problems with having this option enabled by default, or easily changed in some way? C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

When you are trying to talk a non-technical user into fixing it the situation is very frustrating. It would be nice to tell them "Press down arrow and enter" and it just boots into the old kernel.

That is what I was able to do with my friend's Ubuntu install... but like I said, he's migrating to openSUSE soon (planning on 11.1 release timeframe). He is learning... but still... even for myself, it would be nice to have at least the last known working kernel kept around (mental note to go change that config file). C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

It is easy to keep a backup kernel. I do it since the initial installation.

1. Go to the boot directory****************************

#cd /boot

[snip a bunch of manual CLI steps] Try explaining that to a new user.... while you are on the phone to them... because the computer you are supporting is more than 500km away. While the steps outlined may seem "easy" to an experienced user, they are not easy to a new user, nor are they practical to someone who doesn't have time to tinker at that level with every kernel update. Can I do the steps outlined? Yes, but there is no reason we should have to resort to a 9 or 10 step process of manually copying kernels around, doing mkinitrd, and manually editing our grub file. That is just silly given that this can be done automatically... and is done automatically with other Linux distros (well, at least one that I know of anyway). That automatic backup of existing kernels got me out of a bind more than once (machines I do not always have physical or even ssh access to). My question was more to try to spark the idea of... why aren't we doing this automatically? and can we do it? C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Clayton wrote:

...

It is easy to keep a backup kernel. I do it since the initial installation.

1. Go to the boot directory****************************

#cd /boot

[snip a bunch of manual CLI steps]

Try explaining that to a new user.... while you are on the phone to them... because the computer you are supporting is more than 500km away.

While the steps outlined may seem "easy" to an experienced user, they are not easy to a new user, nor are they practical to someone who doesn't have time to tinker at that level with every kernel update.

Can I do the steps outlined? Yes, but there is no reason we should have to resort to a 9 or 10 step process of manually copying kernels around, doing mkinitrd, and manually editing our grub file. That is just silly given that this can be done automatically... and is done automatically with other Linux distros (well, at least one that I know of anyway). That automatic backup of existing kernels got me out of a bind more than once (machines I do not always have physical or even ssh access to).

My question was more to try to spark the idea of... why aren't we doing this automatically? and can we do it?

C.

Must admit I wonder about the need to go through some of these stages (i.e the mkinitrd part), I usually just mirror the boot directory (a simple copy to /boot.old), copy back what is needed and modify menu.lst as appropriate if I really want the option to run both the old kernel and the new kernel (and for me this is rare), and zap the mirror when I am certain everything is OK. (I do not want or need to be lots of old kernel versions floating around). If things do go pear shaped one usually have everything needed to recover simply. However, I have no need to do things with nvidia driver builds etc etc, so my requirements are pretty basic and I therefore have no idea whether this will work with that kind of requirement. As /boot/initrd and /boot/vmlinuz are symbolic links to the current version of the relevant files (at least on my system), a /boot/grub/menu.lst reference to these can simplify reversion to an old version. A couple of mv actions boot -> boot.new and boot.old -> boot should revert OK to a previously working system. (Problems could come if source stuff is installed as well, but if you are using these you are unlikely to be a newbie anyway, and reasonably cognisant of the issues involved). Obviously other stuff will need to be done after this, but at least you will have something usable to work with. I can understand why this is not standard, if one size may not fit all because of the propriety driver issue. However, all the basic components for a simple backup and restore option are already in place if this is not the case. Which I suspect is all the majority would require. My usual - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkMRksACgkQasN0sSnLmgIDowCeL8MDqSMgnUOuKXjQF+vGgFLW e0QAn1WC8j3yM316KvwHvdwOmoNVuXaO =wsu0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2008-10-31 at 20:38 -0600, Teruel de Campo MD wrote:

It is easy to keep a backup kernel. I do it since the initial installation.

1. Go to the boot directory****************************

#cd /boot

2. Find out the name of the running kernel*************

#uname -r

copy the number and pasted over the number in the example below.

3. make backup copy of your kernel and System.map******

#cp vmlinuz-2.6.22.13-0.3-default vmlinuz-2.6.22.13-0.3-bak #cp System.map-2.6.22.13-0.3-default System.map-2.6.22.13-0.3-bak #cp -r /lib/modules/2.6.22.13-0.3-default /lib/modules/2.6.22.13-0.3-bak

... This is not enough, you need to copy also the entire /lib/modules/{kernel-version} tree, which is where the modules are kept. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkMtHkACgkQtTMYHG2NR9XvOQCfZUc/Myg78RCBbzekJ003Tugn FvsAoJMAF8vl06HMoM6lvfIFuLRh6/Zf =H+bi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org