[arch-general] introducing kernel26-lts
Today I've added a 2nd kernel to our svn called "kernel26-lts". It should help to make you less caring about kernel updates. The intention is to 1) have a 2nd choice for the kernel pkg that suits better in certain situations and 2) it can be a fallback when a reboot after updating the core "kernel26" fails more detailed: 1) pkgdesc="The Linux Kernel and modules - stable longtime supported kernel package suitable for servers" The current longtime supported kernel version is 2.6.27.xx, right now we are at 2.6.27.31. The pkgdesc should clearly say what it should become in the future. Server systems won't be forced to take the risk to fail on the next boot after each kernel update. Modifications will be very small in the future within its lifecycle. The kernel configuration is based on the last .27.x config form our core pkg with small changes it has become in later versions + optimizations for server usage taken from here: http://www.serverwatch.com/tutorials/article.php/3715071/Ubuntu-Server--Kern... main changes are: 100Hz, no preempt, deadline I/O schedular. There will be no 3rd party modules. And no further patching. 2) a fallback kernel für almost everybody: a long requested feature. Everybody can install it along the core "kernel26" pkg and add lilo/grub entries for the "lts" kernel. Whenever an update of a future kernel26 will fail you won't be forced to boot with a rescue stick or cd. This should help a lot. attention: 2.6.27 kernel haven't had full ext4 support. I myself run a desktop with an ext4 / partition created with a later kernel version. the "lts" kernel is not capable to boot into this filesystem! But on real servers I guess everybody will wait a bit longer to use ext4. For the future it is planned to probably add Xen support to this or an outsplitted pkg. I will upload packages for both architectures to testing over the next days. Please discuss when you want see changes to the config file (x86_64 is done, i686 is not ready so far). -Andy
Andreas Radke wrote:
Today I've added a 2nd kernel to our svn called "kernel26-lts". It should help to make you less caring about kernel updates. The intention is to
1) have a 2nd choice for the kernel pkg that suits better in certain situations and
2) it can be a fallback when a reboot after updating the core "kernel26" fails
Having a stable unpatched kernel is definately a Good Thing. The constant kernel changes and the associated lava-pants was getting a real nuisance on my Arch servers. I wouldn't bother including Xen though, IMO it's on its last legs since Red Hat took KVM under their wings. KVM is definately the way to go. Glenn
On Monday 24 August 2009 06:34:32 pm Andreas Radke wrote:
Today I've added a 2nd kernel to our svn called "kernel26-lts". It should help to make you less caring about kernel updates. The intention is to
1) have a 2nd choice for the kernel pkg that suits better in certain situations and
2) it can be a fallback when a reboot after updating the core "kernel26" fails
Andreas, THANK YOU. That is an excellent addition. It's rare, but there are occasions every year or two where a new kernel kills needed functionality by some unintended new feature. This will be a great addition to arch. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On 08/25/2009 09:34 AM, David C. Rankin wrote:
On Monday 24 August 2009 06:34:32 pm Andreas Radke wrote:
Today I've added a 2nd kernel to our svn called "kernel26-lts". It should help to make you less caring about kernel updates. The intention is to
1) have a 2nd choice for the kernel pkg that suits better in certain situations and
2) it can be a fallback when a reboot after updating the core "kernel26" fails
Andreas,
THANK YOU. That is an excellent addition. It's rare, but there are occasions every year or two where a new kernel kills needed functionality by some unintended new feature. This will be a great addition to arch.
+1 - very useful! Great work, Andreas! DR
Am Tue, 25 Aug 2009 01:34:32 +0200 schrieb Andreas Radke <a.radke@arcor.de>:
I will upload packages for both architectures to testing over the next days. Please discuss when you want see changes to the config file (x86_64 is done, i686 is not ready so far).
-Andy
i686 is now also done and ready for intensive testing. -Andy
On Tuesday 25 August 2009 05:15:54 pm Andreas Radke wrote:
Am Tue, 25 Aug 2009 01:34:32 +0200
schrieb Andreas Radke <a.radke@arcor.de>:
I will upload packages for both architectures to testing over the next days. Please discuss when you want see changes to the config file (x86_64 is done, i686 is not ready so far).
-Andy
i686 is now also done and ready for intensive testing.
-Andy
Andreas, How do you handle the situation where you are running the nvidia driver on the normal kernel and then boot to the lts kernel? The kernel boots fine, but X is dead, presumably because the nvidia driver isn't compiled against that kernel and laughs when you tell it to start. Any way of having a separate driver in the lts kernel module tree? To do that would you just install the nvidia driver again while the lts kernel is running and have it get put in the right place? I guess so, I'll give it a go tomorrow. If that sounds like a really bad idea, let me know. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
David C. Rankin schrieb:
How do you handle the situation where you are running the nvidia driver on the normal kernel and then boot to the lts kernel? The kernel boots fine, but X is dead, presumably because the nvidia driver isn't compiled against that kernel and laughs when you tell it to start.
You don't. It's a kernel meant for servers, there won't be any module packages for it. A machine that needs the nvidia driver is not a server.
Any way of having a separate driver in the lts kernel module tree? To do that would you just install the nvidia driver again while the lts kernel is running and have it get put in the right place?
There's a PKGBUILD for nvidia, you can make it nvidia-lts with a few simple modifications. But again, you miss the point of this kernel package.
Am Mittwoch 26 August 2009 09:54:50 schrieb Thomas Bächler:
You don't. It's a kernel meant for servers, there won't be any module packages for it. A machine that needs the nvidia driver is not a server.
Maybe the kernel should be renamed to -server then. -lts is a little confusing here. -- Pierre Schmitz, http://users.archlinux.de/~pierre
On Wed, Aug 26, 2009 at 12:05, Pierre Schmitz<pierre@archlinux.de> wrote:
Am Mittwoch 26 August 2009 09:54:50 schrieb Thomas Bächler:
You don't. It's a kernel meant for servers, there won't be any module packages for it. A machine that needs the nvidia driver is not a server.
Maybe the kernel should be renamed to -server then. -lts is a little confusing here.
IMO -lts is fine. -server implies that users should prefer it over the default if they use server, but the default is quite okay for non-critical servers. And -lts name implies that it can be used for non-server purposes as well, like recovering. Anyway this is just bikeshed painting. :-P The idea of such kernel is great, I'm sure it will have quite noticeable user base. Thanks, Andy! -- Roman Kyrylych (Роман Кирилич)
On Wednesday 26 August 2009 02:54:50 am Thomas Bächler wrote:
David C. Rankin schrieb:
How do you handle the situation where you are running the nvidia
driver on
the normal kernel and then boot to the lts kernel? The kernel boots fine, but X is dead, presumably because the nvidia driver isn't compiled against that kernel and laughs when you tell it to start.
You don't. It's a kernel meant for servers, there won't be any module packages for it. A machine that needs the nvidia driver is not a server.
Any way of having a separate driver in the lts kernel module tree? To do that would you just install the nvidia driver again while the lts kernel is running and have it get put in the right place?
There's a PKGBUILD for nvidia, you can make it nvidia-lts with a few simple modifications. But again, you miss the point of this kernel package.
(smacks self for obvious stupidity -- twice for good measure ;-) Thomas, Thanks. The boxes I put the lts kernel on are just that. But, being the perpetual tinkerer, I thought I would kick the tires as many ways as I could. Now, learning has occurred, and I don't have to pick around trying to get X going when I boot the lts kernel. The x86_64 kernel boots and works just fine so far. I'll work wit the i686 kernel today time permitting. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On 08/26/2009 02:23 AM, David C. Rankin wrote:
Andreas,
How do you handle the situation where you are running the nvidia driver on the normal kernel and then boot to the lts kernel? The kernel boots fine, but X is dead, presumably because the nvidia driver isn't compiled against that kernel and laughs when you tell it to start. Any way of having a separate driver in the lts kernel module tree? To do that would you just install the nvidia driver again while the lts kernel is running and have it get put in the right place?
I guess so, I'll give it a go tomorrow. If that sounds like a really bad idea, let me know. Thanks.
Sounds like a bad idea to me. As Andreas indicated, the intended use of the lts kernel is for servers, in order to let them avoid frequent kernel upgrades. It'd be a huge amount more work for him to provide desktop-oriented modules for that kernel as well (e.g., various video cards, various wireless network cards, virtualbox, etc.) DR
On Wed, Aug 26, 2009 at 10:25 AM, David Rosenstrauch<darose@darose.net> wrote:
On 08/26/2009 02:23 AM, David C. Rankin wrote:
Andreas,
How do you handle the situation where you are running the nvidia driver on the normal kernel and then boot to the lts kernel? The kernel boots fine, but X is dead, presumably because the nvidia driver isn't compiled against that kernel and laughs when you tell it to start. Any way of having a separate driver in the lts kernel module tree? To do that would you just install the nvidia driver again while the lts kernel is running and have it get put in the right place?
I guess so, I'll give it a go tomorrow. If that sounds like a really bad idea, let me know. Thanks.
Sounds like a bad idea to me. As Andreas indicated, the intended use of the lts kernel is for servers, in order to let them avoid frequent kernel upgrades. It'd be a huge amount more work for him to provide desktop-oriented modules for that kernel as well (e.g., various video cards, various wireless network cards, virtualbox, etc.)
I half-way agree. The issue is that, no matter what you _intend_ with something, people will always do something you don't expect. It's part of the reason you see warnings like "Do not put in nose" on a package for an electric toothbrush :) We _may_ have to maintain the out-of-tree network drivers, at the very least, but I don't know if nvidia is worth it. Perhaps someone will begin making a side repo with additional LTS modules (*hint* *hint*)
On Wed, 2009-08-26 at 10:29 -0500, Aaron Griffin wrote:
I half-way agree. The issue is that, no matter what you _intend_ with something, people will always do something you don't expect. It's part of the reason you see warnings like "Do not put in nose" on a package for an electric toothbrush :)
We _may_ have to maintain the out-of-tree network drivers, at the very least, but I don't know if nvidia is worth it. Perhaps someone will begin making a side repo with additional LTS modules (*hint* *hint*)
WTF? They do put that on toothbrush packages? :D Anyways, the nice thing about an LTS kernel is that it's LTS stable. So if you compile your own Nvidia drivers that are also LTS, they will keep working, no matter how often you update the LTS kernel. That's the whole idea of having a LTS kernel.
On Wed, Aug 26, 2009 at 18:29, Aaron Griffin<aaronmgriffin@gmail.com> wrote:
I half-way agree. The issue is that, no matter what you _intend_ with something, people will always do something you don't expect. It's part of the reason you see warnings like "Do not put in nose" on a package for an electric toothbrush :)
We _may_ have to maintain the out-of-tree network drivers, at the very least, but I don't know if nvidia is worth it. Perhaps someone will begin making a side repo with additional LTS modules (*hint* *hint*)
I think someone will make packages for drivers in AUR. There are lots of driver packages for user-made kernels, so driver packages for official kernel will surely appear in AUR. -- Roman Kyrylych (Роман Кирилич)
On Wednesday 26 August 2009 10:53:56 am Roman Kyrylych wrote:
On Wed, Aug 26, 2009 at 18:29, Aaron Griffin<aaronmgriffin@gmail.com> wrote:
I half-way agree. The issue is that, no matter what you _intend_ with something, people will always do something you don't expect. It's part of the reason you see warnings like "Do not put in nose" on a package for an electric toothbrush :)
We _may_ have to maintain the out-of-tree network drivers, at the very least, but I don't know if nvidia is worth it. Perhaps someone will begin making a side repo with additional LTS modules (*hint* *hint*)
I think someone will make packages for drivers in AUR. There are lots of driver packages for user-made kernels, so driver packages for official kernel will surely appear in AUR.
Oh, I didn't mean to start a fire-storm. But for any of the kernels I have loaded on my boxes, I usually try to get X setup so if I have to do any lengthy file management, editing, etc. from the console, then I have the convenience of graphical interface should I need or want something that isn't provided in text mode. For the lts kernel, I agree, if the nvidia driver is a whole lot of work to prepare and maintain for the lts kernel, then it's not worth it. But, on the other hand, if it is fairly easy to put together a nvidia-lts package, then it might be something to consider. If the nvidia driver is too much of a pain to maintain, the how about the nv driver. That way all you would have to do is modify your xorg.conf and change "nvidia" to "nv" and restart X if you wanted a gui on the lts kernel. Either the radeon or radeonhd drivers would work fine for the other side of the house. The only reason I go to the trouble of getting X setup on the server boxes is that there are just some things that are easier done in X than from the console. I'm fine with vim, lynx, mc, etc... like them in fact and prefer them over their gui counterparts for a bunch of things. The intent here is *not* a complaint against lts at all. The lack of graphics driver capability on the lts kernel is fine (now that I understand its scope) and I agree there is no reason to rename "lts" to "server" -- I kind of like lts anyway. What led to this was Andreas request that the lts kernel be tested. Which is what I was doing -- I just go about testing in whacky ways.... All of this is just food for thought. As far as the feedback Andreas probably expected -- so far, the lts kernel works fine on my msi k9n2 box w/phenom processor. Apache2, bind, php5.3, ssl, etc.. all seem fine with the kernel. ( Next - I'll go see if I can get virtualbox to work on it and report back ) ((ducking....)) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Wed, Aug 26, 2009 at 7:46 PM, David C. Rankin<drankinatty@suddenlinkmail.com> wrote:
If the nvidia driver is too much of a pain to maintain, the how about the nv driver. That way all you would have to do is modify your xorg.conf and change "nvidia" to "nv" and restart X if you wanted a gui on the lts kernel. Either the radeon or radeonhd drivers would work fine for the other side of the house.
You can already use nv driver (or even vesa), it does not require any kernel modules.
On Wednesday 26 August 2009 12:49:25 pm Xavier wrote:
On Wed, Aug 26, 2009 at 7:46 PM, David C.
Rankin<drankinatty@suddenlinkmail.com> wrote:
If the nvidia driver is too much of a pain to maintain, the how about the nv driver. That way all you would have to do is modify your xorg.conf and change "nvidia" to "nv" and restart X if you wanted a gui on the lts kernel. Either the radeon or radeonhd drivers would work fine for the other side of the house.
You can already use nv driver (or even vesa), it does not require any kernel modules.
Case closed -- we have out answer. Thanks Xavier. For the nv driver: sudo perl -p -i -e 's/"nvidia"/"nv"/' /etc/X11/xorg.conf To go back: sudo perl -p -i -e 's/"nv"/"nvidia"/' /etc/X11/xorg.conf Now where in the arch boot process could I put a script that basically says if uname -r is the lts kernel switch to nv and vice-versa? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Wed, Aug 26, 2009 at 14:46, David C. Rankin<drankinatty@suddenlinkmail.com> wrote:
Now where in the arch boot process could I put a script that basically says if uname -r is the lts kernel switch to nv and vice-versa?
Nowhere. Since when do we modify user config files in this manner? Making something robust would be insanely bloated to cover all the edge cases. Let the user modify their own config files, just as with every other thing we do.
On Wed, Aug 26, 2009 at 15:00, Daenyth Blank<daenyth+arch@gmail.com> wrote:
On Wed, Aug 26, 2009 at 14:46, David C. Rankin<drankinatty@suddenlinkmail.com> wrote:
Now where in the arch boot process could I put a script that basically says if uname -r is the lts kernel switch to nv and vice-versa?
Nowhere. Since when do we modify user config files in this manner? Making something robust would be insanely bloated to cover all the edge cases. Let the user modify their own config files, just as with every other thing we do.
Woops sorry, I misread your message as if you were suggesting such a check be added to the package. Ignore me.
At Mittwoch 26 August 2009 20:46 David C. Rankin wrote:
Now where in the arch boot process could I put a script that basically
says
if uname -r is the lts kernel switch to nv and vice-versa?
/etc/rc.local: if [ $(uname -r) = "2.6.27-lts" ]; then # do what you need to use nv fi But i think this will only works if you start kdm from the inittab ... or better to say, i don't know if this will works in the other case. See you, Attila
On Tue, Aug 25, 2009 at 01:34:32AM +0200, Andreas Radke wrote:
Today I've added a 2nd kernel to our svn called "kernel26-lts". It should help to make you less caring about kernel updates. The intention is to
Does this kernel have PAE support compiled in? Regards Milos
On Tue, Aug 25, 2009 at 1:34 AM, Andreas Radke<a.radke@arcor.de> wrote:
2) a fallback kernel für almost everybody: a long requested feature. Everybody can install it along the core "kernel26" pkg and add lilo/grub entries for the "lts" kernel. Whenever an update of a future kernel26 will fail you won't be forced to boot with a rescue stick or cd. This should help a lot.
That is great ! Now there is one official kernel that virtualbox can actually boot. Even though this was a virtualbox bug, which didn't like 2.6.30, not having any alternative kernel when your system stops booting is never fun. (btw the bug should be fixed in the next 3.0.6 release). Thanks a lot for that, I will be a happy user of lts (even if I don't use it, I will always make sure I have it installed :))
2.6.27.31-2 is up for both arches and _should_ fully support ext4 filesystem. So far I couldn't reboot my ext4 system, because it's busy with uploading other stuff for some hours. Though I don't expect any trouble try it only with non critical ext4 root filesystem partitions. You've been warned. When we can canfirm this kernel well booting also into ext4 it's a major step to get real "fallback" state. -Andy
Am Wed, 26 Aug 2009 20:33:56 +0200 schrieb Andreas Radke <a.radke@arcor.de>:
2.6.27.31-2 is up for both arches and _should_ fully support ext4 filesystem. So far I couldn't reboot my ext4 system, because it's busy with uploading other stuff for some hours.
Though I don't expect any trouble try it only with non critical ext4 root filesystem partitions. You've been warned.
When we can canfirm this kernel well booting also into ext4 it's a major step to get real "fallback" state.
-Andy
I could boot my ext4 system as expected without any trouble and with a clean dmesg. It should be ready now to be a full fallback and rescue kernel with advantages in certain areas (server usage). -Andy
participants (13)
-
Aaron Griffin
-
Andreas Radke
-
Attila
-
Daenyth Blank
-
David C. Rankin
-
David Rosenstrauch
-
Jan de Groot
-
Milos Negovanovic
-
Pierre Schmitz
-
RedShift
-
Roman Kyrylych
-
Thomas Bächler
-
Xavier