Revision as of 18:09, 26 July 2006

Deprecated notice

Since the officialy release of Lunar 1.6.0, this article has now become deprecated, however it may still prove useful for those still running 2.4 systems that may wish to upgrade without a complete reinstall. YMMV - Striker 17:09, 26 Jul 2006 (UTC)

What's this 2.6 kernel hoo-hah about anyway?

The Linux kernel version 2.6 is the current stable Linux kernel. Although Lunar Linux is a bleeding edge distribution, we do not think that a jump to a full 2.6 install is a good idea for production servers yet. A desktop can run comfortably on 2.6, but if you are a newbie, we strongly recommmend you starting off with 2.4. If you still think about going ahead, having a bootable fall back 2.4 kernel is useful, specially when you configure a 2.6 kernel for the first time.

Having said that, and keeping it in mind, we will describe how to install a 2.6 kernel, using our lunar kernel module called linux-2.6 (that only holds stable kernel.org releases). Although we are going to use linux-2.6 here, this howto can be applied for any other of our linux-2.6 set (currently linux-2.6-ck, linux-2.6-grsec, linux-2.6-inotify, linux-2.6-mm and linux-2.6-prepatch).

Who wrote all this fine software?

The main 2.5 and the later 2.6 trees have been maintained by Linus Torvalds. This responsability is now in hands of Andrew Morton, who for testing purposes keeps his own set of patches against the 2.6 tree. The patches' names are suffixed with -mm. A Lunar module with the mm patch is available, though not recommended for first 2.6 installs. If you have a problem with the current served kernel in linux-2.6, linux-2.6-mm maybe a temporary solution. Once tested, the features that are doing fine in mm patches are merged into the main 2.6 tree, so if linux-2.6-mm works now, it is very likely linux-2.6 will as well very soon.

Why would I want to switch away from my 2.4 kernel?

The first time I tried a (then) 2.5 kernel, I did so because of curiosity. I wanted to feel directly how this new thing ran. I've hardly ever stopped using it since then. If you have an X server running on your 2.6 kernel, the first thing that you'll notice is your mouse speed skyrocket. The responsiveness of the X apps has taken a huge step forward. This is only one of the many new features you will find in the 2.6 series.

Apparently, there has been a focus on server side, though the average user should be pleased, as exampled above with X. PDA and embedded linux users should be happy, too.

From server side, the leap from the 2.4 to the 2.6 kernel is more than a simple version change:

• 64 bit support.
• NUMA ( Non-Uniform Memory Access ): For clusters with a high amount of nodes, memory sharing is vital. NUMA adresses this problem.
• The addressing space for unique users is no more 16 bit but 32 bit. so the user support has grown to 4 billion from 65,000.
• Higher limits: PIDs (process IDs) have grown from 32,000 to 1 billion, RAM's max is now 64 GB instead of 4 GB, and filesystem's top is set at 16 Terabytes, instead of 4.

Desktop/laptop have had their share of new features as well:

• ALSA (Advanced Linux Sound Architecture) has been merged in the kernel tree and it has better joystick support.
• Broader wireless and native Bluetooth support.
• Software suspend-to-disk and speed scaling for laptops.

Embedded systems have also been taken care of:

• uCLinux support.
• Support for more types of MMU-less processors, like PDAs, for example.
• Embedded Profile support.

At least the first 2 (servers and desktops/laptops) will benefit from some other upgrades:

• New scheduler: optimization of system resources, no matter if you have 1 CPU or you have many.
• Better I/O scheduler, faster read/writes.

Those most probably are not all, but I suppose you can get a slight idea on how things have changed. Remember that 2.6 kernel is fairly young.

Where would I want to install it?

Starting from the features listed above, the 2.6 kernel would be suited from any machine like a big cluster, SMP machine, down to a desktop or something as small as a handheld. But I have my own case to show you that 2.6 kernels work. I have 2 desktops and a server, all 3 with 2.6 kernels and fully 2.6 installs, and I must say I have no complaint. Don't think I'm alone here, since I have friends that I have helped install 2.6 kernels (no big deal, as you will see), or they have done so by themselves on their desktops, laptops or servers. They didn't worry about if their hardware was the oldest or brand new, they jumped anyway. The news I have is that they are quite happy. Sum up Lunar users and fellow Lunar devs, and I know a good lot running 2.6 kernels. And you are hopefully next :)

