On Streda 04 Február 2009 14:29:09 Dominique Leuenberger wrote:

...

...

...

On 2/4/2009 at 2:25 PM, Felix Miata wrote:

It's really annoying to have zypper up remove working kernels and initrds before replacements have been tested positive, particularly since networking is broken absent a post-2.6.25 kernel.

http://lizards.opensuse.org/2009/02/03/do-you-want-multiple-kernels-on-your -system/

Has never been added to 11.0 and in traditional manner, features are not added to any released product. But as you ask on Factory anyhow I assume you wanted to know if it's in 11.1 or if it has to be raised again for 11.2, right?

It is in 11.1 and newer (i.e. factory right now). Stano -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Felix Miata wrote:

I know that's normal, but still the feature request was technically filed against 11.0. And, one never knows what "feature" will get slipped in as or in a "bugfix" for a released product. AFAICT, this is not all that uncommon when a "bugfix" is a product of upstream.

We do often fixes in current version, and mark the bug as fixed in older versions.

Since it apparently hasn't been and won't be added to 11.0, I'll just have to remember to keep using Smart instead of Zypper on 11.0 systems, something I failed to remember today. It's annoying to not be able to stick to one package manager. :-(

I understand your frustration. I can't get convinced though that a backport is worth the priority. - Either the system is non critical and you don't change kernels (I mean kernel versions) like end-users do - We can reasonable assume a SUSE kernel update will work. - If you run a critical system, you would not change the kernel on a the production system. Duncan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

I understand your frustration. I can't get convinced though that a backport is worth the priority.

- Either the system is non critical and you don't change kernels (I mean kernel versions) like end-users do - We can reasonable assume a SUSE kernel update will work. - If you run a critical system, you would not change the kernel on a the production system. I think you are missing the point. The point is that by removing a known working kernel and installing a kernel that does not work on the user's system leaves the user in a bind. It is much better to have multiple kernels installed as that insures

On Wed, Feb 4, 2009 at 15:28, Duncan Mac-Vicar Prett wrote: {snip] that the user will have one that works. This is one reason why I never user yast or zypper to do kernel upgrades. I use rpm -i and then when I know the newly installed kernel works to my satisfaction, I can rpm -e to remove the old kernel. I hope this helps clarify the situation. ne... -- Registered Linux User # 125653 (http://counter.li.org) Now accepting personal mail for GMail invites. Lucille Ball - "The secret of staying young is to live honestly, eat slowly, and lie about your age." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

ne... wrote:

...

On Wed, Feb 4, 2009 at 15:28, Duncan Mac-Vicar Prett wrote: {snip]

...

I understand your frustration. I can't get convinced though that a backport is worth the priority.

- Either the system is non critical and you don't change kernels (I mean kernel versions) like end-users do - We can reasonable assume a SUSE kernel update will work. - If you run a critical system, you would not change the kernel on a the production system.

I think you are missing the point. The point is that by removing a known working kernel and installing a kernel that does not work on the user's system leaves the user in a bind. It is much better to have multiple kernels installed as that insures that the user will have one that works. This is one reason why I never user yast or zypper to do kernel upgrades. I use rpm -i and then when I know the newly installed kernel works to my satisfaction, I can rpm -e to remove the old kernel. I hope this helps clarify the situation.

I do understand the point. I am arguing how important is to backport it for 11.0, and the fact that I don't think an official kernel update has much chance of not working on the machine if the previous one did. I guess that would depend on when the EOL of oS11 is. I can tell you

On Wed, Feb 4, 2009 at 16:15, Duncan Mac-Vicar Prett wrote: that I am running 2.6.25.16-0.1-pae on my oS11 box as 2.6.25.18-0.2-pae did not work for me. I have yet to test the latest kernel available. It would depend on how hard the backport is. If it is relatively simple, then I guess it could be done. If it isn't, then I guess it would be easy to settle the matter by letting users know that difficulty of the backport precludes this. ne... -- Registered Linux User # 125653 (http://counter.li.org) Now accepting personal mail for GMail invites. Gilda Radner - "Adopted kids are such a pain - you have to teach them how to look like you." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 2009/02/04 14:42 (GMT+0100) Marcus Meissner composed:

On Wed, Feb 04, 2009 at 08:25:58AM -0500, Felix Miata wrote:

...

It's really annoying to have zypper up remove working kernels and initrds before replacements have been tested positive, particularly since networking is broken absent a post-2.6.25 kernel.

Any bugzilla number here?

I got ahead of myself a little before clicking send. I had partially tested for myself and failed to finish first. Zypper up left my networkable 2.6.27 kernel installed, but removed both 11.0 kernels (2.6.25.5 & 2.6.25.18) that were functional. Zypper up in this case installed no kernel, only removed the two oldest kernels. Thus, a working (.27) kernel (and initrd, possibly because this update never caused mkintrd to replace the old?) remained. http://fm.no-ip.com/tmp/SUSE/110/zypper-big31.txt is today's tail of /var/log/zypper.log. Zypper multiversion kernel support was filed against 11.0, but fixed for 11.1 & up: https://bugzilla.novell.com/show_bug.cgi?id=395349 (marked 11.1 FIXED) Broken 11.0 networking was also filed against 11.0 and fixed only for 11.1 & up: https://bugzilla.novell.com/show_bug.cgi?id=406035 (remains marked 11.0, yet FIXED) -- "Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up." Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rob OpenSuSE wrote:

I complained about that in a bug against 10.3, after an update broke my system making it unbootable due to lack of sanity checking. You can install a kernel, with rpm off a live CD using chroot option, and then avoid having YaST notice it, presumably the same thing would likely happen with zypper, as the update likes to use a delta rpm, so it zaps latest version rather than your fallback.

Guys, if you are changing kernels, you have the option to install more than one. The bug is addressed. Just add kernel-default to multiversion. The discussion was about why is not fixed as backport to 11.0, which is not the current release. Duncan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Rob OpenSuSE [02-04-09 11:51]:

2009/2/4 Duncan Mac-Vicar Prett :

...

Guys, if you are changing kernels, you have the option to install more than one. The bug is addressed. Just add kernel-default to multiversion.

The discussion was about why is not fixed as backport to 11.0, which is not the current release.

The point is, you can work round this issue fairly easily, without need of a destabilising backport of 11.1 features.

Saying kernel updates are unlikely to break your box, is not going to silence demand for the feature. Explaining how it is possible to get same effect without the feature is.

The "point" is/was that the OP wants it in zypper on 11.0 and "it will not be", and explanations have been provided. So the only thing left is fruitless banter, er discussion. -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/2/4 Duncan Mac-Vicar Prett :

Patrick Shanahan wrote:

...

The "point" is/was that the OP wants it in zypper on 11.0 and "it will not be", and explanations have been provided. So the only thing left is fruitless banter, er discussion.

Oh sure we can!, if it is considered a bug PrjMgrs could decide backporting it. The question is whether it is worth it, because any work shares resources with 11.2 ;-)

