On Sunday 16 August 2009 13:47:30 Anders Johansson wrote:

On Sunday 16 August 2009 13:39:53 houghi wrote:

...

However, the pill could be a lot less bitter if there is a good and easy way to upgrade. Something like `apt-get upgrade`. Is such a thing underway?

I believe that is the idea behind "zypper dist-upgrade" (or zypper dup)

Correct, Andreas -- Andreas Jaeger, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Mon, Aug 17, 2009 at 01:52:36AM +0200, Javier Llorente wrote:

On Sunday 16 August 2009 13:39:53 houghi wrote:

...

However, the pill could be a lot less bitter if there is a good and easy way to upgrade. Something like `apt-get upgrade`. Is such a thing underway?

It's one of the top features on openFATE. https://features.opensuse.org/305634

Great, thanks. houghi -- You are standing at the end of a road before a small brick building. Around you is a forest. A small stream flows out of the building and down a gully. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Mon, 17 Aug 2009, Carlos E. R. wrote:

On Sunday, 2009-08-16 at 13:39 +0200, houghi wrote:

...

As from 11.2 there will be an 18 months support instead of the 24 previously.

That's bad news. :-(

Not if we have a tool to upgrade without server downtime. ;-)) Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Moenkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen (GWDG) Am Fassberg 11, 37077 Goettingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschaeftsfuehrer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe Sitz der Gesellschaft: Goettingen Registergericht: Goettingen Handelsregister-Nr. B 598 ------------------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, Aug 17, 2009 at 5:04 PM, Marco Calistri wrote:

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

- -------- Original Message  -------- Subject: Re: [opensuse-factory] 18 months of updates From: Eberhard Moenkeberg To: opensuse-factory@opensuse.org Date: 17/08/2009 17.57

...

Hi,

On Mon, 17 Aug 2009, Carlos E. R. wrote:

...

On Sunday, 2009-08-16 at 13:39 +0200, houghi wrote:

...

...

 As from 11.2 there will be an 18 months support instead of the 24  previously.

That's bad news. :-(

Not if we have a tool to upgrade without server downtime. ;-))

Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)

To me ending support life after 18 months, means no more updates available whatsoever.

Do I lost something?

BR,

- -- Marco Calistri <amdturion>

If you look at openfate, one of the top actions is getting zypper dup to work in a much more reliable way so that upgrades can occur without having to down servers, etc. They "may" be okay because the switch to KDE 4 seems to be almost complete. If you look back 18 months you are at 10.3 and I think a lot of users would be unhappy if they were forced to move away from that to 11.0 or 11.1 right now. ie. both have a bad "reputation" as relates to KDE. I personally most concerned with servers and I've been following a 18-20 month cycle on them, so I find 18 months to be uncomfortably short, but only by a month or two. As an example I have about half my servers on 11.1 and half on 11.0. Typically about 2 months after a release, I seriously consider updating the oldest set to current, so in this situation I would be upgrading 11.0 to 11.2. I would rather have 3 or 4 months to get that done, not just 2. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Greg Freemyer wrote:

They "may" be okay because the switch to KDE 4 seems to be almost complete. If you look back 18 months you are at 10.3 and I think a lot of users would be unhappy if they were forced to move away from that to 11.0 or 11.1 right now. ie. both have a bad "reputation" as relates to KDE.

I still see somewhat of a problem in 10.3, which my server is running, going out of support in October and 11.2 coming in November. If we had a 2 month overlap as is the plan usually, I would upgrade during that overlap time but with things the way they are, it feels sucky to upgrade to 11.1 right now, and also sucky to upgrade to 11.2 in December (after my 3-week vacation in November). I'd wish we had some overlap of 10.3 maintenance and 11.2 being final, just for security's sake. :-/ Robert Kaiser -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Original Message -------- Subject: Re: [opensuse-factory] 18 months of updates From: Bryen M Yunashko To: opensuse-factory@opensuse.org Date: 17/08/2009 18.22