Okay. I'm convinced. How do I install this thing?

Before you do anything else, I'd recommend you take your time to do the switch, because changing from a 2.4 tree to a 2.6 tree kernel is not so simple as compiling a 2.6 kernel with your 2.4 .config. Please don't rush!

Installing the Kernel

The first stage of a jump to a 2.6 kernel install would be to install the latest available in moonbase; the second stage would be setting all your Lunar install to be 2.6 based, recompiling each Lunar module against 2.6 headers, but you need not worry about that, if you don't want to -it is not necessary, though it will be explained. By the way, you can still run a 2.6 kernel in a 2.4 header environment, if you just want to give it a small test.

To install the last 2.6 kernel from moonbase all you have to do is to install the linux-2.6 Lunar module. You will start the compile from a default .config the kernel tarball brings, since the difference between 2.6's config and 2.4's is too big to import your current 2.4 kernel configuration -in some cases it has even been problematic. I again here strongly recommend walking through the whole kernel's configuration. This is important because the configuration's hierarchy tree has changed a lot: things have been moved, others taken out, and new features have been fitted in (that you might want to know).

Now let's get to the nitty gritty of it, and do the install itself. As root:

  root@myshinybox ~ # lin linux-2.6

will fetch the sources and prepare the build. As a dependency, the module-init-tools Lunar module will be installed, because it is needed for kernel module management (as the modutils Lunar module is needed for 2.4 kernels).

Now you will be asked a few questions, first of all about your bootloader:

  linux-2.6: Configure this kernel to load from grub? [n]

If you answer 'y', an entry will be added to grub's menu.lst file, and you will be prompted with another question after:

  linux-2.6: Configure grub? [n]

If you say no, grub will be handled automagically. If you say yes, you will have to configure grub yourself after the kernel build. If, on the other hand, you said no to the "Configure this kernel to load from grub" question, you should see, analogously to grub:

  linux-2.6: Configure this kernel to load from lilo? [n]

Answer yes ('y'), if you wish to use lilo as your prime bootloader.

If you answered yes to the lilo question, you should be prompted just like grub:

  linux-2.6: Configure lilo? [n]

Once again, if you say 'y' (yes) you will have to hand configure lilo.conf after the kernel build has finished. If you said no, lin will take care for you. For now, a safe answer is say no to bootloader configuration, so Lunar takes care of your grub or lilo.

Next step to cope with is what interface we are going to use to configure the kernel:

  linux-2.6: Do you prefer xconfig over menuconfig? [n]

If you want to use xconfig, answer 'y'. If you prefer any other answer 'n'. If you answer 'n', you will have one more question on this topic:

  linux-2.6: Do you prefer menuconfig over config? [y]

Unless you really know what you are doing, say 'y' to use a ncurses interface (make menuconfig) and not use a questionaire method (make config). Any other answer than 'y' will lead you to make config.

Finally, you will see one last question:

  linux-2.6: Configure linux kernel? [n]

As it is your first encounter with linux-2.6, please answer 'y', so you walk the whole kernel config (remember, it is important to walk to whole lot!).

Now that questions have been dealt with, the source will be downloaded. Once the download finished, the source has been unpacked, and the build began, your interface of choice to the kernel's configuration will be shown. Choose what you need for your box.

After kernel configuration, you will be prompted one more time:

  Repeat config? [n]

If you think you missed something and you want to go back to kernel configuration, you are still in time; yet, if you are happy already, just say 'n', and watch your kernel build. You will prompted with this question every time you finish your config method.

When the kernel has succesfully built, two things may happen, depending on what you answered previously: if you have answered yes to configure your bootloader, you will see your bootloader's config file opened in an editor for you. A new kernel entry, for your new kernel will be there, so you can do some tweaking if you like. If you decided to let lin take care (answered 'n' to configure your bootloader), this will be done without your interaction.

