You are not logged in.
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/ar … ations.htm
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
Offline
Great idea, great job!
Offline
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
I love Arch!
This is a good idea (TM)
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Great news, but I think most desktop users have an ext4 root by now, so manually adding it to the initcpio image is the only option?
Offline
if you mount an old ext3 as ext4 it _should_ work. you can try it out.
on my system with a true ext4 partition created with a later kernel version (29?) it failed. kernel is running well on my laptop with reiserfs and my server with jfs on /.
Offline
Afaik you can only mount ext3 partitions as ext4 but not the other way round due to extents which ext3 simply does not support.
Offline
maybe you can try to mount the partition as ext4dev (depends on the .config
of course, IIRC you have a ext4dev compat option)
ext4dev has been around since ages:
http://www.kernel.org/pub/linux/kernel/ … nounce.txt
(oopsie the link is for the -mm branch but anyway, I guess it's in Linus' tree since a long time too)
edit#2 i saw the ext4dev module in the .config of this kernel26-lts so that /may/ work.
Last edited by bangkok_manouel (2009-08-25 10:01:05)
Offline
http://projects.archlinux.org/?p=mkinit … f2625ac22a
maybe we need to add something similar to get mkinitcpio accepting ext4dev system supported by lts kernel.
Offline
Great idea the lts-kernel. I'm going to install this one on my server, because I don't like to reboot my server every month. Concerning the kernel-version of kernel26-lts: why was 2.6.27 choosen as the lts-kernel? And does the lts-kernel include a patch for this security leak? http://cve.mitre.org/cgi-bin/cvename.cg … -2009-2692
Offline
1.) http://lkml.org/lkml/2008/10/11/235
2) yes, the fix is included in 2.6.27.30 - http://article.gmane.org/gmane.linux.kernel/878235
Offline
First thank for your works and this is realy a nice idea.
I have one proposal: I have a 2.6.27 stable kernel package too but instead of using it for a server i use it more than a "real" fallback kernel. Therefore i use a seperate /etc/mkinitcpio-stable.conf where i load more modules (most of the filesystems) and activate more HOOKS than in the normal mkinitcpio.conf. For a fallback this could be a nice idea because if the most is activated there should no problem to transfer the harddisk to another pc at example. This be only an idea.
Offline
that case should be covered by the fallback image that don't extract unneded modules with the autodetect hook.
Offline
that case should be covered by the fallback image that don't extract unneded modules with the autodetect hook.
Sorry, i'm not sure so i have to ask this: Is it realy true that the fallback image includes more filesystems with the autodetect hook? If yes, than i have misunderstood this hook.
But there is another point: What happens to your 2.6.27 kernel if i have activate lzma in the mkinitcpio.conf?
Please be aware about one thing: This be only thoughts of mine and no showstoppers.:)
Offline
autodetect is for the small initrd and not for the fallback one! by default many filesystems are loaded into the initrd, using the autodetect hook finds the one for /boot and only puts this one into the small initrd. autodetect is not for the fallback image!
try "less /lib/initcpio/install/autodetect" and all the other mkinitcpio files.
Offline
@AndyRTR Thanks for the infos.
Offline
Afaik its not really recommond to mount etx4 with the ext4-dev driver anymore; especially if this should be used on production systems.
Offline
Thomas also told that it would be not possible to make mkinitcpio mount ext4 with that kernel in a safe way. So the resolution is simple: this kernel doesn't support any ext4. I may remove it from the config at all, not sure.
Offline
The current udev requires a minimum kernel of 2.6.24 (see http://www.archlinux.org/news/457/). How is kernel26-lts going to handle udev, when Arch's udev is upgraded to a version that doesn't support 2.6.27?
Offline
The current udev requires a minimum kernel of 2.6.24 (see http://www.archlinux.org/news/457/). How is kernel26-lts going to handle udev, when Arch's udev is upgraded to a version that doesn't support 2.6.27?
24 is older than 27 (the higher number the newer version)
Offline
jealma wrote:The current udev requires a minimum kernel of 2.6.24 (see http://www.archlinux.org/news/457/). How is kernel26-lts going to handle udev, when Arch's udev is upgraded to a version that doesn't support 2.6.27?
24 is older than 27 (the higher number the newer version)
I think you need to read that question again.
archlinux - please read this and this — twice — then ask questions.
--
http://rsontech.net | http://github.com/rson
Offline
I believe uvdev will still support .27 for a long time, as the kernel is being maitained for a long period of time by kernel developer(s).
Last edited by Zariel (2009-08-25 20:27:49)
Offline
yes, I also expect a long udev support for .27 series. at least until next lts kernel is born.
btw: i686 version is now also up.
please now give it good and intensive tests. look out for changes you'd like to see in the config. right now i686 and x86_64 should be almost in sync expect 4gb memory support for i686 and 64gb for x86_64.
Offline
Thomas also told that it would be not possible to make mkinitcpio mount ext4 with that kernel in a safe way. So the resolution is simple: this kernel doesn't support any ext4. I may remove it from the config at all, not sure.
If i take a look at the changelogs of this lts kernel series than i have the impression that they backport the changes for ext4. If i see how many people starts using ext4 than lts without ext4 makes no sense and i don't think that the kernel devs from 2.6.27 don't know this. So i think it would be worth to look nearer to find out if this is realy true.
Or do we speak about the problem with a "/"-partition without a separate "/boot"-partition? In this case it is not necessary to stop including the ext4 modul from my view.
Offline
I have no seperate /boot partition and / is ext4 created by a kernel/e2fsprogs around 2.6.28 or 29. The boot failed when mkinitcpio detected the partition as ext4 filesystem and gave a panic.
I doubt kernel devs will back anything major into a stable series.
Offline