On Mon, 2009-08-17 at 18:04 -0300, Marco Calistri wrote:

What he's saying is that with a better improved zypper with in-place live updating, it would be less painful for some people to update and the 18 or 24 months become less relevant.

Ok Bryen, now it seems to be more clear. Talking about an improved zypper, you mean that upgrading will continue, also after the new 18 months life-cycle? That's is, at the end, what I would hope be. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqJzmIACgkQi4zJuA3lyFdaOwCgoyYWmGcBszUlD7KWAe74w95f vYQAnArr4RRzdLC71P6R8rCjAbm7xrBi =Dggl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Quoting Bryen M Yunashko :

What he's saying is that with a better improved zypper with in-place live updating, it would be less painful for some people to update and the 18 or 24 months become less relevant.

That implies that if the `zypper dup` sucks, it will be relevant. Would it not be a good idea to say that if all is well, we go to 18 months, but if there are still serious issues, we stay with 24 months? What I mean is to still have an official statement of 18 months, but the realization that if there are issues, we still can go to 24 months for 11.2. With 11.3 these issues should be solved, so 18 months should not be an issue for 11.3 onward. houghi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Quoting Stephan Kulow :

...

Would it not be a good idea to say that if all is well, we go to 18 months, but if there are still serious issues, we stay with 24 months?

What I mean is to still have an official statement of 18 months, but the realization that if there are issues, we still can go to 24 months for 11.2.

That depends on how you define "we", Novell will not. If you wants to, I'm sure we (openSUSE) find a way.

I personally will not be the right person to do it. ;-) However if openSUSE has the ability to do this that would be great. Again: just if `zypper dup` does not work as expected and only for this one version. houghi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Original Message -------- Subject: Re: [opensuse-factory] 18 months of updates From: Eberhard Moenkeberg To: opensuse-factory@opensuse.org Date: 17/08/2009 18.39

Hi,

On Mon, 17 Aug 2009, Marco Calistri wrote:

If you have a tool which allows dist upgrade without server downtime, you can upgrade much easier than with the need to boot from installation medium.

After this, you will not need updates for the old version any longer, and you have newer version of lots of packages.

If plus or minus, just depends on the quality of the "dist upgrade" tool.

Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)

Thanks Eberhard, Dist-upgrade concept is now clear. But what happen to, for example, 11.0 kernel updates after 18 months? Cheers! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqJ1XcACgkQi4zJuA3lyFfy0wCfZw280fiu8Pu5X0tiITqlYKdF L88AnRRFVqWodsCIhLinpwd7A3DUQfFO =KtB9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, 2009-08-17 at 23:39 +0200, Eberhard Moenkeberg wrote:

...

...

Not if we have a tool to upgrade without server downtime. ;-))

...

Do I lost something?

If you have a tool which allows dist upgrade without server downtime, you can upgrade much easier than with the need to boot from installation medium.

Without _any_ downtime? You can bet there will be a kernel update, so going down is inevitable.. hw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Wed, 19 Aug 2009, Carlos E. R. wrote:

On Wednesday, 2009-08-19 at 00:11 +0200, Hans Witvliet wrote:

...

...

can upgrade much easier than with the need to boot from installation medium.

Without _any_ downtime?

You can bet there will be a kernel update, so going down is inevitable..

Not only that. Many programs get new configuration files, with the original one moved to a backup (.rpmold). Or the old one is preserved and the new one copied alongside (.rpmnew). In any case, the admin has got to review all those before the system is fully operational after the upgrade. Some services run perfectly the first moment, some others need a lot of reconfiguration.

So, yes, there is downtime.

Please stop suggesting "it is impossible to survive a dist upgrade". Usually you get a mail in every case of .rpmnew or .rpmold, so you can fix if necessary on-the-fly. Next we need the chance to survive during dist upgarade - noone is requesting 100% instantly. SLES/SLED claims to be "Enterprise", haha... Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Moenkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen (GWDG) Am Fassberg 11, 37077 Goettingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschaeftsfuehrer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe Sitz der Gesellschaft: Goettingen Registergericht: Goettingen Handelsregister-Nr. B 598 ------------------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Le mercredi 19 août 2009, à 22:33 +0200, Hans Witvliet a écrit :