There's a risk to in updating old "stable" systems, if something goes wrong with an update to something critical like zypper, there will be a huge fuss. Does the OP know how to work round the issue? If it is not obvious to him, finding a way, might make a backport seem less of an issue. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/2/4 Patrick Shanahan :

* Rob OpenSuSE [02-04-09 14:56]:

...

There's a risk to in updating old "stable" systems, if something goes wrong with an update to something critical like zypper, there will be a huge fuss.

Does the OP know how to work round the issue? If it is not obvious to him, finding a way, might make a backport seem less of an issue.

He "forgot" that 11.0 zypper did *not* keep replaced/updated kernels. He knows that rpm -i and smart are available and will accomplish what he wishes. BUT he has lost the kernel that *worked* for his environment. Thus the discussion.

So providing the kernel that worked is required. Updating zypper alone is not a solution! Presumably someone who runs 11.0 actually backs up their system? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

...

So providing the kernel that worked is required. Updating zypper alone is not a solution! Presumably someone who runs 11.0 actually backs up their system? Never did a kernel update via "yast online update", "zypper up" or ... Everytime I was happy to do this with a _TEST_ machine: rpm -ihv <new-kernel>, hoping mkinitrd, perl-bootloader and what else is able to do crappy things is doing this right. If all goes the right way you'll have a new grub entry at boot with you can test. Remember: _TEST_ machine! If all seems good, boot into

That would not help. A "native" OpenSUSE/SLES/SLED system just has one kernel to boot. And if it does't, you won't reach your backups with ease. No, even with old LILO you can manage to choose a kernel image, initrd and

