When I update a kernel using urpmi in Mandriva, it defaults to saving the old kernel and modules, so that it is easy to switch back to the old one if some compatibility issue arises. That's a whole lot easier than trying to get an old kernel reinstalled to get a problem system back in operation. I can't see any way to do this in YOU in 10.0. Is there some convenient (not command line rpm) way to do this in SuSE? -- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/auth/
On Sat January 14 2006 12:42 pm, Felix Miata wrote:
When I update a kernel using urpmi in Mandriva, it defaults to saving the old kernel and modules, so that it is easy to switch back to the old one if some compatibility issue arises. That's a whole lot easier than trying to get an old kernel reinstalled to get a problem system back in operation. I can't see any way to do this in YOU in 10.0. Is there some convenient (not command line rpm) way to do this in SuSE?
you might try using rsync, cp or the file manager and copy the files from /boot to someplace else BEFORE you update the kernel... just copy them back if you have issues with the new setup. -- Paul Cartwright Registered Linux user # 367800
On Saturday 14 January 2006 12:08 pm, Paul Cartwright wrote:
On Sat January 14 2006 12:42 pm, Felix Miata wrote:
When I update a kernel using urpmi in Mandriva, it defaults to saving the old kernel and modules, so that it is easy to switch back to the old one if some compatibility issue arises. That's a whole lot easier than trying to get an old kernel reinstalled to get a problem system back in operation. I can't see any way to do this in YOU in 10.0. Is there some convenient (not command line rpm) way to do this in SuSE?
you might try using rsync, cp or the file manager and copy the files from /boot to someplace else BEFORE you update the kernel... just copy them back if you have issues with the new setup.
Paul Cartwright
Or copy them in /boot to a different file name and add that name and associated parameters as another choice in the /boot/grub/menu.lst file. Stan
Stan Glasoe wrote:
On Saturday 14 January 2006 12:08 pm, Paul Cartwright wrote:
On Sat January 14 2006 12:42 pm, Felix Miata wrote:
When I update a kernel using urpmi in Mandriva, it defaults to saving the old kernel and modules, so that it is easy to switch back to the old one if some compatibility issue arises. That's a whole lot easier than trying to get an old kernel reinstalled to get a problem system back in operation. I can't see any way to do this in YOU in 10.0. Is there some convenient (not command line rpm) way to do this in SuSE?
you might try using rsync, cp or the file manager and copy the files from /boot to someplace else BEFORE you update the kernel... just copy them back if you have issues with the new setup.
I would use none of the above, but instead mc, far easier when dealing with multiple files scattered in various locations.
Or copy them in /boot to a different file name and add that name and associated parameters as another choice in the /boot/grub/menu.lst file.
Different names might be easy enough for files in /boot, but it would be unwieldy for the content of /lib/modules/2.6*. Any of the suggested copy/rename schemes would put the installed software and rpm database in an out of sync condition, which is why I asked in the first place, wishing not to have any such condition. -- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/
Felix, On Saturday 14 January 2006 18:02, Felix Miata wrote:
Stan Glasoe wrote:
...
you might try using rsync, cp or the file manager and copy the files from /boot to someplace else BEFORE you update the kernel... just copy them back if you have issues with the new setup.
I would use none of the above, but instead mc, far easier when dealing with multiple files scattered in various locations.
That's exactly when a CLI tool--scripted, of course--makes far _more_ sense than a GUI or semi-GUI (such as midnight commander).
...
Felix Miata
Randall Schulz
On Saturday 14 January 2006 22:22, Randall R Schulz wrote:
That's exactly when a CLI tool--scripted, of course--makes far _more_ sense than a GUI or semi-GUI (such as midnight commander).
Why not, as root /at/ root: cp -rp /boot /bootbak ? I just checked in /lib/modules and it appears every previous kernel configuration is still there in it's own directory, I assume preserved in the event a rollback is necessary. - Carl
Carl, On Saturday 14 January 2006 19:43, Carl Hartung wrote:
On Saturday 14 January 2006 22:22, Randall R Schulz wrote:
That's exactly when a CLI tool--scripted, of course--makes far _more_ sense than a GUI or semi-GUI (such as midnight commander).
Why not, as root /at/ root: cp -rp /boot /bootbak ? I just checked in /lib/modules and it appears every previous kernel configuration is still there in it's own directory, I assume preserved in the event a rollback is necessary.
This seems to me to be a non-sequitur. (And there is such a thing as _too much_ quote trimming.) I was responding in the contrary to Felix's suggestion that Midnight Commander was preferable "when dealing with multiple files scattered in various locations"
- Carl
Randall Schulz
On Saturday 14 January 2006 23:46, Randall R Schulz wrote:
I was responding in the contrary to Felix's suggestion that Midnight Commander was preferable "when dealing with multiple files scattered in various locations"
Hi Randall, I actually knew that. I suppose I should have hung my reply directly on Felix's post, but my question was a genuine one. I've never actually had to do it, so I figured I'd ask. You know, of course, getting slapped around on this list for making a dumb suggestion is actually a lot less painful than having to rebuild your system after an ill-advised CLI operation. ;-) Is it safe to conclude that the alternative I suggested is a reasonable approach? - Carl
On Saturday 14 January 2006 22:43, Carl Hartung wrote:
Why not, as root /at/ root: cp -rp /boot /bootbak ? I just checked in /lib/modules and it appears every previous kernel configuration is still there in it's own directory, I assume preserved in the event a rollback is necessary.
Re-reading your earlier post, Felix, I see you're concerned that reverting to a previous kernel puts the rpm database out of sync with the installed system. I don't know why you'd rule out using CLI rpm tools (the --force and --justdb options will solve this problem) but running the system in that state until you've sorted the newer kernel problem(s) out seems a minor inconvenience -- particularly when it is so readily resolved. Is this your way of suggesting a new 'rollback' feature?... one comparable to the one offered in Mandriva? - Carl
Carl Hartung wrote:
On Saturday 14 January 2006 22:43, Carl Hartung wrote:
Re-reading your earlier post, Felix, I see you're concerned that reverting to a previous kernel puts the rpm database out of sync with the installed system. I don't know why you'd rule out using CLI rpm tools (the --force and --justdb options will solve this problem) but running the system in that state until you've sorted the newer kernel problem(s) out seems a minor inconvenience -- particularly when it is so readily resolved.
It's more readily resolved by leaving it installed, including in menu.lst, in the first place, which is what Mandriva's URPMI does by default. I would expect no less from YOU, but it apparently disappoints in this regard.
Is this your way of suggesting a new 'rollback' feature?... one comparable to the one offered in Mandriva?
I know how to use Bugzilla if it becomes appropriate, but that it is not for discovering functional existing features, which is what my OP asked about. If the answers I've seen already are any indication, I will be needing to find or file such a bug as my OP asks about. -- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/auth/
On Sunday 15 January 2006 00:08, Felix Miata wrote:
On Saturday 14 January 2006 22:43, Carl Hartung wrote:
Re-reading your earlier post, Felix, I see you're concerned that reverting to a previous kernel puts the rpm database out of sync with the installed system. I don't know why you'd rule out using CLI rpm tools (the --force and --justdb options will solve this problem) but running the system in that state until you've sorted the newer kernel problem(s) out seems a minor inconvenience -- particularly when it is so readily resolved.
It's more readily resolved by leaving it installed, including in menu.lst, in the first place, which is what Mandriva's URPMI does by default. I would expect no less from YOU, but it apparently disappoints in this regard.
Could you please be more precise than "it"? It seems we keep shifting focus between keeping the rpm database in sync with the active kernel and the actual mechanics of rolling the kernel forward and back. Pardon my ignorance, but I'm not familiar with Mandriva. Are you saying they've got kernel 'update' and 'rollback' functions which automatically keep the rpm database in sync?
Is this your way of suggesting a new 'rollback' feature?... one comparable to the one offered in Mandriva?
I know how to use Bugzilla if it becomes appropriate, but that it is not for discovering functional existing features, which is what my OP asked about.
I read your OP and the problem, IMHO, is the way you worded it... I misinterpreted your question until I read it a second and third time. I only did /that/ because the direction you were pulling the thread started to confuse me. I figured I must have missed /something/ and, sure enough, I had.
If the answers I've seen already are any indication, I will be needing to find or file such a bug as my OP asks about.
The opensuse list is appropriate for a topic like this. There is also the opensuse.org website. I think there are links there to pages where you can post feature requests for future releases. Have you considered taking that route? regards, - Carl
Carl Hartung wrote:
On Sunday 15 January 2006 00:08, Felix Miata wrote:
It's more readily resolved by leaving it installed, including in menu.lst, in the first place, which is what Mandriva's URPMI does by default. I would expect no less from YOU, but it apparently disappoints in this regard.
Could you please be more precise than "it"? It seems we keep shifting focus between keeping the rpm database in sync with the active kernel and the actual mechanics of rolling the kernel forward and back.
It == existing kernel, initrd, and matching module cast.
Pardon my ignorance, but I'm not familiar with Mandriva. Are you saying they've got kernel 'update' and 'rollback' functions which automatically keep the rpm database in sync?
By default, an upgrade kernel installation only adds a new kernel package (and IIRC, makes it the default boot kernel). It does not remove the existing kernel, initrd, or module tree.
If the answers I've seen already are any indication, I will be needing to find or file such a bug as my OP asks about.
The opensuse list is appropriate for a topic like this. There is also the opensuse.org website. I think there are links there to pages where you can post feature requests for future releases. Have you considered taking that route?
One normally reserves addition or change requests for a next version only for what cannot be accomplished in a current version. I've not quite yet seen conclusive evidence that will be necessary on this topic. -- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/auth/
On Sunday 15 January 2006 01:44, Felix Miata wrote:
It == existing kernel, initrd, and matching module cast.
I've never come across a YaST2 function in YOU or Install/Remove Software (now Software Management) providing one-click reversals of kernel upgrades. It stands to reason that if one doesn't exist it can't be tied into rpm to keep the database in sync.
Pardon my ignorance, but I'm not familiar with Mandriva. Are you saying they've got kernel 'update' and 'rollback' functions which automatically keep the rpm database in sync?
By default, an upgrade kernel installation only adds a new kernel package (and IIRC, makes it the default boot kernel). It does not remove the existing kernel, initrd, or module tree.
This doesn't answer my question concerning Mandriva.
One normally reserves addition or change requests for a next version only for what cannot be accomplished in a current version. I've not quite yet seen conclusive evidence that will be necessary on this topic.
SUSE won't retrofit a released version... I know you know that... the bottom line is you aren't convinced that a "non rpm command line" solution doesn't exist to address this scenario. It's hard to prove a negative, Felix, but I've never seen any indication that the function you're after exists. regards, - Carl
Carl Hartung wrote:
On Sunday 15 January 2006 01:44, Felix Miata wrote:
It == existing kernel, initrd, and matching module cast.
I've never come across a YaST2 function in YOU or Install/Remove Software (now Software Management) providing one-click reversals of kernel upgrades. It stands to reason that if one doesn't exist it can't be tied into rpm to keep the database in sync.
There's nothing to rollback or reverse when a kernel package is added rather than replaced. My original query is about installing an additional/new package, not a package replacement update/upgrade.
Pardon my ignorance, but I'm not familiar with Mandriva. Are you saying they've got kernel 'update' and 'rollback' functions which automatically keep the rpm database in sync?
By default, an upgrade kernel installation only adds a new kernel package (and IIRC, makes it the default boot kernel). It does not remove the existing kernel, initrd, or module tree.
This doesn't answer my question concerning Mandriva.
Then I guess I don't understand your question. What Mandriva does parallels compat-libstdc++ and libstdc++, which when installed coexist. Apps that need one or the other simply use whichever they need. With coexisting kernels, one simply chooses whichever one wants from the Grub menu at boot time.
One normally reserves addition or change requests for a next version only for what cannot be accomplished in a current version. I've not quite yet seen conclusive evidence that will be necessary on this topic.
SUSE won't retrofit a released version... I know you know that... the bottom line is you aren't convinced that a "non rpm command line" solution doesn't exist to address this scenario. It's hard to prove a negative, Felix, but I've never seen any indication that the function you're after exists.
Only Schulz and you have responded to this thread with any substance, and neither have an email address or any other direct indication that your responses should be authoritative. I'm surprised to find the apparent lack of this function, given its usefulness in defending against incompatabilities in replacement kernels, and SuSE's otherwise superior polish and function to other major distros in most regards. -- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/auth/
On Sunday 15 January 2006 08:10, Felix Miata wrote:
There's nothing to rollback or reverse when a kernel package is added rather than replaced. My original query is about installing an additional/new package, not a package replacement update/upgrade.
Thanks, Felix, I think we're getting somewhere. I suspect most people on this list would interpret your original question as I did, along this vein: A scenario where you've applied a kernel update with YOU that somehow breaks your system... you're seeking a "non rpm command line" solution, i.e. a graphical function in YOU or YaST2 to completely reverse the update including keeping the rpm database in sync. Now, after much digging, it seems you are actually talking about something related, but completely different: You want to add and have the option to boot from alternative kernels in such a way that, when booted, the appropriate differences are automatically reflected in the (active?) rpm database. Is this correct? - Carl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-01-15 at 09:44 -0500, Carl Hartung wrote:
Thanks, Felix, I think we're getting somewhere.
I suspect most people on this list would interpret your original question as I did, along this vein:
A scenario where you've applied a kernel update with YOU that somehow breaks your system... you're seeking a "non rpm command line" solution, i.e. a graphical function in YOU or YaST2 to completely reverse the update including keeping the rpm database in sync.
That Yast does readily: it will replace the existing rpm by the one you force, even if older.
Now, after much digging, it seems you are actually talking about something related, but completely different:
You want to add and have the option to boot from alternative kernels in such a way that, when booted, the appropriate differences are automatically reflected in the (active?) rpm database.
I understood he asked about what what Anders wrote a moment ago, in his first paragraph, using rpm -i instead of -U. There is nothing to reflect in the rpm database at boot time: simply, the database knows there are two kernel versions installed. No problemo :-) - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDymf+tTMYHG2NR9URAsK+AJ9oLj0QlL+CZnFdTSjPpqthZY028gCgh58j 3nfcHvBKsCgu4RZb6NyrNh0= =1EgH -----END PGP SIGNATURE-----
On Sunday 15 January 2006 10:19, Carlos E. R. wrote:
A scenario where you've applied a kernel update with YOU that somehow breaks your system... you're seeking a "non rpm command line" solution, i.e. a graphical function in YOU or YaST2 to completely reverse the update including keeping the rpm database in sync.
That Yast does readily: it will replace the existing rpm by the one you force, even if older.
Yes, but the 'spirit' of Felix's question was "Where is the button in YOU to select this arrangement when I'm installing a kernel update?" The operative phrase in my scenario, above, is "graphical function"... meaning predefined and automatic, not requiring a lot of decisions or manual intervention.
I understood he asked about what what Anders wrote a moment ago, in his first paragraph, using rpm -i instead of -U.
Except, of course, for the fact that his original inquiry was about a "non rpm command line" solution.
There is nothing to reflect in the rpm database at boot time: simply, the database knows there are two kernel versions installed. No problemo :-)
Preaching to the choir, Sir! regards, - Carl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-01-15 at 12:30 -0500, Carl Hartung wrote:
Yes, but the 'spirit' of Felix's question was "Where is the button in YOU to select this arrangement when I'm installing a kernel update?" The operative phrase in my scenario, above, is "graphical function"... meaning predefined and automatic, not requiring a lot of decisions or manual intervention.
I know, and I said there is no such thing: you can replace kernels, or do nothing, that's all.
I understood he asked about what what Anders wrote a moment ago, in his first paragraph, using rpm -i instead of -U.
Except, of course, for the fact that his original inquiry was about a "non rpm command line" solution.
I know, and I said there is no such thing - bis ;-) - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDypnUtTMYHG2NR9URApBYAJ0bqyCwzkYTX3Ck4crHGJ+zfAMKpACfdKRg 7n/q9oHZEvXPjaQcqC/PYS8= =Gbqr -----END PGP SIGNATURE-----
Carl Hartung wrote Sun, 15 Jan 2006 12:30:09 -0500:
On Sunday 15 January 2006 10:19, Carlos E. R. wrote:
That Yast does readily: it will replace the existing rpm by the one you force, even if older.
Yes, but the 'spirit' of Felix's question was "Where is the button in YOU to select this arrangement when I'm installing a kernel update?" The operative phrase in my scenario, above, is "graphical function"... meaning predefined and automatic, not requiring a lot of decisions or manual intervention.
Exactly!
I understood he asked about what what Anders wrote a moment ago, in his first paragraph, using rpm -i instead of -U.
Except, of course, for the fact that his original inquiry was about a "non rpm command line" solution.
Yes, and for more reasons than might be apparent. I think most of us forget how simple YOU makes our lives. YOU not only installs, if finds, checks deps, and downloads. To use rpm instead of YOU, one must first find the appropriate RPM, then download it, attempt to install it, and then when it complains about some unavailable dep update like hal or udev, start all over again. Once success is achieved, one must then do the cleanup manually that YOU also does automatically. -- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/auth/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-01-18 at 09:00 -0500, Felix Miata wrote:
Yes, but the 'spirit' of Felix's question was "Where is the button in YOU to select this arrangement when I'm installing a kernel update?" The operative phrase in my scenario, above, is "graphical function"... meaning predefined and automatic, not requiring a lot of decisions or manual intervention.
Exactly!
I know that. But I already said it doesn't exist, and the only way to get that behaviour is to update the kernel from the command line. That's the way it is, sorry. So, your only option is to request that button for the next version of SuSE. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDztaUtTMYHG2NR9URAie1AJ9DhhP8dY4icjo0fwgADFPUAlqLmwCfVSbm mI6GKMjsSfpg7+5I/DXlh1E= =/uEV -----END PGP SIGNATURE-----
On Sun, 2006-01-15 at 09:44 -0500, Carl Hartung wrote:
On Sunday 15 January 2006 08:10, Felix Miata wrote:
There's nothing to rollback or reverse when a kernel package is added rather than replaced. My original query is about installing an additional/new package, not a package replacement update/upgrade.
Thanks, Felix, I think we're getting somewhere.
I suspect most people on this list would interpret your original question as I did, along this vein:
A scenario where you've applied a kernel update with YOU that somehow breaks your system... you're seeking a "non rpm command line" solution, i.e. a graphical function in YOU or YaST2 to completely reverse the update including keeping the rpm database in sync.
Now, after much digging, it seems you are actually talking about something related, but completely different:
You want to add and have the option to boot from alternative kernels in such a way that, when booted, the appropriate differences are automatically reflected in the (active?) rpm database.
Having just changed to Suse after using Mandrake/Mandriva since its
beginings I think I can comment on this. Urpmi is configured, by
default, to install and not update kernels. The old kernel is added to
the boot list, giving you the possibility of getting the machine going
if the new kernel gives problems.
That said, in the case of kernel source it just upgrades, you could
therefore be in the situation of kernel and kernel source being out of
sync.
The existance of 2 different kernels gives no problem.
I must say when I first did an update on Suse I was a little scared by
the default action.
--
Dave Cotton
Dave Cotton wrote Sun, 15 Jan 2006 16:29:43 +0100:
Having just changed to Suse after using Mandrake/Mandriva since its beginings I think I can comment on this.
Here's the install path I've trod: 2.0.35 199808 RedHat 5.2 apollo 2.2.12 199909 RedHat 6.1 cartman 2.2.12? Corel 1.0 2.2.14 200001 Mandrake 7.0 2.2.14 200003 Corel 1.1 2.2.14 200003 RedHat 6.2 zoot 2.2.14 200005 Mandrake 7.1 2.? 200103 Mandrake 8.0 2.2.16 200007 Corel 1.2 2.4.8 200109 Mandrake 8.1 2.4.13 200112 Caldera 3.1.1 2.4.18 200203 Mandrake 8.2 2.4.18 200204 RedHat 7.3 valhalla 2.4.18 200204 SuSE 8.0 2.4.18 200209 RedHat 8.0 psyche 2.4.19 200209 Mandrake 9.0 2.4.19 200210 SuSE 8.1 2.4.20 200303 RedHat 9.0 shrike 2.4.20 200304 SuSE 8.2 2.4.21 200303 Mandrake 9.1 2.4.21 200311 SuSE 9.0 2.4.22 200309 Mandrake 9.2 2.4.22 200311 Fedora Core 1 yarrow 2.4.24 200403 Xandros 2 2.6.3 200403 Mandrake 10.0 2.6.4 200404 SuSE 9.1 2.6.5 200405 Fedora Core 2 2.6.8 200410 Mandriva 10.1 2.6.8 200412 SuSE 9.2 2.6.9 200411 Fedora Core 3 2.6.10 200503 Linspire 5 2.6.11 200503 SuSE 9.3 2.6.11 200504 Mandriva 10.2/2005 2.6.11 200506 Fedora Core 4 2.6.11 200506 Xandros 3 2.6.12 200509 Mandriva 2006 2.6.12 200510 Edubuntu 5.10 2.6.12 200510 Kubuntu 5.10 2.6.12 200510 Ubuntu 5.10 2.6.12 Debian Etch 2.6.13 200509 SuSE 10.0 Knoppix 3.2 . . . 4.0.2 Mandrake Cooker - since 9.0 dev cycle OpenSuse Devel - about to start About 12 from that list are still installed and operational, plus the Knoppix CDs.
Urpmi is configured, by default, to install and not update kernels. The old kernel is added to the boot list, giving you the possibility of getting the machine going if the new kernel gives problems.
The existance of 2 different kernels gives no problem.
I must say when I first did an update on Suse I was a little scared by the default action.
SuSE 8.2 made SuSE my favorite. It became my local server, replace only late last summer with a newer machine, initially with Mandriva 2006, which is still installed, but as of late last month, runs a SuSE 10.0 DVD install, and since about a week after installation, has functioned as host for my own web site. SuSE did so because the engineering, fit, and polish the Germans are famous for was obvious, giving best evidence it was worthy of my trust. Things aren't exactly as they used to be. NAICT, it isn't run by Germans any more, and from what I've read on this list since that change, its quality is gravitating toward everyone else's. In particular in this regard, discussion of upgrade kernels comes to mind, and that's why I began this thread, in order to minimize the potential for that kind of pain, wishing for the same behavior by default with YOU that comes with URPMI. -- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/
Felix Miata wrote:
I'm surprised to find the apparent lack of this function, given its usefulness in defending against incompatabilities in replacement kernels, and SuSE's otherwise superior polish and function to other major distros in most regards.
It is a very requested feature. If you install the kernel update rpm with rpm -i instead of -U you will get the effect you're after (at least I think that's what you're after, the old kernel will then be moved to vmlinuz.previous and initrd.previous and grub has an entry for those) but with YOU you don't get this, as it uses -U to update If you use red carpet to update you get this though. I don't know about apt or smart as I haven't tried those yet (and anyway, they're not official yet). So on Open Enterprise Server, which uses red carpet to update, and the next version of SLES, which will use it, you'll get this. I can't say how it will be in 10.1, since I haven't been able to test the update feature there
On Sunday 15 January 2006 05:08, Felix Miata wrote:
Carl Hartung wrote:
On Saturday 14 January 2006 22:43, Carl Hartung wrote:
Re-reading your earlier post, Felix, I see you're concerned that reverting to a previous kernel puts the rpm database out of sync with the installed system. I don't know why you'd rule out using CLI rpm tools (the --force and --justdb options will solve this problem) but running the system in that state until you've sorted the newer kernel problem(s) out seems a minor inconvenience -- particularly when it is so readily resolved.
It's more readily resolved by leaving it installed, including in menu.lst, in the first place, which is what Mandriva's URPMI does by default. I would expect no less from YOU, but it apparently disappoints in this regard.
Is this your way of suggesting a new 'rollback' feature?... one comparable to the one offered in Mandriva?
I know how to use Bugzilla if it becomes appropriate, but that it is not for discovering functional existing features, which is what my OP asked about. If the answers I've seen already are any indication, I will be needing to find or file such a bug as my OP asks about. -- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://mrmazda.no-ip.com/auth/
Thing is this is SUSE not Mandriva i am glad to say .. -- The Labour party has changed there emblem from a rose to a condom as it more accuratley reflects the governments political stance. A condom allows for inflation halts production destroys the next gereration, protects a bunch of pricks, and givesyou a sense of security while you are actually bieng fucked from GSM
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-01-15 at 00:08 -0500, Felix Miata wrote:
It's more readily resolved by leaving it installed, including in menu.lst, in the first place, which is what Mandriva's URPMI does by default. I would expect no less from YOU, but it apparently disappoints in this regard.
The easiest way to do this, ie, maintain the new and the previous kernel versions would be to use the command rpm directly. What YOU (or Yast) does is to install the newer version, and remove the old; there is no provision that I know of to keep the previous version. I remember some SuSE developer answering this same question time ago, so this is conclusive - except that I don't use version 10, but I don't think it has changed. So, the proper way, I understand, is to manually install the kernel update/patch, with rpm, using option "--install" instead of "--upgrade" - I think. Then, you have to check the bootloader configuration so that there are appropriate entries to both the new and old kernels. If I remember correctly, some filenames are updated appropriately this way by the rpm command. Another method, after running YOU, is to reinstall the old rpm package, perhaps even manually using 'mc'; but it is probably easier to make a backup copy anywhere, and put it back in place afterward, forgetting about rpm databases (it is easy, only some files in /boot and the tree in /lib/modules/{kernel-version}). You just have to remember what you did and undo it at the next update; the database is not corrupted, it simply not informed ;-) The problem is that the option "--oldpackage" replaces completely the new files with the old ones, so it is not valid. It would be a nice feature to ask for in 10.1, I think. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDymU8tTMYHG2NR9URAnX/AJ0ZXuT2NDxGHHc6RxjASie9kDKyWwCfXelw BneZN5Q6hOXVijniPLORCi8= =v0Wx -----END PGP SIGNATURE-----
Speaking of kernel updates, what the hell does the /sbin/kernel-update-tool do, anyway?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-01-15 at 09:35 -0700, John Meyer wrote:
Speaking of kernel updates, what the hell does the /sbin/kernel-update-tool do, anyway?
I don't have such a file here, nor anywhere in my system. I also grepped (it sounds familiar, somehow) in the entire /usr/src/linux directory and found no mention of it. Is that the correct spelling? - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDyqbjtTMYHG2NR9URAt9BAJ9pCekbMJCQId3hA9tpQQEP13ox+gCcCUTP X+71ZAqavdiQ3v5XLzINeyU= =Ygyo -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Sunday 2006-01-15 at 09:35 -0700, John Meyer wrote:
Speaking of kernel updates, what the hell does the /sbin/kernel-update-tool do, anyway?
I don't have such a file here, nor anywhere in my system. I also grepped (it sounds familiar, somehow) in the entire /usr/src/linux directory and found no mention of it.
Is that the correct spelling?
Yes it's correct (except it's /usr/sbin). It's in noarch and the description is Kernel driver packages contain kernel loadable modules, and only work with a specific kernel package. The kernel upgrade tool (/sbin/kernel-upgrade-tool) supports kernel package status inquiry, and handles driver packages during kernel installations and upgrades (user interaction, driver download and/or reuse of drivers for more recent kernels). Note that the text is wrong. The program is /usr/sbin/kernel-update-tool It helps you update the kernel, and to get updated versions of kernel module packages external to the main kernel package when you update the kernel Ugh, that sentence doesn't look good, I hope the meaning comes across :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-01-16 at 02:39 +0100, Anders Johansson wrote:
Kernel driver packages contain kernel loadable modules, and only work with a specific kernel package. The kernel upgrade tool (/sbin/kernel-upgrade-tool) supports kernel package status inquiry, and handles driver packages during kernel installations and upgrades (user interaction, driver download and/or reuse of drivers for more recent kernels).
Note that the text is wrong. The program is /usr/sbin/kernel-update-tool
Neither kernel-update-tool nor kernel-upgrade-tool exist in my installed system or in the dvd. It must be something new.
It helps you update the kernel, and to get updated versions of kernel module packages external to the main kernel package when you update the kernel
Ugh, that sentence doesn't look good, I hope the meaning comes across :)
Yep :-) - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDyv8ttTMYHG2NR9URAvT8AJ49YQYM4MaxC7J2DCsXWcGbISe4VQCdHFWa FzkGE5YHnsFJnmwdzcCJ7Ps= =niJi -----END PGP SIGNATURE-----
On 1/15/06, Anders Johansson
Yes it's correct (except it's /usr/sbin). It's in noarch and the description is
Kernel driver packages contain kernel loadable modules, and only work with a specific kernel package. The kernel upgrade tool (/sbin/kernel-upgrade-tool) supports kernel package status inquiry, and handles driver packages during kernel installations and upgrades (user interaction, driver download and/or reuse of drivers for more recent kernels).
Note that the text is wrong. The program is /usr/sbin/kernel-update-tool
It helps you update the kernel, and to get updated versions of kernel module packages external to the main kernel package when you update the kernel
Ugh, that sentence doesn't look good, I hope the meaning comes across :)
I'm not completely sure, but this description really looks like something which creates a kernel modules for third party drivers like nVidia's. So, most probably it is present on nVidia systems, at least I have it. In the past I used to update my nVidia drivers manually, and then, whenever I updated the kernel, I needed to rerun nvidia installer and to rebuild the kernel driver for this new kernel. Later on, after I used the fetchnvidia from online update, I do not have to do this any more, so looks like something takes care for this. As I said, I'm not sure, but the description fits such a behaviour. -- -- Svetoslav Milenov (Sunny)
On Sun, 2006-01-15 at 20:47 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Sunday 2006-01-15 at 09:35 -0700, John Meyer wrote:
Speaking of kernel updates, what the hell does the /sbin/kernel-update-tool do, anyway?
I don't have such a file here, nor anywhere in my system. I also grepped (it sounds familiar, somehow) in the entire /usr/src/linux directory and found no mention of it.
Is that the correct spelling?
From pin output:
---> ./CD1/suse/noarch/kernel-update-tool-0.9-10.noarch.rpm ./CD1/suse/noarch/kernel-update-tool-0.9-10.noarch.rpm: Name : kernel-update-tool Relocations: (not relocatable) This is on 10.0 (download version). -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-01-16 at 09:19 -0500, Ken Schneider wrote:
From pin output:
---> ./CD1/suse/noarch/kernel-update-tool-0.9-10.noarch.rpm ./CD1/suse/noarch/kernel-update-tool-0.9-10.noarch.rpm: Name : kernel-update-tool Relocations: (not relocatable)
This is on 10.0 (download version).
That was the missing info, 10.0. It is not included in 9.3 - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD4DBQFDy7NztTMYHG2NR9URApxWAJUVb4x3WNko0EJjmNXHGJNJ36YPAJ9h/6fB 5kgg44jTZgAjnv2dvBcKuA== =tfeu -----END PGP SIGNATURE-----
On Sun, 2006-01-15 at 16:07 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Sunday 2006-01-15 at 00:08 -0500, Felix Miata wrote:
It's more readily resolved by leaving it installed, including in menu.lst, in the first place, which is what Mandriva's URPMI does by default. I would expect no less from YOU, but it apparently disappoints in this regard.
The easiest way to do this, ie, maintain the new and the previous kernel versions would be to use the command rpm directly. What YOU (or Yast) does is to install the newer version, and remove the old; there is no provision that I know of to keep the previous version. I remember some SuSE developer answering this same question time ago, so this is conclusive - except that I don't use version 10, but I don't think it has changed.
So, the proper way, I understand, is to manually install the kernel update/patch, with rpm, using option "--install" instead of "--upgrade" - I think. Then, you have to check the bootloader configuration so that there are appropriate entries to both the new and old kernels. If I remember correctly, some filenames are updated appropriately this way by the rpm command.
Another method, after running YOU, is to reinstall the old rpm package, perhaps even manually using 'mc'; but it is probably easier to make a backup copy anywhere, and put it back in place afterward, forgetting about rpm databases (it is easy, only some files in /boot and the tree in /lib/modules/{kernel-version}). You just have to remember what you did and undo it at the next update; the database is not corrupted, it simply not informed ;-)
Remember that if you -install- the old version along with the new one watch to make sure the links in /boot point to what -you- think are the correct places. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
Randall R Schulz wrote:
On Saturday 14 January 2006 18:02, Felix Miata wrote:
I would use none of the above, but instead mc, far easier when dealing with multiple files scattered in various locations.
That's exactly when a CLI tool--scripted, of course--makes far _more_ sense than a GUI or semi-GUI (such as midnight commander).
Only to those who know scripting. I find using mc far easier than learning scripting or remembering which scripts do what, and mc is ready and waiting on fresh installs, unlike custom scripts. -- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/auth/
Felix, On Saturday 14 January 2006 21:13, Felix Miata wrote:
Randall R Schulz wrote:
On Saturday 14 January 2006 18:02, Felix Miata wrote:
I would use none of the above, but instead mc, far easier when dealing with multiple files scattered in various locations.
That's exactly when a CLI tool--scripted, of course--makes far _more_ sense than a GUI or semi-GUI (such as midnight commander).
Only to those who know scripting. I find using mc far easier than learning scripting or remembering which scripts do what, and mc is ready and waiting on fresh installs, unlike custom scripts.
If you know enough to be messing around with RPMs, performing kernel and boot file manipulation and such, you really ought to know something about some simple scripting. In this case, the only "scripting" I'm referring to is listing out the cp (or mv or rsync or whatever) commands in a single file, so the what's to be done can be seen and reviewed in advance and so there is a record afterward of what manipulations were performed on key system files. Do you get that from Midnight Commander? The whole GUI vs. CLI thing is not about what's better, but about what _better for the purpose at hand_!
...
Felix Miata
Randall Schulz
Randall R Schulz wrote:
If you know enough to be messing around with RPMs, performing kernel and boot file manipulation and such, you really ought to know something about some simple scripting.
I learned vi and scripting in the '80's. After discovering OFMS, I forgot virtually everything I ever learned about both.
In this case, the only "scripting" I'm referring to is listing out the cp (or mv or rsync or whatever) commands in a single file, so the what's to be done can be seen and reviewed in advance and so there is a record afterward of what manipulations were performed on key system files. Do you get that from Midnight Commander?
I get what I need. As example, one of the 2nd things I do on a new system install (#1 is start mc, or install it if it didn't start), is navigate to /boot/grub. I find the initial menu.lst file if there is one with some installer-given backup name, and shift-F3 it to menu.lst.01. If that file isn't the newest, the newest gets shift-F3'd to menu.lst.02. Then I F4 it to replace splash with splash=0 on the kernel line(s), adjust vga= arguments to my liking, and so forth. That file then gets shift-F3 to menu.lst.03. I then proceed to /etc and do similarly with fstab, kdmrc, exports, hosts, .wgetrc and so forth. After the login manager and nfs are configured, I navigate to an nfs mount, F4 a file containing sections the installers leave out of xorg.conf, mark, ctrl-ins, F10, tab, F4, locate insert point, and shift-ins. Until this point following install, I'm not ready to venture into X. Such customizing is just not suited to scripting unless you're doing the exact same thing repeatedly, which I rarely am, and can remember which script does what, which my tired old brain would find a hopeless proposition. -- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/auth/
On Saturday 14 January 2006 22:33, Felix Miata wrote:
...
Such customizing is just not suited to scripting unless you're doing the exact same thing repeatedly, which I rarely am, and can remember which script does what, which my tired old brain would find a hopeless proposition.
Suit yourself, but frankly, you don't know what you're talking about.
...
Felix Miata *** http://mrmazda.no-ip.com/auth/
RRS
Randall R Schulz wrote:
Suit yourself, but frankly, you don't know what you're talking about.
You're apparently at most an OFM dabbler, not an OFM user. Only OFM users understand OFMs. Scripting as you've described is programming. I'm not a programmer. OFMs are ready to use programs, something mere mortal users like me can handle. -- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/auth/
Felix, On Sunday 15 January 2006 04:33, Felix Miata wrote:
Randall R Schulz wrote:
Suit yourself, but frankly, you don't know what you're talking about.
You're apparently at most an OFM dabbler, not an OFM user. Only OFM users understand OFMs. Scripting as you've described is programming. I'm not a programmer. OFMs are ready to use programs, something mere mortal users like me can handle.
Scripting as I've advocated it in this thread is _not_ programming. It's just the preparation of a list of fixed actions (commands) written down in a file in advance of their being executed. It simultaneously leaves a record of those actions. No loops, no conditionals, no computation of values. I don't know what OFM is.
... Felix Miata *** http://mrmazda.no-ip.com/auth/
Randall Schulz
Randall R Schulz wrote Sun, 15 Jan 2006 07:09:15 -0800:
I don't know what OFM is.
mc is one such: http://www.softpanorama.org/OFM/index.shtml -- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/
On Wednesday 18 January 2006 05:50, Felix Miata wrote:
Randall R Schulz wrote Sun, 15 Jan 2006 07:09:15 -0800:
I don't know what OFM is.
mc is one such: http://www.softpanorama.org/OFM/index.shtml
"Orthodox File Manager." Leave it to a religion freak to cling to "orthodoxy."
-- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV
"My god can kick your god's ass." RRS
On Wednesday 18 January 2006 9:06 am, Randall R Schulz wrote:
On Wednesday 18 January 2006 05:50, Felix Miata wrote:
Randall R Schulz wrote Sun, 15 Jan 2006 07:09:15 -0800:
I don't know what OFM is.
mc is one such: http://www.softpanorama.org/OFM/index.shtml
"Orthodox File Manager."
Leave it to a religion freak to cling to "orthodoxy."
-- "Blessed is the nation whose God is the Lord." Psalm 33:12 NIV
"My god can kick your god's ass."
Risk Godstorm edition = fun, fun, fun! http://www.wizards.com/default.asp?x=ah/prod/riskgodstorm B-)
participants (13)
-
Anders Johansson -
Brad Bourn -
Carl Hartung -
Carlos E. R. -
Dave Cotton -
Felix Miata -
John Meyer -
Ken Schneider -
Paul Cartwright -
Peter Nikolic -
Randall R Schulz -
Stan Glasoe -
Sunny