So the limitation of the duration for support is in contrast with the request for LTS, like the five years offered by Ubuntu.

Not all Ubuntu releases are LTS. Normal releases have a 18-months support. See http://www.ubuntu.com/products/whatisubuntu/serveredition/benefits/lifecycle LTS releases have 5 years of support for the server, and 3 years for the desktop. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wed, 19 Aug 2009, Eberhard Moenkeberg wrote:

If I buy today a license for SLES10 and tomorrow SLES11 appears, my "old" license covers both and I can "reuse" it after upgrading.

Kind of. :-) You cannot buy licenses for SLES, but subscriptions. And you cannot buy a subscription for SLES 10, but for SLES (without reference to version number) which indeed you can then use for SLES 9, SLES 10, or SLES 11 on that machine.

And the biggest stone in this way currently is YaST's stupidity first deleting the current kernel modules and then telling "oops, you should reboot as soon as possible".

How can we best address this, technically? I'm a bit puzzled we still have not managed to have a simple PARALLEL_KERNELS=N option somewhere that would keep up to N kernels on a system. Would that address your usecase? Gerald -- Dr. Gerald Pfeifer E gp@novell.com SUSE Linux Products GmbH Director Product Management F +49(911)74053-483 HRB 16746 (AG Nuremberg) SUSE Linux Enterprise, openSUSE, Appliances GF Markus Rex -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Mon, 24 Aug 2009, Gerald Pfeifer wrote:

On Wed, 19 Aug 2009, Eberhard Moenkeberg wrote:

...

And the biggest stone in this way currently is YaST's stupidity first deleting the current kernel modules and then telling "oops, you should reboot as soon as possible".

How can we best address this, technically? I'm a bit puzzled we still have not managed to have a simple PARALLEL_KERNELS=N option somewhere that would keep up to N kernels on a system. Would that address your usecase?

Any solution which keeps the running kernel is a step forward. Lars Mueller has the deepest thoughts how to avoid flooding the filesystem with old kernels, I guess. Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Moenkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen (GWDG) Am Fassberg 11, 37077 Goettingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschaeftsfuehrer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe Sitz der Gesellschaft: Goettingen Registergericht: Goettingen Handelsregister-Nr. B 598 ------------------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wed, 2009-08-19 at 23:07 +0200, Graham Anderson wrote:

On Wednesday 19 August 2009 22:33:35 Hans Witvliet wrote:

...

SLES may probably have "enterprise support", but that's only within one release. A co-worker has to upgrade a couple of hundred machines with SLES running SAP. A very time consuming error-prone manual job, no smooth upgrade procedure.

While I can appreciate that It's a hard job to migrate servers running any SAP on *any* platform; _specifically_ what would make your job easier on suse? What automated tasks such as 'autoyast' system configuration don't meet your requirements?

Won't talk about sap@sles migration (as it's not a part of my job)... But now you mention autoyast: (though probably more intended for another list...) I build all my systems with xml-files, but found out that i had to re-create them each time over again from scratch. Obviously there are some part that change inherrently, eg the part where the installation-source is defined, (but that is understandable). Problems that spring to mind are: nfs-mountpoints often don't work (got a partially created fstab-file), same with post-installation scripts,... It's a fact of life i become to accept, but it's a waste of time. Hans -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Aug 19, 11:07pm, Graham Anderson wrote:

While I can appreciate that It's a hard job to migrate servers running any SAP on *any* platform; _specifically_ what would make your job easier on suse? What automated tasks such as 'autoyast' system configuration don't meet your requirements?

