[arch-dev-public] 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
i686 version is now also available. to the devs: please post your opinions where it should go after the testing period? do you want it in extra or as official alternative even in core? I'd prefer extra but would also like to see this kernel as a 2nd choice on our future iso snapshots. -Andy
On Tue, Aug 25, 2009 at 5:18 PM, Andreas Radke<a.radke@arcor.de> wrote:
i686 version is now also available.
to the devs: please post your opinions where it should go after the testing period? do you want it in extra or as official alternative even in core?
I'd prefer extra but would also like to see this kernel as a 2nd choice on our future iso snapshots.
I agree it might be nice to have a choice, but I also think that if we're going to make sure something is stable, we should try to enforce some sort of signoff process, just to ensure it's all working ok
On Wed, Aug 26, 2009 at 12:20 AM, Aaron Griffin<aaronmgriffin@gmail.com> wrote:
On Tue, Aug 25, 2009 at 5:18 PM, Andreas Radke<a.radke@arcor.de> wrote:
i686 version is now also available.
to the devs: please post your opinions where it should go after the testing period? do you want it in extra or as official alternative even in core?
I'd prefer extra but would also like to see this kernel as a 2nd choice on our future iso snapshots.
I agree it might be nice to have a choice, but I also think that if we're going to make sure something is stable, we should try to enforce some sort of signoff process, just to ensure it's all working ok
agreed, it should go into core where we have to signoff. It would be funny to find out that our lts kernel is broken at some time... people expect something more 'stable' than the latest kernel so we have to make sure that it works fine. Ronald
On Wed, Aug 26, 2009 at 3:34 AM, Ronald van Haren<pressh@gmail.com> wrote:
On Wed, Aug 26, 2009 at 12:20 AM, Aaron Griffin<aaronmgriffin@gmail.com> wrote:
On Tue, Aug 25, 2009 at 5:18 PM, Andreas Radke<a.radke@arcor.de> wrote:
i686 version is now also available.
to the devs: please post your opinions where it should go after the testing period? do you want it in extra or as official alternative even in core?
I'd prefer extra but would also like to see this kernel as a 2nd choice on our future iso snapshots.
I agree it might be nice to have a choice, but I also think that if we're going to make sure something is stable, we should try to enforce some sort of signoff process, just to ensure it's all working ok
agreed, it should go into core where we have to signoff. It would be funny to find out that our lts kernel is broken at some time... people expect something more 'stable' than the latest kernel so we have to make sure that it works fine.
Ronald
I don't think that it needs to go in core to get signoffs. We could put it in extra and make an exception (i.e. require signoff). The only advantage of putting it in core is to offer it as an alternative kernel for the iso.
I don't think that it needs to go in core to get signoffs. We could put it in extra and make an exception (i.e. require signoff). The only advantage of putting it in core is to offer it as an alternative kernel for the iso.
Is there a disadvantage to putting it in core? I'd say if I was going to install the lts kernel on a server, It'd be annoying to have to install using kernel26 then install lts from extra later. Having it available on the install CD would be useful. Not to mention core explicitly requires signoffs which solves that problem also. Dale
Dale Blount a écrit :
I don't think that it needs to go in core to get signoffs. We could put it in extra and make an exception (i.e. require signoff). The only advantage of putting it in core is to offer it as an alternative kernel for the iso.
Is there a disadvantage to putting it in core? I'd say if I was going to install the lts kernel on a server, It'd be annoying to have to install using kernel26 then install lts from extra later. Having it available on the install CD would be useful. Not to mention core explicitly requires signoffs which solves that problem also.
Dale
+1 from me for putting it in core
Am Wed, 26 Aug 2009 22:00:11 +0200 schrieb Firmicus <Firmicus@gmx.net>:
Dale Blount a écrit :
I don't think that it needs to go in core to get signoffs. We could put it in extra and make an exception (i.e. require signoff). The only advantage of putting it in core is to offer it as an alternative kernel for the iso.
Is there a disadvantage to putting it in core? I'd say if I was going to install the lts kernel on a server, It'd be annoying to have to install using kernel26 then install lts from extra later. Having it available on the install CD would be useful. Not to mention core explicitly requires signoffs which solves that problem also.
Dale
+1 from me for putting it in core
I can boot my ext4 / filesystem with a clean dmesg :) I don't care if I will maintain it in core or extra with additional signoff. Maybe our ISO makers should say if they have enough space for this kernel for both arches in core or if they would like to put it manually as bonus to the disc and how the selection will work (remember the scsi/ide years?). To me core would be the more logical place stating it's of the same quality and importance. -Andy
Andreas Radke schrieb:
I can boot my ext4 / filesystem with a clean dmesg :)
I don't care if I will maintain it in core or extra with additional signoff. Maybe our ISO makers should say if they have enough space for this kernel for both arches in core or if they would like to put it manually as bonus to the disc and how the selection will work (remember the scsi/ide years?).
To me core would be the more logical place stating it's of the same quality and importance.
This may mean the end of the multi-arch images unless we can compress the squashfs better.
On Wed, Aug 26, 2009 at 5:14 PM, Thomas Bächler<thomas@archlinux.org> wrote:
Andreas Radke schrieb:
I can boot my ext4 / filesystem with a clean dmesg :)
I don't care if I will maintain it in core or extra with additional signoff. Maybe our ISO makers should say if they have enough space for this kernel for both arches in core or if they would like to put it manually as bonus to the disc and how the selection will work (remember the scsi/ide years?).
To me core would be the more logical place stating it's of the same quality and importance.
This may mean the end of the multi-arch images unless we can compress the squashfs better.
We can. squashfs-lzma is a significant improvement, but it can't be built out of tree, I don't think (last I checked was a while ago, this may have changed)
On Wed, Aug 26, 2009 at 5:31 PM, Aaron Griffin<aaronmgriffin@gmail.com> wrote:
On Wed, Aug 26, 2009 at 5:14 PM, Thomas Bächler<thomas@archlinux.org> wrote:
Andreas Radke schrieb:
I can boot my ext4 / filesystem with a clean dmesg :)
I don't care if I will maintain it in core or extra with additional signoff. Maybe our ISO makers should say if they have enough space for this kernel for both arches in core or if they would like to put it manually as bonus to the disc and how the selection will work (remember the scsi/ide years?).
To me core would be the more logical place stating it's of the same quality and importance.
This may mean the end of the multi-arch images unless we can compress the squashfs better.
We can. squashfs-lzma is a significant improvement, but it can't be built out of tree, I don't think (last I checked was a while ago, this may have changed)
http://www.squashfs-lzma.org/ method block size Slax data size percent uncompressed - 668 MB 100% mksquashfs+gzip 64KB 227 MB 34% mksquashfs+gzip 1024KB 222 MB 33% mksquashfs+lzma 64KB 191 MB 28% mksquashfs+lzma 128KB 184 MB 27% mksquashfs+lzma 512KB 172 MB 26% mksquashfs+lzma 1024KB 167 MB 25%
Aaron Griffin schrieb:
We can. squashfs-lzma is a significant improvement, but it can't be built out of tree, I don't think (last I checked was a while ago, this may have changed)
It has been discontinued when squashfs was merged into the kernel. Now lzma is also merged into the kernel, but neither squashfs nor the squashfs-tools support lzma. I guess OpenWRT has patches for it.
On Wed, Aug 26, 2009 at 5:32 PM, Thomas Bächler<thomas@archlinux.org> wrote:
Aaron Griffin schrieb:
We can. squashfs-lzma is a significant improvement, but it can't be built out of tree, I don't think (last I checked was a while ago, this may have changed)
It has been discontinued when squashfs was merged into the kernel. Now lzma is also merged into the kernel, but neither squashfs nor the squashfs-tools support lzma.
I guess OpenWRT has patches for it.
From a mailing list port:
Phillip Lougher Jun 17, 2009
Since lzma is in kernel 2.6.30 now, is it going to be added into kernel 2.6.31 or 2.6.32 merger window?
I started working on LZMA support a couple of days ago. I'm hoping to get it finished for the 2.6.31 merge window, though I may miss this. It depends on whether I hit any problems, and how soon the merge window closes. ------ So this is on the docket. When it's supported, we'll have more space to play with. We can also play with the blocksize for squashfs, to see if it'd make a difference
I don't care if it goes to either core or extra. We can request signoffs also in extra. Though there should be no need in a stable series. But this wouldn't be a problem for me. Maybe our iso makers Dieter and Gerhard should post their opinion from technical view how the iso integration would be affected by the repo choice where it will go. Anyways I'd like to hear some more "yeah, at least it boots and dmesg is quiet clean" before I'll start to request signoffs (if needed/wanted). -Andy
participants (7)
-
Aaron Griffin
-
Andreas Radke
-
Dale Blount
-
Eric Bélanger
-
Firmicus
-
Ronald van Haren
-
Thomas Bächler