[Lunar-commits] r15508 - lunar-doc/trunk/lunar-manual
ca3sar
ca3sar at lunar-linux.org
Tue Jun 28 15:29:12 UTC 2005
Author: ca3sar
Date: 2005-06-28 15:29:10 +0000 (Tue, 28 Jun 2005)
New Revision: 15508
Modified:
lunar-doc/trunk/lunar-manual/Lunar_Book.tex
Log:
Updated chapter about Linux 2.6
Modified: lunar-doc/trunk/lunar-manual/Lunar_Book.tex
===================================================================
--- lunar-doc/trunk/lunar-manual/Lunar_Book.tex 2005-06-28 15:05:08 UTC (rev 15507)
+++ lunar-doc/trunk/lunar-manual/Lunar_Book.tex 2005-06-28 15:29:10 UTC (rev 15508)
@@ -834,123 +834,64 @@
\section{Kernel 2.6}
- WHAT
+\subsection{Preamble}
- 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 everyone right now.
-Therefore, the 2.6 kernel, from Lunar's point of view, is still
-considered beta, until we feel that the maturity of the kernel itself
-and the whole userland software we serve is 2.6 safe. This means that
-the userland applications will have to compile flawlessly against our
-2.6 headers.
+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 everyone right now. Therefore, the 2.6 kernel, from Lunar's point of view, is still considered beta, until we feel that the maturity of the kernel itself and the whole userland software we serve is 2.6 safe. This means that the userland applications will have to compile flawlessly against our 2.6 headers.\par
- Please note that this is in no way a judgement about the stability
-or usability of the 2.6 kernel. It just doesn't do well with a few
-applications, as did the 2.4 kernel when it just came out a few years ago.
-
- Having said that, and keeping it in mind, we will describe how to
-install a 2.6 kernel. If you feel lucky, you can upgrade your whole
-Lunar install to be completely 2.6 based. If you are thinking of doing
-this on a production server, you should think twice. A 2.6 kernel could
-be fine, but a full 2.6 install may just not be a good idea.
-
-
-
- WHEN
+Please note that this is in no way a judgement about the stability or usability of the 2.6 kernel. It just doesn't do well with a few applications, as did the 2.4 kernel when it just came out a few years ago. \par
+ Having said that, and keeping it in mind, we will describe how to install a 2.6 kernel. If you feel lucky, you can upgrade your whole Lunar install to be completely 2.6 based. If you are thinking of doing this on a production server, you should think twice. A 2.6 kernel could be fine, but a full 2.6 install may just not be a good idea. \par
- The 2.5 kernel became grown up on the 18th of December, 2003,
-when the stable 2.6 tree was released. Before that, since April 2003,
-the linux-beta Lunar module has been in moonbase.
+The 2.5 kernel became grown up on the 18th of December, 2003, when the stable 2.6 tree was released. Before that, since April 2003, the linux-beta Lunar module has been in moonbase. \par
+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-beta, linux-beta-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-beta-mm works now it is very likely linux-beta will as well very soon. \par
+ 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. \par
- WHO
+From server side, the leap from the 2.4 to the 2.6 kernel is more than a simple version change:
- 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-beta,
-linux-beta-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-beta-mm works now it is very likely linux-beta will as well very
-soon.
+\begin{itemize}
+\item 64 Bit
+\item NUMA ( Non-Uniform Memory Access ): For clusters with a high amount of nodes, memory sharing is vital. NUMA adresses this problem.
+\item Better performance under heavy loads: Many benchmarks demonstrate 2.4 is completely outperformed. High payload environments are webservers and databases, for example.
+\item The addressing space for unique users has gone to 32-bit, from16-bit, so now you can support 4 billion unique users, instead of a measly 65,000.
+\item Hyper-Threading: Intel's P4 and Xeon servers support multiprocessor emulation, although they really only have 1 processor.
+\item Higher limits: PIDs (process IDs) have been boosted from 32,000 to 1 billion. Filesystems, even on 32-bit processors, have a theoretical upper limit of 16 terabytes, up from 4 terabytes. Another nice boost for 32-bit systems is support for 64 GB of RAM, up from 4 gigabytes.
+\item Higher bandwidth network support.
+\end{itemize}
-
-
- WHY
-
- 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
- * NUMA ( Non-Uniform Memory Access ): For clusters with a high amount
- of nodes, memory sharing is vital. NUMA adresses this problem.
- * Better performance under heavy loads: Many benchmarks demonstrate 2.4
- is completely outperformed. High payload environments are
- webservers and databases, for example.
- * The addressing space for unique users has gone to 32-bit, from
- 16-bit, so now you can support 4 billion unique users, instead of a
- measly 65,000.
- * Hyper-Threading: Intel's P4 and Xeon servers support multiprocessor
- emulation, although they really only have 1 processor.
- * Higher limits: PIDs (process IDs) have been boosted from 32,000 to 1
- billion. Filesystems, even on 32-bit processors, have a theoretical
- upper limit of 16 terabytes, up from 4 terabytes. Another nice boost
- for 32-bit systems is support for 64 GB of RAM, up from 4 gigabytes.
- * Higher bandwidth network support.
-
- Desktop/laptop have had their share of new features as well:
-
- * ALSA (Advanced Linux Sound Architecture) has been merged in
+Desktop/laptop have had their share of new features as well:
+\begin{itemize}
+\item 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.
- * Samba protocol update, to interact better with Windows
+\item Broader wireless and native Bluetooth support.
+\item Software suspend-to-disk and speed scaling for laptops.
+\item Samba protocol update, to interact better with Windows
environments.
-
+\end{itemize}
Embedded systems have also been taken care of:
-
- * uCLinux support.
- * Support for more types of MMU-less processors, like PDAs, for
+\begin{itemize}
+\item uCLinux support.
+\item 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
+\item Embedded Profile support.
+\end{itemize}
+ At least the first 2 (servers and desktops/laptops) will benefit from some other upgrades:
+\begin{itemize}
+\item New scheduler: optimization of system resources, no matter if
you have 1 CPU or you have many.
- * Better I/O scheduler, faster read/writes.
- * NFS (Network File System) upgrade, supporting NFSv4,
+\item Better I/O scheduler, faster read/writes.
+\item NFS (Network File System) upgrade, supporting NFSv4,
cryptography and higher loads.
- * ext3, xfs journalised filesystems.
- * Native USB 2.0 support.
- * IPSec: IP Security protocol
-
+\item ext3, xfs journalised filesystems.
+\item Native USB 2.0 support.
+\item IPSec: IP Security protocol
+\end{itemize}
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
young, and it will need some more time to fully accomplish these and
-other features.
+other features. \par
-
-
- WHERE
-
- Starting from the features listed above, the 2.6 kernel would be
+Starting from the features listed above, the 2.6 kernel would be
suited for any machine from a big cluster, SMP machine, desktop or
handheld. But I have my own case to show you that 2.6 kernels work. I
have 2 desktops, both with 2.6 kernels and fully 2.6 installs, and I
@@ -960,22 +901,22 @@
They didn't worry about if their targetted hardware was the oldest or
brand new, they did it the same. 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 next.
+running 2.6 kernels. And you are next. \par
- HOW
+\subsection{Installation Process}
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!
+don't rush! \par
The first stage of a jump to a 2.6 kernel install would be to
install the latest 2.6 kernel itself from moonbase; the second stage
would be setting all your Lunar install to be 2.6 based, recompiling
each Lunar module, but you need not worry about that, if you don't want
-to. It is not necessary, though it will be explained.
+to. It is not necessary, though it will be explained. \par
To install the last 2.6 kernel from moonbase all you have to do
is to install the linux-beta Lunar module. Although in the process your
@@ -985,64 +926,76 @@
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). Another reason is because options in the
-2.6's .config may not be well set by your 2.4's .config file.
+2.6's .config may not be well set by your 2.4's .config file. \par
Now let's get to the nitty gritty of it, and do the install
itself. As root:
- root at myshinybox# lin linux-beta
+\begin{flushleft}
+ root at myshinybox\# \textit{ lin linux-beta}
+\end{flushleft}
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).
+2.4 kernels). \par
After that has been settled, we will be asked a few questions,
first of all about our bootloader:
- Choose either GRUB or LILO
+\begin{flushleft}
+ Choose either GRUB or LILO\\
linux-beta: Use LILO? [y]
+\end{flushleft}
If you answer 'y', LILO will be used, any other answer GRUB will be
used. If you didn't say yes, so you have chosen GRUB, you'll be prompted
with another GRUB question:
+\begin{flushleft}
linux-beta: Configure grub? [n]
+\end{flushleft}
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 yes to LILO, you should see, analogously to GRUB:
+\begin{flushleft}
linux-beta: Configure lilo? [n]
+\end{flushleft}
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.
+configuration, so Lunar takes care of your grub or lilo. \par
Next step to cope with is what interface we are going to use to
-configure the kernel:
+configure the kernel:\par
- Reconfiguration is optional.
+\begin{flushleft}
+ Reconfiguration is optional.\\
linux-beta: Do you prefer make menuconfig over make config [y]
+\end{flushleft}
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.
+config). Any other answer than 'y' will lead you to make config. \par
Now that questions have been dealt with, the source(s) will be
downloaded. Once the download finished, the sources have 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.
+configuration will be shown. Choose what you need for your box. \par
- After kernel configuration, you will be prompted one more time:
+ After kernel configuration, you will be prompted one more time:\par
+\begin{flushleft}
Repeat config?
+\end{flushleft}
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.
+with this question every time you finish your config method. \par
When the kernel has succesfully built, two things may happen,
depending on what you answered previously: if you have answered yes to
@@ -1050,26 +1003,27 @@
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.
+will be done without your interaction. \par
- Reboot into your new 2.6 kernel. Welcome onboard!
+ Reboot into your new 2.6 kernel. Welcome onboard! \par
The possible second stage of a 2.6 migration would be rebuilding
our software against 2.6 headers. This migration has its downside, as
there are a series of Lunar modules that do not compile against 2.6
headers. Problematic modules are currently :
+\begin{itemize}
+\item syslogd: patched lunar module exists
+\item lvm: no fix available
+\item lilo: no fix available
+\item eject: no fix available
+\item iputils: no fix available
+\item xfree86: we have a working xfree86-beta module
+\item iproute2 no fix available
+\end{itemize}
- * syslogd: patched lunar module exists
- * lvm: no fix available
- * lilo: no fix available
- * eject: no fix available
- * iputils: no fix available
- * xfree86: we have a working xfree86-beta module
- * iproute2 no fix available
-
This is a dynamic list, though. In a near future, these problems
-should be solved.
+should be solved. \par
Before explaining how to accomplish the 2.6 header based Lunar
box, I will make one last warning: The Lunar Linux team does not
@@ -1079,7 +1033,7 @@
it, as it will be taken in consideration, that is for sure. Example of
this willingness to help is this howto. But it can never have the same
handling as a 2.4 install. If the problems can be addressed, they will
-be. Don't think you are on your own!
+be. Don't think you are on your own! \par
The process of switching is quite simple, really. There is a
Lunar module that serves a series of sanitized kernel headers,
@@ -1089,7 +1043,7 @@
from it and installed. 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.
+non-support module scheme. \par
For the sake of standarization, we recommend the install of
kernel-headers-2.6. Bug tracking for you and for us will be simplified
@@ -1097,43 +1051,48 @@
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.
+all move forward together. \par
Taking for granted you do want to install kernel-headers-2.6, as
root type:
- # lin kernel-headers-2.6
+\begin{flushleft}
+\textit{ \# lin kernel-headers-2.6}
+\end{flushleft}
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
- * binutils
- * coreutils
- * bzip2
- * gzip
- * tar
- * diffutils
- * findutils
- * make
- * grep
- * gawk
- * sed
- * gettext
- * ncurses
- * patch
- * texinfo
- * bash
- * util-linux
- * perl
-
+
+\begin{itemize}
+\item kernel-headers-2.6
+\item gcc
+\item glibc
+\item binutils
+\item coreutils
+\item bzip2
+\item gzip
+\item tar
+\item diffutils
+\item findutils
+\item make
+\item grep
+\item gawk
+\item sed
+\item gettext
+\item ncurses
+\item patch
+\item texinfo
+\item bash
+\item util-linux
+\item perl
+\end{itemize}
+
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.
+based. \par
There is a newcoming feature in 2.6 that I have deliberately not
mentioned (2 actually): sysfs and udev. Unlike other features, that have
@@ -1142,22 +1101,24 @@
information on each one. udev, the substitute of devfs, uses sysfs. udev
has the same aim as devfs, dynamic allocation of device nodes, but
unlike devfs it does so in userspace. udev is relatively new, and
-although it is usable, it has a couple of glitches.
+although it is usable, it has a couple of glitches. \par
There is no reason why you should install udev, except for the
pleasure of doing so. Sooner or later, devfs will be deprecated (it is
already marked as such in the kernel) and will be droped out. The other
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.
+nodes using the makedev Lunar module. \par
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 set device naming policies, and libsysfs to query sysfs. \par
- To install udev, as root:
+ To install udev, as root: \par
- # lin udev
+\begin{flushleft}
+\textit{\# lin udev}
+\end{flushleft}
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.
@@ -1166,84 +1127,88 @@
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).
+devices). \par
udev obviously has to be added to boot, so it creates the
devices under /dev. For now, this is still something that has to be
done by hand (temporary fix). For those of you that have not installed
the initscripts Lunar module (initscripts are not recommended for
-anybody), you must edit /etc/init.d/mount, and add a 'udevstart' line:
+anybody), you must edit /etc/init.d/mount, and add a 'udevstart' line: \par
- rm -f /fastboot /forcefsck
+\begin{flushleft}
+ rm -f /fastboot /forcefsck \\
+ # added by us\\
+ /sbin/udevstart\\
+\end{flushleft}
- # added by us
- /sbin/udevstart
-
If, on the other hand, you do have initscripts installed, you should
edit /etc/rc.sysinit, and add the udestart, nearly at the top:
+\begin{flushleft}
- . /etc/init.d/functions
+ . /etc/init.d/functions\\
- # added by us
- /sbin/udevstart
+ # added by us\\
+ /sbin/udevstart\\
+\end{flushleft}
If you currently have a devfs install, you shouldn't worry. If
you have a static /dev, I would recommend renaming it to /dev_static,
for example, so that if there is any problem, we will always be able to
-get back to our old install.
+get back to our old install. \par
All we have left now is to configure udev. If you check, you
will have an /udev dir, where udev starts by default to not conflict
with your actual /dev. This is set in udev's configuration file,
/etc/udev/udev.conf:
- # udev_root - where in the filesystem to place the device nodes
- udev_root="/udev/"
+\begin{flushleft}
+ # udev\_root - where in the filesystem to place the device nodes\\
+ udev\_root="/udev/"
+\end{flushleft}
This will have to be set to /dev instead of /udev so it works. Also, we
will have to set the default permissions for each node:
- # default_mode - set the default mode for all nodes that have no
- # explicit match in the permissions file
+\begin{flushleft}
+ # default_mode - set the default mode for all nodes that have no\\
+ # explicit match in the permissions file\\
default_mode="0600"
+\end{flushleft}
We should set default permissions to 0660, so we don't have any
-problems.
+problems. \par
There are, however, some device nodes that have to be explicitly
created, for the time being, for udev to work. These have to be created
statically. If you moved /dev to /dev_static, create /dev again, so we
have an empty dir; if you use devfs, don't worry about creating it, it
should be there. In any case, you must create 2 nodes:
+\begin{flushleft}
- * cd /dev
- * mknod -m 660 console c 5 1
- * mknod -m 660 null c 1 3
+\textit{ cd /dev \\
+mknod -m 660 console c 5 1 \\
+ mknod -m 660 null c 1 3}
+\end{flushleft}
Still in /dev, two dirs must be created :
- root at my shinybox /dev # mkdir pts
- root at my shinybox /dev # mkdir shm
+\begin{flushleft}
+ root at my shinybox /dev # \textit{ mkdir pts}
+ root at my shinybox /dev # \textit{mkdir shm}
+\end{flushleft}
-That's it. Good luck! You are ready to roll!
+That's it. Good luck! You are ready to roll! \par
+\subsection{Usefull Links}
---------------------------
-
-CREDITS
-
"Is Linux Kernel 2.6 Primed for the Enterprise?",
http://www.enterpriseitplanet.com/networking/features/article.php/3321801
"Linux 2.6.0: What's New"
-http://www.osdl.org/newsroom/press_releases/2003/2003_12_18_beaverton_2_6_new.html
+http://www.osdl.org/newsroom/press\_releases/2003/2003\_12\_18\_beaverton\_2\_6\_new.html
-
-
-Powered by
-
\section{64-Bit Linux}
\section{(A)DSL}
More information about the Lunar-commits
mailing list