Something that would make updating far easier is what I've seen on other systems (Gentoo and NetBSD at least): etc_update, which is a tool that makes it easy to merge old/new config files. Steve -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Wed, 19 Aug 2009, Hans Witvliet wrote:

On Mon, 2009-08-17 at 23:39 +0200, Eberhard Moenkeberg wrote:

...

...

...

Not if we have a tool to upgrade without server downtime. ;-))

...

...

Do I lost something?

Maybe your human naivity which should get held strong...

...

If you have a tool which allows dist upgrade without server downtime, you can upgrade much easier than with the need to boot from installation medium.

Without _any_ downtime?

You can bet there will be a kernel update, so going down is inevitable..

Of course, but please read Lars Mueller's struggling for a betterness which is already there but unused. Usually you can't reboot a server just-in-time when YaST is telling you to do it, but usually you can reboot a server at a time you have freely chosen. So from this view, the SUSE task is simple: enable YaST to not hurt a running system during kernel updates. BTW: if I remember right (I do!), Lars Mueller was worldwide the only guy who could show an uptime of > 300 days after dist upgrade with change from glibc 2.5 to glibc 2.6 or other numbers, it was about the change 4.4.1 -> 5.0 or 5.x -> 6.0, maybe ten or more years ago... Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Moenkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen (GWDG) Am Fassberg 11, 37077 Goettingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschaeftsfuehrer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe Sitz der Gesellschaft: Goettingen Registergericht: Goettingen Handelsregister-Nr. B 598 ------------------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Mon, 17 Aug 2009, Patrick Shanahan wrote:

* Eberhard Moenkeberg [08-17-09 16:59]:

...

On Mon, 17 Aug 2009, Carlos E. R. wrote:

...

On Sunday, 2009-08-16 at 13:39 +0200, houghi wrote:

...

...

...

As from 11.2 there will be an 18 months support instead of the 24 previously.

That's bad news. :-(

Not if we have a tool to upgrade without server downtime. ;-))

Is it no longer necessary to reboot when a new kernel version is installed?

It will probably still be necessary "by system", but it is already currently not necessary if you do by hand: cd /lib/modues mkdir x cp -al `uname -r` x/ cd /boot mkdir x cp -a *`uname -r`* x/ cd /usr/src mkdir x cp -al linux-`uname -r`* x/ before doing the update and after doing the removes to the original locations. Hopefully SUSE's struggling for a "smooth" kernel update (without loss of the running kernel modules) will bring fruit in time. We are lacking this "system feature" far too long already. Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Moenkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen (GWDG) Am Fassberg 11, 37077 Goettingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschaeftsfuehrer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe Sitz der Gesellschaft: Goettingen Registergericht: Goettingen Handelsregister-Nr. B 598 ------------------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Mon, 17 Aug 2009, Greg KH wrote:

On Tue, Aug 18, 2009 at 02:15:13AM +0200, Eberhard Moenkeberg wrote:

...

On Mon, 17 Aug 2009, Patrick Shanahan wrote:

...

* Eberhard Moenkeberg [08-17-09 16:59]:

...

On Mon, 17 Aug 2009, Carlos E. R. wrote:

...

On Sunday, 2009-08-16 at 13:39 +0200, houghi wrote:

...

...

...

...

...

As from 11.2 there will be an 18 months support instead of the 24 previously.

That's bad news. :-(

Not if we have a tool to upgrade without server downtime. ;-))

Is it no longer necessary to reboot when a new kernel version is installed?

It will probably still be necessary "by system", but it is already currently not necessary if you do by hand:

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

before doing the update and after doing the removes to the original locations.

Hopefully SUSE's struggling for a "smooth" kernel update (without loss of the running kernel modules) will bring fruit in time. We are lacking this "system feature" far too long already.

No need to jump through those crazy hoops, you can just tell zypper to keep the last kernel around, that feature has been present for quite some time now.

