[arch-general] Multiple Kernels
How to install multiple kernels using pacman ? Arch should do something like Fedora/Redhat. Maintain 1-2 previous kernels so that if a new one is buggy, then the old one can be used. -- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com
You can still use it, starting fallback kernel and downgrading it with pacman. Mantaining multiple kernels would only add overhead on developers' work, and bloating /boot. 2010/2/1 Nilesh Govindarajan <lists@itech7.com>
How to install multiple kernels using pacman ?
Arch should do something like Fedora/Redhat. Maintain 1-2 previous kernels so that if a new one is buggy, then the old one can be used.
-- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com
Mantaining multiple kernels would only add overhead on developers' work, and bloating /boot.
I don't really get that. I'm no expert in using pacman or writing PKGBUILDs, but I can very readily imagine a mechanism that on each rolling release update to the kernel, moves the current kernel on the users system to say 'kernel-previous', and puts the update in place for 'kernel'. Add a line to grub to reflect the two kernel-versions (current and previous) and handle this with symlinks so that the actual kernel + libs and so on can have version names. On the other hand, I have never had a kernel-update completely break my system, so the question really is, if automation of such functionality is needed. After all, you really should compile your own kernels, and keep backups around just in case you break something there yourself... IMHO Tom
Am Mon, 1 Feb 2010 20:48:14 +0100 schrieb Tom <uebershark@googlemail.com>:
I don't really get that. I'm no expert in using pacman or writing PKGBUILDs, but I can very readily imagine a mechanism that on each rolling release update to the kernel, moves the current kernel on the users system to say 'kernel-previous', and puts the update in place for 'kernel'. Add a line to grub to reflect the two kernel-versions (current and previous) and handle this with symlinks so that the actual kernel + libs and so on can have version names.
On the other hand, I have never had a kernel-update completely break my system, so the question really is, if automation of such functionality is needed. After all, you really should compile your own kernels, and keep backups around just in case you break something there yourself...
I used Gentoo some years before I switched to Arch. Gentoo is also a rolling release distro. And Gentoo keeps several older versions of every package in the portage tree, so that you can easily install a version of your choice and downgrade every package to every version you want. On Gentoo sometimes this is necessary, but it also makes the distro more complex. On Arch this wasn't really necessary, yet. On Gentoo the older kernel version was kept on the system and renamed to /boot/vmlinuz.old etc. when the kernel was updated. And neither on Gentoo nor on Arch I had to downgrade the kernel once. And also on Gentoo I always removed the older kernel version directly after updating the kernel and before rebooting and I never had a problem. So Arch should stay with its policy to only provide the latest version of a package. And if you really need to downgrade the kernel or another package just do it with pacman -U /var/cache/pacman/pkg/<packagename>-<oldversion>. Greetings, Heiko
At Montag, 1. Februar 2010 22:08 Heiko Baums wrote: At first i want to say that i'm not interested for that the devs have to have too much work.
And if you really need to downgrade the kernel or another package just do it with pacman -U /var/cache/pacman/pkg/<packagename>-<oldversion>.
I know this is the No.1 hint but this solution is not very well from my view because instead the hardidsk getting bigger and bigger it sounds unlogical to keep a lot of files in the cache and only a few one could be important for seldom cases. One of them which is important be the kernel. So if pacman would have the option to install a certain version of a package than the user need only to know if there is more than one version in db. So perhaps this coould be solved at example for a search of all by a "pacman -Ss --allversions ^kernel". Last not least repo-add and repo-remove must have the possibilty to do this too. Than the devs could decide for what for packages they think it is worth to have an downgrade option and it doesn't matter what is in the cache of everyone. I think all other ways makes too much work for seldom cases but this is only my view and not a feature request. On the other side i think it is even worth to have an own kernel package and the PKGBUILD of kernel26 makes it very easy to do this. See you, Attila
And if you really need to downgrade the kernel or another package just do it with pacman -U /var/cache/pacman/pkg/<packagename>-<oldversion>.
I know this is the No.1 hint but this solution is not very well from my view because instead the hardidsk getting bigger and bigger it sounds unlogical to keep a lot of files in the cache and only a few one could be important for seldom cases.
One of them which is important be the kernel. So if pacman would have the option to install a certain version of a package than the user need only to know if there is more than one version in db. So perhaps this coould be solved at example for a search of all by a "pacman -Ss --allversions ^kernel". Last not least repo-add and repo-remove must have the possibilty to do this too.
cp `ls -1 /var/cache/pacman/pkg/kernel26-2.6* | tail -n 1` ./ Is it really that hard?
At Montag, 1. Februar 2010 23:45 Muhammed Uluyol wrote:
cp `ls -1 /var/cache/pacman/pkg/kernel26-2.6* | tail -n 1` ./
Is it really that hard?
You have over read that i don't have this problem because i have own kernel packages (one optimzed which includes the BFS Scheduler and one stable). I said only my opinion about this wish to have multiple kernel versions. See you, Attila
Am Mon, 01 Feb 2010 23:08:23 +0100 schrieb Attila <vodoo0904@sonnenkinder.org>:
One of them which is important be the kernel. So if pacman would have the option to install a certain version of a package than the user need only to know if there is more than one version in db. So perhaps this coould be solved at example for a search of all by a "pacman -Ss --allversions ^kernel". Last not least repo-add and repo-remove must have the possibilty to do this too.
Than the devs could decide for what for packages they think it is worth to have an downgrade option and it doesn't matter what is in the cache of everyone.
I think all other ways makes too much work for seldom cases but this is only my view and not a feature request. On the other side i think it is even worth to have an own kernel package and the PKGBUILD of kernel26 makes it very easy to do this.
It's contrary because these cases are so seldom it would make too much work to keep and maintain several older versions and it would cost much more disk space and traffic on the mirrors. See Gentoo with its USE flags, slots, multiple versions in the portage tree etc. All these features are quite nice and supposedly flexible. But in fact I like the feeling of having lost all this ballast on Arch. On Gentoo you need to have several versions of several packages installed (the slots) because of keeping all these older versions and because of the version based dependencies. And the two cases in which I needed the previous version I was lucky with the pacman -U option. Greetings, Heiko
At Montag, 1. Februar 2010 23:57 Heiko Baums wrote:
It's contrary because these cases are so seldom it would make too much work to keep and maintain several older versions and it would cost much more disk space and traffic on the mirrors.
+1 I speak about this seldom cases and the only one what i propose to have multiple versions is the kernel package. Perhaps the devs see more but not me.-)
See Gentoo with its USE flags, slots, multiple versions in the portage tree etc. All these features are quite nice and supposedly flexible. But in fact I like the feeling of having lost all this ballast on Arch.
I tried gentoo in the past but this USE flags confused me more than they helps me because i don't know enough about what for apps need what to use it in a constructive way.
And the two cases in which I needed the previous version I was lucky with the pacman -U option.
We both are not so much different in our opinions (perhaps we should try it in german -) ) but instead of you i don't see the cache on my local disk as a backup. That is why i use own kernel packages to be on the safe side.-) See you, Attila
On Mon, Feb 01, 2010 at 08:48:14PM +0100, Tom wrote:
Mantaining multiple kernels would only add overhead on developers' work, and bloating /boot.
I don't really get that. I'm no expert in using pacman or writing PKGBUILDs, but I can very readily imagine a mechanism that on each rolling release update to the kernel, moves the current kernel on the users system to say 'kernel-previous', and puts the update in place for 'kernel'. Add a line to grub to reflect the two kernel-versions (current and previous) and handle this with symlinks so that the actual kernel + libs and so on can have version names.
That's what happens in Fedora when e.g. you install the RT-patched kernel from the CCARMA audio packages, and AFAIK also (but I never did this) when you update the Fedora provided kernel. It can occasionally save your system. On Arch you of course always have the 'fallback' boot option (which can be expected to work), or you can boot from the original netinstall CD. But it's by no means clear to me how you could 'rewind' a failed kernel update using either of these. -- FA O tu, che porte, correndo si ? E guerra e morte !
On Mon, Feb 1, 2010 at 6:01 PM, <fons@kokkinizita.net> wrote:
On Arch you of course always have the 'fallback' boot option (which can be expected to work), or you can boot from the original netinstall CD. But it's by no means clear to me how you could 'rewind' a failed kernel update using either of these.
This is why you don't immediately clean out your /var/cache/pacman/pkg directory. In case of some catastrophic failure (like a kernel upgrade), you still have your previous kernel package tucked away for re-installation.
Am Mon, 1 Feb 2010 18:09:58 -0500 schrieb dave reisner <d@falconindy.com>:
On Mon, Feb 1, 2010 at 6:01 PM, <fons@kokkinizita.net> wrote:
On Arch you of course always have the 'fallback' boot option (which can be expected to work), or you can boot from the original netinstall CD. But it's by no means clear to me how you could 'rewind' a failed kernel update using either of these.
This is why you don't immediately clean out your /var/cache/pacman/pkg directory. In case of some catastrophic failure (like a kernel upgrade), you still have your previous kernel package tucked away for re-installation.
Alternatively use the core CD and install the kernel package from there. Greetings, Heiko
On Mon, Feb 01, 2010 at 06:09:58PM -0500, dave reisner wrote:
On Mon, Feb 1, 2010 at 6:01 PM, <fons@kokkinizita.net> wrote:
On Arch you of course always have the 'fallback' boot option (which can be expected to work), or you can boot from the original netinstall CD. But it's by no means clear to me how you could 'rewind' a failed kernel update using either of these.
This is why you don't immediately clean out your /var/cache/pacman/pkg directory. In case of some catastrophic failure (like a kernel upgrade), you still have your previous kernel package tucked away for re-installation.
In that case, would pacman -U /var/cache/pacman/pkg/the-previous-kernel-package in a chroot running below /mnt do the right thing ? Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
Well, Arch is rolling release distro, I agree. Arch rocks. But only one thing. pacman should support installing multiple kernels. Developers need not maintain the old version. Let it be in the cache of the user. But pacman should not remove the older one after upgrade. -- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com
On Mon, Feb 1, 2010 at 9:59 PM, Nilesh Govindarajan <lists@itech7.com> wrote:
Well, Arch is rolling release distro, I agree. Arch rocks. But only one thing. pacman should support installing multiple kernels. Developers need not maintain the old version. Let it be in the cache of the user. But pacman should not remove the older one after upgrade.
Do you understand what you are actually implying here? Pacman doesn't "remove the older one", it upgrades a package. The kernel26 package installs its files in *the same place every time*. We don't do auto-modification of your grub menu; we don't tack on a version string to each vmlinuz image, and we don't (except for major kernel version bumps) have the modules in a different directory under /lib/modules/. This is nowhere near as simple of a proposition as you make it out to be. -Dan
On 02/02/2010 09:34 AM, Dan McGee wrote:
On Mon, Feb 1, 2010 at 9:59 PM, Nilesh Govindarajan<lists@itech7.com> wrote:
Well, Arch is rolling release distro, I agree. Arch rocks. But only one thing. pacman should support installing multiple kernels. Developers need not maintain the old version. Let it be in the cache of the user. But pacman should not remove the older one after upgrade.
Do you understand what you are actually implying here? Pacman doesn't "remove the older one", it upgrades a package.
The kernel26 package installs its files in *the same place every time*. We don't do auto-modification of your grub menu; we don't tack on a version string to each vmlinuz image, and we don't (except for major kernel version bumps) have the modules in a different directory under /lib/modules/. This is nowhere near as simple of a proposition as you make it out to be.
-Dan
Actually I kept in mind the same thing you said above, but wrote something else :D pacman should do what you said. keeping /boot/vmlinuz-<version> instead of just /boot/vmlinuz which will help users in case the new kernel broke their system and also for people like me who don't have any recovery media. I installed Arch from Fedora on USB key using static pacman then formatted HDD and copied all files to HDD. But recently I lost my USB key and also my DVD drive is not working to use Fedora's DVD as recovery. -- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com
On Mon, Feb 1, 2010 at 10:30 PM, Nilesh Govindarajan <lists@itech7.com> wrote:
pacman should do what you said. keeping /boot/vmlinuz-<version> instead of just /boot/vmlinuz
Then arch will try to load modules for a newer kernel version and that WILL fail. I doesn't work and isn't difficult to store a limited number of older packages.
On 02/03/2010 06:45 AM, Muhammed Uluyol wrote:
On Mon, Feb 1, 2010 at 10:30 PM, Nilesh Govindarajan<lists@itech7.com> wrote:
pacman should do what you said. keeping /boot/vmlinuz-<version> instead of just /boot/vmlinuz
Then arch will try to load modules for a newer kernel version and that WILL fail. I doesn't work and isn't difficult to store a limited number of older packages.
Modules are defined in initrd. Each kernel has to have a different initrd else the system won't boot. -- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com
On 02/01/10 21:59, Nilesh Govindarajan wrote:
Well, Arch is rolling release distro, I agree. Arch rocks. But only one thing. pacman should support installing multiple kernels. Developers need not maintain the old version. Let it be in the cache of the user. But pacman should not remove the older one after upgrade.
I 2nd that motion .... -- William A. Mahaffey III ---------------------------------------------------------------------- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr.
On 02/02/10 15:13, William A. Mahaffey III wrote:
On 02/01/10 21:59, Nilesh Govindarajan wrote:
Well, Arch is rolling release distro, I agree. Arch rocks. But only one thing. pacman should support installing multiple kernels. Developers need not maintain the old version. Let it be in the cache of the user. But pacman should not remove the older one after upgrade.
I 2nd that motion ....
Not going to happen...
On 02/01/10 23:10, Allan McRae wrote:
On 02/02/10 15:13, William A. Mahaffey III wrote:
On 02/01/10 21:59, Nilesh Govindarajan wrote:
Well, Arch is rolling release distro, I agree. Arch rocks. But only one thing. pacman should support installing multiple kernels. Developers need not maintain the old version. Let it be in the cache of the user. But pacman should not remove the older one after upgrade.
I 2nd that motion ....
Not going to happen...
No problema, just opining .... -- William A. Mahaffey III ---------------------------------------------------------------------- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr.
On Mon, 01 Feb 2010 23:13:38 -0600 "William A. Mahaffey III" <wam@hiwaay.net> wrote:
On 02/01/10 21:59, Nilesh Govindarajan wrote:
Well, Arch is rolling release distro, I agree. Arch rocks. But only one thing. pacman should support installing multiple kernels. Developers need not maintain the old version. Let it be in the cache of the user. But pacman should not remove the older one after upgrade.
I 2nd that motion ....
As previously mentioned, that is what the user's local cache is for.
On 2 February 2010 13:43, Ty John <ty-ml@eye-of-odin.com> wrote:
On Mon, 01 Feb 2010 23:13:38 -0600 "William A. Mahaffey III" <wam@hiwaay.net> wrote:
On 02/01/10 21:59, Nilesh Govindarajan wrote:
Well, Arch is rolling release distro, I agree. Arch rocks. But only one thing. pacman should support installing multiple kernels. Developers need not maintain the old version. Let it be in the cache of the user. But pacman should not remove the older one after upgrade.
I 2nd that motion ....
As previously mentioned, that is what the user's local cache is for.
Urmm..if it is so important, Arch gives you the power to roll your own kernel. Heck, I don't even have a fallback, because I don't need it. Like Fons, I have an RT kernel, and a normal kernel. Either acts as a backup of the other, since neither gets updated along with the other. -- GPG/PGP ID: B42DDCAD
There is no rescue shell for when the kernel is broken ? I remember having broken archlinux 3 times, mostly the graphical interface. I have installed only one time archlinux. No need to reinstall to fix it. By the way, I'm fine with the way kernel are handled. And I doesn't understand why we should have 2 or more vmlinuz with some weird var in their names. That's archlinux, not ubuntnoob (not sure of the spelling.) But, having older package hanging in repos, no support, just the bunch of bit making an archive, could be something good. People can this way get older kernel, and try if there are less buggy. Probably that most of the time older kernel will be more buggy. But user will have the choice to downgrade there kernel, even if they haven't the space te keep every package in their cache. I feel the need to repeat, that letting package in the repo doesn't need that these package need support. Just to be in wget range at least. Allowing pacman to downgrade the kernel from the repo would be the best, but it's more work than forgetting the head-1 version of a major package in repo. -- Cordialement, Coues Ludovic 06 148 743 42 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
On Tue, Feb 2, 2010 at 8:53 AM, Ray Rashif <schivmeister@gmail.com> wrote:
Urmm..if it is so important, Arch gives you the power to roll your own kernel. Heck, I don't even have a fallback, because I don't need it. Like Fons, I have an RT kernel, and a normal kernel. Either acts as a backup of the other, since neither gets updated along with the other.
To all the complainers in that thread : WHO has a serious problem with the above, and can give a strong argument WHY ? I completely agree that having only one kernel installed sucks, if that one stops booting, you need a livecd/usb in order to boot and fix things. That simply does not happen if you have two kernels installed, be it RT or LTS or custom or whatever. Now if we are talking about minor issues, the kernel boots and works, then there is no reason the kernel should be handled in a more special way than any other packages. It's not the only critical component of the system. So just follow : http://wiki.archlinux.org/index.php/Downgrading_Packages And I actually find quite annoying the debian/ubuntu handling of accumulating old kernels and having to clean up every time. Final word : if you are not happy with the quality of testing already made for core packages, just HELP to improve the situation.
After all, you really should compile your own kernels, and keep backups around just in case you break something there yourself...
What I mean is, for me, the official arch-kernel IS the main backup... ;)
On Mon, Feb 1, 2010 at 8:35 PM, Nilesh Govindarajan <lists@itech7.com> wrote:
How to install multiple kernels using pacman ?
Arch should do something like Fedora/Redhat. Maintain 1-2 previous kernels so that if a new one is buggy, then the old one can be used.
QFT. WAIT WHAT? http://www.archlinux.org/packages/core/i686/kernel26-lts/ http://www.archlinux.org/packages/core/x86_64/kernel26-lts/
2010/2/1 Emmanuel Benisty <benisty.e@gmail.com>
On Mon, Feb 1, 2010 at 8:35 PM, Nilesh Govindarajan <lists@itech7.com> wrote:
How to install multiple kernels using pacman ?
Arch should do something like Fedora/Redhat. Maintain 1-2 previous kernels so that if a new one is buggy, then the old one can be used.
QFT.
WAIT WHAT? http://www.archlinux.org/packages/core/i686/kernel26-lts/ http://www.archlinux.org/packages/core/x86_64/kernel26-lts/
lts is not for everyday desktop usage. By the way, there should be a way to get older with something like that pacman -S kernel26-2.6.32.6-1 In my mind, when package version is specified, pacman look if the asked version is in the repo, and get it if there is such a version. Lot of app would only provide the current version, but some critical app, like kernel, could provide one or two older version. Just by letting them in the repo. But maybe I'm totally wrong, and this will not work cause every kernel module work only with the current one. -- Cordialement, Coues Ludovic 06 148 743 42 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
On 02/01/10 08:59, ludovic coues wrote:
2010/2/1 Emmanuel Benisty<benisty.e@gmail.com>
On Mon, Feb 1, 2010 at 8:35 PM, Nilesh Govindarajan<lists@itech7.com> wrote:
How to install multiple kernels using pacman ?
Arch should do something like Fedora/Redhat. Maintain 1-2 previous
kernels
so that if a new one is buggy, then the old one can be used.
QFT.
WAIT WHAT? http://www.archlinux.org/packages/core/i686/kernel26-lts/ http://www.archlinux.org/packages/core/x86_64/kernel26-lts/
lts is not for everyday desktop usage.
Why not ? Different modules or optimization ? Something else ? Please elaborate .... <snip> -- William A. Mahaffey III ---------------------------------------------------------------------- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr.
On Mon, Feb 1, 2010 at 09:59, ludovic coues <couesl@gmail.com> wrote:
2010/2/1 Emmanuel Benisty <benisty.e@gmail.com> lts is not for everyday desktop usage.
By the way, there should be a way to get older with something like that pacman -S kernel26-2.6.32.6-1
Arch is a rolling release distro. The repo only keeps one version of any given package at a time. Running pacman -S pkgname will get that version.
On Mon, 2010-02-01 at 15:59 +0100, ludovic coues wrote:
2010/2/1 Emmanuel Benisty <benisty.e@gmail.com>
On Mon, Feb 1, 2010 at 8:35 PM, Nilesh Govindarajan <lists@itech7.com> wrote:
How to install multiple kernels using pacman ?
Arch should do something like Fedora/Redhat. Maintain 1-2 previous kernels so that if a new one is buggy, then the old one can be used.
QFT.
WAIT WHAT? http://www.archlinux.org/packages/core/i686/kernel26-lts/ http://www.archlinux.org/packages/core/x86_64/kernel26-lts/
lts is not for everyday desktop usage.
By the way, there should be a way to get older with something like that pacman -S kernel26-2.6.32.6-1
In my mind, when package version is specified, pacman look if the asked version is in the repo, and get it if there is such a version. Lot of app would only provide the current version, but some critical app, like kernel, could provide one or two older version. Just by letting them in the repo.
But maybe I'm totally wrong, and this will not work cause every kernel module work only with the current one.
Two words: rolling release. Once kernel26-2.6.32.7-1 is in [core], mirrors will not have kernel26-2.6.32.6-1 anymore. This is one of the central ideas about Arch, that everyone is running basically the same system with different beads on top. kernel26-lts is there for those who want stability (in which case they should use their own kernel26-custom, and perhaps shouldn't use Arch at all). Kernel modules and the like are all targetted for the current kernel in [core], its a tremendous duplication to have to keep versions for all of those, too. In summary, yes you're totally wrong, and no, its not for the reason you think.
On 02/01/2010 08:53 PM, Ng Oon-Ee wrote:
On Mon, 2010-02-01 at 15:59 +0100, ludovic coues wrote:
2010/2/1 Emmanuel Benisty<benisty.e@gmail.com>
On Mon, Feb 1, 2010 at 8:35 PM, Nilesh Govindarajan<lists@itech7.com> wrote:
How to install multiple kernels using pacman ?
Arch should do something like Fedora/Redhat. Maintain 1-2 previous kernels so that if a new one is buggy, then the old one can be used.
QFT.
WAIT WHAT? http://www.archlinux.org/packages/core/i686/kernel26-lts/ http://www.archlinux.org/packages/core/x86_64/kernel26-lts/
lts is not for everyday desktop usage.
By the way, there should be a way to get older with something like that pacman -S kernel26-2.6.32.6-1
In my mind, when package version is specified, pacman look if the asked version is in the repo, and get it if there is such a version. Lot of app would only provide the current version, but some critical app, like kernel, could provide one or two older version. Just by letting them in the repo.
But maybe I'm totally wrong, and this will not work cause every kernel module work only with the current one.
Two words: rolling release.
Once kernel26-2.6.32.7-1 is in [core], mirrors will not have kernel26-2.6.32.6-1 anymore. This is one of the central ideas about Arch, that everyone is running basically the same system with different beads on top. kernel26-lts is there for those who want stability (in which case they should use their own kernel26-custom, and perhaps shouldn't use Arch at all). Kernel modules and the like are all targetted for the current kernel in [core], its a tremendous duplication to have to keep versions for all of those, too.
In summary, yes you're totally wrong, and no, its not for the reason you think.
Agreed. But recently a USB problem (possibly a bug) was being discussed heavily on the forums. What about it ? Didn't the developers test the kernel properly before releasing it to the community ? -- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com
2010/2/1 Nilesh Govindarajan <lists@itech7.com>:
On 02/01/2010 08:53 PM, Ng Oon-Ee wrote:
On Mon, 2010-02-01 at 15:59 +0100, ludovic coues wrote:
2010/2/1 Emmanuel Benisty<benisty.e@gmail.com>
On Mon, Feb 1, 2010 at 8:35 PM, Nilesh Govindarajan<lists@itech7.com> wrote:
How to install multiple kernels using pacman ?
Arch should do something like Fedora/Redhat. Maintain 1-2 previous
kernels
so that if a new one is buggy, then the old one can be used.
QFT.
WAIT WHAT? http://www.archlinux.org/packages/core/i686/kernel26-lts/ http://www.archlinux.org/packages/core/x86_64/kernel26-lts/
lts is not for everyday desktop usage.
By the way, there should be a way to get older with something like that pacman -S kernel26-2.6.32.6-1
In my mind, when package version is specified, pacman look if the asked version is in the repo, and get it if there is such a version. Lot of app would only provide the current version, but some critical app, like kernel, could provide one or two older version. Just by letting them in the repo.
But maybe I'm totally wrong, and this will not work cause every kernel module work only with the current one.
Two words: rolling release.
Once kernel26-2.6.32.7-1 is in [core], mirrors will not have kernel26-2.6.32.6-1 anymore. This is one of the central ideas about Arch, that everyone is running basically the same system with different beads on top. kernel26-lts is there for those who want stability (in which case they should use their own kernel26-custom, and perhaps shouldn't use Arch at all). Kernel modules and the like are all targetted for the current kernel in [core], its a tremendous duplication to have to keep versions for all of those, too.
In summary, yes you're totally wrong, and no, its not for the reason you think.
Agreed. But recently a USB problem (possibly a bug) was being discussed heavily on the forums. What about it ? Didn't the developers test the kernel properly before releasing it to the community ?
Oh my! A bug! But software never has bugs, and we should test everything for months before releasing it! Seriously, do you think we purposely release buggy software? (We don't) Do strive for a rock solid system? No, because our users (and us!) want a more bleeding-edge distro that uses the latest version of upstream software. If you don't want this you shouldn't be using Arch. -Dan
Dan McGee wrote:
2010/2/1 Nilesh Govindarajan <lists@itech7.com>:
On 02/01/2010 08:53 PM, Ng Oon-Ee wrote:
On Mon, 2010-02-01 at 15:59 +0100, ludovic coues wrote:
2010/2/1 Emmanuel Benisty<benisty.e@gmail.com>
On Mon, Feb 1, 2010 at 8:35 PM, Nilesh Govindarajan<lists@itech7.com> wrote:
How to install multiple kernels using pacman ?
Arch should do something like Fedora/Redhat. Maintain 1-2 previous
kernels
so that if a new one is buggy, then the old one can be used.
QFT.
WAIT WHAT? http://www.archlinux.org/packages/core/i686/kernel26-lts/ http://www.archlinux.org/packages/core/x86_64/kernel26-lts/
lts is not for everyday desktop usage.
By the way, Â there should be a way to get older with something like that pacman -S kernel26-2.6.32.6-1
In my mind, when package version is specified, pacman look if the asked version is in the repo, and get it if there is such a version. Lot of app would only provide the current version, but some critical app, like kernel, could provide one or two older version. Just by letting them in the repo.
But maybe I'm totally wrong, and this will not work cause every kernel module work only with the current one.
Two words: rolling release.
Once kernel26-2.6.32.7-1 is in [core], mirrors will not have kernel26-2.6.32.6-1 anymore. This is one of the central ideas about Arch, that everyone is running basically the same system with different beads on top. kernel26-lts is there for those who want stability (in which case they should use their own kernel26-custom, and perhaps shouldn't use Arch at all). Kernel modules and the like are all targetted for the current kernel in [core], its a tremendous duplication to have to keep versions for all of those, too.
In summary, yes you're totally wrong, and no, its not for the reason you think.
Agreed. But recently a USB problem (possibly a bug) was being discussed heavily on the forums. What about it ? Didn't the developers test the kernel properly before releasing it to the community ?
Oh my! A bug! But software never has bugs, and we should test everything for months before releasing it!
Seriously, do you think we purposely release buggy software? (We don't) Do strive for a rock solid system? No, because our users (and us!) want a more bleeding-edge distro that uses the latest version of upstream software. If you don't want this you shouldn't be using Arch.
-Dan
No you folks do a very good job, no no no.... an outstanding job But one opps and the users have a bad day :)
On 02/01/2010 09:06 AM, Dan McGee wrote:
[snip] Oh my! A bug! But software never has bugs, and we should test everything for months before releasing it!
Seriously, do you think we purposely release buggy software? (We don't) Do strive for a rock solid system? No, because our users (and us!) want a more bleeding-edge distro that uses the latest version of upstream software. If you don't want this you shouldn't be using Arch.
-Dan
Isn't this precisely why we use Arch? Because the bug you get every couple months is an acceptable price to pay to not be running 6 month old software? Not to mention that once it's found, it's fixed quickly since the devs focus on one version instead of a several. -Brendan Long
2010/2/1 Nilesh Govindarajan <lists@itech7.com>:
Agreed. But recently a USB problem (possibly a bug) was being discussed heavily on the forums. What about it ? Didn't the developers test the kernel properly before releasing it to the community ?
They do test the kernel, but you can't possibly expect them to stop updates for a bug that probably never came up during testing. They can't test every possible hardware combination, we just don't have the resources or manpower for that. If you want to help out in the process, use of the testing repo (and bug tracker and arch-dev-public mailing lists) is encouraged.
2010/2/1 Nilesh Govindarajan <lists@itech7.com>:
Agreed. But recently a USB problem (possibly a bug) was being discussed heavily on the forums. What about it ? Didn't the developers test the kernel properly before releasing it to the community ?
want to improve this situation ? use [testing] in arch, report bugs, use rc kernels, report bugs, use -next kernels, report bugs, use -mm kernels, report bugs. easy. otherwise, just get the arch premium license from the archStore, I heard they have special golden account packages with 0.001% bugs only.
2010/2/1 Nilesh Govindarajan <lists@itech7.com>:
Agreed. But recently a USB problem (possibly a bug) was being discussed heavily on the forums. What about it ? Didn't the developers test the kernel properly before releasing it to the community ?
Can you point me to this thread? Forum search and google aren't finding it, and I'm interested in this problem.
On Mon, 2010-02-01 at 11:43 -0500, Ray Kohler wrote:
2010/2/1 Nilesh Govindarajan <lists@itech7.com>:
Agreed. But recently a USB problem (possibly a bug) was being discussed heavily on the forums. What about it ? Didn't the developers test the kernel properly before releasing it to the community ?
Can you point me to this thread? Forum search and google aren't finding it, and I'm interested in this problem.
In general, I find the term 'discussed heavily' normally means 'I was affected by this and refreshed/bumped this post every few minutes to see who else was'. I have not noticed such a thread. Of course, I could have missed it, but if it was turning up on 'most recent' repeatedly I'm sure it would have stood out.
On Mon, Feb 1, 2010 at 3:59 PM, ludovic coues <couesl@gmail.com> wrote:
WAIT WHAT? http://www.archlinux.org/packages/core/i686/kernel26-lts/ http://www.archlinux.org/packages/core/x86_64/kernel26-lts/
lts is not for everyday desktop usage.
Who said anything about desktop usage ? It is useful for a server. And it turns out to also be a nice fallback if your new kernel is very broken. A fallback is not for everyday desktop usage, it's supposed to allow you to boot and fix/report/figure out whatever problem you have with the new kernel.
2010/2/1 Xavier Chantry <chantry.xavier@gmail.com>
On Mon, Feb 1, 2010 at 3:59 PM, ludovic coues <couesl@gmail.com> wrote:
WAIT WHAT? http://www.archlinux.org/packages/core/i686/kernel26-lts/ http://www.archlinux.org/packages/core/x86_64/kernel26-lts/
lts is not for everyday desktop usage.
Who said anything about desktop usage ? It is useful for a server. And it turns out to also be a nice fallback if your new kernel is very broken. A fallback is not for everyday desktop usage, it's supposed to allow you to boot and fix/report/figure out whatever problem you have with the new kernel.
If a remember right, the original poster was asking for an older kernel 'cause of usb trouble. I don't know what a server will do with a usb device. And I'm agree that head kernel is the right choice, I've chosen archlinux cause it have up to date package. And to be on the right side when world domination will happen. -- Cordialement, Coues Ludovic 06 148 743 42 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Emmanuel Benisty wrote:
On Mon, Feb 1, 2010 at 8:35 PM, Nilesh Govindarajan <lists@itech7.com> wrote:
How to install multiple kernels using pacman ?
Arch should do something like Fedora/Redhat. Maintain 1-2 previous kernels so that if a new one is buggy, then the old one can be used.
QFT.
WAIT WHAT? http://www.archlinux.org/packages/core/i686/kernel26-lts/ http://www.archlinux.org/packages/core/x86_64/kernel26-lts/
Here is how I do this My boot filesystem is on a separate partition YMMV You also need to keep all the kernel modules so you will have to save them or pacman will remove them on the upgrade. ie copy /lib/modules<kernel version> to some place and restore them after the kernel upgrade otherwise the previous kernel will complain it can't find them when you try to boot it. mkdir -vp /boot/previous # make a pkace in /boot cp -var /boot/<all the kernel files>* /boot/previous # copy all the kernel stuff #add to /boot/grub/menu.lst #(#) Arch Linux Previous title Arch Linux [Previous] root (hd0,0) kernel /prevoius/vmlinuz26 root=/dev/sda3 ro initrd /previous/kernel26.img # Now do the upgrade sudo pacman -Syy && sudo pacman -S kernel26
participants (21)
-
Allan McRae
-
Attila
-
Baho Utot
-
Brendan Long
-
Cainã
-
Daenyth Blank
-
Dan McGee
-
dave reisner
-
Emmanuel Benisty
-
fons＠kokkinizita.net
-
Heiko Baums
-
ludovic coues
-
Muhammed Uluyol
-
Ng Oon-Ee
-
Nilesh Govindarajan
-
Ray Kohler
-
Ray Rashif
-
Tom
-
Ty John
-
William A. Mahaffey III
-
Xavier Chantry