Yay, done with the kernel! ;)

udev and sysfs

udev is a new feature in 2.6. It brings dynamic userspace dev nodes, the equivalent in userspace of what devfs did in kernel for 2.4. Udev is based on another new feature: sysfs. Sysfs is a virtual filesystem, that lists system information in a hierarchical way (like a boosted proc, so you can get the idea). Both udev and sysfs, unlike other features in 2.6 that have been backported, are not seen in 2.4 kernels.

There is no fixed reason why you should install udev, though it will simplify a lot your work, so we do recommend doing so. A good reason is that if you are used to using dynamic dev nodes, sooner or later devfs will be deprecated (it is already marked as such in the kernel) and will be droped out. Another solution is having a static /dev with permanent nodes, that you can hand create each time you need a new node, or create the whole lot of device nodes using the makedev Lunar module.

udev uses hotplug to create the nodes under /dev, so it is completely independant from the running kernel. It uses namedev to set device naming policies, and libsysfs to query sysfs.

To install udev, as root:

  root@myshinybox ~ # lin udev

will install udev, and sysfsutils and hotplug as dependencies. One thing you have to know about udev is that its use excludes the use of devfs. You can still have devfs support as a module but you must not enable "automatically mount devfs at boot" (see the kernel's Filesystems section, subsection pseudo filesystems). Furthermore, the kernel has to be hotplug aware, so this option should be included when compiling a kernel for udev (see General Setup -> Support for hot-pluggable devices).

Yay, done with udev!

IMPORTANT NOTE: At this point, whatever you choose as your /dev, please really read The kernel commandline /dev params mini-HowTo

Rebuilding software against 2.6 headers

The possible second stage of a 2.6 migration would be rebuilding our software against 2.6 headers.

Before explaining how to accomplish the 2.6 header based Lunar box, I will make one last warning: The Lunar Linux team does not officially support 2.6 installs. This is very important, because we currently do not do 2.6 specific fixes, if these collide with 2.4 only Lunar module setups (there are exceptions). If you come around any problem, please report it, as it will be taken in consideration, that is for sure. Example of this willingness to help is this howto.

The process of switching is quite simple, really. There is a Lunar module that serves a series of sanitized kernel headers, kernel-headers-2.6, but everytime glibc is recompiled it creates a tarball from the headers under /usr/src/linux. So if the last kernel you installed was linux-2.6, you'll have a 2.6 headers tarball created from it and installed, if you recompiled glibc after installing your kernel. This is not true if you installed kernel-headers-2.6's Lunar module; glibc would still create the headers, but not install them. This is an exception to the Lunar's 2.6 non-support module scheme.

For the sake of standarization, we recommend the install of kernel-headers-2.6. Bug tracking for you and for us will be simplified if we use the same set of headers. If each of us have our own headers with different versions, it would be harder to know if it is an app problem or a header problem. So, if you decide to take this step, and move to a fully 2.6 environment, please install kernel-headers-2.6. We all move forward together.

Taking for granted you do want to install kernel-headers-2.6, as root type:

  root@myshinybox ~ # lin kernel-headers-2.6

Second step here is to rebuild your software against your new headers. This should be done in a certain order. As a base 2.6 install, from which later rebuild the rest of your apps, you should lin:

• kernel-headers-2.6
• gcc
• glibc
• installwatch
• binutils
• coreutils
• bzip2
• gzip
• tar
• diffutils
• findutils
• make
• grep
• gawk
• sed
• gettext
• ncurses
• patch
• texinfo
• bash
• util-linux
• perl

Having done this, you will have a good base towards having a fully 2.6 install. From now on, you can rebuild in whatever order you want the rest of your installed Lunar modules so they as well are 2.6 based.

Yay, done with headers!

Credits

"Linux 2.6.0: What's New" from osdl.org

Special thanks to : Aaron Watry, Alex Hunsaker, and Auke Kok

Original article text by Jaime Buffery (nestu AT lunar-linux DOT org)

Old docbook conversion and other nifty tweaks by Drew Swayze (drew AT lunar-linux DOT org)

Copyleft 2004-2005 The Lunar-Linux Team