Surely, but to land "positive" within the communitxy with this, YaST2 should have this capability too. SUSE has promoted YaST for years (more than 10), and finally now it seems to have gained acceptance even "outside", so please continue to let it be the best tool for system maintenance.. Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Moenkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen (GWDG) Am Fassberg 11, 37077 Goettingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschaeftsfuehrer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe Sitz der Gesellschaft: Goettingen Registergericht: Goettingen Handelsregister-Nr. B 598 ------------------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Mon, 17 Aug 2009, Greg KH wrote:

On Tue, Aug 18, 2009 at 02:41:30AM +0200, Eberhard Moenkeberg wrote:

...

On Mon, 17 Aug 2009, Greg KH wrote:

...

On Tue, Aug 18, 2009 at 02:15:13AM +0200, Eberhard Moenkeberg wrote:

...

On Mon, 17 Aug 2009, Patrick Shanahan wrote:

...

* Eberhard Moenkeberg [08-17-09 16:59]:

...

On Mon, 17 Aug 2009, Carlos E. R. wrote: > On Sunday, 2009-08-16 at 13:39 +0200, houghi wrote:

...

...

...

...

...

>> As from 11.2 there will be an 18 months support instead of the 24 >> previously. > > That's bad news. :-(

Not if we have a tool to upgrade without server downtime. ;-))

Is it no longer necessary to reboot when a new kernel version is installed?

It will probably still be necessary "by system", but it is already currently not necessary if you do by hand:

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

before doing the update and after doing the removes to the original locations.

Hopefully SUSE's struggling for a "smooth" kernel update (without loss of the running kernel modules) will bring fruit in time. We are lacking this "system feature" far too long already.

No need to jump through those crazy hoops, you can just tell zypper to keep the last kernel around, that feature has been present for quite some time now.

Surely, but to land "positive" within the communitxy with this, YaST2 should have this capability too.

SUSE has promoted YaST for years (more than 10), and finally now it seems to have gained acceptance even "outside", so please continue to let it be the best tool for system maintenance..

Yast uses zypper to update packages...

But to keep the running kernel still has to get implemented... Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Moenkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen (GWDG) Am Fassberg 11, 37077 Goettingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschaeftsfuehrer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe Sitz der Gesellschaft: Goettingen Registergericht: Goettingen Handelsregister-Nr. B 598 ------------------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, Aug 18, 2009 at 08:36:22PM +0200, Lars Müller wrote:

It was suggested several times to always keep the currently running kernel and to install the new one in addition only. A member of the SUSE feature heaven decided this isn't required.

Then open a new fate entry to try to convince the powers-that-be to change this default value. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Tue, 18 Aug 2009, Lars Müller wrote:

On Tue, Aug 18, 2009 at 11:44:24AM -0700, Greg KH wrote:

...

On Tue, Aug 18, 2009 at 08:36:22PM +0200, Lars Müller wrote:

...

...

It was suggested several times to always keep the currently running kernel and to install the new one in addition only. A member of the SUSE feature heaven decided this isn't required.

Then open a new fate entry to try to convince the powers-that-be to change this default value.

Honestly I tried to explain the need at the time of the very, very old feature document, next by using bugzilla, then gave it a try with FATE, to finally find me with this topic back at bugzilla after several years.

The final result: nobody needs this.

Therefore I'm each time a little bit unhappily "satisfied" while reading again about the trouble this piece of sugar is able to cause.

The kind of trouble is nothing which happens with every kernel update. Maybe it happens only one time of 1000 updates. But if it happens it causes stress to the administrator. Cause then you have no bootable media at hand or the available kernel modules don't work with the used kernel.

If this happened once to you with a server many people depend and rely on you're quite happy if you're able to get the system up again immediatly. And you're more happy and relaxed if you don't have to bother with bootable CD or DVD medias.

I'm sure the required efforts are _not_ a question of a weekend hack session. The required changes need to consider several different boot loaders (LILO, GRUB, ELILO, PowerLILO, ZIPL) and they require testing.

While writing this I'm more and more convinced the pain isn't (yet) big enough.