Jumping in late, the new kernel and feel free to "rpm -e <old kernel>". parameters to boot an older (the one that's present before the update, see above) kernel. And this should enable you to reach your backups and restore them. my 1 ct -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am Mittwoch 04 Februar 2009 schrieb Eberhard Moenkeberg:

Hi,

On Wed, 4 Feb 2009, Hans-Peter Holler wrote:

...

...

That would not help. A "native" OpenSUSE/SLES/SLED system just has one kernel to boot. And if it does't, you won't reach your backups with ease.

No, even with old LILO you can manage to choose a kernel image, initrd and parameters to boot an older (the one that's present before the update, see above) kernel. And this should enable you to reach your backups and restore them.

Surely, "forever young" LILO can manage multiple kernels. mkinitrd does this for you _if_ you install/update with plain rpm. And, of course, grub and lilo take what you want from them. The question is; do you really trust in higher level software like you or zypper?

But the recent OpenSUSE/SLES/SLED mechanisms will delete your kernel before installing the new. bugzilla? So you have to take your hands on at the right time, or YOU/zypper will fuck you off. This behaviour is contrary to the YaST philosophy - after just you have reached to feel the comfort of YaST, it will kick you into the ass. maybe the yast developers are reading this. _my_ experience: yast rocks, the other: ... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/2/4 Eberhard Moenkeberg :

...

So providing the kernel that worked is required. Updating zypper alone is not a solution! Presumably someone who runs 11.0 actually backs up their system?

That would not help. A "native" OpenSUSE/SLES/SLED system just has one kernel to boot. And if it does't, you won't reach your backups with ease.

Well I actually had the problem, due to update being screwed up, and I sorted it fairly simply, with a Live CD, the rpm(8) man page, chroot & mkinitrd, and fetching known good kernel rpm's. Fetching the files from backup would have been even simpler. Surely someone has the rpm's still? This issue has been the same in SuSE for ages and folk have muddled through, even though this was obviously severely compromising the enterprise worthiness of the distro. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/2/4 Eberhard Moenkeberg :

If YOU is offering a kernel update, it brings a popup window. I then do

cd /lib/modules mkdir x cp -al `uname -r` x/ cd /boot mkdir x cp -a *`uname -r`* x/ cd /usr/src cp -al linux-`uname -r`* x/

I just install a fall back kernel once that stays untouched. You can run 2 kernel configurations, just updating one of them, which works for me without leaving YaST. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Tue, 17 Feb 2009, Peter Poeml wrote:

On Thu, Feb 05, 2009 at 12:45:12AM +0100, Eberhard Moenkeberg wrote:

...

On Wed, 4 Feb 2009, Rob OpenSuSE wrote:

...

2009/2/4 Eberhard Moenkeberg :

...

...

...

...

So providing the kernel that worked is required. Updating zypper alone is not a solution! Presumably someone who runs 11.0 actually backs up their system?

That would not help. A "native" OpenSUSE/SLES/SLED system just has one kernel to boot. And if it does't, you won't reach your backups with ease.

Well I actually had the problem, due to update being screwed up, and I sorted it fairly simply, with a Live CD, the rpm(8) man page, chroot & mkinitrd, and fetching known good kernel rpm's. Fetching the files from backup would have been even simpler.

Surely someone has the rpm's still? This issue has been the same in SuSE for ages and folk have muddled through, even though this was obviously severely compromising the enterprise worthiness of the distro.

I can live with it, but it is nasty, and against YaST's philosophy.

If YOU is offering a kernel update, it brings a popup window. I then do

cd /lib/modules mkdir x cp -al `uname -r` x/ cd /boot mkdir x cp -a *`uname -r`* x/ cd /usr/src cp -al linux-`uname -r`* x/

then ack the popup, and after YOU has finished, I copy the saves back to ..

This way, my old, but running kernel is still valid - I can delay the reboot as long as I like and enter an additional, "safe" boot target into the grub or lilo setup.

YaST is still wasting /etc/lilo.conf and /boot/grub/menue.lst regularly in this case, but that is a different point if you need something to argue against the "quality" which I will not reflect upon here.

rpm -e --justdb kernel-$version should achieve the same; it is what I used until I settled for yum.

Splendid idea. Thanks.

On 11.x (with new enough libzypp, i.e. from 11.1 or newer), I use zypper with the new "multiversion" feature. It is simple to configure and does the job - Stano has blogged about it here: http://lizards.opensuse.org/2009/02/03/do-you-want-multiple-kernels-on-your-...

Viele Grüße Eberhard Mönkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Mönkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG) Am Fassberg 11, 37077 Göttingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschäftsführer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -------------------------------------------------------------------------

Hi, On Tue, 17 Feb 2009, Peter Poeml wrote:

On Tue, Feb 17, 2009 at 04:31:18PM +0100, Eberhard Moenkeberg wrote:

...

...

...

I can live with it, but it is nasty, and against YaST's philosophy.

If YOU is offering a kernel update, it brings a popup window. I then do

cd /lib/modules mkdir x cp -al `uname -r` x/ cd /boot mkdir x cp -a *`uname -r`* x/ cd /usr/src cp -al linux-`uname -r`* x/

then ack the popup, and after YOU has finished, I copy the saves back to ..

This way, my old, but running kernel is still valid - I can delay the reboot as long as I like and enter an additional, "safe" boot target into the grub or lilo setup.

YaST is still wasting /etc/lilo.conf and /boot/grub/menue.lst regularly in this case, but that is a different point if you need something to argue against the "quality" which I will not reflect upon here.

rpm -e --justdb kernel-$version should achieve the same; it is what I used until I settled for yum.

Splendid idea. Thanks.

--noscripts can be useful, as well. Otherwise the bootloader config might be touched, which poses a risk in itself. But the config needs to be closely watched anyway, if a kernel is going to be updated. (I forgot to mention it before.)

Oh yes, both /etc/lilo.conf and /boot/grub/menue.conf get mangled unusable currently if you have symlinks like "vmlinuz.old" and "vmlinuz.ori" for saved older kernels... I had entered https://bugzilla.novell.com/show_bug.cgi?id=410431 against it, but contrary to the last comment from 2008-09-19 no solution yet.

(And I routinely find myself deinstalling the suspend package; because it has a habit of recreating *all* initrds in its postinstall script, which I'm not fond of.)

Bugzilla ID? ... and the rpm -e --just-db" command should read in full: rpm -e --justdb --noscripts kernel-source kernel-<flavour> where <flavour> is default, xen, smp, bigsmp and so on. Viele Grüße Eberhard Mönkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Mönkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG) Am Fassberg 11, 37077 Göttingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschäftsführer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -------------------------------------------------------------------------

On 2009/02/04 15:35 (GMT-0500) Patrick Shanahan composed:

* Rob OpenSuSE [02-04-09 14:56]:

...

There's a risk to in updating old "stable" systems, if something goes wrong with an update to something critical like zypper, there will be a huge fuss.

...

Does the OP know how to work round the issue? If it is not obvious to him, finding a way, might make a backport seem less of an issue.

He "forgot" that 11.0 zypper did *not* keep replaced/updated kernels. He knows that rpm -i and smart are available and will accomplish what he wishes. BUT he has lost the kernel that *worked* for his environment. Thus the discussion.

When I wrote I expected I had lost the working kernel, but as it turns out I didn't. Zypper removed both official kernels, but left the ilya_41 2.6.27 kernel required for networking to be usable. Why it chose to leave or remove as it did I don't know. Was it because: 1-it left the kernel with the newest version? 2-it left the kernel with the newest build date? 3-it left the .27 kernel because it was not from a configured repository (installed via rpm directly)? I have a lot of machines. Those used more than the others mostly get booted to 11.1 or Factory. I just need to remember better to check what is booted before deciding what updater to invoke. I still like urpmi best, zypper least, but Smart on pre-11.1 still seems to get best openSUSE results. :-p -- "Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up." Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Wed, 4 Feb 2009, Rob OpenSuSE wrote:

Saying kernel updates are unlikely to break your box, is not going to silence demand for the feature. Explaining how it is possible to get same effect without the feature is.

For example: Dell PE 1650 and 2650 servers with onboard raid (aacraid module) using SLES10 still need the latest kernel from SP1 - all newer kernels (from SP2) have a broken aacraid driver. At least 5 broken kernel updates in sequence. All kernels are affected, not only SUSE. Viele Grüße Eberhard Mönkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Mönkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG) Am Fassberg 11, 37077 Göttingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschäftsführer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -------------------------------------------------------------------------