If anyone else shares my general point of view I'm happy to work on a patch as the current approach still causes some extra work if you have to maintain several systems. And it's my intention to get rid of this superfluous, time-consuming, and boring tasks.

I would be glad if I could forget my silly workaround some day... Currently not even "enterprise" SUSE Linux is able to keep a running system sane after updating a kernel with YaST Online Update. Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Moenkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen (GWDG) Am Fassberg 11, 37077 Goettingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschaeftsfuehrer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe Sitz der Gesellschaft: Goettingen Registergericht: Goettingen Handelsregister-Nr. B 598 -------------------------------------------------------------------------

This really should be default, a package manager should never change my kernel. Ie. SLES 10 does not have updated drivers for my nic card, so I had to create a e1000e rpm for my kernel. I update packages using zypper, and it upgrades my kernel, but the module does not get recompiled. Without local access to the device, it is now hard down. sharms On Tue, Aug 18, 2009 at 2:49 PM, jdd wrote:

...

More useful options needed/ possible?

Some of you might need to boot a rescue system from time to time.

more.

My hosting provider use special hardware. They have all the necessary drivers compiled *hard* in the kernel - so no other kernel allowed.

They work well, new kernels are available when necessary. I can even boot them from netboot as rescue;

However this make some utilities not to work well. SuSEfirewall being one of them.

So any update/upgrade *must* take in account than the booting kernel may not be the exact one it use to be. This is needed for whatever kernel install is not exactly the original one.

This provider boots with lilo :-)) grub don't work there :-!

jdd

-- http://www.dodin.net http://valerie.dodin.org http://news.opensuse.org/2009/04/13/people-of-opensuse-jean-daniel-dodin/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Tue, 18 Aug 2009, Rajko M. wrote:

On Tuesday 18 August 2009 01:58:06 pm Steven Harms wrote:

...

This really should be default, a package manager should never change my kernel. ...

Kernel update is done to close security holes or fix problem that affects large number of users, so default not to touch is plain wrong for majority.

Those that need "don't update kernel" can taboo kernel package, and YOU/zypper will not touch it.

You are missing the point. We don't want a smooth workaround about all steps and stones, but a solid procedure: "My server needs to continue running". Until I decide to reboot, not YaST.

The multiversion feature of zypper solves problem that user can have when new kernel is not good for particular system, make the old one default, let updates come and test them, until there is one that works for you.

I see this on three HP servers here currently since the first kernel of SLES10-SP2, I have seen this at beginning of SLES10-SP2 with all my Dell PE1650 and PE2650 servers with aacraid driver, and so on.

The only missing feature would be simplified user interface in a YaST Bootloader module, so that users don't have to go to geekish display as it is now, to change defaults. In other words, 2 sets of settings, simple for Joe_That_Is_Not_Geek, by any stretch of imagination, that will go to Bootloader module only if some kind soul tells him that such thing exists, and advanced for the rest.

We need a YaST not destroying the "surviveabilty" of the running system during kernel updates. "Enterprise", haha... Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Moenkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen (GWDG) Am Fassberg 11, 37077 Goettingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschaeftsfuehrer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe Sitz der Gesellschaft: Goettingen Registergericht: Goettingen Handelsregister-Nr. B 598 ------------------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

...

...

On 19/08/2009 at 2:34 AM, Eberhard Moenkeberg wrote: You are missing the point. We don't want a smooth workaround about all steps and stones, but a solid procedure:

"My server needs to continue running". Until I decide to reboot, not YaST.

Why don't you, as the admin of that server, not schedule the updates with kernels in a specific way? We know that replacing the kernel requires reboot, yast says so, zypper says so and it's nothing new (just as you also have to reboot your system when the hardware vendor told you to update the bios..). I would never have a cron job taking care of updates without my approval. And yes, we do have more than one server here. And no: they are not outdated. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, Aug 18, 2009 at 07:24:20PM -0500, Rajko M. wrote:

Kernel update is done to close security holes or fix problem that affects large number of users, so default not to touch is plain wrong for majority.

ack

Those that need "don't update kernel" can taboo kernel package, and YOU/zypper will not touch it.

The multiversion feature of zypper solves problem that user can have when new kernel is not good for particular system, make the old one default, let updates come and test them, until there is one that works for you.

One thing I don't understand about the multiversion feature (and "man zypper" doesn't help the least): how many is "multi"? Is it 2, N, or infinite? If it is infinite, then this feature doesn't provide what a "normal user" expects. Ciao Joerg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wed, Aug 19, 2009 at 10:02:52AM +0200, Joerg Mayer wrote: [ 8< ]

One thing I don't understand about the multiversion feature (and "man zypper" doesn't help the least): how many is "multi"? Is it 2, N, or infinite? If it is infinite, then this feature doesn't provide what a "normal user" expects.

Unfortunately at the moment it is infinite. That's why there is a risk to flood the /boot/ device. To get the potential issue fixed it's not a question of a static defined number of kernel packages which are kept. We must not remove the currently running kernel. That is priority number one as this kernel is known to work. We might need this one of the new kernel fails to boot. We also need to keep it installed to have fitting kernel modules available. It's not possible to immediately reboot in any use case. As a reasonable default I would keep 2 kernel package sets (the running and the new). In my mind one kernel package set might consist of several different kernel sub packages which all share the same version and release (kernel-default, kernel-default-base, kernel-default-extra, kernel-pae, kernel-pae-base, kernel-pae-extra, and so on). Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

* Greg KH [08-17-09 20:31]:

No need to jump through those crazy hoops, you can just tell zypper to keep the last kernel around, that feature has been present for quite some time now.

I *know* about keeping the previous kernels and do it for safety's sake. If I don't have problems after some time, I remove the 4th back just for space. What I wonder is how to make the *new* kernel active w/o rebooting? -- 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

On 2009/08/17 22:23 (GMT-0400) Patrick Shanahan composed:

What I wonder is how to make the *new* kernel active w/o rebooting?

I doubt that's possible, but you can speed up a reboot with kexec: http://en.opensuse.org/Kexec -- How much better to get wisdom than gold, to choose understanding rather than silver. Proverbs 16:16 NKJV 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

On Tuesday 18 August 2009 04:23:28 Patrick Shanahan wrote:

What I wonder is how to make the *new* kernel active w/o rebooting?

I'm not sure you can without using something funky like ksplice, and i'm not even sure that's available for other kernels other than Ubuntu at the moment. The fastest reboot option would be kexec though. from man: EXAMPLE For example, if the kernel image you want to reboot to is /boot/vmlinux, the contents of /proc/cmdline is root=/dev/hda1, and the path to the initrd is /boot/initrd, then you would use the following command to load the kernel: kexec -l /boot/vmlinux --append=root=/dev/hda1 --initrd=/boot/initrd After this kernel is loaded, it can be booted to at any time using the command: kexec -e -- “Experience is the name everyone gives to their mistakes.” ☘ Oscar Wilde -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 08/18/2009 04:51 AM, Graham Anderson wrote:

On Tuesday 18 August 2009 04:23:28 Patrick Shanahan wrote:

...

What I wonder is how to make the *new* kernel active w/o rebooting?

I'm not sure you can without using something funky like ksplice, and i'm not even sure that's available for other kernels other than Ubuntu at the moment.

The fastest reboot option would be kexec though.

from man:

EXAMPLE For example, if the kernel image you want to reboot to is /boot/vmlinux, the contents of /proc/cmdline is root=/dev/hda1, and the path to the initrd is /boot/initrd, then you would use the following command to load the kernel:

kexec -l /boot/vmlinux --append=root=/dev/hda1 --initrd=/boot/initrd

After this kernel is loaded, it can be booted to at any time using the command:

kexec -e

kexec actually bypasses grub as well and can be used from the rescue system when grub has failed. Regards Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org