Lunar Linux - User contributions [en]

Installation:lfirsttime.8.manpage

2012-12-11T17:51:47Z

Engelsman: /* WARNING: Here be Dragons! */ - link to temporary install guide

=WARNING: Here be Dragons!=

The 1.6.5 ISO is now almost two years old, and there have been major updates of the kernel, gcc, glibc, and a host of other key modules. The development team is currently in the middle of the switch from sysvinit to systemd in preparation for the next ISO image. In addition, the single project repository is being split to provide improved system integrity and cohesion, and re-hosted at github, so you might find that your favourite utility is not yet available in the new configuration.

''If you can't wait a couple of months for the new ISO, and really do want to install 1.6.5, please make sure that you connect to [irc://irc.freenode.net/lunar #Lunar] on [http://freenode.net/ Freenode.net] and ask for the latest guide to installation. This [https://gist.github.com/d867a58f9d0373051f47 temporary guide from 2012-09-23] may quickly become outdated.'' '''Be warned: you may break your box!'''

=== Disclaimer: ===

This page may not be in synchronization with the man pages available on a Lunar-Linux system.

The initial version was a cut'n'paste from the man command, which produces weird wiki formatting.

----

lfirsttime(8) Lunar Linux for the first time lfirsttime(8)

NAME
lfirsttime - or 'What to do after a successful installation?'

SYNOPSIS
This manual page has been written in order to ease the life of the system administrator after the
installation part of Lunar Linux.

DO NOT PANIC!
These are the suggested tasks you should accomplish immediately after the first boot of a newly
installed Lunar box.

All of the lunar related commands mentioned below either feature a whole manpage or at least a very
useful helpscreen. If you need immediate assistance regarding any of those commands, issue:

man 'command' or 'command' --help

at your console.

The operations described below follow a strict logic and they should be executed in sequence.

Please remember that the Lunar Install/Rescue ISO is not a full featured system.

NETWORK SETTINGS
This step is crucial to your future success with Lunar Linux. If you haven't set up your network card
yet try it with lnet. Remember, you need to know about your current network card's driver and have the
kernel build the appropriate modules for it.

Check your network settings

Once you've set up your network card correctly, try to ping out.

Example: ping google.com

If it doesn't work you may be having a name resolution problem, try pinging to the IP address instead
of the name.

Example: ping 216.239.57.99

If pinging to IP is working but pinging to name fails, check the /etc/resolv.conf file and see if the
nameserver entries are there. You may also want to check the man page, man resolv.conf if you are not
familiar with the entries which should be in that file.

Check the network device

If pinging the IP address fails, check to see if your network interface is up and running. You may use
the command ifconfig to see the interface's status. You must be able to see the details of your network
interface in the output of ifconfig.

If you cannot, then check if your NIC (network interface card) module is loaded (assuming you are using
a modular kernel); use the command lsmod to see the already loaded modules and see wether the module
for your network card is already loaded.

If you do not know for sure what type of network card you have try executing the command: cat
/proc/pci|grep Ethernet or lspci. This should give the manufacturer and model name of your ethernet
card.

If your NIC module is there but your interface is not up, reconfigure the interface with lnet and test
again. If your NIC module is still not listed in the output of lsmod, the chances are you have miscon-
figured the kernel or misconfigured your network. To check the kernel modules, try ls -l /lib/mod-
ules/`uname -r`/kernel/drivers/net to see the network modules available with the current kernel. If the
your NIC's kernel module doesn't show up you probably have to reconfigure and recompile your current
kernel to include the appropriate module(s).

lnet or manual configuration

Your network setting can be configured completely using lnet; just make sure you set up your interface
correctly as needed. If you encounter problems after having configured your network with lnet you prob-
ably want to adjust the configuration manually.

The network configuration file for your Lunar installation may be found in /etc/config.d/net-
work/'interface' (f.e. 'eth0' -> /etc/config.d/network/eth0). Any time you adjust your interface's con-
figuration manually or through lnet you will have to restart the network to make use of any changes
that have been done in the meantime. The init script used to start/stop/restart network is
/etc/init.d/network.

Example: /etc/init.d/network restart

Good luck and please remember that you have to to be able to ping f.e. 'google.com' to install any
other packages or update your system!

CORE UPDATES AND SETUP
Since Lunar Linux is a source based distribution, some of the binaries and/or modules on the CD may
have been upgraded to newer versions already. Here are the first steps you should take to get an
up-to-date, smoothly running and fast system:

Update your coretools

You need to get the most recent version of the available coretools. The coretools are the heart of
every Lunar Linux system. They provide you with all the necessary commands to maintain a working
installation thus it's always recommended to have the latest version installed. There are two different
choices:

lunar or theedge

lunar is the stable branch of the lunar coretools. It's meant to run with stable production environ-
ments. theedge is the unstable branch. It might occasionally contain bugs, however it's generally used
to test out new features and bugfixes before they're migrated to the stable branch. If you'd like to
help out with the lunar development or you discovered a bug in lunar you might want to give theedge a
try.

Since the ISO ships with theedge preinstalled you have to update theedge before you do anything else --
even if you're planning to use lunar later on!

Execute: lin theedge

If you want to keep Lunar Linux as stable as possible you need to install the stable coretools branch
now by running

Execute: lin lunar

Core Components

A very brief explanation of the most important coretool components. For further information regarding
the referenced parts please refer to their manpages (i.e. man <part>):

lin; usage: lin <module>
Install a package/module.

lvu; usage: lvu <options> <module>
Gather information about a package/module.

lrm; usage: lrm <module>
Remove a package/module.

lunar; usage: lunar <options>
Lunar configuration utility

Update your moonbase

The package repository from where the coretools gather their package information is called moonbase.
Also, packages are usually referred to as modules. Since the moonbase on your installation is probably
outdated it's strongly recommended to update your moonbase right after your coretools.

Execute: lin moonbase

Set your preferences

Lunar Linux can easily be customized and is highly configurable. For changing the options that affect
your system you may use the menu driven lunar configuration utility. It's based upon ncurses which
means you can even run it in the console of your choice. You need to become root to use it.

Optimizations
Set the right optimizations for your computer. Be aware that changing your optimizations to the
wrong values might actually break your whole installation so be really careful about what you're
choosing. The ISO has been built with a minimum of available optimizations to ensure the highest
amount of flexibility. To see whether or not your processor supports a certain feature try a cat
/proc/cpu. It usually shows the available settings that suit your machine.

Integrity checking
Lunar is performing a range of security checks on tarballs and installed packages to prevent faulty
tarballs and possible intruders from taking over your system. It also ensures that none of your
currently installed packages is broken.

You may select the amount of checks from the Integrity checking submenu at the Options menu. It's
generally recommended to at least chose FIND_CHECK and LDD_CHECK.

Feature menu
As mentioned before, Lunar is highly configurable. Thus you have a whole menu to select its fea-
tures from. It's strongly advised to at least take a look at it and get used to them. Explanations
are usually displayed as soon as you select an item.

Apart from that
Take a look at the lunar configuration tool. It can be a powerful companion while achieving the
goal of setting up your system.

GENERAL UPDATES
Right now you're set to update your whole system. Before you do that make sure you have the most recent
coretools and moonbase installed.

The next step can be omitted -- however, it is highly recommended that you rebuild the following mod-
ules in the right order to ensure that your system is working right.

Here we go:

Execute: lin -cr gcc glibc gcc bash coreutils tar wget

Explanation:

lin is obviously used to install a module. It also accepts multiple modules in a row. The '-cr' switch
means 'compile (c)' and 'reconfigure (r)'. They're explained at the manpage. One needs to update gcc
thus the first gcc statement. Right after that one should recompile glibc to ensure that it's working
well with the latest compiled gcc. And finally gcc again to make use of the newly compiled glibc. The
modules right afterwards are used by Lunar Linux itself thus they need to be up-to-date and compiled
against the latest available gcc and glibc.

A complete update

Now, to update your whole system you need to issue the following

Execute: lunar update

It's going to compare your system's installed modules against the moonbases' definitions and update the
installed modules accordingly. It's going to give you a list of modules that are going to be updated.
If you're not sure wether you want a certain module to be updated remove it from the list. Once you're
done the coretools are going to start the update which usually is going to take a very long time on a
freshly installed system since most of its components will probably be outdated. So grab a coffee
and/or a book and wait for it to finish ;-)

Once it is done it is going to present you with a summary about how many module where successfully
updated and which of them failed. lvu ('lvu activity') is going to show you which of them failed and
usually why. lvu ('lvu compile <module>') is also going to show you the compilation's logfile which
should clearly point you to the error that led to the failure of the module's compilation.

The first thing to do would be to 're'lin' (i.e. execute lin -c once more. It is always advised to use
the -c and the -r switch in case a module fails to compile) all the failed modules by hand. If you
think you will not be able to resolve the matter on your own you can still file a bugreport at the
Lunar Linux bugtracker http://bugs.lunar-linux.org or report the error to the Lunar Linux mailinglist.
However, you will have to subscribe to the list at http://foo-projects.org/mailman/listinfo/lunar
before being able to post any mail to it.

Once the update has been completed successfully you may go ahead and customize your installation to
suit your own needs. Well done!

HINTS
TAB-completion
All of the coretools are able to do tab-completion. Say, you want to install the module
'xfce4-panel' just go ahead and type 'lin xfce4-p<TAB>' and lin is going to append the rest of the
module's name to the command. Once there are too few characters to resolve the name into one single
module you just need to hit TAB twice to get a list of all the modules starting with the characters
you just typed i.e. 'lin xfce<TAB><TAB>' is going to give you a list of all modules starting with
'xfce'.

Leftovers
In case of a compilation failure the sources of the failed module are left in $BUILD_DIRECTORY
(usually /usr/src/). Moreover, a few tracking files lunar creates to monitor the running installa-
tion process might be left in /tmp. Make sure you tidy up these two locations from time to time.

CAUTION: Directories like 'linux-2.x' are kernel source directories and _must_ be left intact. Oth-
erwise your system is going to break! Only delete them if you're absolutely sure that they don't
belong to your currently running kernel.

Running coretools processes
If you're interrupting a module installation process (f.e. by pressing 'CTRL-C) you should check if
there are any running coretools processes running in the background as another try to install the
module might fail because of them. Have a closer look at ps aux and kill/killall all the remaining
coretools instances of a failed installation attempt.

CAUTION: Lunar allows you to run multiple installations independently. Be sure about the processes'
purpose you're terminating!

IRC channel
The fastest help you get is by chatting with the developers directly. Join the Lunar Linux IRC
channel at freenode

irc://irc.freenode.net/#lunar

NOTES
This is merely an introduction to what should be done to get a ready-to-go Lunar system. Please consult
the documentation at the Lunar website for more information.

SEE ALSO
Documentation at the Lunar Linux website at http://lunar-linux.org

lunar(8), moonbase(1), lin(8), lvu(1), lget(8), lrm(8), lnet(8)

DISCLAIMER
The information and examples given here are for illustrative purposes. If you encounter any inaccura-
cies please send an email to the authors.

COPYRIGHT
This document is originally Copyrighted Kagan Kongar 2002.

Portions of this document Copyrighted (C) 2003-2004 Terry Chan

It has been almost completely rewritten by Moritz Heiber for the Lunar Linux development team under the
Creative Commons License, (C) 2005

AUTHORS
Kagan Kongar <kongar@tsrsb.org.tr>

Terry Chan <tchan@lunar-linux.org>

Moritz Heiber <moe@lunar-linux.org>

Moritz Heiber 2005-03-09 lfirsttime(8)

Lunar Linux:Installation/1.6.5

2012-09-23T13:08:52Z

Engelsman: /* WARNING: Here be Dragons! */ - link to temporary install guide

__TOC__

Lunar Linux is a revolutionary Linux distribution in that it is not binary based, as are most distributions, but is instead built entirely by compiling source code, using your own custom optimizations.

Essentially, it installs a complete bootstrap development system on your machine, and then you tell the Lunar package manager what tools you want, and it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward your specific needs.

The result is a leaner, meaner, refreshingly uncluttered, and strikingly faster operating system than most Linux distributions.

This installation guide is designed to get you through the installation process as painlessly as possible. It assumes that you have some experience with Linux or another Unix variant, and have a general idea of what you are doing. If you are unfamiliar with such things as partitions, or have never used Linux before, Lunar may not be the best introduction for you into the world of open source. There are always Lunar gods available on irc.freenode.net in the #lunar channel to answer any questions that this manual may not make quite clear enough.

With that said, we hope you enjoy using Lunar!

=WARNING: Here be Dragons!=

The 1.6.5 ISO is now almost two years old, and there have been major updates of the kernel, gcc, glibc, and a host of other key modules. The development team is currently in the middle of the switch from sysvinit to systemd in preparation for the next ISO image. In addition, the single project repository is being split to provide improved system integrity and cohesion, and re-hosted at github, so you might find that your favourite utility is not yet available in the new configuration.

''If you can't wait a couple of months for the new ISO, and really do want to install 1.6.5, please make sure that you connect to [irc://irc.freenode.net/lunar #Lunar] on [http://freenode.net/ Freenode.net] and ask for the latest guide to installation. This [https://gist.github.com/d867a58f9d0373051f47 temporary guide from 2012-09-23] may quickly become outdated.'' '''Be warned: you may break your box!'''

==About this installation manual==

Although this manual is not intended to be a full and complete overview of any situation you may be confronted with, given the wide diversity of hardware available these days, it is intended to be an introduction to the world of Lunar Linux. You will see examples that are not tailored towards your to-be built server or workstation, optimizations that are overly broad or too specific, and examples that don't apply to any real situations. We tried hard to give you the idea of how much power you have over how you can setup your system, but we are forgetting to tell you how to run your own server or desktop (or other system) at all. That means that the examples and steps taken most probably do not apply to your situation at all.

Do not despair: if you understand what is going on and you get the idea, the installer will allow you to do pretty much everything you want to do with your system. There are really (almost) no limits.

* A note: please read "Jump to 3.X kernel + Tips" section which belongs to "Known Problem" chapter. It would help you make Lunar Linux recognize the latest hardware

==Getting the ISO==

The primary site for retrieving the ISO is [http://www.lunar-linux.org/ lunar-linux.org]. There, you will find links to our US, EU, and Internet2 mirrors, as well as a Bittorrent link. As of this writing, the current version of the Lunar ISO is version 1.6.5-rc1, codename Mare Ingenii (20100709). (''Check the main site for the actual latest version!'')

Locate and retrieve the file lunar-1.6.5-rc1-i686.iso.bz2 (or lunar-1.6.5-rc1-x86_64.iso.bz2 if you have a 64-bit system). After downloading this file, you will need to unpack the ISO using bzip2. Windows users will need a program that can extract bzip2 archives, like WinZip (also capable of extracting bzip2 archives under windows are IZarc, Winrar, powerarchiver and 7-Zip). Mac should unzip the file by itself. Then all that is left to do is use your favorite program to burn the ISO to a cdrom and begin the installation. Lunar can also be installed without using a CD. If you need to do it this way, our [[FAQ]] provides simple instructions.

It should be noted that the 1.6.5 ISO and Lunar use udev for device management. The devfs system, and the "old-school" method of manually installing devices, are no longer supported.

We are assuming the you are installing Lunar as your primary OS. Make sure you have a backup of any important data that you need to retain. The Lunar Linux Project and its developers are not responsible in any way for any loss of data on your system!

==Booting the ISO==

Upon booting the ISO, the first thing you will see are options for booting the ISO kernel, or for performing RAM tests [Note: MemTest is not available on x86_64]. There is even a safe mode which will disable DMA, MTRR, RAID, LVM, USB keyboards, NTFS, HPFS, Advanced Partitions, and Firewire. Most folks, however, will be just fine pressing enter at the boot prompt and loading the default kernel.

To boot the iso with support for your usb keyboard:
''linux uhci-hcd ehci-hcd''

After loading the kernel, the first screen presents you with a few options. If there are extra modules you need to load in order continue with the install, they can be loaded here. There is also a shell option. However, if you are using this ISO for rescue purposes, you do not want to shell out here; rather continue booting and shell out in the next section. Most people will select "continue booting" here.

It should be noted that the 1.6.5 ISO tries to autodetect some hardware (mostly scsi drivers and network interfaces) during this stage. This will help you establish a network connection if you desire so during installation. For this reason the programs 'dhcpcd' and 'ftp' are already available at this stage.

==Virtual Consoles==

Once the ISO has booted into the installer, you can immediately shell out or switch to one of the other virtual consoles. These will have ready to go root shells and are available throughout the installer sequence. With these you can start rescue actions, setup networking or double check the install progress and make manual adjustments.

==Language and keyboard interface Settings==

After reading the introduction, you will be presented with options for choosing the proper font, keymap, and language for your install.
You will also need to choose an editor, as you are going to need one later on in the installation for setting up your lilo or grub configuration. The choices available are e3, [e3/emacs], joe, nano, vi, and zile. If you have never used a text editor in Linux before, nano is the best choice for you. If you skip the Native Language Support option, the system will install the default editor, nano, for you. When you have finished setting up your options, press cancel to return to the main setup menu.
Less important for most people is the ability to choose the console font, although it may help display some non-English characters. Most people will want to set the system-default language variable and editor though. All these values are unset by default, so make sure you set them now.
The keymap table allows people to use azerty and dvorak keyboards, and much more. This is especially required for non-English keyboards which provide many accented characters.
All these language and keymap settings might not apply to the lunar code itself, which (currently) does not have any international support, but most programs that run during the installer sequence, and after booting into your new system, will be affected properly.

Warning: the keymap entry appears to default to ANSI-dvorak so make sure that you really select what you want.

==Creating or editing Partitions==

The next step is to set up partitions on your hard drive. Upon selecting the "Partition Drive" option, you will be shown a list of all the discs the kernel has detected. For this guide, we will assume that you have one hard drive connected via an IDE channel, which will show up in the menu as "disc0". After selecting the disc to partition, you are given the option of using one of three partitioning programs. They are:

* cfdisk -- A menu driven partitioner, and very easy to use. If you are unfamiliar with various partitioning programs, this is the best option for you.
* fdisk -- Text based partitioner that requires a little more know-how than cfdisk. More experienced users will probably use this program. However new users should not be daunted, as it does have help offered at every step.
* parted -- Text based partitioner that is good for advanced users. Parted is excellent for resizing current partitions on your hard disk, however be forewarned that resizing partitions is an excellent way to hose your entire disc.

Note: under the <Settings> option on the main menu there is an option to configure the fstab mount style as DEV, LABEL or UUID. The first is the traditional Linux method, but can sometimes give problems if a kernel update causes the disk to be renamed. The default is UUID, which uses a unique marker on the partition to avoid this problem.

For our example, we have a 40GB IDE drive and we'll set up six partitions; /, /boot, /home, /usr, /var, and a swap partition. It's a good idea to keep certain directories, such as /var and /usr on separate partitions, as this can save you a lot of headache in the future in case your disk ever completely fails on you and you need to recover data (God forbid!). Also, when you have a separate /boot partition as we have in our example, you need to have your partitioning program mark that partition as active or bootable. In our example, if we were using fdisk, you would press "a" at the command line, and then select part1 as the active partition.

You might also want to install a /tmp partition. By default, Lunar will create a tempfs filesystem mounted on /tmp (tempfs minimizes filesystem fragmentation because it resides in volatile memory). This can be a good choice if you have a lot of memory on your machine. If memory is tight, we recommend creating a /tmp partition to minimize filesystem fragmentation.

It is important to note that you <span class="emphasis">''can not''</span> mount the directories /etc, /bin, /sbin, /dev, /lib and /proc on separate partitions. These directories need to be contained within the root ("/") directory. The installation program should block you from doing this, but it's best not to try.

Here's our partition setup:

1 /boot 100MB
2 / 4GB
3 swap 1GB
5 /usr 10GB
6 /var 10GB
7 /home 15GB

(''If you're wondering about this choice of partitions: it's really just an example. Read the [[FAQ#So_how_should_I_partition_my_disk.3F|FAQ]] on what makes sense in the real world''))

You'll notice that there is no fourth partition in our list above. In order for you to have more than four partitions on a single drive, the fourth partition is made into what is known as an extended or logical partition in which the fifth, sixth, and seventh (etc, etc) partitions reside. For our example above, if we were using fdisk, we would make the fourth partition an extended/logical partition that was 35GB, and then the fifth, sixth, and seventh partitions in our scheme resided within it. However, if we used cfdisk, we would just worry about creating six partitions, making sure that the first three are the primary type, and the last three logical.

Note that the names and mount points for these partitions will be assigned during the next step of this process, when you mount the partitions. Write down exactly what partitions you are planning to create because it can otherwise get confusing!

Lunar offers two choices when it comes to swap. You can set up a swap partition, as we have in our example, or you can set up a swapfile in the root directory. We recommend setting up a swap partition, as you will get better performance with it than with the swapfile. However, there may be a need for you to set up the swapfile instead, which can be setup and activated after you have mounted your other partitions.

==Selecting Partitions and Filesystems==

After creating your partitions, you need to select them and assign file systems. Select the menu option "Select Filesystems" and verify that you are indeed done creating partitions.

The partitions can be selected in random order with the new installer. First select the partition and then assign a filesystem and mountpoint to it. The installer will add this to the job queue and formatting and mounting takes place later so you can edit your selection. Here's a list of filesystems that are currently supported:

* ''ext4'' (Fourth Extended File System) -- Version 4 of the Extended File System, which was ... TO BE COMPLETED.
* ''ext3'' (Third Extended File System) -- Version 3 of the Extended File System, which is essentially just the journaled version of ext2. This filesystem is available with all kernels on the ISO.
* ''ext2'' (Second Extended File System) -- Version 2 of the Extended File System, which was designed for linux as a replacement for the Minix Filesystem. Ext2 is not a journaled filesystem, which means that you'll need to perform disc recovery operations after a power failure or other such system crash. This filesystem is available with all kernels on the ISO.
* ''reiserfs'' (Reiser Filesystem) -- Journaled filesystem created by Hans Reiser that is excellent for use with extremely small files. This filesystem is available with all kernels on the ISO.
* ''xfs'' -- Created by SGI for IRIX, SGI's brand of Unix, and later ported to linux under the GPL. A journaled filesystem that SGI claims is better than any other at handling extremely large files and sparse files. This filesystem is only available with the lunar or grsec patched kernels, which we will come to in a few steps.
* ''jfs'' (Journaled File System) -- Created by IBM for AIX, IBM's brand of Unix, and later ported to linux by IBM under the GPL. A journaled filesystem that is very good at handling high throughput issues. This filesystem is available with all kernels on the ISO.
* ''swap'' Swap (Virtual memory or paging filesystem) for swap partitions only!

After selecting the filesystem type you wish to use, you will be prompted through a series of steps to initialize the partition. You'll notice that the prompts are quite redundant in nature in order to be absolutely positive that you will not inadvertantly erase crucial data that you might have on a working filesystem. In addition, if you have more than four partitions, as we do in our example, you don't want to select any file systems on the fourth partition, as it is the extended partition that houses the fifth, sixth (and so on) partitions. (The installer will try to detect this and skip the extended partition from the list).

As we mentioned earlier, there is an option in the installation process to set up a swap file in the root partition instead of a swap partition as we have done in our example. The next option after selecting your filesystems is to select a swapfile if you so desire. <span class="emphasis">''If you have set up a swap partition already, as we have done, you can skip this step.''</span> Otherwise, you can set up your swap file here, and the only thing you need to tell the installer is how large you want the file to be. Running without swap completely is also possible of course.

'''Please note during this step, no modifications are made to your filesystem!'''

==Installing Lunar==

Next, we need to ''format'' your partitions, ''mount'' them in the right place, create ''swap'' and transfer the entire Lunar system to the partitions that you now have created. This happens all in one single step.

Select ''Install Lunar'', and the system will proceed to transfer all of the necessary files for you. The installer will display progress as packages are transferred to your system and you'll have some idea how long it will take. On normal machines, this should take about 5 minutes.

At the end of this step, the installer sets various system parameters like language, timezone and vital package configuration files in order for your machine.

==Setting Up Your Compiler Optimizations==

The compiler optimizations is a crucial step, since what you choose will make your system fly! However, it is important that you do not overdo it on you optimization settings, as certain selections can, in some instances, break code while compiling.

The first step is to choose your preferred compiler. There is only one version on the 1.6.5 ISO, so the only option here is GCC 4.4. However, once the main system installation is complete, it is possible to install GCC 3.x -- and even the deprecated GCC 2.x! If you don't intend to install those, you should go to the GCC_4_4 submenu now and set GCC 4.4 as the default compiler.

The GCC_4_4 menu also allows you to change other options:

* ''safe'' : allows you to turn off optimization safety, so you should leave this well alone unless you really know what you are doing. Turning this off will result in many more options appearing than are described below.
* ''bopt'' : allows you to change the base compile-time optimization. Your choice depends on what your needs are. Most folks will want to use -O2 here, as it is the wisest choice. More advanced users may want to use the -O3 option, but it's not for everyone. If you're short on disk space, you would take the -Os Small option. (As an example, we used -Os for the ISO since we were working within a confined amount of disc space.) Those of you with older or slower systems that wouldn't be able to take advantage of faster optimizations may choose a more conservative setting like -O1. For our example system, we will choose -O2.
* ''cpu'' : allows you to set your processor type. This may seem unimportant, but the GCC 4.x [and GCC 3.x] compiler has ways of optimizing code for certain processors
* ''cc_opt'' : allows you to set some limited C/C++ compiler settings. Very few people, if any, would need to turn off the -pipe option.

The unsafe optimizations are:
* ''xtra'' : CPU extensions
* ''spd'' : Specialized optimizations
* ''fpm'' : Floating point optimizations
* ''stack'' : Stack optimizations

==Adding Other Compiler Toolchain Optimizations==

'''You can safely SKIP this entire step!'''

The GNU_LD menu shows the screen for linker options, where you will find that "-s Strip" has already been checked off. Very few people will want to uncheck this option, so we will leave this screen as is.

The GNU_MAKE menu allows you to set the number of concurrent makes. As the hint mentions on the "Concurrent Makes" screen, you'll want to enter in the number of cpu's your machine has. Unless you have a machine with more than one processor, you'll want to leave this field blank.

We are now finished setting up our GCC optimizations! When you have you lunar system up and running, you can always change and tweak these GCC settings by typing "lunar" at the commandline prompt, and going to "Optimization Settings". In addition, if you aren't that familiar with what your processor is capable of using for optimizations, you can go to the shell out option on the ISO and type

cat /proc/cpuinfo

at the prompt and the system will show you all the optimizations that the processor reports it can handle.

==Configuring Your Bootloader==

=== Configuring LILO ===

If you chose to use lilo and also said yes to automatically configuring and running lilo, then most of the work is done for you. If you chose not to hand edit lilo.conf, however, be warned that the default configuration has the system set up to be password protected on boot. You can change this by selecting the option from the menu "Reconfigure LILO".

To turn off password protection, you will need to comment out (with the symbol "#") or delete two lines in your lilo.conf file. The first is "password=lunar", which is found in the top section of the file, and the other is "restricted" which is found right below the name of your kernel in the second section.

The other item of note is whether you want lilo to reside in your MBR (Master Boot Record) or on the first sector of your /boot partition. The line in your lilo.conf file to edit for this purpose is

boot=/dev/sda1

To make lilo get installed on the first sector of your /boot partition, you would leave this line as it is. If you want lilo to be written to your MBR, which is the recommended method, you would change the line to read

boot=/dev/sda

Of course, these examples are pertinent to our setup that we have been using thoughout this manual. Your actual lilo.conf file may be different.

=== Configuring GRUB ===

If you chose grub as your bootloader, you will need to set up the configuration file entirely on your own. An example would be:

default 0
timeout 30
color white/blue white/black
title linux-2.4.25
root (hd0,0)
kernel /vmlinubz-2.4.25-r5.0.0 root=/dev/sda2 devfs=nomount

As we mentioned earlier in the partitioning section, you would want to mark your /boot partition as active. With grub it is ''imperative'' that you mark your /boot partition as active, otherwise grub will not work at all when you are finished with the installation and reboot to your new system.

NOTE: The option to install grub is not available on the 1.6.5-rc1-x86_64 ISO because grub is not yet fully stable on 64-bit systems. If you really know what you are doing, the source tarball is saved to disk, so you can configure it manually once the main installation is complete.
==Installing kernels==

===Installing a precompiled kernel===

The ISO comes with a selection of precompiled kernels and modules that should work for most people. If you have problems getting your kernel to compile, install or getting the right drivers, or just want to get a quick start at lunar, we ''suggest'' that you use this option instead of compiling your own kernel. You can later of course compile as many kernels as you want, and indeed the first ''lunar update'' after the main installation might ask whether you want to update the kernel too. Why do it twice if you don't need to?

There are several kernels for you to choose from. They are:

* ''2.6.34.1'' -- Normal kernel (SMP, 4GB memory max) (RECOMMENDED).
* ''2.6.34.1-safe'' -- Very safe non-optimized minimal kernel (no ACPI, DMA, SMP, 1GB).
* ''2.6.34.1-server'' -- Server optimized (SELINUX, SMP, 64GB, no preempt).

===Building Your Customized Linux Kernel===

We have now come to the most important part of the installation; the configuration of the kernel. The kernel is the heart of Linux, and without it, nothing would work. Configuration is, actually, a rather simple process. All you need to remember is to not panic, and that lunar is going to do most of the work for you. Here are a few pointers that will make the configuration a breeze for you.

* Help is a click away! The people working on creating and maintaining the Linux kernel have help placed throughout the entire configuration process. If you're not sure what something does, just look at the help file for whatever item you're on, and it will almost certainly explain what it is and what it does. The most handy thing is that every help file will suggest whether you should really use the item or not. Many help files end with "If you're not sure, it is safe to say N here", thus letting you know that it is safe to leave that particular item out of the kernel.
* You can use the ISO kernel! The configuration used to make the kernel for the ISO is the same configuration you'll see when you start your kernel customization. If you leave the configuration the way it is, the only thing you truly have to worry about is your network and, if you want it, sound. There are also two additional default configurations available on the ISO that are available to you called "config.safe" and "config.server". We'll show you how to load these configurations in just a little bit. [TODO: check these files]
* Never build filesystems or core components as modules! Make sure that whatever filesystems you decided to use for your partitions earlier are built into the kernel, and are not separate modules. Likewise, make sure that certain crucial things like ide and scsi drivers are not modules, as this will make your machine unbootable. (This rule doesn't apply to the scsi low level drivers though; they can be modules.) Modules are kernel drivers that can be manually activated and deactivated after the system has been booted, but not during boot time. The kernel from the ISO already has all the filesystems available during the installation built into the kernel, so if you don't change anything there, you will be fine.

You will be shown two screens of information before you actually begin you kernel configuration, letting you know that you are going to need a few things built into the kernel in order to have Lunar run properly, and what options you have for boot loaders. Lunar comes with both lilo (LInux LOader) and grub (GRand Unified Bootloader).

If you don't have much experience with bootloaders, we suggest using lilo for now, as the installation program will set up the configuration file for you. If you would prefer to use grub, and we encourage folks to learn how to use it, be forewarned that the installation program does not set up any configuration at all for you.

[On the 1.6.5-rc1-x86_64 ISO] There is only one kernel available for you to choose from:

* ''linux-2.6.'' -- Latest 2.6 kernel with minor patchlevel patches (2.6.x.Y)

For our example, we are going to use linux-2.6.

Before you begin is which type of configuration method you would like to use.

* ''config'' -- The original way to configure the linux kernel. It is completely text based, and assumes you know what everything is. Unless you've been using linux since its inception, you probably don't want to use this method.
* ''menuconfig'' -- As the name implies, a menu driven version of the kernel configuration. This is the easiest, and by far the most popular way of configurating your kernel.
* ''xconfig'' -- If you have an X server running, you can use this option to configure your kernel using a nifty GUI interface. You won't be able to use this on the ISO, but once your system is up and running with X, you can use this option. If you do choose this option while installing from the ISO, the system will fall back to next available configuration method, in this case menuconfig, so there is no harm in selecting it if you do.

For our example, we are going to use menuconfig. Once Lunar is finished applying the patches for the kernel, which can take a minute or two, you'll be brought to the configuration screen for the linux kernel.

As we mentioned earlier, the configuration that was used to build the kernel for the ISO is the same configuration that you'll be presented with when you start. However, as we also mentioned earlier, there are two alternate kernel configurations available to you that you may want to use; config.safe and config.server. Both of these configurations can be found on the ISO, along with the original default config file, in /etc/lunar/local. When you are looking at the kernel menuconfig main page, scroll all the way to bottom, and you will find an option called "Load an Alternate Configuration File". Select this and then give the absolute path to the alternate configuration file, i.e. /etc/lunar/local/.config.server. As with all kernel configuration files, they are hidden files preceded with a ".", so make sure to not forget it.

Once you have completed configuring your kernel, you'll get one more prompt from the installer asking if you want to go back to the configuration in case you exited by mistake or forgot something. If everything is good to go, say no here and sit back for a few minutes while your kernel compiles.

==Setting Up Networking==

The final step is to set up networking. When you select the "Set Up Networking" option, you'll be prompted by a series of questions as to what kind of card you have (only needed if you built your networking device as a module, and not part of the kernel), if you need to set up wireless or not, and whether you'll need to use dhcp or not. You should be familiar enough with your network to set this up on your own, as the questions put to you are very straightforward.

* if you use dhcp, you don't need to set up the default gateway or DNS because dhcp will take care of them for you.
* you are using a wireless connection with wpa_supplicant, you might want to run "wpa_passphrase" to set up a simple /etc/wpa_supplicant.conf rather than try to edit the example file.

==Other settings==

The installer will prompt you now for some more settings. You should set a root password and generate ssh host keys to identify your box uniquely for later. You might also want to administrate services on the newly installed machine.

==Reboot!==

Once you have completed setting up your networking, you are finished installing Lunar Linux! Congratulations! Select the option "Done" and remove the cd from the drive when it ejects. Your Lunar system is now ready to go!

==Upgrade Moonbase==

After the initial installation and reboot, please follow the instructions given in '''man lfirsttime''' to bring your system up-to-date.

Congratulations! You now have a minimal system as a foundation on which to build.

==KNOWN PROBLEMS==

=== You need to run 'lin linux-2.6' explicitly before running 'lunar update' ===

WARNING: the pre-compiled 2.6.35.3 kernel on the ISO is now out-of-date compared to the ''linux-2.6'' module in the moonbase, but you will
need to build it explicitly using '''lin linux-2.6''' because it won't be rebuilt as part of the first '''lunar update'''. If you didn't
recompile the kernel as part of the ISO installation, or if you experience problems with ALSA or NVIDIA, you should run '''lin linux-2.6'''
to rebuild the kernel explicitly. After you have built the kernel once, '''lunar update''' should then detect and install a newer versions
of the kernel as they become available in the moonbase.

=== configure: error: C compiler cannot create executables ===

WARNING: the ISO installs gcc-4.4 on your system, but gcc-4.6 will be installed as part of the '''man lfirsttime''' and '''lunar update'''
process. You will then need to run '''lunar''', select the '''Options / Optimize Architecture''' menu and set the gcc-4.5 options. Failure
to do so may result in ''"configure: error: C compiler cannot create executables"'' messages when building modules later.

=== Jump to 3.X kernel + Tips ===

These are some problems you'll encounter with the outdated 1.6.5 installation ISO of Lunar Linux. For example:
- Lunar Linux doesn't recognize the most recent network hardware correctly, but it still recognizes a few USB tethering from your smartphone
(e.g. hTC Evo 4G+). The tricky part is that lin(package installer) tries to connect via dial-up modem if it doesn't find any ethX.
- If you try to use Linux kernel 3.X udev would not start because Lunar's initscript would treat it as 2.4 kernel.
It is due to initscript design pitfall then where there was no 3.X kernels.<br><br>
Of course these issues are all resolved with current updates. To solve the issues following modules should be updated:
- <b>linux</b>: Of course, Linux kernel, to support the most recent hardware. Please refer to [[Moonbase]] for details.
- <b>lunar / theedge</b>: Lunar Linux utilities(including "package managers"), for lin(module installer) to work in any network condition(e.g. connected to the Internet without ethX)
- <b>lunar-init</b>: the initscript of Lunar Linux to correctly recognize and work
- Though deprecated, module-init-tools would work with 3.X kernels anyway. Or you can replace it with kmod.<br><br>
Or, if you prefer, you can just recompile Linux kernel with built-in drivers so that you don't have to be concerned with kernel modules.

==Where to go from here==
To install a desktop environment check out this page. [[Lunar_Linux:DesktopEnvironments]]

''Have Phun!!''

[http://www.gnu.org/copyleft/ Copyleft] 2004-2010 [http://lunar-linux.org/ The Lunar Penguin Team]

Lunar Installation Manual and Harassment of Lunar Developers by Drew Swayze (drew AT lunar-linux DOT org).

Edits and Nitpicking by Suzanne Burns (sburns AT lunar-linux DOT org).

Initial update for the 1.6.5 ISO by Duncan Gibson (engelsman AT lunar-linux DOT org).

Update for "Jump to 3.X kernel + Tips" by Robert Teminian(individual contributor).

GitForLunarDevs

2012-08-02T07:39:09Z

Engelsman: WARNING: move from doppio to github

Module Submission for developers

2012-08-02T07:37:25Z

Engelsman: WARNING: move from doppio to github

==WARNING: move from doppio to github==

The single project repository is being split to provide improved system integrity and cohesion, and re-hosted at github, so the workflow described here is obsolete.Ask on the [irc://irc.freenode.net/lunar #lunar] IRC channel on [http://freenode.net/ Freenode.net] for the latest details.

===Module Submission for developers===

Why and how users should submit modules is described on the [[Module_Submission]] page. This page describes what a developer needs to do to handle these submissions. Or rather, it describes what works for me.

I'm no expert by any means and this is not intended to be a comprehensive guide to git. There is just enough information to get started, and to describe my workflow.

====Developer access====

Before you will be able to save anything back to the central git repository holding the [[Moonbase]], you will obviously need to apply for a username and password on the central machine. You will need to have been a regular, constructive contributor to the [irc://irc.freenode.net/lunar #lunar] IRC channel on [http://freenode.net/ Freenode.net], or the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List] or have successfully submitted modules in the past.

====Cloning your own moonbase.git====

Just like other source code management systems, git uses the concepts of a repository and working files. In the past git has allowed the repository and the working files to exist within the same top level directory structure. It seems that this has lead to some problems, so work is under way to separate out the repository and the working files. At the moment certain operations generate warning messages if you try to save to a combined repository and working directory. In the future you will need to have a "bare" repository and a separate working version. This article describes how to set up and use such a future-proof system.

I don't have a public server of my own on which I can make a repository available for sharing, testing and cherry-picking by others. Therefore I use a multi-stage repository and working directory system. If you have a public server, you may be able to work with just one.

I have three repositories: a remote copy of the main [[Lunar Linux]] [[Moonbase]] repository; a remote working copy; and a local working copy. The first one is optional, but it allows me to share files between the working copies without having to commit them to the main [[Moonbase]] repository first.

First of all I login to the main [[Lunar Linux]] machine, '''doppio''', using ssh, and set two important global git defaults:

doppio$ git config --global user.name "Full Name"
doppio$ git config --global user.email "username@lunar-linux.org"

Then I create the remote "bare" copy of the main [[Moonbase]] repository and configure two useful properties:

doppio$ git clone '''--bare''' git://lunar-linux.org/lunar/moonbase.git moonbase.git
doppio$ git config --get-regexp '^(remote|branch)\.'
doppio$ git config remote.origin.push master:master

Next I create a remote "working" repository that shadows the remote "bare" one, again on '''doppio''':

doppio$ git clone moonbase.git workbase.git
doppio$ cd workbase.git
doppio$ git config --get-regexp '^(remote|branch)\.'
doppio$ git config remote.origin.push master:master

The second git config command tells git that the default action for the "push" command is to push changes from the master branch of the current repository to the master branch of the parent repository. Otherwise you need to provide that information on the command line every time.

I have a local "working" repository on my private machine that also shadows the remote "bare" one. I shall call my local machine '''satellite''' so that it matches the instructions given in [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT With 20 Commands Or So] but see the Note at the end of the section.

satellite$ git config --global user.name "Full Name"
satellite$ git config --global user.email "username@lunar-linux.org"

satellite$ git clone ssh://username@lunar-linux.org/~username/moonbase.git workbase.git
satellite$ cd workbase.git
satellite$ git config --get-regexp '^(remote|branch)\.'
satellite$ git config remote.origin.push master:master

This repository setup allows the following workflow:

* first ensure that the my central repo is up to date:

doppio$ cd moonbase.git
doppio$ git fetch # note: fetch not pull

* then, either work in the remote working directory:

doppio$ cd workbase.git
doppio$ git checkout master
doppio$ git pull
doppio$ git checkout -b testing master
doppio$ ... edit files and commit ...
doppio$ git checkout master
doppio$ git merge testing
doppio$ git branch -D testing
doppio$ git push

* or work on the local working directory:

satellite$ cd workbase.git
satellite$ git checkout master
satellite$ git pull
satellite$ git checkout -b testing master
satellite$ ... edit files and commit ...
satellite$ git checkout master
satellite$ git merge testing
satellite$ git branch -D testing
satellite$ git push

* Finally I can update the central [[Moonbase]] repository, although I'm sure there must be a better way:

doppio$ cd moonbase.git
doppio$ git push /var/git/lunar/moonbase.git master

* I can only share files back and forth between the local and remote working repositories using this method. I can't pull from the working directory on satellite to the working directory on doppio because satellite is private and can only call out. I can't push from the working directory on satellite to the working directory on doppio either because it is not a bare repository.

''Note that [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT...] recommends having the following line instead:

satellite$ git config remote.origin.push master:refs/remotes/satellite/master

but this doesn't work with the bare repository system. Or rather, it does something, but I haven't worked out how to use the information in the remote repository.''

====Reviewing module submissions====

There is a neat script on '''doppio''' called '''review''' that you can use to view and apply the module submission patches directly to the current working copy of '''moonbase.git'''. The '''review''' script assumes that the submitter has already tested the patch and that if it applies cleanly it will be accepted, otherwise it will be rejected. One really cool feature of '''review''' is that the submitter gets the credit in the commit message. Unfortunately, if there are any problems in your working copy of '''moonbase.git''' - and there often were in mine - the script can delete the patch.

By default '''review''' will work through all of the modules in the [http://foo-projects.org/~sofar/queue.php submission queue] so it's best to specify the module that you are interested in. '''review''' will open an editor session containing the module patch file so that you can view the changes, and remove "Subject: " from the subject line and annotate what will become the text of the commit message. After you leave the editor, '''review''' checks whether the patch will apply to the current working copy of '''moonbase.git''' without problems, suggests what should be done with the patch, and waits for your input. If the patch applies cleanly, the default action is to ''accept'' it. You could still ''reject'' it for some other reason; because it does not conform to the [[Module_Guidelines]] for example. If the patch can't be applied - and that might mean that the submission was valid but that a developer has already updated that module in the moonbase - the action is to ''reject'' and another editor session will open so that you can explain why. The two other possible actions are ''defer'' and ''quit''.

You can also use ''/home/engelsman/review.new'' which gives the added option to ''thank'' someone for a submission that was valid but can no longer be applied because another developer has beaten them to it. It's a little less harsh than ''reject''.

doppio$ cd moonbase.git
doppio$ git fetch # make sure we are up to date
doppio$ cd ../workbase.git
doppio$ git pull # make sure working copy is also up to date
doppio$ git checkout -b testing master # create a test branch in case of problems
doppio$ review submitted_module # view patch in editor, then accept,reject,defer,quit

# if accepted:
doppio$ git checkout master # still in workbase.git
doppio$ git merge testing
doppio$ git branch -D testing
doppio$ git push
doppio$ cd ../moonbase.git
doppio$ git push /var/git/lunar/moonbase.git master

# else:
doppio$ git checkout master # still in workbase.git
doppio$ git branch -D testing

If all has gone smoothly, '''git status''' won't show any added, deleted or modified files. Take care to clean up if there are.

====Testing the submission locally before committing====

If you want to be really thorough - or paranoid - you should really check that the patch applies and builds on your own machine first. That takes a little more effort, because you will first need to grab the patch file, apply and test locally:

doppio$ cd moonbase.git
doppio$ git fetch # make sure up to date before pulling working copy

Make sure that your local moonbase is up-to-date before you try dealing with the patch:

satellite$ cd moonbase.git
satellite$ git pull
satellite$ git checkout -b testing master

and then use the method of your choice to grab the patch and apply it:

satellite$ # method 1
satellite$ scp username@doppio.lunar-linux.org:/var/anonymous/submissions/submitted_module.patch /tmp
satellite$ git am /tmp/submitted_module.patch

satellite$ # method 2
satellite$ wget -q <nowiki>"http://foo-projects.org/~sofar/queue.php?p=submitted_module"</nowiki> -O - | git am

satellite$ # method 3
satellite$ # browse to "http://foo-projects.org/~sofar/queue.php"
satellite$ # right click on patch and "save link as" /tmp/submitted_module.patch
satellite$ git am /tmp/submitted_module.patch

satellite$ # check '''lin submitted_module''' works as expected

At this point, if you want the submitter to get a feel-good "Your patch was accepted" message:

satellite$ git checkout master
satellite$ git branch -D testing

doppio$ # use '''git''' and '''review''' as described earlier

Otherwise, just continue with the usual git workflow:

satellite$ git checkout master
satellite$ git merge testing
satellite$ git branch -D testing
satellite$ git push

doppio$ cd moonbase.git
doppio$ git merge satellite/testing # see '''git config''' tip earlier
doppio$ git push /var/git/lunar/moonbase.git master
doppio$ review # patch already applied, so use '''review''' thank option

As mentioned earlier, run '''git status''', tidy up if required, and run '''git pull''' again.

===Is there a better way?===

I'm an apprentice rather than a wizard level developer, and I've just about understood git-101, but diagnosing git problems makes my head hurt.

So if you can see a better way of doing things, please add a section at the bottom and describe your workflow.

Lunar Linux:Installation/1.6.5

2012-08-02T07:30:20Z

Engelsman: Here be Dragons!

__TOC__

Lunar Linux is a revolutionary Linux distribution in that it is not binary based, as are most distributions, but is instead built entirely by compiling source code, using your own custom optimizations.

Essentially, it installs a complete bootstrap development system on your machine, and then you tell the Lunar package manager what tools you want, and it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward your specific needs.

The result is a leaner, meaner, refreshingly uncluttered, and strikingly faster operating system than most Linux distributions.

This installation guide is designed to get you through the installation process as painlessly as possible. It assumes that you have some experience with Linux or another Unix variant, and have a general idea of what you are doing. If you are unfamiliar with such things as partitions, or have never used Linux before, Lunar may not be the best introduction for you into the world of open source. There are always Lunar gods available on irc.freenode.net in the #lunar channel to answer any questions that this manual may not make quite clear enough.

With that said, we hope you enjoy using Lunar!

=WARNING: Here be Dragons!=

The 1.6.5 ISO is now almost two years old, and there have been major updates of the kernel, gcc, glibc, and a host of other key modules. The development team is currently in the middle of the switch from sysvinit to systemd in preparation for the next ISO image. In addition, the single project repository is being split to provide improved system integrity and cohesion, and re-hosted at github, so you might find that your favourite utility is not yet available in the new configuration.

''If you can't wait a couple of months for the new ISO, and really do want to install 1.6.5, please make sure that you connect to [irc://irc.freenode.net/lunar #Lunar] on [http://freenode.net/ Freenode.net] and ask for the latest guide to installation.'' '''Be warned: you may break your box!'''

==About this installation manual==

Although this manual is not intended to be a full and complete overview of any situation you may be confronted with, given the wide diversity of hardware available these days, it is intended to be an introduction to the world of Lunar Linux. You will see examples that are not tailored towards your to-be built server or workstation, optimizations that are overly broad or too specific, and examples that don't apply to any real situations. We tried hard to give you the idea of how much power you have over how you can setup your system, but we are forgetting to tell you how to run your own server or desktop (or other system) at all. That means that the examples and steps taken most probably do not apply to your situation at all.

Do not despair: if you understand what is going on and you get the idea, the installer will allow you to do pretty much everything you want to do with your system. There are really (almost) no limits.

* A note: please read "Jump to 3.X kernel + Tips" section which belongs to "Known Problem" chapter. It would help you make Lunar Linux recognize the latest hardware

==Getting the ISO==

The primary site for retrieving the ISO is [http://www.lunar-linux.org/ lunar-linux.org]. There, you will find links to our US, EU, and Internet2 mirrors, as well as a Bittorrent link. As of this writing, the current version of the Lunar ISO is version 1.6.5-rc1, codename Mare Ingenii (20100709). (''Check the main site for the actual latest version!'')

Locate and retrieve the file lunar-1.6.5-rc1-i686.iso.bz2 (or lunar-1.6.5-rc1-x86_64.iso.bz2 if you have a 64-bit system). After downloading this file, you will need to unpack the ISO using bzip2. Windows users will need a program that can extract bzip2 archives, like WinZip (also capable of extracting bzip2 archives under windows are IZarc, Winrar, powerarchiver and 7-Zip). Mac should unzip the file by itself. Then all that is left to do is use your favorite program to burn the ISO to a cdrom and begin the installation. Lunar can also be installed without using a CD. If you need to do it this way, our [[FAQ]] provides simple instructions.

It should be noted that the 1.6.5 ISO and Lunar use udev for device management. The devfs system, and the "old-school" method of manually installing devices, are no longer supported.

We are assuming the you are installing Lunar as your primary OS. Make sure you have a backup of any important data that you need to retain. The Lunar Linux Project and its developers are not responsible in any way for any loss of data on your system!

==Booting the ISO==

Upon booting the ISO, the first thing you will see are options for booting the ISO kernel, or for performing RAM tests [Note: MemTest is not available on x86_64]. There is even a safe mode which will disable DMA, MTRR, RAID, LVM, USB keyboards, NTFS, HPFS, Advanced Partitions, and Firewire. Most folks, however, will be just fine pressing enter at the boot prompt and loading the default kernel.

To boot the iso with support for your usb keyboard:
''linux uhci-hcd ehci-hcd''

After loading the kernel, the first screen presents you with a few options. If there are extra modules you need to load in order continue with the install, they can be loaded here. There is also a shell option. However, if you are using this ISO for rescue purposes, you do not want to shell out here; rather continue booting and shell out in the next section. Most people will select "continue booting" here.

It should be noted that the 1.6.5 ISO tries to autodetect some hardware (mostly scsi drivers and network interfaces) during this stage. This will help you establish a network connection if you desire so during installation. For this reason the programs 'dhcpcd' and 'ftp' are already available at this stage.

==Virtual Consoles==

Once the ISO has booted into the installer, you can immediately shell out or switch to one of the other virtual consoles. These will have ready to go root shells and are available throughout the installer sequence. With these you can start rescue actions, setup networking or double check the install progress and make manual adjustments.

==Language and keyboard interface Settings==

After reading the introduction, you will be presented with options for choosing the proper font, keymap, and language for your install.
You will also need to choose an editor, as you are going to need one later on in the installation for setting up your lilo or grub configuration. The choices available are e3, [e3/emacs], joe, nano, vi, and zile. If you have never used a text editor in Linux before, nano is the best choice for you. If you skip the Native Language Support option, the system will install the default editor, nano, for you. When you have finished setting up your options, press cancel to return to the main setup menu.
Less important for most people is the ability to choose the console font, although it may help display some non-English characters. Most people will want to set the system-default language variable and editor though. All these values are unset by default, so make sure you set them now.
The keymap table allows people to use azerty and dvorak keyboards, and much more. This is especially required for non-English keyboards which provide many accented characters.
All these language and keymap settings might not apply to the lunar code itself, which (currently) does not have any international support, but most programs that run during the installer sequence, and after booting into your new system, will be affected properly.

Warning: the keymap entry appears to default to ANSI-dvorak so make sure that you really select what you want.

==Creating or editing Partitions==

The next step is to set up partitions on your hard drive. Upon selecting the "Partition Drive" option, you will be shown a list of all the discs the kernel has detected. For this guide, we will assume that you have one hard drive connected via an IDE channel, which will show up in the menu as "disc0". After selecting the disc to partition, you are given the option of using one of three partitioning programs. They are:

* cfdisk -- A menu driven partitioner, and very easy to use. If you are unfamiliar with various partitioning programs, this is the best option for you.
* fdisk -- Text based partitioner that requires a little more know-how than cfdisk. More experienced users will probably use this program. However new users should not be daunted, as it does have help offered at every step.
* parted -- Text based partitioner that is good for advanced users. Parted is excellent for resizing current partitions on your hard disk, however be forewarned that resizing partitions is an excellent way to hose your entire disc.

Note: under the <Settings> option on the main menu there is an option to configure the fstab mount style as DEV, LABEL or UUID. The first is the traditional Linux method, but can sometimes give problems if a kernel update causes the disk to be renamed. The default is UUID, which uses a unique marker on the partition to avoid this problem.

For our example, we have a 40GB IDE drive and we'll set up six partitions; /, /boot, /home, /usr, /var, and a swap partition. It's a good idea to keep certain directories, such as /var and /usr on separate partitions, as this can save you a lot of headache in the future in case your disk ever completely fails on you and you need to recover data (God forbid!). Also, when you have a separate /boot partition as we have in our example, you need to have your partitioning program mark that partition as active or bootable. In our example, if we were using fdisk, you would press "a" at the command line, and then select part1 as the active partition.

You might also want to install a /tmp partition. By default, Lunar will create a tempfs filesystem mounted on /tmp (tempfs minimizes filesystem fragmentation because it resides in volatile memory). This can be a good choice if you have a lot of memory on your machine. If memory is tight, we recommend creating a /tmp partition to minimize filesystem fragmentation.

It is important to note that you <span class="emphasis">''can not''</span> mount the directories /etc, /bin, /sbin, /dev, /lib and /proc on separate partitions. These directories need to be contained within the root ("/") directory. The installation program should block you from doing this, but it's best not to try.

Here's our partition setup:

1 /boot 100MB
2 / 4GB
3 swap 1GB
5 /usr 10GB
6 /var 10GB
7 /home 15GB

(''If you're wondering about this choice of partitions: it's really just an example. Read the [[FAQ#So_how_should_I_partition_my_disk.3F|FAQ]] on what makes sense in the real world''))

You'll notice that there is no fourth partition in our list above. In order for you to have more than four partitions on a single drive, the fourth partition is made into what is known as an extended or logical partition in which the fifth, sixth, and seventh (etc, etc) partitions reside. For our example above, if we were using fdisk, we would make the fourth partition an extended/logical partition that was 35GB, and then the fifth, sixth, and seventh partitions in our scheme resided within it. However, if we used cfdisk, we would just worry about creating six partitions, making sure that the first three are the primary type, and the last three logical.

Note that the names and mount points for these partitions will be assigned during the next step of this process, when you mount the partitions. Write down exactly what partitions you are planning to create because it can otherwise get confusing!

Lunar offers two choices when it comes to swap. You can set up a swap partition, as we have in our example, or you can set up a swapfile in the root directory. We recommend setting up a swap partition, as you will get better performance with it than with the swapfile. However, there may be a need for you to set up the swapfile instead, which can be setup and activated after you have mounted your other partitions.

==Selecting Partitions and Filesystems==

After creating your partitions, you need to select them and assign file systems. Select the menu option "Select Filesystems" and verify that you are indeed done creating partitions.

The partitions can be selected in random order with the new installer. First select the partition and then assign a filesystem and mountpoint to it. The installer will add this to the job queue and formatting and mounting takes place later so you can edit your selection. Here's a list of filesystems that are currently supported:

* ''ext4'' (Fourth Extended File System) -- Version 4 of the Extended File System, which was ... TO BE COMPLETED.
* ''ext3'' (Third Extended File System) -- Version 3 of the Extended File System, which is essentially just the journaled version of ext2. This filesystem is available with all kernels on the ISO.
* ''ext2'' (Second Extended File System) -- Version 2 of the Extended File System, which was designed for linux as a replacement for the Minix Filesystem. Ext2 is not a journaled filesystem, which means that you'll need to perform disc recovery operations after a power failure or other such system crash. This filesystem is available with all kernels on the ISO.
* ''reiserfs'' (Reiser Filesystem) -- Journaled filesystem created by Hans Reiser that is excellent for use with extremely small files. This filesystem is available with all kernels on the ISO.
* ''xfs'' -- Created by SGI for IRIX, SGI's brand of Unix, and later ported to linux under the GPL. A journaled filesystem that SGI claims is better than any other at handling extremely large files and sparse files. This filesystem is only available with the lunar or grsec patched kernels, which we will come to in a few steps.
* ''jfs'' (Journaled File System) -- Created by IBM for AIX, IBM's brand of Unix, and later ported to linux by IBM under the GPL. A journaled filesystem that is very good at handling high throughput issues. This filesystem is available with all kernels on the ISO.
* ''swap'' Swap (Virtual memory or paging filesystem) for swap partitions only!

After selecting the filesystem type you wish to use, you will be prompted through a series of steps to initialize the partition. You'll notice that the prompts are quite redundant in nature in order to be absolutely positive that you will not inadvertantly erase crucial data that you might have on a working filesystem. In addition, if you have more than four partitions, as we do in our example, you don't want to select any file systems on the fourth partition, as it is the extended partition that houses the fifth, sixth (and so on) partitions. (The installer will try to detect this and skip the extended partition from the list).

As we mentioned earlier, there is an option in the installation process to set up a swap file in the root partition instead of a swap partition as we have done in our example. The next option after selecting your filesystems is to select a swapfile if you so desire. <span class="emphasis">''If you have set up a swap partition already, as we have done, you can skip this step.''</span> Otherwise, you can set up your swap file here, and the only thing you need to tell the installer is how large you want the file to be. Running without swap completely is also possible of course.

'''Please note during this step, no modifications are made to your filesystem!'''

==Installing Lunar==

Next, we need to ''format'' your partitions, ''mount'' them in the right place, create ''swap'' and transfer the entire Lunar system to the partitions that you now have created. This happens all in one single step.

Select ''Install Lunar'', and the system will proceed to transfer all of the necessary files for you. The installer will display progress as packages are transferred to your system and you'll have some idea how long it will take. On normal machines, this should take about 5 minutes.

At the end of this step, the installer sets various system parameters like language, timezone and vital package configuration files in order for your machine.

==Setting Up Your Compiler Optimizations==

The compiler optimizations is a crucial step, since what you choose will make your system fly! However, it is important that you do not overdo it on you optimization settings, as certain selections can, in some instances, break code while compiling.

The first step is to choose your preferred compiler. There is only one version on the 1.6.5 ISO, so the only option here is GCC 4.4. However, once the main system installation is complete, it is possible to install GCC 3.x -- and even the deprecated GCC 2.x! If you don't intend to install those, you should go to the GCC_4_4 submenu now and set GCC 4.4 as the default compiler.

The GCC_4_4 menu also allows you to change other options:

* ''safe'' : allows you to turn off optimization safety, so you should leave this well alone unless you really know what you are doing. Turning this off will result in many more options appearing than are described below.
* ''bopt'' : allows you to change the base compile-time optimization. Your choice depends on what your needs are. Most folks will want to use -O2 here, as it is the wisest choice. More advanced users may want to use the -O3 option, but it's not for everyone. If you're short on disk space, you would take the -Os Small option. (As an example, we used -Os for the ISO since we were working within a confined amount of disc space.) Those of you with older or slower systems that wouldn't be able to take advantage of faster optimizations may choose a more conservative setting like -O1. For our example system, we will choose -O2.
* ''cpu'' : allows you to set your processor type. This may seem unimportant, but the GCC 4.x [and GCC 3.x] compiler has ways of optimizing code for certain processors
* ''cc_opt'' : allows you to set some limited C/C++ compiler settings. Very few people, if any, would need to turn off the -pipe option.

The unsafe optimizations are:
* ''xtra'' : CPU extensions
* ''spd'' : Specialized optimizations
* ''fpm'' : Floating point optimizations
* ''stack'' : Stack optimizations

==Adding Other Compiler Toolchain Optimizations==

'''You can safely SKIP this entire step!'''

The GNU_LD menu shows the screen for linker options, where you will find that "-s Strip" has already been checked off. Very few people will want to uncheck this option, so we will leave this screen as is.

The GNU_MAKE menu allows you to set the number of concurrent makes. As the hint mentions on the "Concurrent Makes" screen, you'll want to enter in the number of cpu's your machine has. Unless you have a machine with more than one processor, you'll want to leave this field blank.

We are now finished setting up our GCC optimizations! When you have you lunar system up and running, you can always change and tweak these GCC settings by typing "lunar" at the commandline prompt, and going to "Optimization Settings". In addition, if you aren't that familiar with what your processor is capable of using for optimizations, you can go to the shell out option on the ISO and type

cat /proc/cpuinfo

at the prompt and the system will show you all the optimizations that the processor reports it can handle.

==Configuring Your Bootloader==

=== Configuring LILO ===

If you chose to use lilo and also said yes to automatically configuring and running lilo, then most of the work is done for you. If you chose not to hand edit lilo.conf, however, be warned that the default configuration has the system set up to be password protected on boot. You can change this by selecting the option from the menu "Reconfigure LILO".

To turn off password protection, you will need to comment out (with the symbol "#") or delete two lines in your lilo.conf file. The first is "password=lunar", which is found in the top section of the file, and the other is "restricted" which is found right below the name of your kernel in the second section.

The other item of note is whether you want lilo to reside in your MBR (Master Boot Record) or on the first sector of your /boot partition. The line in your lilo.conf file to edit for this purpose is

boot=/dev/sda1

To make lilo get installed on the first sector of your /boot partition, you would leave this line as it is. If you want lilo to be written to your MBR, which is the recommended method, you would change the line to read

boot=/dev/sda

Of course, these examples are pertinent to our setup that we have been using thoughout this manual. Your actual lilo.conf file may be different.

=== Configuring GRUB ===

If you chose grub as your bootloader, you will need to set up the configuration file entirely on your own. An example would be:

default 0
timeout 30
color white/blue white/black
title linux-2.4.25
root (hd0,0)
kernel /vmlinubz-2.4.25-r5.0.0 root=/dev/sda2 devfs=nomount

As we mentioned earlier in the partitioning section, you would want to mark your /boot partition as active. With grub it is ''imperative'' that you mark your /boot partition as active, otherwise grub will not work at all when you are finished with the installation and reboot to your new system.

NOTE: The option to install grub is not available on the 1.6.5-rc1-x86_64 ISO because grub is not yet fully stable on 64-bit systems. If you really know what you are doing, the source tarball is saved to disk, so you can configure it manually once the main installation is complete.
==Installing kernels==

===Installing a precompiled kernel===

The ISO comes with a selection of precompiled kernels and modules that should work for most people. If you have problems getting your kernel to compile, install or getting the right drivers, or just want to get a quick start at lunar, we ''suggest'' that you use this option instead of compiling your own kernel. You can later of course compile as many kernels as you want, and indeed the first ''lunar update'' after the main installation might ask whether you want to update the kernel too. Why do it twice if you don't need to?

There are several kernels for you to choose from. They are:

* ''2.6.34.1'' -- Normal kernel (SMP, 4GB memory max) (RECOMMENDED).
* ''2.6.34.1-safe'' -- Very safe non-optimized minimal kernel (no ACPI, DMA, SMP, 1GB).
* ''2.6.34.1-server'' -- Server optimized (SELINUX, SMP, 64GB, no preempt).

===Building Your Customized Linux Kernel===

We have now come to the most important part of the installation; the configuration of the kernel. The kernel is the heart of Linux, and without it, nothing would work. Configuration is, actually, a rather simple process. All you need to remember is to not panic, and that lunar is going to do most of the work for you. Here are a few pointers that will make the configuration a breeze for you.

* Help is a click away! The people working on creating and maintaining the Linux kernel have help placed throughout the entire configuration process. If you're not sure what something does, just look at the help file for whatever item you're on, and it will almost certainly explain what it is and what it does. The most handy thing is that every help file will suggest whether you should really use the item or not. Many help files end with "If you're not sure, it is safe to say N here", thus letting you know that it is safe to leave that particular item out of the kernel.
* You can use the ISO kernel! The configuration used to make the kernel for the ISO is the same configuration you'll see when you start your kernel customization. If you leave the configuration the way it is, the only thing you truly have to worry about is your network and, if you want it, sound. There are also two additional default configurations available on the ISO that are available to you called "config.safe" and "config.server". We'll show you how to load these configurations in just a little bit. [TODO: check these files]
* Never build filesystems or core components as modules! Make sure that whatever filesystems you decided to use for your partitions earlier are built into the kernel, and are not separate modules. Likewise, make sure that certain crucial things like ide and scsi drivers are not modules, as this will make your machine unbootable. (This rule doesn't apply to the scsi low level drivers though; they can be modules.) Modules are kernel drivers that can be manually activated and deactivated after the system has been booted, but not during boot time. The kernel from the ISO already has all the filesystems available during the installation built into the kernel, so if you don't change anything there, you will be fine.

You will be shown two screens of information before you actually begin you kernel configuration, letting you know that you are going to need a few things built into the kernel in order to have Lunar run properly, and what options you have for boot loaders. Lunar comes with both lilo (LInux LOader) and grub (GRand Unified Bootloader).

If you don't have much experience with bootloaders, we suggest using lilo for now, as the installation program will set up the configuration file for you. If you would prefer to use grub, and we encourage folks to learn how to use it, be forewarned that the installation program does not set up any configuration at all for you.

[On the 1.6.5-rc1-x86_64 ISO] There is only one kernel available for you to choose from:

* ''linux-2.6.'' -- Latest 2.6 kernel with minor patchlevel patches (2.6.x.Y)

For our example, we are going to use linux-2.6.

Before you begin is which type of configuration method you would like to use.

* ''config'' -- The original way to configure the linux kernel. It is completely text based, and assumes you know what everything is. Unless you've been using linux since its inception, you probably don't want to use this method.
* ''menuconfig'' -- As the name implies, a menu driven version of the kernel configuration. This is the easiest, and by far the most popular way of configurating your kernel.
* ''xconfig'' -- If you have an X server running, you can use this option to configure your kernel using a nifty GUI interface. You won't be able to use this on the ISO, but once your system is up and running with X, you can use this option. If you do choose this option while installing from the ISO, the system will fall back to next available configuration method, in this case menuconfig, so there is no harm in selecting it if you do.

For our example, we are going to use menuconfig. Once Lunar is finished applying the patches for the kernel, which can take a minute or two, you'll be brought to the configuration screen for the linux kernel.

As we mentioned earlier, the configuration that was used to build the kernel for the ISO is the same configuration that you'll be presented with when you start. However, as we also mentioned earlier, there are two alternate kernel configurations available to you that you may want to use; config.safe and config.server. Both of these configurations can be found on the ISO, along with the original default config file, in /etc/lunar/local. When you are looking at the kernel menuconfig main page, scroll all the way to bottom, and you will find an option called "Load an Alternate Configuration File". Select this and then give the absolute path to the alternate configuration file, i.e. /etc/lunar/local/.config.server. As with all kernel configuration files, they are hidden files preceded with a ".", so make sure to not forget it.

Once you have completed configuring your kernel, you'll get one more prompt from the installer asking if you want to go back to the configuration in case you exited by mistake or forgot something. If everything is good to go, say no here and sit back for a few minutes while your kernel compiles.

==Setting Up Networking==

The final step is to set up networking. When you select the "Set Up Networking" option, you'll be prompted by a series of questions as to what kind of card you have (only needed if you built your networking device as a module, and not part of the kernel), if you need to set up wireless or not, and whether you'll need to use dhcp or not. You should be familiar enough with your network to set this up on your own, as the questions put to you are very straightforward.

* if you use dhcp, you don't need to set up the default gateway or DNS because dhcp will take care of them for you.
* you are using a wireless connection with wpa_supplicant, you might want to run "wpa_passphrase" to set up a simple /etc/wpa_supplicant.conf rather than try to edit the example file.

==Other settings==

The installer will prompt you now for some more settings. You should set a root password and generate ssh host keys to identify your box uniquely for later. You might also want to administrate services on the newly installed machine.

==Reboot!==

Once you have completed setting up your networking, you are finished installing Lunar Linux! Congratulations! Select the option "Done" and remove the cd from the drive when it ejects. Your Lunar system is now ready to go!

==Upgrade Moonbase==

After the initial installation and reboot, please follow the instructions given in '''man lfirsttime''' to bring your system up-to-date.

Congratulations! You now have a minimal system as a foundation on which to build.

==KNOWN PROBLEMS==

=== You need to run 'lin linux-2.6' explicitly before running 'lunar update' ===

WARNING: the pre-compiled 2.6.35.3 kernel on the ISO is now out-of-date compared to the ''linux-2.6'' module in the moonbase, but you will
need to build it explicitly using '''lin linux-2.6''' because it won't be rebuilt as part of the first '''lunar update'''. If you didn't
recompile the kernel as part of the ISO installation, or if you experience problems with ALSA or NVIDIA, you should run '''lin linux-2.6'''
to rebuild the kernel explicitly. After you have built the kernel once, '''lunar update''' should then detect and install a newer versions
of the kernel as they become available in the moonbase.

=== configure: error: C compiler cannot create executables ===

WARNING: the ISO installs gcc-4.4 on your system, but gcc-4.6 will be installed as part of the '''man lfirsttime''' and '''lunar update'''
process. You will then need to run '''lunar''', select the '''Options / Optimize Architecture''' menu and set the gcc-4.5 options. Failure
to do so may result in ''"configure: error: C compiler cannot create executables"'' messages when building modules later.

=== Jump to 3.X kernel + Tips ===

These are some problems you'll encounter with the outdated 1.6.5 installation ISO of Lunar Linux. For example:
- Lunar Linux doesn't recognize the most recent network hardware correctly, but it still recognizes a few USB tethering from your smartphone
(e.g. hTC Evo 4G+). The tricky part is that lin(package installer) tries to connect via dial-up modem if it doesn't find any ethX.
- If you try to use Linux kernel 3.X udev would not start because Lunar's initscript would treat it as 2.4 kernel.
It is due to initscript design pitfall then where there was no 3.X kernels.<br><br>
Of course these issues are all resolved with current updates. To solve the issues following modules should be updated:
- <b>linux</b>: Of course, Linux kernel, to support the most recent hardware. Please refer to [[Moonbase]] for details.
- <b>lunar / theedge</b>: Lunar Linux utilities(including "package managers"), for lin(module installer) to work in any network condition(e.g. connected to the Internet without ethX)
- <b>lunar-init</b>: the initscript of Lunar Linux to correctly recognize and work
- Though deprecated, module-init-tools would work with 3.X kernels anyway. Or you can replace it with kmod.<br><br>
Or, if you prefer, you can just recompile Linux kernel with built-in drivers so that you don't have to be concerned with kernel modules.

==Where to go from here==
To install a desktop environment check out this page. [[Lunar_Linux:DesktopEnvironments]]

''Have Phun!!''

[http://www.gnu.org/copyleft/ Copyleft] 2004-2010 [http://lunar-linux.org/ The Lunar Penguin Team]

Lunar Installation Manual and Harassment of Lunar Developers by Drew Swayze (drew AT lunar-linux DOT org).

Edits and Nitpicking by Suzanne Burns (sburns AT lunar-linux DOT org).

Initial update for the 1.6.5 ISO by Duncan Gibson (engelsman AT lunar-linux DOT org).

Update for "Jump to 3.X kernel + Tips" by Robert Teminian(individual contributor).

TestingLunarStable

2012-03-29T10:05:15Z

Engelsman: initial draft

=== Testing Lunar Stable ===

==== Introduction ====

Lunar has always been a bit of a bleeding edge distro, where some devs are keen to keep up-to-date with key packages as soon as new versions are released. However, while they may have successfully compiled and tested these packages on their own systems, there are some packages that require more extensive testing to make sure that they run on a wider range of systems, with different video or sound cards for example. In addition, while a major release of a package might add some important feature, it may take a couple of follow-up patch releases to iron out new problems which might have been introduced.

Users new to Lunar might experience problems if they install from the ISO and then update while such wrinkles are being sorted out. Therefore some of the Lunar developers would like to introduce "stable" and "unstable" versions of the Moonbase. The "stable" version would contain only modules that had been tested and approved by three developers, or where no obvious teething problems had been reported on the modules' mailing lists during the first month. New users would download modules from "stable" and developers would work with "unstable" to get the bleeding edge, just as before.

That's the theory. Now we have to set it up and see how it works in practice.

==== How to proceed ====

* Install from the ISO as usual
* '''lin moonbase'''
* '''lin theedge'''
* run '''lunar''' and make sure you select the stable branch, although it should be the default
* continue with a normal installation as described in '''man lfirsttime'''
** '''lin -cr gcc glibc gcc bash coreutil tar wget
** etc

You can report any problems via
the [http://bugs.lunar-linux.org/view_all_bug_page.php Bug Tracker],
the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List], or discuss them on
the [irc://irc.freenode.net/lunar #Lunar] IRC channel on [http://freenode.net/ Freenode.net]

Lunar Linux:FAQ

2011-07-30T11:08:20Z

Engelsman: /* How do I safely remove an optional module? */

These are the '''F'''requently '''A'''sked '''Q'''uestions for Lunar Linux. You have a question about Lunar? You might get your answer below.<br /><br />

__TOC__

==General==

===What is Lunar Linux?===
What exactly is Lunar Linux?

'''Answer:'''
* Please read [[Lunar Linux:About|About Lunar Linux]].

===Can I run Lunar Linux in 64-bit mode?===
Can I run Lunar Linux on my new 64-bit system?

'''Answer:'''

Yes you can. You can run Lunar Linux in '''either''' 64-bit '''or''' 32-bit mode, but there is no multi-lib mode. Be aware that some applications are still only available for 32-bit mode!

===Where can I find how to ...?===
Where can I find how to customize the kernel under Lunar Linux? Or the desktop...

'''Answer:'''

The Lunar Wiki only offers details specific to Lunar Linux. Many other resources already exist for general Linux problem solving. For example, information on how to customize the Linux kernel can be found at:
* http://kernelnewbies.org/
* http://en.wikipedia.org/wiki/Linux_kernel_mailing_list

==Optimizations==

===How do I set optimizations?===
How do I set these optimizations for my machine?

'''Answer:'''

Run <code>lunar optimize</code>. You'll be taken through an interactive menu that explains all the options. Remember to optimize safely.

===What are safe optimizations?===
What are the recomended safe optimizations for [[Lunar Linux]]?

'''Answer:'''

The default sure fire optimizations that are recommended are:

* '''C'''
** <code>-pipe</code>
* '''C++'''
** <code>-pipe</code>
* '''CPU Architecture'''
** You should pick the correct architecture for your own system (defaults to x86 for most people).
* '''Basic Optimzations'''
** Faster (-O2, the default).
* '''CPU'''
** This, of course, should be set to your own cpu, or the cpu of the machine you plan to run this install on. If you want to be able to run this install on many machines, you should be safe with I686.
* '''Speed Optimizations'''
** If you want to be 100% sure that there won't be optimization problems you shouldn't select any of these.
* '''Extra features'''
** It is not recommended to use any of these optimizations, even for modules known to be able to handle them, since they cause many apps to break.
* '''Floating Point Math'''
** None. If your architecture is x86 and you don't own a 386SX and 486SX, it's safe to select x387.
* '''Linker Options'''
** Strip.
* '''Addon Program Support'''
** CCache. Make sure to install it first.

These settings should work for almost everyone, and there is a lot room for pushing these optimizations more, at the risk of problems with some applications. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations may cause problems?===
What optimizations are known to cause problems in some setups?

'''Answer:'''

Some optimizations that are known to cause problems on x86 with many applications, and even a entire system:

* <code>-funroll-loops</code>
* <code>-fstrict-aliasing</code>
* <code>-ffast-math</code>
* <code>-ffloat-store</code>

These are sorted from the least unstable to most unstable. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations can give some speed without issues?===
What optimizations can I use to gain some speed but without major risks?

'''Answer:'''

Start with the basic optimizations in [[Lunar Linux:FAQ#What_are_safe_optimizations.3F|FAQ #2.2]] and change the Basic Optimizations to Faster or Fastest if you know that gcc will generate correct code for that cpu. -O2 obviously takes more compile time than -O1, and -O3 takes the most time to compile. Then select the cpu you will run it on. Some of the speed optimizations that should be decent and shouldn't cause too many problems, if any, are: -fomit-frame-pointer. A safe bet for floating point math on a x86 would be x387, if you know your cpu has a floating point unit. Check <code>cat /proc/cpuinfo</code> to see if your cpu supports SSE or SSE2. If your cpu does have sse or sse2 then you can also add that to the math optimizations.

Your results may vary. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations should I avoid?===
What optimizations should I stay away from?

'''Answer:'''

All the ones listed in the [[Lunar Linux:FAQ#What_optimizations_may_cause_problems.3F|FAQ #2.3]] plus:
* <code>-fprofile-arcs</code>
* <code>-fbranching-probabilities</code>

Please read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it. The Lunar developers will not respond to bug reports of broken compiles by users with risky optimizations.

==Installing modules==

===Can I compile several modules at once?===
Is it possible to install multiple modules at the same time without breaking things?

'''Answer:'''

Yes, Lunar even promotes it. However doing so will cause installs compile slower of course. Lunar will not install core system modules like gcc and glibc while something else is installing and will wait until the rest is finished. Also, you cannot install applications while those major modules are installing, they will wait their turn until it's safe and continue to install them automatically.

===error : download failed - broken URL===
I tried to install a module, but the download failed due to a broken URL. What do I do now?

'''Answer:'''

There are three possible reasons why the download failed:
# You are trying to download from one of a set of mirror sites, and the mirror you are using is either busy or incomplete.
#* Run "lunar" as root, select Options / Software Mirrors, and change the mirror to something closer to you.
#* Note: there seems to be a consistent problem with the SFORGE mirror: http://osdn.dl.sourceforge.net
# You are trying to download from a particular site, but the location of the file has changed [or the site is temporarily off-line].
#* Browse the module's website (see "lvu website") [or search the web for the tarball],
#* Download it manually, copy it to /var/spool/lunar, and try to run "lin" again,
#* Run "lvu edit" to create a [[zlocal]] copy, and edit that copy with the new location [or secondary URL]
# You are trying to download a version that has been removed because a newer version exists.
#* Browse the module's website to discover the new version number,
#* Run "lvu edit" to create a [[zlocal]] copy, and edit that copy with the new location, version number, sha1sum, etc.
#* Note: you could first try to run "lin -w newVersion" and hope that it builds without problems.
If you do create your own [[zlocal]] copy, please consider submitting it using "lvu submit". (See [[Module Submission]])

===error : C compiler cannot create executables===
What does this error mean and how can I fix it?
* <code>C compiler cannot create executables</code>

'''Answer:'''

Read the next topic - this is basically the same problem: There are kernel headers missing that are vital to compilation. You will have to restore them. Below is explained how to do that.

===configure: error: C preprocessor "/lib/cpp" fails sanity check===
What does this error mean and how can I fix it?
* <code>configure: error: C preprocessor "/lib/cpp" fails sanity check</code>

'''Answer:'''

This is an include file problem. Sometimes ''/usr/include/gnu/stubs.h'' is missing, this can be found in the glibc source tarball. Most of the time the following applies:

Your kernel headers are missing from <code>/usr/include</code>. This means the C PreProcessor cannot verify that it has the proper cached copies of those vital header files. You need to install the proper ones manually. Here's how:

lin kernel-headers-2.4

This might work for you! (Use the 2.6 version if needed of course)

Otherwise:

mkdir -p /usr/include/{linux,asm}

to create the two target dirs, if needed. Then execute:

cp -av /usr/src/linux/include/linux /usr/include/
cp -av /usr/src/linux/include/asm/* /usr/include/asm/

to copy the files manually. Be warned that the second command has to be done this way since <code>/usr/src/linux/include/asm</code> is a softlink to your arch asm header files, asm points to asm-i386, on x86 machines. So if, on the other hand, you had copied

cp -av /usr/src/linux/include/asm /usr/include/

you would then get a softlink to nowhere under <code>/usr/include/</code>.

Last, you can always try to unpack the kernel tarball you have into <code>/usr/src/linux</code> and manaully link or copy the headers over yourself.

===Can I add more window managers to gdm?===
How do I add other window managers to the sessions list on gdm?

'''Answer:'''

Copy the desktop startup files to <code>/etc/X11/dm/Sessions/</code>. That works with gdm. For kdm you will have to copy them to <code>$KDE_PREFIX/share/apps/kdm/sessions</code>.

===How do I get Flash to work in Mozilla or Firefox?===
How do I get Flash to work in Mozilla or Firefox?

'''Answer:'''

If you are using Mozilla or Firefox, then you can simply do a <code>lin flash-plugin</code> and that will download and install the Macromedia Flash plugin that works with a gtk+ based mozilla through the old abi wrappers.

The flash plugin does ''not'' work with Galeon. The Galeon developers have declined to provide the "old" abi wrappers needed for the plugin to work.

===How do I install Java?===
How do I get Java for my Lunar box?

'''Answer:'''

You will have to download the Java source code from Sun yourself and you have to "click" to agree on their license. You have to compile it yourself too. We don't have a Sun Java module as we currently have no way to automate the "click" to agree to the Sun Java license. See this URL for some handy info:

http://www.linuxfromscratch.org/~tushar/hints/javafromscratch.txt

There is a j2sdk module in moonbase which is the Blackdown port of Sun's Java Virtual Machine.

==Removing modules==

===How do I remove a module?===
How do I remove a module?

'''Answer:'''

If you have just installed a module for the first time using ''lin'' then it is usually safe to remove it using ''lrm''.

However, if you have built or rebuilt other modules that depend on it, you will need to be careful. Use ''lvu eert'' to identify these modules, and then remove them too, or rebuild them using ''lin -rc'' to change the optional dependency. You should run ''lunar nofix'' to make sure that some hidden dependency has not been affected.

You can also use ''lrm -p'' to purge all modules that depend on it, but this is not recommended in general because it is easy to break your system.

===How do I safely remove an optional module?===
How do I safely remove an optional module, especially one that is now deprecated or obsolete but lots of other modules use it?

'''Answer:'''

There are three ways, ranging from 'time-consuming but safe' to 'possibly quick but dangerous'.

1. You can use the ''lvu eert'' approach described above.

2a. You can use ''lsh'' to access the the lunar internal functions to find the other modules that have a known dependency on theModule and rebuild them. If you ''lrm theModule'' first, the rebuilds and ''lunar fix'' can not silently reuse the module again.

for i in `lsh list_installed_depending theModule` ; do lin -cr "$i" ; done
lunar fixdepends
lunar fix

2b. If you want to rebuild the modules in dependency order, you will need to do a bit more work.

MODULES=""
for i in `lsh list_installed_depending theModule`
do
VAR=$(echo "$MODULES" | grep "$i")
if [ -z "$VAR" ]
then
MODULES="$MODULES $i"
fi
done
lin -cr "$MODULES"
lunar fixdepends
lunar fix

3. Run ''lrm theModule''. Use ''lunar nofix'' to identify problems. Run ''lin -cr'' for each problem. Rinse and repeat.

==Lunar core tools==

===How can I recompile my module with new options?===
How do I force lunar to recompile my modules with different options?

'''Answer:'''

Try:

lin -r ''MODULE''

The -r switch will allow you to select new configuration and dependencies for modules.

===How can I make modules recompile instead of resurrecting?===
How do I tell lunar to recompile my application instead of resurrecting it?

'''Answer:'''

Try doing:

lin -c ''MODULE''

The -c option means tells <code>lin</code> to compile this module even if there is an install cache copy available in <code>/var/cache/lunar</code>.

===How can I tell lunar that module X no longer depends on module Y?===
Module X no longer depends on module Y, but lunar insists on reinstalling module Y too. How can I get tell lunar to remove that dependency?

'''Answer:'''

Lunar adds a module's dependencies to a cache when you install it. You can't remove a dependency automatically, but you can rebuild the dependency cache to reflect the current dependencies of the modules that are now installed.

lsh create_module_index
lsh create_depends_cache
lunar fixdepends

Note: Dependencies of modules in [[zlocal]] are ignored. If module X in the main moonbase depends on module Y then the dependency cache will still contain that dependency.

===My moonbase is gone and I can't install anything.===
How do I fix problems with my moonbase when it's missing or damaged?

'''Answer:'''

Simple solution to this is just running:

lin moonbase

This will download the latest moonbase from the internet, and restore it to working order.

===What is a module?===
What is a [[module]] and what does it do??

'''Answer:'''

A [[module]] is a set of files that tell the core tools the following:

* What name, version, and other properties a package has
* Where to download all needed source files
* What other modules are required, or conflict with this one
* How to unpack the source files, how to patch
* How to configure the code
* How to compile
* How to install everything
* What else to do with it

The [[module]] is coded in a set of files in a directory structure, and scripted in bash.

===What is the Moonbase?===
What is that thing you call [[Moonbase]]?

'''Answer:'''

The [[Moonbase]] is a database with [[modules]]. In this database there are description of packages that tell the core tools where to download, how to compile, and how install a [[module]]. You can consider this the lunar equivalent of portage, grimoire, ports, etc.

===What is theedge?===
What is theedge?

'''Answer:'''

[[theedge]] is the same as lunar, and also known as the core code. Theedge is just another version of lunar. These two pieces of code install your packages, but they do not contain package descriptions. Those are defined in moonbase.

[[Theedge]] is a development version of [[lunar]]. Often there are much more features in theedge, and bugs are fixed quicker as well. However, if you do not like all this tweaking on your system, we advice you to use the stable lunar core tools instead on your system.

You can install [[theedge]] by issuing:

lin theedge

Theedge is automatically updated if you do a <code>lunar renew</code> or <code>lunar update</code>.

==Lunar-Linux Installation==

===My usb keyboard is not recognized===
At the boot prompt type ''linux uhci-hcd ehci-hcd'' to make sure those modules are loaded during startup. Those will then enable your usb keyboard.

===So how should I partition my disk?===
I'm setting up lunar from scratch, but how should I partition my disk for a server or desktop system?

'''Answer:'''

Server systems have very different demands than desktops. It's all about flexibility. First desktops:

''desktops'' commonly have one hard disk. You don't want to reformat or repartition often, so you just want to be done with it at once. The easiest is just to setup 2 (two) partitions: one root filesystem big enough for all lunar software, and the rest for <code>/home</code>. Typically, lunar occupies between 4 and 12 gb based on how many applications you install. If you clean up often you can manage with 8gb, but you should keep some extra space. I certainly advise to use a swapfile instead of a swap partition: you can always later delete the swap, or move the swapfile to another disk or partition. A swap partition is harder to relocate.

''Servers'' have different needs. First of all <code>/home</code> doesn't need to be that large, but you will want to setup space for logfiles that cannot cause problems if they grow too fast. Putting <code>/var/tmp</code> and <code>/var/log</code> on separate partitions is quite normal. <code>/tmp</code> can be abused similarly, and is mostly run in [[tmpfs]] to avoid cluttering and give fast access times. Then <code>/usr</code> will be separate and the usual separate <code>rootfs</code>. As you can see this list is already getting quite big! Most users will actually want to make the <code>rootfs</code> quite small (as small as 200mb sometimes!) and thus <code>/home</code> also needs to be on a separate partition.

===Kernel features, built-in or module?===
When I compile a kernel, should I compile drivers that I need in the kernel image or as module?

'''Answer:'''

There are many schools of thought on kernel compiling. One is to build everything into the main kernel without modules. The other one takes building modules to the extreme. Here is a suggestion, if it's not needed to boot it's a module. Thus usb, input, sound, mice ACPI, network, and also cdrom, floppy, and all the non boot file systems, all get built as modules. This reduces the size of the main kernel so it can be put on a floppy. Another thing to consider is that not everything works perfectly, and some features can cause your kernel to misbehave, so if some feature is built-in, the bad behavior is practically inevitible. Instead, with a module you can choose not to load it and thus be left with a working system.

Please note that some people need to make some features built into their kernel and vice versa, do whatever works best for you.

===QEMU and Lunar ISO testing===
How do I use qemu to try out lunar ISO's?

'''Answer:'''

Just a quick note on how to use qemu for testing a Lunar Linux installation. See <code>/var/lib/lunar/moonbase/devel/qemu/DETAILS</code> for a description of qemu. Think of it as a low-cost (''read: free'') version of a virtual machine, that has quite a few useful features and is under active development.

A very simple way to just test a Lunar ISO for booting purposes is:

qemu -cdrom lunar-1.5.0-i686.iso -boot d

If you want to test a full install, then create a 512 megabyte sparse root_fs image with this <code>dd</code> command:

dd if=/dev/zero of=hda.img bs=$((1024 * 1024)) count=0 seek=512

Now invoke qemu:

qemu -cdrom lunar-1.5.0-i686.iso -boot d -hda hda.img

You can then proceed to test your Lunar install. Refer the qemu homepage for further tips and tricks. qemu can also be quite easily used to test if your brand new kernel is bootable or not, which is quite neat.

Note that you should say yes to using SDL as an optional_depends. The gui version of qemu is ''very'' nice in its own little X11 window.

==Other==

===How do I unpack an .RPM file in lunar?===
How do I install RPM files in lunar? Is that possible?

'''Answer:'''

The easiest way to unpack a rpm file is to use the module called <code>rpmunpack</code>. Simply run <code>rpmupack ''XYZ''.rpm</code> for your RPM. This will create a cpio file (''XYZ.cpio.gz'' and ''XYZ.cpio.bz2'' are not uncommon). Once you perform any additional uncompression with <code>gunzip</code> or <code>bunzip2</code>, you can then extract it using <code>cpio -i -d < XYZ.cpio</code> -- After all that you should be all done. If you are trying to rpmunpack a source RPM (i.e. .src.rpm) file then ''XYZ.cpio'' may further contain a tar.bz2 or tar.gz source tarball.

In the zbeta section of moonbase, there is an '''''unsupported''''' module called <code>rpm</code> for those of you that are really desperate.

You might want to do <code>man cpio</code>, to check out additional cpio parameters that may interest you, such as the -L switch.

===What is that in the Lunar-Linux logo?===
What is that logo of yours? It looks like a <nowiki>[cat|ferret|dog|owl|insert nutty animal here]</nowiki>!

'''Answer:'''

The logo is a [[wikipedia:Southern Rockhopper Penguin|Rockhopper Penguin]]. It's a kind of nasty penguin, the one that crowd up in thousands to take over the continent. They have a few long feathers sticking out at their "ears" sideway, just like some owl species do.

You can check out [http://images.google.com/images?q=Rockhopper+Penguin Google Images] for lots of Rockhopper Penguin pictures!

The current logo has been designed by Michael Schindler in 2003 and appeared as the official logo of the Lunar Linux project in 2004.

Lunar Linux:FAQ

2011-07-30T10:23:49Z

Engelsman: /* Removing modules */

These are the '''F'''requently '''A'''sked '''Q'''uestions for Lunar Linux. You have a question about Lunar? You might get your answer below.<br /><br />

__TOC__

==General==

===What is Lunar Linux?===
What exactly is Lunar Linux?

'''Answer:'''
* Please read [[Lunar Linux:About|About Lunar Linux]].

===Can I run Lunar Linux in 64-bit mode?===
Can I run Lunar Linux on my new 64-bit system?

'''Answer:'''

Yes you can. You can run Lunar Linux in '''either''' 64-bit '''or''' 32-bit mode, but there is no multi-lib mode. Be aware that some applications are still only available for 32-bit mode!

===Where can I find how to ...?===
Where can I find how to customize the kernel under Lunar Linux? Or the desktop...

'''Answer:'''

The Lunar Wiki only offers details specific to Lunar Linux. Many other resources already exist for general Linux problem solving. For example, information on how to customize the Linux kernel can be found at:
* http://kernelnewbies.org/
* http://en.wikipedia.org/wiki/Linux_kernel_mailing_list

==Optimizations==

===How do I set optimizations?===
How do I set these optimizations for my machine?

'''Answer:'''

Run <code>lunar optimize</code>. You'll be taken through an interactive menu that explains all the options. Remember to optimize safely.

===What are safe optimizations?===
What are the recomended safe optimizations for [[Lunar Linux]]?

'''Answer:'''

The default sure fire optimizations that are recommended are:

* '''C'''
** <code>-pipe</code>
* '''C++'''
** <code>-pipe</code>
* '''CPU Architecture'''
** You should pick the correct architecture for your own system (defaults to x86 for most people).
* '''Basic Optimzations'''
** Faster (-O2, the default).
* '''CPU'''
** This, of course, should be set to your own cpu, or the cpu of the machine you plan to run this install on. If you want to be able to run this install on many machines, you should be safe with I686.
* '''Speed Optimizations'''
** If you want to be 100% sure that there won't be optimization problems you shouldn't select any of these.
* '''Extra features'''
** It is not recommended to use any of these optimizations, even for modules known to be able to handle them, since they cause many apps to break.
* '''Floating Point Math'''
** None. If your architecture is x86 and you don't own a 386SX and 486SX, it's safe to select x387.
* '''Linker Options'''
** Strip.
* '''Addon Program Support'''
** CCache. Make sure to install it first.

These settings should work for almost everyone, and there is a lot room for pushing these optimizations more, at the risk of problems with some applications. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations may cause problems?===
What optimizations are known to cause problems in some setups?

'''Answer:'''

Some optimizations that are known to cause problems on x86 with many applications, and even a entire system:

* <code>-funroll-loops</code>
* <code>-fstrict-aliasing</code>
* <code>-ffast-math</code>
* <code>-ffloat-store</code>

These are sorted from the least unstable to most unstable. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations can give some speed without issues?===
What optimizations can I use to gain some speed but without major risks?

'''Answer:'''

Start with the basic optimizations in [[Lunar Linux:FAQ#What_are_safe_optimizations.3F|FAQ #2.2]] and change the Basic Optimizations to Faster or Fastest if you know that gcc will generate correct code for that cpu. -O2 obviously takes more compile time than -O1, and -O3 takes the most time to compile. Then select the cpu you will run it on. Some of the speed optimizations that should be decent and shouldn't cause too many problems, if any, are: -fomit-frame-pointer. A safe bet for floating point math on a x86 would be x387, if you know your cpu has a floating point unit. Check <code>cat /proc/cpuinfo</code> to see if your cpu supports SSE or SSE2. If your cpu does have sse or sse2 then you can also add that to the math optimizations.

Your results may vary. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations should I avoid?===
What optimizations should I stay away from?

'''Answer:'''

All the ones listed in the [[Lunar Linux:FAQ#What_optimizations_may_cause_problems.3F|FAQ #2.3]] plus:
* <code>-fprofile-arcs</code>
* <code>-fbranching-probabilities</code>

Please read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it. The Lunar developers will not respond to bug reports of broken compiles by users with risky optimizations.

==Installing modules==

===Can I compile several modules at once?===
Is it possible to install multiple modules at the same time without breaking things?

'''Answer:'''

Yes, Lunar even promotes it. However doing so will cause installs compile slower of course. Lunar will not install core system modules like gcc and glibc while something else is installing and will wait until the rest is finished. Also, you cannot install applications while those major modules are installing, they will wait their turn until it's safe and continue to install them automatically.

===error : download failed - broken URL===
I tried to install a module, but the download failed due to a broken URL. What do I do now?

'''Answer:'''

There are three possible reasons why the download failed:
# You are trying to download from one of a set of mirror sites, and the mirror you are using is either busy or incomplete.
#* Run "lunar" as root, select Options / Software Mirrors, and change the mirror to something closer to you.
#* Note: there seems to be a consistent problem with the SFORGE mirror: http://osdn.dl.sourceforge.net
# You are trying to download from a particular site, but the location of the file has changed [or the site is temporarily off-line].
#* Browse the module's website (see "lvu website") [or search the web for the tarball],
#* Download it manually, copy it to /var/spool/lunar, and try to run "lin" again,
#* Run "lvu edit" to create a [[zlocal]] copy, and edit that copy with the new location [or secondary URL]
# You are trying to download a version that has been removed because a newer version exists.
#* Browse the module's website to discover the new version number,
#* Run "lvu edit" to create a [[zlocal]] copy, and edit that copy with the new location, version number, sha1sum, etc.
#* Note: you could first try to run "lin -w newVersion" and hope that it builds without problems.
If you do create your own [[zlocal]] copy, please consider submitting it using "lvu submit". (See [[Module Submission]])

===error : C compiler cannot create executables===
What does this error mean and how can I fix it?
* <code>C compiler cannot create executables</code>

'''Answer:'''

Read the next topic - this is basically the same problem: There are kernel headers missing that are vital to compilation. You will have to restore them. Below is explained how to do that.

===configure: error: C preprocessor "/lib/cpp" fails sanity check===
What does this error mean and how can I fix it?
* <code>configure: error: C preprocessor "/lib/cpp" fails sanity check</code>

'''Answer:'''

This is an include file problem. Sometimes ''/usr/include/gnu/stubs.h'' is missing, this can be found in the glibc source tarball. Most of the time the following applies:

Your kernel headers are missing from <code>/usr/include</code>. This means the C PreProcessor cannot verify that it has the proper cached copies of those vital header files. You need to install the proper ones manually. Here's how:

lin kernel-headers-2.4

This might work for you! (Use the 2.6 version if needed of course)

Otherwise:

mkdir -p /usr/include/{linux,asm}

to create the two target dirs, if needed. Then execute:

cp -av /usr/src/linux/include/linux /usr/include/
cp -av /usr/src/linux/include/asm/* /usr/include/asm/

to copy the files manually. Be warned that the second command has to be done this way since <code>/usr/src/linux/include/asm</code> is a softlink to your arch asm header files, asm points to asm-i386, on x86 machines. So if, on the other hand, you had copied

cp -av /usr/src/linux/include/asm /usr/include/

you would then get a softlink to nowhere under <code>/usr/include/</code>.

Last, you can always try to unpack the kernel tarball you have into <code>/usr/src/linux</code> and manaully link or copy the headers over yourself.

===Can I add more window managers to gdm?===
How do I add other window managers to the sessions list on gdm?

'''Answer:'''

Copy the desktop startup files to <code>/etc/X11/dm/Sessions/</code>. That works with gdm. For kdm you will have to copy them to <code>$KDE_PREFIX/share/apps/kdm/sessions</code>.

===How do I get Flash to work in Mozilla or Firefox?===
How do I get Flash to work in Mozilla or Firefox?

'''Answer:'''

If you are using Mozilla or Firefox, then you can simply do a <code>lin flash-plugin</code> and that will download and install the Macromedia Flash plugin that works with a gtk+ based mozilla through the old abi wrappers.

The flash plugin does ''not'' work with Galeon. The Galeon developers have declined to provide the "old" abi wrappers needed for the plugin to work.

===How do I install Java?===
How do I get Java for my Lunar box?

'''Answer:'''

You will have to download the Java source code from Sun yourself and you have to "click" to agree on their license. You have to compile it yourself too. We don't have a Sun Java module as we currently have no way to automate the "click" to agree to the Sun Java license. See this URL for some handy info:

http://www.linuxfromscratch.org/~tushar/hints/javafromscratch.txt

There is a j2sdk module in moonbase which is the Blackdown port of Sun's Java Virtual Machine.

==Removing modules==

===How do I remove a module?===
How do I remove a module?

'''Answer:'''

If you have just installed a module for the first time using ''lin'' then it is usually safe to remove it using ''lrm''.

However, if you have built or rebuilt other modules that depend on it, you will need to be careful. Use ''lvu eert'' to identify these modules, and then remove them too, or rebuild them using ''lin -rc'' to change the optional dependency. You should run ''lunar nofix'' to make sure that some hidden dependency has not been affected.

You can also use ''lrm -p'' to purge all modules that depend on it, but this is not recommended in general because it is easy to break your system.

===How do I safely remove an optional module?===
How do I safely remove an optional module, especially one that is now deprecated or obsolete but lots of other modules use it?

'''Answer:'''

There are three ways, ranging from 'time-consuming but safe' to 'possibly quick but dangerous'.

1. You can use the ''lvu eert'' approach described above.

2a. You can use ''lsh'' to access the the lunar internal functions to find the other modules that have a known dependency on theModule and rebuild them. If you ''lrm theModule'' first, the rebuilds and ''lunar fix'' can not silently reuse the module again.

for i in `lsh list_installed_depending theModule` ; do lin -cr "$i" ; done
lunar fixdepends
lunar fix

2b. If you want to rebuild the modules in dependency order, you will need to do a bit more work.

MODULES=""
for i in `lsh list_installed_depending theModule`
do
VAR=$(echo "$MODULES" | grep "$i")
if [ -z "$VAR" ]
then
MODULES="$MODULES $i"
fi
done
for i in $MODULES ; do lin -cr "$i" ; done
lunar fixdepends
lunar fix

3. Run ''lrm theModule''. Use ''lunar nofix'' to identify problems. Run ''lin -cr'' for each problem. Rinse and repeat.

==Lunar core tools==

===How can I recompile my module with new options?===
How do I force lunar to recompile my modules with different options?

'''Answer:'''

Try:

lin -r ''MODULE''

The -r switch will allow you to select new configuration and dependencies for modules.

===How can I make modules recompile instead of resurrecting?===
How do I tell lunar to recompile my application instead of resurrecting it?

'''Answer:'''

Try doing:

lin -c ''MODULE''

The -c option means tells <code>lin</code> to compile this module even if there is an install cache copy available in <code>/var/cache/lunar</code>.

===How can I tell lunar that module X no longer depends on module Y?===
Module X no longer depends on module Y, but lunar insists on reinstalling module Y too. How can I get tell lunar to remove that dependency?

'''Answer:'''

Lunar adds a module's dependencies to a cache when you install it. You can't remove a dependency automatically, but you can rebuild the dependency cache to reflect the current dependencies of the modules that are now installed.

lsh create_module_index
lsh create_depends_cache
lunar fixdepends

Note: Dependencies of modules in [[zlocal]] are ignored. If module X in the main moonbase depends on module Y then the dependency cache will still contain that dependency.

===My moonbase is gone and I can't install anything.===
How do I fix problems with my moonbase when it's missing or damaged?

'''Answer:'''

Simple solution to this is just running:

lin moonbase

This will download the latest moonbase from the internet, and restore it to working order.

===What is a module?===
What is a [[module]] and what does it do??

'''Answer:'''

A [[module]] is a set of files that tell the core tools the following:

* What name, version, and other properties a package has
* Where to download all needed source files
* What other modules are required, or conflict with this one
* How to unpack the source files, how to patch
* How to configure the code
* How to compile
* How to install everything
* What else to do with it

The [[module]] is coded in a set of files in a directory structure, and scripted in bash.

===What is the Moonbase?===
What is that thing you call [[Moonbase]]?

'''Answer:'''

The [[Moonbase]] is a database with [[modules]]. In this database there are description of packages that tell the core tools where to download, how to compile, and how install a [[module]]. You can consider this the lunar equivalent of portage, grimoire, ports, etc.

===What is theedge?===
What is theedge?

'''Answer:'''

[[theedge]] is the same as lunar, and also known as the core code. Theedge is just another version of lunar. These two pieces of code install your packages, but they do not contain package descriptions. Those are defined in moonbase.

[[Theedge]] is a development version of [[lunar]]. Often there are much more features in theedge, and bugs are fixed quicker as well. However, if you do not like all this tweaking on your system, we advice you to use the stable lunar core tools instead on your system.

You can install [[theedge]] by issuing:

lin theedge

Theedge is automatically updated if you do a <code>lunar renew</code> or <code>lunar update</code>.

==Lunar-Linux Installation==

===My usb keyboard is not recognized===
At the boot prompt type ''linux uhci-hcd ehci-hcd'' to make sure those modules are loaded during startup. Those will then enable your usb keyboard.

===So how should I partition my disk?===
I'm setting up lunar from scratch, but how should I partition my disk for a server or desktop system?

'''Answer:'''

Server systems have very different demands than desktops. It's all about flexibility. First desktops:

''desktops'' commonly have one hard disk. You don't want to reformat or repartition often, so you just want to be done with it at once. The easiest is just to setup 2 (two) partitions: one root filesystem big enough for all lunar software, and the rest for <code>/home</code>. Typically, lunar occupies between 4 and 12 gb based on how many applications you install. If you clean up often you can manage with 8gb, but you should keep some extra space. I certainly advise to use a swapfile instead of a swap partition: you can always later delete the swap, or move the swapfile to another disk or partition. A swap partition is harder to relocate.

''Servers'' have different needs. First of all <code>/home</code> doesn't need to be that large, but you will want to setup space for logfiles that cannot cause problems if they grow too fast. Putting <code>/var/tmp</code> and <code>/var/log</code> on separate partitions is quite normal. <code>/tmp</code> can be abused similarly, and is mostly run in [[tmpfs]] to avoid cluttering and give fast access times. Then <code>/usr</code> will be separate and the usual separate <code>rootfs</code>. As you can see this list is already getting quite big! Most users will actually want to make the <code>rootfs</code> quite small (as small as 200mb sometimes!) and thus <code>/home</code> also needs to be on a separate partition.

===Kernel features, built-in or module?===
When I compile a kernel, should I compile drivers that I need in the kernel image or as module?

'''Answer:'''

There are many schools of thought on kernel compiling. One is to build everything into the main kernel without modules. The other one takes building modules to the extreme. Here is a suggestion, if it's not needed to boot it's a module. Thus usb, input, sound, mice ACPI, network, and also cdrom, floppy, and all the non boot file systems, all get built as modules. This reduces the size of the main kernel so it can be put on a floppy. Another thing to consider is that not everything works perfectly, and some features can cause your kernel to misbehave, so if some feature is built-in, the bad behavior is practically inevitible. Instead, with a module you can choose not to load it and thus be left with a working system.

Please note that some people need to make some features built into their kernel and vice versa, do whatever works best for you.

===QEMU and Lunar ISO testing===
How do I use qemu to try out lunar ISO's?

'''Answer:'''

Just a quick note on how to use qemu for testing a Lunar Linux installation. See <code>/var/lib/lunar/moonbase/devel/qemu/DETAILS</code> for a description of qemu. Think of it as a low-cost (''read: free'') version of a virtual machine, that has quite a few useful features and is under active development.

A very simple way to just test a Lunar ISO for booting purposes is:

qemu -cdrom lunar-1.5.0-i686.iso -boot d

If you want to test a full install, then create a 512 megabyte sparse root_fs image with this <code>dd</code> command:

dd if=/dev/zero of=hda.img bs=$((1024 * 1024)) count=0 seek=512

Now invoke qemu:

qemu -cdrom lunar-1.5.0-i686.iso -boot d -hda hda.img

You can then proceed to test your Lunar install. Refer the qemu homepage for further tips and tricks. qemu can also be quite easily used to test if your brand new kernel is bootable or not, which is quite neat.

Note that you should say yes to using SDL as an optional_depends. The gui version of qemu is ''very'' nice in its own little X11 window.

==Other==

===How do I unpack an .RPM file in lunar?===
How do I install RPM files in lunar? Is that possible?

'''Answer:'''

The easiest way to unpack a rpm file is to use the module called <code>rpmunpack</code>. Simply run <code>rpmupack ''XYZ''.rpm</code> for your RPM. This will create a cpio file (''XYZ.cpio.gz'' and ''XYZ.cpio.bz2'' are not uncommon). Once you perform any additional uncompression with <code>gunzip</code> or <code>bunzip2</code>, you can then extract it using <code>cpio -i -d < XYZ.cpio</code> -- After all that you should be all done. If you are trying to rpmunpack a source RPM (i.e. .src.rpm) file then ''XYZ.cpio'' may further contain a tar.bz2 or tar.gz source tarball.

In the zbeta section of moonbase, there is an '''''unsupported''''' module called <code>rpm</code> for those of you that are really desperate.

You might want to do <code>man cpio</code>, to check out additional cpio parameters that may interest you, such as the -L switch.

===What is that in the Lunar-Linux logo?===
What is that logo of yours? It looks like a <nowiki>[cat|ferret|dog|owl|insert nutty animal here]</nowiki>!

'''Answer:'''

The logo is a [[wikipedia:Southern Rockhopper Penguin|Rockhopper Penguin]]. It's a kind of nasty penguin, the one that crowd up in thousands to take over the continent. They have a few long feathers sticking out at their "ears" sideway, just like some owl species do.

You can check out [http://images.google.com/images?q=Rockhopper+Penguin Google Images] for lots of Rockhopper Penguin pictures!

The current logo has been designed by Michael Schindler in 2003 and appeared as the official logo of the Lunar Linux project in 2004.

Module Submission

2011-04-22T19:03:22Z

Engelsman: Added a header for the acceptance/rejection criteria

===Submitting modules to the official Moonbase===

====Why would I want to?====

The official [[Moonbase]] is maintained and updated by the [[Lunar Linux]] developers.
But what if there isn't a module in the [[Moonbase]] for the package that you want,
or it is not the latest version, or it is out-of-date in some other way?

Well obviously you can report the problem via
the [http://bugs.lunar-linux.org/view_all_bug_page.php Bug Tracker],
the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List], or discuss it on
the [irc://irc.freenode.net/lunar #Lunar] IRC channel on [http://freenode.net/ Freenode.net]
and hope that someone can help you.

Or you can scratch your itch the open source way and create or update the module yourself using the information in
the articles:
[[Module Basics|A basic module outline]] and
[[Module Writing|Writing Lunar-Linux Modules]].
''Remember to work in the [[zlocal]] section so that your updates are not lost the next time you download a new Moonbase.''

And then what?
Maybe other people could benefit from your module.
Maybe other people could improve your module.
So why not submit it to the Lunar developers so they can decide whether to commit it to the [[Moonbase]]?

====What are the acceptance/rejection criteria for submissions?====

* In general, module submissions will probably be accepted if they:
: + introduce a new or missing module into the moonbase;
: + provide an updated version of a module;
: + provide updated download and website URLs;
: + provide missing dependencies required to build the module;
: + add BUILD options that enable a failing module to build.

* However, module submissions are likely to be rejected if they:
: - do not follow the formatting guidelines given on the wiki;
: - fail to download sources correctly, or fail to build;
: - introduce system specific changes that not all users will want;
: - remove explicit dependencies in favour of implicit ones;
: - form part part of a larger suite of modules that need to be updated and tested together, such as an X, KDE or GNOME component;
: - introduce an svn or git development version of a module that already has a recent, stable version;
: - change a core module, or one which is known to cause update problems for other tools.

====How do I create a new module?====

The easiest way is to run '''lvu new''' ''theModule''. It will ask for URLs for the source tarball and the website, and for short and long description entries, and then create a basic [[DETAILS]] file for you. Then follow the guidelines below.

====How do I update a module?====

Let's assume that you have found the ''theModule'' no longer downloads and installs properly and you want to fix it.

* run '''lvu edit''' '''''theModule''''' to copy the existing ''theModule'' files to [[zlocal]].
* run '''lvu cd''' '''''theModule''''' or manually change into the directory given by ''lvu edit''
* edit the [http://wiki.lunar-linux.org/index.php/Module_Basics#The_DETAILS_script DETAILS] file
* if you are updating because there is a new release:
** modify the version number to the latest one available
** edit the ''UPDATED'' date to today's date
** run '''lget''' '''''theModule''''' and see if the new version downloads OK
** run '''sha1sum /var/spool/lunar/theModule-(whatever the new file name is)'''
** insert this checksum in the ''SOURCE_VFY'' field in the [http://wiki.lunar-linux.org/index.php/Module_Basics#The_DETAILS_script DETAILS] file
* if you are correcting a broken link or sha1sum without changing the version:
** leave the ''UPDATED'' field as it was so that people will not be forced to download and re-install
* run '''lin''' '''''theModule''''' and test, test and test again
** run '''lvu install''' '''''theModule''''' to make sure that it has not installed files where it shouldn't
** run '''lvu links''' '''''theModule''''' and check whether you need to create or update [[DEPENDS]]

Many modules only require a [[DETAILS]] file. Others may also need [[DEPENDS]], [[BUILD]], etc. or require '''x86_64''' versions of the files. See [[Module_Basics]] for more information.

====How do I submit the module?====

Once you have successfully installed the module using '''lin -rc''' ''theModule'':

* '''subscribe to the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List].''' Not sure if this is still required, but why not do it now anyway? Other users might have feedback about the module.

* if you haven't already done so, you will need run '''lunar set ADMIN''' '''''your@e-mail.adress''''', or run '''lunar''' and follow the menus, before the next step in order for the submission script to work (it requires a valid e-mail address).

* run '''lvu submit''' '''''theModule''''' and provide a meaningful message (see Note below).
* you should receive e-mail feedback whether your submission was accepted or the reasons for rejection but remember that:
# the Lunar development team is quite small,
# they are all working in their spare time, and have real lives and other commitments,
# some of the submissions require specific hardware/software environments to be able to install and test them properly

'''Note''': The first line of the message will be visible on the on-line [http://foo-projects.org/~sofar/queue.php Submission queue]. Give the reasons why the module has been updated, and what you have changed. This message can then be used directly when submitting the changes to the central [[moonbase]].

====The view from the developers' side!====

For an idea of how the developers process the submissions, see [[Module_Submission_for_developers]] and [[GitForLunarDevs]]

Module Submission

2011-04-22T19:01:20Z

Engelsman: Removed old note about possible module rejection

===Submitting modules to the official Moonbase===

====Why would I want to?====

The official [[Moonbase]] is maintained and updated by the [[Lunar Linux]] developers.
But what if there isn't a module in the [[Moonbase]] for the package that you want,
or it is not the latest version, or it is out-of-date in some other way?

Well obviously you can report the problem via
the [http://bugs.lunar-linux.org/view_all_bug_page.php Bug Tracker],
the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List], or discuss it on
the [irc://irc.freenode.net/lunar #Lunar] IRC channel on [http://freenode.net/ Freenode.net]
and hope that someone can help you.

Or you can scratch your itch the open source way and create or update the module yourself using the information in
the articles:
[[Module Basics|A basic module outline]] and
[[Module Writing|Writing Lunar-Linux Modules]].
''Remember to work in the [[zlocal]] section so that your updates are not lost the next time you download a new Moonbase.''

And then what?
Maybe other people could benefit from your module.
Maybe other people could improve your module.
So why not submit it to the Lunar developers so they can decide whether to commit it to the [[Moonbase]]?

* In general, module submissions will probably be accepted if they:
: + introduce a new or missing module into the moonbase;
: + provide an updated version of a module;
: + provide updated download and website URLs;
: + provide missing dependencies required to build the module;
: + add BUILD options that enable a failing module to build.

* However, module submissions are likely to be rejected if they:
: - do not follow the formatting guidelines given on the wiki;
: - fail to download sources correctly, or fail to build;
: - introduce system specific changes that not all users will want;
: - remove explicit dependencies in favour of implicit ones;
: - form part part of a larger suite of modules that need to be updated and tested together, such as an X, KDE or GNOME component;
: - introduce an svn or git development version of a module that already has a recent, stable version;
: - change a core module, or one which is known to cause update problems for other tools.

====How do I create a new module?====

The easiest way is to run '''lvu new''' ''theModule''. It will ask for URLs for the source tarball and the website, and for short and long description entries, and then create a basic [[DETAILS]] file for you. Then follow the guidelines below.

====How do I update a module?====

Let's assume that you have found the ''theModule'' no longer downloads and installs properly and you want to fix it.

* run '''lvu edit''' '''''theModule''''' to copy the existing ''theModule'' files to [[zlocal]].
* run '''lvu cd''' '''''theModule''''' or manually change into the directory given by ''lvu edit''
* edit the [http://wiki.lunar-linux.org/index.php/Module_Basics#The_DETAILS_script DETAILS] file
* if you are updating because there is a new release:
** modify the version number to the latest one available
** edit the ''UPDATED'' date to today's date
** run '''lget''' '''''theModule''''' and see if the new version downloads OK
** run '''sha1sum /var/spool/lunar/theModule-(whatever the new file name is)'''
** insert this checksum in the ''SOURCE_VFY'' field in the [http://wiki.lunar-linux.org/index.php/Module_Basics#The_DETAILS_script DETAILS] file
* if you are correcting a broken link or sha1sum without changing the version:
** leave the ''UPDATED'' field as it was so that people will not be forced to download and re-install
* run '''lin''' '''''theModule''''' and test, test and test again
** run '''lvu install''' '''''theModule''''' to make sure that it has not installed files where it shouldn't
** run '''lvu links''' '''''theModule''''' and check whether you need to create or update [[DEPENDS]]

Many modules only require a [[DETAILS]] file. Others may also need [[DEPENDS]], [[BUILD]], etc. or require '''x86_64''' versions of the files. See [[Module_Basics]] for more information.

====How do I submit the module?====

Once you have successfully installed the module using '''lin -rc''' ''theModule'':

* '''subscribe to the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List].''' Not sure if this is still required, but why not do it now anyway? Other users might have feedback about the module.

* if you haven't already done so, you will need run '''lunar set ADMIN''' '''''your@e-mail.adress''''', or run '''lunar''' and follow the menus, before the next step in order for the submission script to work (it requires a valid e-mail address).

* run '''lvu submit''' '''''theModule''''' and provide a meaningful message (see Note below).
* you should receive e-mail feedback whether your submission was accepted or the reasons for rejection but remember that:
# the Lunar development team is quite small,
# they are all working in their spare time, and have real lives and other commitments,
# some of the submissions require specific hardware/software environments to be able to install and test them properly

'''Note''': The first line of the message will be visible on the on-line [http://foo-projects.org/~sofar/queue.php Submission queue]. Give the reasons why the module has been updated, and what you have changed. This message can then be used directly when submitting the changes to the central [[moonbase]].

====The view from the developers' side!====

For an idea of how the developers process the submissions, see [[Module_Submission_for_developers]] and [[GitForLunarDevs]]

Module Submission

2011-04-22T18:59:44Z

Engelsman: Added general module submission acceptance/rejection criteria

===Submitting modules to the official Moonbase===

====Why would I want to?====

The official [[Moonbase]] is maintained and updated by the [[Lunar Linux]] developers.
But what if there isn't a module in the [[Moonbase]] for the package that you want,
or it is not the latest version, or it is out-of-date in some other way?

Well obviously you can report the problem via
the [http://bugs.lunar-linux.org/view_all_bug_page.php Bug Tracker],
the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List], or discuss it on
the [irc://irc.freenode.net/lunar #Lunar] IRC channel on [http://freenode.net/ Freenode.net]
and hope that someone can help you.

Or you can scratch your itch the open source way and create or update the module yourself using the information in
the articles:
[[Module Basics|A basic module outline]] and
[[Module Writing|Writing Lunar-Linux Modules]].
''Remember to work in the [[zlocal]] section so that your updates are not lost the next time you download a new Moonbase.''

And then what?
Maybe other people could benefit from your module.
Maybe other people could improve your module.
So why not submit it to the Lunar developers so they can decide whether to commit it to the [[Moonbase]]?

* In general, module submissions will probably be accepted if they:
: + introduce a new or missing module into the moonbase;
: + provide an updated version of a module;
: + provide updated download and website URLs;
: + provide missing dependencies required to build the module;
: + add BUILD options that enable a failing module to build.

* However, module submissions are likely to be rejected if they:
: - do not follow the formatting guidelines given on the wiki;
: - fail to download sources correctly, or fail to build;
: - introduce system specific changes that not all users will want;
: - remove explicit dependencies in favour of implicit ones;
: - form part part of a larger suite of modules that need to be updated and tested together, such as an X, KDE or GNOME component;
: - introduce an svn or git development version of a module that already has a recent, stable version;
: - change a core module, or one which is known to cause update problems for other tools,

<blockquote>
'''Important Note:''' Just because you can submit a module does not mean that it will be accepted! For example, if the module is part of a larger suite of modules that all need to be updated and tested together, such as an X, GNOME or KDE module, your submission might be rejected. If you submit an svn or git development version of a module that already has a recent, stable version, your submission might be rejected. If you submit an update for a core module, or one which is known to cause update problems for other tools, your submission might be rejected.
</blockquote>

====How do I create a new module?====

The easiest way is to run '''lvu new''' ''theModule''. It will ask for URLs for the source tarball and the website, and for short and long description entries, and then create a basic [[DETAILS]] file for you. Then follow the guidelines below.

====How do I update a module?====

Let's assume that you have found the ''theModule'' no longer downloads and installs properly and you want to fix it.

* run '''lvu edit''' '''''theModule''''' to copy the existing ''theModule'' files to [[zlocal]].
* run '''lvu cd''' '''''theModule''''' or manually change into the directory given by ''lvu edit''
* edit the [http://wiki.lunar-linux.org/index.php/Module_Basics#The_DETAILS_script DETAILS] file
* if you are updating because there is a new release:
** modify the version number to the latest one available
** edit the ''UPDATED'' date to today's date
** run '''lget''' '''''theModule''''' and see if the new version downloads OK
** run '''sha1sum /var/spool/lunar/theModule-(whatever the new file name is)'''
** insert this checksum in the ''SOURCE_VFY'' field in the [http://wiki.lunar-linux.org/index.php/Module_Basics#The_DETAILS_script DETAILS] file
* if you are correcting a broken link or sha1sum without changing the version:
** leave the ''UPDATED'' field as it was so that people will not be forced to download and re-install
* run '''lin''' '''''theModule''''' and test, test and test again
** run '''lvu install''' '''''theModule''''' to make sure that it has not installed files where it shouldn't
** run '''lvu links''' '''''theModule''''' and check whether you need to create or update [[DEPENDS]]

Many modules only require a [[DETAILS]] file. Others may also need [[DEPENDS]], [[BUILD]], etc. or require '''x86_64''' versions of the files. See [[Module_Basics]] for more information.

====How do I submit the module?====

Once you have successfully installed the module using '''lin -rc''' ''theModule'':

* '''subscribe to the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List].''' Not sure if this is still required, but why not do it now anyway? Other users might have feedback about the module.

* if you haven't already done so, you will need run '''lunar set ADMIN''' '''''your@e-mail.adress''''', or run '''lunar''' and follow the menus, before the next step in order for the submission script to work (it requires a valid e-mail address).

* run '''lvu submit''' '''''theModule''''' and provide a meaningful message (see Note below).
* you should receive e-mail feedback whether your submission was accepted or the reasons for rejection but remember that:
# the Lunar development team is quite small,
# they are all working in their spare time, and have real lives and other commitments,
# some of the submissions require specific hardware/software environments to be able to install and test them properly

'''Note''': The first line of the message will be visible on the on-line [http://foo-projects.org/~sofar/queue.php Submission queue]. Give the reasons why the module has been updated, and what you have changed. This message can then be used directly when submitting the changes to the central [[moonbase]].

====The view from the developers' side!====

For an idea of how the developers process the submissions, see [[Module_Submission_for_developers]] and [[GitForLunarDevs]]

Module Submission for developers

2011-04-16T18:19:33Z

Engelsman: corrected wget | git am command line

===Module Submission for developers===

Why and how users should submit modules is described on the [[Module_Submission]] page. This page describes what a developer needs to do to handle these submissions. Or rather, it describes what works for me.

I'm no expert by any means and this is not intended to be a comprehensive guide to git. There is just enough information to get started, and to describe my workflow.

====Developer access====

Before you will be able to save anything back to the central git repository holding the [[Moonbase]], you will obviously need to apply for a username and password on the central machine. You will need to have been a regular, constructive contributor to the [irc://irc.freenode.net/lunar #lunar] IRC channel on [http://freenode.net/ Freenode.net], or the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List] or have successfully submitted modules in the past.

====Cloning your own moonbase.git====

Just like other source code management systems, git uses the concepts of a repository and working files. In the past git has allowed the repository and the working files to exist within the same top level directory structure. It seems that this has lead to some problems, so work is under way to separate out the repository and the working files. At the moment certain operations generate warning messages if you try to save to a combined repository and working directory. In the future you will need to have a "bare" repository and a separate working version. This article describes how to set up and use such a future-proof system.

I don't have a public server of my own on which I can make a repository available for sharing, testing and cherry-picking by others. Therefore I use a multi-stage repository and working directory system. If you have a public server, you may be able to work with just one.

I have three repositories: a remote copy of the main [[Lunar Linux]] [[Moonbase]] repository; a remote working copy; and a local working copy. The first one is optional, but it allows me to share files between the working copies without having to commit them to the main [[Moonbase]] repository first.

First of all I login to the main [[Lunar Linux]] machine, '''doppio''', using ssh, and set two important global git defaults:

doppio$ git config --global user.name "Full Name"
doppio$ git config --global user.email "username@lunar-linux.org"

Then I create the remote "bare" copy of the main [[Moonbase]] repository and configure two useful properties:

doppio$ git clone '''--bare''' git://lunar-linux.org/lunar/moonbase.git moonbase.git
doppio$ git config --get-regexp '^(remote|branch)\.'
doppio$ git config remote.origin.push master:master

Next I create a remote "working" repository that shadows the remote "bare" one, again on '''doppio''':

doppio$ git clone moonbase.git workbase.git
doppio$ cd workbase.git
doppio$ git config --get-regexp '^(remote|branch)\.'
doppio$ git config remote.origin.push master:master

The second git config command tells git that the default action for the "push" command is to push changes from the master branch of the current repository to the master branch of the parent repository. Otherwise you need to provide that information on the command line every time.

I have a local "working" repository on my private machine that also shadows the remote "bare" one. I shall call my local machine '''satellite''' so that it matches the instructions given in [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT With 20 Commands Or So] but see the Note at the end of the section.

satellite$ git config --global user.name "Full Name"
satellite$ git config --global user.email "username@lunar-linux.org"

satellite$ git clone ssh://username@lunar-linux.org/~username/moonbase.git workbase.git
satellite$ cd workbase.git
satellite$ git config --get-regexp '^(remote|branch)\.'
satellite$ git config remote.origin.push master:master

This repository setup allows the following workflow:

* first ensure that the my central repo is up to date:

doppio$ cd moonbase.git
doppio$ git fetch # note: fetch not pull

* then, either work in the remote working directory:

doppio$ cd workbase.git
doppio$ git checkout master
doppio$ git pull
doppio$ git checkout -b testing master
doppio$ ... edit files and commit ...
doppio$ git checkout master
doppio$ git merge testing
doppio$ git branch -D testing
doppio$ git push

* or work on the local working directory:

satellite$ cd workbase.git
satellite$ git checkout master
satellite$ git pull
satellite$ git checkout -b testing master
satellite$ ... edit files and commit ...
satellite$ git checkout master
satellite$ git merge testing
satellite$ git branch -D testing
satellite$ git push

* Finally I can update the central [[Moonbase]] repository, although I'm sure there must be a better way:

doppio$ cd moonbase.git
doppio$ git push /var/git/lunar/moonbase.git master

* I can only share files back and forth between the local and remote working repositories using this method. I can't pull from the working directory on satellite to the working directory on doppio because satellite is private and can only call out. I can't push from the working directory on satellite to the working directory on doppio either because it is not a bare repository.

''Note that [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT...] recommends having the following line instead:

satellite$ git config remote.origin.push master:refs/remotes/satellite/master

but this doesn't work with the bare repository system. Or rather, it does something, but I haven't worked out how to use the information in the remote repository.''

====Reviewing module submissions====

There is a neat script on '''doppio''' called '''review''' that you can use to view and apply the module submission patches directly to the current working copy of '''moonbase.git'''. The '''review''' script assumes that the submitter has already tested the patch and that if it applies cleanly it will be accepted, otherwise it will be rejected. One really cool feature of '''review''' is that the submitter gets the credit in the commit message. Unfortunately, if there are any problems in your working copy of '''moonbase.git''' - and there often were in mine - the script can delete the patch.

By default '''review''' will work through all of the modules in the [http://foo-projects.org/~sofar/queue.php submission queue] so it's best to specify the module that you are interested in. '''review''' will open an editor session containing the module patch file so that you can view the changes, and remove "Subject: " from the subject line and annotate what will become the text of the commit message. After you leave the editor, '''review''' checks whether the patch will apply to the current working copy of '''moonbase.git''' without problems, suggests what should be done with the patch, and waits for your input. If the patch applies cleanly, the default action is to ''accept'' it. You could still ''reject'' it for some other reason; because it does not conform to the [[Module_Guidelines]] for example. If the patch can't be applied - and that might mean that the submission was valid but that a developer has already updated that module in the moonbase - the action is to ''reject'' and another editor session will open so that you can explain why. The two other possible actions are ''defer'' and ''quit''.

You can also use ''/home/engelsman/review.new'' which gives the added option to ''thank'' someone for a submission that was valid but can no longer be applied because another developer has beaten them to it. It's a little less harsh than ''reject''.

doppio$ cd moonbase.git
doppio$ git fetch # make sure we are up to date
doppio$ cd ../workbase.git
doppio$ git pull # make sure working copy is also up to date
doppio$ git checkout -b testing master # create a test branch in case of problems
doppio$ review submitted_module # view patch in editor, then accept,reject,defer,quit

# if accepted:
doppio$ git checkout master # still in workbase.git
doppio$ git merge testing
doppio$ git branch -D testing
doppio$ git push
doppio$ cd ../moonbase.git
doppio$ git push /var/git/lunar/moonbase.git master

# else:
doppio$ git checkout master # still in workbase.git
doppio$ git branch -D testing

If all has gone smoothly, '''git status''' won't show any added, deleted or modified files. Take care to clean up if there are.

====Testing the submission locally before committing====

If you want to be really thorough - or paranoid - you should really check that the patch applies and builds on your own machine first. That takes a little more effort, because you will first need to grab the patch file, apply and test locally:

doppio$ cd moonbase.git
doppio$ git fetch # make sure up to date before pulling working copy

Make sure that your local moonbase is up-to-date before you try dealing with the patch:

satellite$ cd moonbase.git
satellite$ git pull
satellite$ git checkout -b testing master

and then use the method of your choice to grab the patch and apply it:

satellite$ # method 1
satellite$ scp username@doppio.lunar-linux.org:/var/anonymous/submissions/submitted_module.patch /tmp
satellite$ git am /tmp/submitted_module.patch

satellite$ # method 2
satellite$ wget -q <nowiki>"http://foo-projects.org/~sofar/queue.php?p=submitted_module"</nowiki> -O - | git am

satellite$ # method 3
satellite$ # browse to "http://foo-projects.org/~sofar/queue.php"
satellite$ # right click on patch and "save link as" /tmp/submitted_module.patch
satellite$ git am /tmp/submitted_module.patch

satellite$ # check '''lin submitted_module''' works as expected

At this point, if you want the submitter to get a feel-good "Your patch was accepted" message:

satellite$ git checkout master
satellite$ git branch -D testing

doppio$ # use '''git''' and '''review''' as described earlier

Otherwise, just continue with the usual git workflow:

satellite$ git checkout master
satellite$ git merge testing
satellite$ git branch -D testing
satellite$ git push

doppio$ cd moonbase.git
doppio$ git merge satellite/testing # see '''git config''' tip earlier
doppio$ git push /var/git/lunar/moonbase.git master
doppio$ review # patch already applied, so use '''review''' thank option

As mentioned earlier, run '''git status''', tidy up if required, and run '''git pull''' again.

===Is there a better way?===

I'm an apprentice rather than a wizard level developer, and I've just about understood git-101, but diagnosing git problems makes my head hurt.

So if you can see a better way of doing things, please add a section at the bottom and describe your workflow.

Template:Main Page:About

2011-03-25T14:10:10Z

Engelsman:

<div style="float: right; padding-top: 0.1em; padding-right: 15px;">
{{ed|Main_Page:About|}}
</div>

==[[Lunar Linux:About|'''About Lunar Linux''']]==

'''Lunar Linux''' is a [[wikipedia:source code|source]] based [[wikipedia:Linux distribution|Linux distribution]]. It is built entirely by [[wikipedia:compiler|compiling]] [[wikipedia:source code|source code]], using custom [[wikipedia:Optimization (computer_science)|optimizations]].

It installs a complete [[wikipedia:Bootstrap#Computing|bootstrap]] development system first. After telling the Lunar package manager which software will be required, it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward the users specific needs.
This should result in a lean and optimized [[wikipedia:operating system|operating system]]. On the downside, compiling a whole distribution from scratch may be time-consuming and complicate the task of keeping the packages up to date.

Currently, Lunar only supports the [[wikipedia:X86|x86]] and [[wikipedia:X86-64|x86-64]] architectures.

Lunar Linux is licensed under the GPLv2.

'''2011-03-25''': Despite appearances, Lunar Linux is still very much alive. The official 1.6.5 ISO was released on 2010-08-22, and work on a beta release of the next ISO is currently in progress. The Forums and Wiki are inactive because they were locked after prolonged spam-bot vandalism. If you require help, simply go to the #lunar irc channel and ask!

<div style="text-align: right; font-variant: small-caps; padding-right: 15px;">
[[Lunar Linux:About|More Information]]
</div>

Lunar Linux:Installation/1.6.5

2011-03-16T20:37:03Z

Engelsman: /* KNOWN PROBLEMS */

__TOC__

Lunar Linux is a revolutionary Linux distribution in that it is not binary based, as are most distributions, but is instead built entirely by compiling source code, using your own custom optimizations.

Essentially, it installs a complete bootstrap development system on your machine, and then you tell the Lunar package manager what tools you want, and it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward your specific needs.

The result is a leaner, meaner, refreshingly uncluttered, and strikingly faster operating system than most Linux distributions.

This installation guide is designed to get you through the installation process as painlessly as possible. It assumes that you have some experience with Linux or another Unix variant, and have a general idea of what you are doing. If you are unfamiliar with such things as partitions, or have never used Linux before, Lunar may not be the best introduction for you into the world of open source. There are always Lunar gods available on irc.freenode.net in the #lunar channel to answer any questions that this manual may not make quite clear enough.

With that said, we hope you enjoy using Lunar!

==About this installation manual==

Although this manual is not intended to be a full and complete overview of any situation you may be confronted with, given the wide diversity of hardware available these days, it is intended to be an introduction to the world of Lunar Linux. You will see examples that are not tailored towards your to-be built server or workstation, optimizations that are overly broad or too specific, and examples that don't apply to any real situations. We tried hard to give you the idea of how much power you have over how you can setup your system, but we are forgetting to tell you how to run your own server or desktop (or other system) at all. That means that the examples and steps taken most probably do not apply to your situation at all.

Do not despair: if you understand what is going on and you get the idea, the installer will allow you to do pretty much everything you want to do with your system. There are really (almost) no limits.

==Getting the ISO==

The primary site for retrieving the ISO is [http://www.lunar-linux.org/ lunar-linux.org]. There, you will find links to our US, EU, and Internet2 mirrors, as well as a Bittorrent link. As of this writing, the current version of the Lunar ISO is version 1.6.5-rc1, codename Mare Ingenii (20100709). (''Check the main site for the actual latest version!'')

Locate and retrieve the file lunar-1.6.5-rc1-i686.iso.bz2 (or lunar-1.6.5-rc1-x86_64.iso.bz2 if you have a 64-bit system). After downloading this file, you will need to unpack the ISO using bzip2. Windows users will need a program that can extract bzip2 archives, like WinZip (also capable of extracting bzip2 archives under windows are IZarc, Winrar, powerarchiver and 7-Zip). Mac should unzip the file by itself. Then all that is left to do is use your favorite program to burn the ISO to a cdrom and begin the installation. Lunar can also be installed without using a CD. If you need to do it this way, our [[FAQ]] provides simple instructions.

It should be noted that the 1.6.5 ISO and Lunar use udev for device management. The devfs system, and the "old-school" method of manually installing devices, are no longer supported.

We are assuming the you are installing Lunar as your primary OS. Make sure you have a backup of any important data that you need to retain. The Lunar Linux Project and its developers are not responsible in any way for any loss of data on your system!

==Booting the ISO==

Upon booting the ISO, the first thing you will see are options for booting the ISO kernel, or for performing RAM tests [Note: MemTest is not available on x86_64]. There is even a safe mode which will disable DMA, MTRR, RAID, LVM, USB keyboards, NTFS, HPFS, Advanced Partitions, and Firewire. Most folks, however, will be just fine pressing enter at the boot prompt and loading the default kernel.

To boot the iso with support for your usb keyboard:
''linux uhci-hcd ehci-hcd''

After loading the kernel, the first screen presents you with a few options. If there are extra modules you need to load in order continue with the install, they can be loaded here. There is also a shell option. However, if you are using this ISO for rescue purposes, you do not want to shell out here; rather continue booting and shell out in the next section. Most people will select "continue booting" here.

It should be noted that the 1.6.5 ISO tries to autodetect some hardware (mostly scsi drivers and network interfaces) during this stage. This will help you establish a network connection if you desire so during installation. For this reason the programs 'dhcpcd' and 'ftp' are already available at this stage.

==Virtual Consoles==

Once the ISO has booted into the installer, you can immediately shell out or switch to one of the other virtual consoles. These will have ready to go root shells and are available throughout the installer sequence. With these you can start rescue actions, setup networking or double check the install progress and make manual adjustments.

==Language and keyboard interface Settings==

After reading the introduction, you will be presented with options for choosing the proper font, keymap, and language for your install.
You will also need to choose an editor, as you are going to need one later on in the installation for setting up your lilo or grub configuration. The choices available are e3, [e3/emacs], joe, nano, vi, and zile. If you have never used a text editor in Linux before, nano is the best choice for you. If you skip the Native Language Support option, the system will install the default editor, nano, for you. When you have finished setting up your options, press cancel to return to the main setup menu.
Less important for most people is the ability to choose the console font, although it may help display some non-English characters. Most people will want to set the system-default language variable and editor though. All these values are unset by default, so make sure you set them now.
The keymap table allows people to use azerty and dvorak keyboards, and much more. This is especially required for non-English keyboards which provide many accented characters.
All these language and keymap settings might not apply to the lunar code itself, which (currently) does not have any international support, but most programs that run during the installer sequence, and after booting into your new system, will be affected properly.

Warning: the keymap entry appears to default to ANSI-dvorak so make sure that you really select what you want.

==Creating or editing Partitions==

The next step is to set up partitions on your hard drive. Upon selecting the "Partition Drive" option, you will be shown a list of all the discs the kernel has detected. For this guide, we will assume that you have one hard drive connected via an IDE channel, which will show up in the menu as "disc0". After selecting the disc to partition, you are given the option of using one of three partitioning programs. They are:

* cfdisk -- A menu driven partitioner, and very easy to use. If you are unfamiliar with various partitioning programs, this is the best option for you.
* fdisk -- Text based partitioner that requires a little more know-how than cfdisk. More experienced users will probably use this program. However new users should not be daunted, as it does have help offered at every step.
* parted -- Text based partitioner that is good for advanced users. Parted is excellent for resizing current partitions on your hard disk, however be forewarned that resizing partitions is an excellent way to hose your entire disc.

Note: under the <Settings> option on the main menu there is an option to configure the fstab mount style as DEV, LABEL or UUID. The first is the traditional Linux method, but can sometimes give problems if a kernel update causes the disk to be renamed. The default is UUID, which uses a unique marker on the partition to avoid this problem.

For our example, we have a 40GB IDE drive and we'll set up six partitions; /, /boot, /home, /usr, /var, and a swap partition. It's a good idea to keep certain directories, such as /var and /usr on separate partitions, as this can save you a lot of headache in the future in case your disk ever completely fails on you and you need to recover data (God forbid!). Also, when you have a separate /boot partition as we have in our example, you need to have your partitioning program mark that partition as active or bootable. In our example, if we were using fdisk, you would press "a" at the command line, and then select part1 as the active partition.

You might also want to install a /tmp partition. By default, Lunar will create a tempfs filesystem mounted on /tmp (tempfs minimizes filesystem fragmentation because it resides in volatile memory). This can be a good choice if you have a lot of memory on your machine. If memory is tight, we recommend creating a /tmp partition to minimize filesystem fragmentation.

It is important to note that you <span class="emphasis">''can not''</span> mount the directories /etc, /bin, /sbin, /dev, /lib and /proc on separate partitions. These directories need to be contained within the root ("/") directory. The installation program should block you from doing this, but it's best not to try.

Here's our partition setup:

1 /boot 100MB
2 / 4GB
3 swap 1GB
5 /usr 10GB
6 /var 10GB
7 /home 15GB

(''If you're wondering about this choice of partitions: it's really just an example. Read the [[FAQ#So_how_should_I_partition_my_disk.3F|FAQ]] on what makes sense in the real world''))

You'll notice that there is no fourth partition in our list above. In order for you to have more than four partitions on a single drive, the fourth partition is made into what is known as an extended or logical partition in which the fifth, sixth, and seventh (etc, etc) partitions reside. For our example above, if we were using fdisk, we would make the fourth partition an extended/logical partition that was 35GB, and then the fifth, sixth, and seventh partitions in our scheme resided within it. However, if we used cfdisk, we would just worry about creating six partitions, making sure that the first three are the primary type, and the last three logical.

Note that the names and mount points for these partitions will be assigned during the next step of this process, when you mount the partitions. Write down exactly what partitions you are planning to create because it can otherwise get confusing!

Lunar offers two choices when it comes to swap. You can set up a swap partition, as we have in our example, or you can set up a swapfile in the root directory. We recommend setting up a swap partition, as you will get better performance with it than with the swapfile. However, there may be a need for you to set up the swapfile instead, which can be setup and activated after you have mounted your other partitions.

==Selecting Partitions and Filesystems==

After creating your partitions, you need to select them and assign file systems. Select the menu option "Select Filesystems" and verify that you are indeed done creating partitions.

The partitions can be selected in random order with the new installer. First select the partition and then assign a filesystem and mountpoint to it. The installer will add this to the job queue and formatting and mounting takes place later so you can edit your selection. Here's a list of filesystems that are currently supported:

* ''ext4'' (Fourth Extended File System) -- Version 4 of the Extended File System, which was ... TO BE COMPLETED.
* ''ext3'' (Third Extended File System) -- Version 3 of the Extended File System, which is essentially just the journaled version of ext2. This filesystem is available with all kernels on the ISO.
* ''ext2'' (Second Extended File System) -- Version 2 of the Extended File System, which was designed for linux as a replacement for the Minix Filesystem. Ext2 is not a journaled filesystem, which means that you'll need to perform disc recovery operations after a power failure or other such system crash. This filesystem is available with all kernels on the ISO.
* ''reiserfs'' (Reiser Filesystem) -- Journaled filesystem created by Hans Reiser that is excellent for use with extremely small files. This filesystem is available with all kernels on the ISO.
* ''xfs'' -- Created by SGI for IRIX, SGI's brand of Unix, and later ported to linux under the GPL. A journaled filesystem that SGI claims is better than any other at handling extremely large files and sparse files. This filesystem is only available with the lunar or grsec patched kernels, which we will come to in a few steps.
* ''jfs'' (Journaled File System) -- Created by IBM for AIX, IBM's brand of Unix, and later ported to linux by IBM under the GPL. A journaled filesystem that is very good at handling high throughput issues. This filesystem is available with all kernels on the ISO.
* ''swap'' Swap (Virtual memory or paging filesystem) for swap partitions only!

After selecting the filesystem type you wish to use, you will be prompted through a series of steps to initialize the partition. You'll notice that the prompts are quite redundant in nature in order to be absolutely positive that you will not inadvertantly erase crucial data that you might have on a working filesystem. In addition, if you have more than four partitions, as we do in our example, you don't want to select any file systems on the fourth partition, as it is the extended partition that houses the fifth, sixth (and so on) partitions. (The installer will try to detect this and skip the extended partition from the list).

As we mentioned earlier, there is an option in the installation process to set up a swap file in the root partition instead of a swap partition as we have done in our example. The next option after selecting your filesystems is to select a swapfile if you so desire. <span class="emphasis">''If you have set up a swap partition already, as we have done, you can skip this step.''</span> Otherwise, you can set up your swap file here, and the only thing you need to tell the installer is how large you want the file to be. Running without swap completely is also possible of course.

'''Please note during this step, no modifications are made to your filesystem!'''

==Installing Lunar==

Next, we need to ''format'' your partitions, ''mount'' them in the right place, create ''swap'' and transfer the entire Lunar system to the partitions that you now have created. This happens all in one single step.

Select ''Install Lunar'', and the system will proceed to transfer all of the necessary files for you. The installer will display progress as packages are transferred to your system and you'll have some idea how long it will take. On normal machines, this should take about 5 minutes.

At the end of this step, the installer sets various system parameters like language, timezone and vital package configuration files in order for your machine.

==Setting Up Your Compiler Optimizations==

The compiler optimizations is a crucial step, since what you choose will make your system fly! However, it is important that you do not overdo it on you optimization settings, as certain selections can, in some instances, break code while compiling.

The first step is to choose your preferred compiler. There is only one version on the 1.6.5 ISO, so the only option here is GCC 4.4. However, once the main system installation is complete, it is possible to install GCC 3.x -- and even the deprecated GCC 2.x! If you don't intend to install those, you should go to the GCC_4_4 submenu now and set GCC 4.4 as the default compiler.

The GCC_4_4 menu also allows you to change other options:

* ''safe'' : allows you to turn off optimization safety, so you should leave this well alone unless you really know what you are doing. Turning this off will result in many more options appearing than are described below.
* ''bopt'' : allows you to change the base compile-time optimization. Your choice depends on what your needs are. Most folks will want to use -O2 here, as it is the wisest choice. More advanced users may want to use the -O3 option, but it's not for everyone. If you're short on disk space, you would take the -Os Small option. (As an example, we used -Os for the ISO since we were working within a confined amount of disc space.) Those of you with older or slower systems that wouldn't be able to take advantage of faster optimizations may choose a more conservative setting like -O1. For our example system, we will choose -O2.
* ''cpu'' : allows you to set your processor type. This may seem unimportant, but the GCC 4.x [and GCC 3.x] compiler has ways of optimizing code for certain processors
* ''cc_opt'' : allows you to set some limited C/C++ compiler settings. Very few people, if any, would need to turn off the -pipe option.

The unsafe optimizations are:
* ''xtra'' : CPU extensions
* ''spd'' : Specialized optimizations
* ''fpm'' : Floating point optimizations
* ''stack'' : Stack optimizations

==Adding Other Compiler Toolchain Optimizations==

'''You can safely SKIP this entire step!'''

The GNU_LD menu shows the screen for linker options, where you will find that "-s Strip" has already been checked off. Very few people will want to uncheck this option, so we will leave this screen as is.

The GNU_MAKE menu allows you to set the number of concurrent makes. As the hint mentions on the "Concurrent Makes" screen, you'll want to enter in the number of cpu's your machine has. Unless you have a machine with more than one processor, you'll want to leave this field blank.

We are now finished setting up our GCC optimizations! When you have you lunar system up and running, you can always change and tweak these GCC settings by typing "lunar" at the commandline prompt, and going to "Optimization Settings". In addition, if you aren't that familiar with what your processor is capable of using for optimizations, you can go to the shell out option on the ISO and type

cat /proc/cpuinfo

at the prompt and the system will show you all the optimizations that the processor reports it can handle.

==Configuring Your Bootloader==

=== Configuring LILO ===

If you chose to use lilo and also said yes to automatically configuring and running lilo, then most of the work is done for you. If you chose not to hand edit lilo.conf, however, be warned that the default configuration has the system set up to be password protected on boot. You can change this by selecting the option from the menu "Reconfigure LILO".

To turn off password protection, you will need to comment out (with the symbol "#") or delete two lines in your lilo.conf file. The first is "password=lunar", which is found in the top section of the file, and the other is "restricted" which is found right below the name of your kernel in the second section.

The other item of note is whether you want lilo to reside in your MBR (Master Boot Record) or on the first sector of your /boot partition. The line in your lilo.conf file to edit for this purpose is

boot=/dev/sda1

To make lilo get installed on the first sector of your /boot partition, you would leave this line as it is. If you want lilo to be written to your MBR, which is the recommended method, you would change the line to read

boot=/dev/sda

Of course, these examples are pertinent to our setup that we have been using thoughout this manual. Your actual lilo.conf file may be different.

=== Configuring GRUB ===

If you chose grub as your bootloader, you will need to set up the configuration file entirely on your own. An example would be:

default 0
timeout 30
color white/blue white/black
title linux-2.4.25
root (hd0,0)
kernel /vmlinubz-2.4.25-r5.0.0 root=/dev/sda2 devfs=nomount

As we mentioned earlier in the partitioning section, you would want to mark your /boot partition as active. With grub it is ''imperative'' that you mark your /boot partition as active, otherwise grub will not work at all when you are finished with the installation and reboot to your new system.

NOTE: The option to install grub is not available on the 1.6.5-rc1-x86_64 ISO because grub is not yet fully stable on 64-bit systems. If you really know what you are doing, the source tarball is saved to disk, so you can configure it manually once the main installation is complete.
==Installing kernels==

===Installing a precompiled kernel===

The ISO comes with a selection of precompiled kernels and modules that should work for most people. If you have problems getting your kernel to compile, install or getting the right drivers, or just want to get a quick start at lunar, we ''suggest'' that you use this option instead of compiling your own kernel. You can later of course compile as many kernels as you want, and indeed the first ''lunar update'' after the main installation might ask whether you want to update the kernel too. Why do it twice if you don't need to?

There are several kernels for you to choose from. They are:

* ''2.6.34.1'' -- Normal kernel (SMP, 4GB memory max) (RECOMMENDED).
* ''2.6.34.1-safe'' -- Very safe non-optimized minimal kernel (no ACPI, DMA, SMP, 1GB).
* ''2.6.34.1-server'' -- Server optimized (SELINUX, SMP, 64GB, no preempt).

===Building Your Customized Linux Kernel===

We have now come to the most important part of the installation; the configuration of the kernel. The kernel is the heart of Linux, and without it, nothing would work. Configuration is, actually, a rather simple process. All you need to remember is to not panic, and that lunar is going to do most of the work for you. Here are a few pointers that will make the configuration a breeze for you.

* Help is a click away! The people working on creating and maintaining the Linux kernel have help placed throughout the entire configuration process. If you're not sure what something does, just look at the help file for whatever item you're on, and it will almost certainly explain what it is and what it does. The most handy thing is that every help file will suggest whether you should really use the item or not. Many help files end with "If you're not sure, it is safe to say N here", thus letting you know that it is safe to leave that particular item out of the kernel.
* You can use the ISO kernel! The configuration used to make the kernel for the ISO is the same configuration you'll see when you start your kernel customization. If you leave the configuration the way it is, the only thing you truly have to worry about is your network and, if you want it, sound. There are also two additional default configurations available on the ISO that are available to you called "config.safe" and "config.server". We'll show you how to load these configurations in just a little bit. [TODO: check these files]
* Never build filesystems or core components as modules! Make sure that whatever filesystems you decided to use for your partitions earlier are built into the kernel, and are not separate modules. Likewise, make sure that certain crucial things like ide and scsi drivers are not modules, as this will make your machine unbootable. (This rule doesn't apply to the scsi low level drivers though; they can be modules.) Modules are kernel drivers that can be manually activated and deactivated after the system has been booted, but not during boot time. The kernel from the ISO already has all the filesystems available during the installation built into the kernel, so if you don't change anything there, you will be fine.

You will be shown two screens of information before you actually begin you kernel configuration, letting you know that you are going to need a few things built into the kernel in order to have Lunar run properly, and what options you have for boot loaders. Lunar comes with both lilo (LInux LOader) and grub (GRand Unified Bootloader).

If you don't have much experience with bootloaders, we suggest using lilo for now, as the installation program will set up the configuration file for you. If you would prefer to use grub, and we encourage folks to learn how to use it, be forewarned that the installation program does not set up any configuration at all for you.

[On the 1.6.5-rc1-x86_64 ISO] There is only one kernel available for you to choose from:

* ''linux-2.6.'' -- Latest 2.6 kernel with minor patchlevel patches (2.6.x.Y)

For our example, we are going to use linux-2.6.

Before you begin is which type of configuration method you would like to use.

* ''config'' -- The original way to configure the linux kernel. It is completely text based, and assumes you know what everything is. Unless you've been using linux since its inception, you probably don't want to use this method.
* ''menuconfig'' -- As the name implies, a menu driven version of the kernel configuration. This is the easiest, and by far the most popular way of configurating your kernel.
* ''xconfig'' -- If you have an X server running, you can use this option to configure your kernel using a nifty GUI interface. You won't be able to use this on the ISO, but once your system is up and running with X, you can use this option. If you do choose this option while installing from the ISO, the system will fall back to next available configuration method, in this case menuconfig, so there is no harm in selecting it if you do.

For our example, we are going to use menuconfig. Once Lunar is finished applying the patches for the kernel, which can take a minute or two, you'll be brought to the configuration screen for the linux kernel.

As we mentioned earlier, the configuration that was used to build the kernel for the ISO is the same configuration that you'll be presented with when you start. However, as we also mentioned earlier, there are two alternate kernel configurations available to you that you may want to use; config.safe and config.server. Both of these configurations can be found on the ISO, along with the original default config file, in /etc/lunar/local. When you are looking at the kernel menuconfig main page, scroll all the way to bottom, and you will find an option called "Load an Alternate Configuration File". Select this and then give the absolute path to the alternate configuration file, i.e. /etc/lunar/local/.config.server. As with all kernel configuration files, they are hidden files preceded with a ".", so make sure to not forget it.

Once you have completed configuring your kernel, you'll get one more prompt from the installer asking if you want to go back to the configuration in case you exited by mistake or forgot something. If everything is good to go, say no here and sit back for a few minutes while your kernel compiles.

==Setting Up Networking==

The final step is to set up networking. When you select the "Set Up Networking" option, you'll be prompted by a series of questions as to what kind of card you have (only needed if you built your networking device as a module, and not part of the kernel), if you need to set up wireless or not, and whether you'll need to use dhcp or not. You should be familiar enough with your network to set this up on your own, as the questions put to you are very straightforward.

* if you use dhcp, you don't need to set up the default gateway or DNS because dhcp will take care of them for you.
* you are using a wireless connection with wpa_supplicant, you might want to run "wpa_passphrase" to set up a simple /etc/wpa_supplicant.conf rather than try to edit the example file.

==Other settings==

The installer will prompt you now for some more settings. You should set a root password and generate ssh host keys to identify your box uniquely for later. You might also want to administrate services on the newly installed machine.

==Reboot!==

Once you have completed setting up your networking, you are finished installing Lunar Linux! Congratulations! Select the option "Done" and remove the cd from the drive when it ejects. Your Lunar system is now ready to go!

==Upgrade Moonbase==

After the initial installation and reboot, please follow the instructions given in '''man lfirsttime''' to bring your system up-to-date.

Congratulations! You now have a minimal system as a foundation on which to build.

==KNOWN PROBLEMS==

=== You need to run 'lin linux-2.6' explicitly before running 'lunar update' ===

WARNING: the pre-compiled 2.6.35.3 kernel on the ISO is now out-of-date compared to the ''linux-2.6'' module in the moonbase, but you will
need to build it explicitly using '''lin linux-2.6''' because it won't be rebuilt as part of the first '''lunar update'''. If you didn't
recompile the kernel as part of the ISO installation, or if you experience problems with ALSA or NVIDIA, you should run '''lin linux-2.6'''
to rebuild the kernel explicitly. After you have built the kernel once, '''lunar update''' should then detect and install a newer versions
of the kernel as they become available in the moonbase.

=== configure: error: C compiler cannot create executables ===

WARNING: the ISO installs gcc-4.4 on your system, but gcc-4.5 will be installed as part of the '''man lfirsttime''' and '''lunar update'''
process. You will then need to run '''lunar''', select the '''Options / Optimize Architecture''' menu and set the gcc-4.5 options. Failure
to do so may result in ''"configure: error: C compiler cannot create executables"'' messages when building modules later.

==Where to go from here==
To install a desktop environment check out this page. [[Lunar_Linux:DesktopEnvironments]]

''Have Phun!!''

[http://www.gnu.org/copyleft/ Copyleft] 2004-2010 [http://lunar-linux.org/ The Lunar Penguin Team]

Lunar Installation Manual and Harassment of Lunar Developers by Drew Swayze (drew AT lunar-linux DOT org).

Edits and Nitpicking by Suzanne Burns (sburns AT lunar-linux DOT org).

Initial update for the 1.6.5 ISO by Duncan Gibson (engelsman AT lunar-linux DOT org).

Module Basics

2011-02-20T17:17:34Z

Engelsman: /* The BUILD script */ warning about prepare_install

__TOC__

In ''Lunar'' parlance, software packages are called [[modules]]. The collection of all modules is the [[moonbase]], which is simply a directory (usually <code>/var/lib/lunar/moonbase/</code>) containing ''sections'' (i.e. directories) which in turn contain the [[module]] directories.

A module is simply a directory containing the scripts necessary to build a software package, and optionally configuration files which may be needed in <code>/etc</code>. Some modules require only a [[DETAILS]] file, however this is only the case for a few of the modules in the entire moonbase. In each case, after [[DETAILS]], [[DEPENDS]], and [[CONFIGURE]], where a module can use lunar's default internal function(s), there is no need for a module-specific script.

* [[DETAILS]] sets version, source URL(s) and other critical data
* [[CONFLICTS]] specifies modules which must (will) be removed by module
* [[CONFIGURE]] interactive script where build options can be set
* [[DEPENDS]] specifies required and optional packages
* [[PRE_REMOVE]] used by [[lrm]]; actions which must preceed removal
* [[PRE_BUILD]] most often used for patching, unpacking addional source tarballs
* [[BUILD]] runs necessary variations on: configure; make; make install
* [[POST_BUILD]] install configuration scripts and data.
* [[POST_INSTALL]] messages, notes more cleanups, configuration fixes
* [[POST_REMOVE]] used by [[lrm]]; actions which must follow removal

'''Note:''' modules that require changes for 64-bit systems may also have DETAILS.x86_64, etc.

== Package Build and Install Scripts ==

The following scripts are used by [[Tools:lin|lin]] or indirectly by [[lunar]] when building modules.

=== The DETAILS script ===

Every module is required to have at least a [[DETAILS]] file. A minimal [[DETAILS]] may appear as follows: (<code>/var/lib/lunar/moonbase/editors/emacs/DETAILS</code>)

MODULE=emacs
VERSION=21.3
SOURCE=$MODULE-$VERSION.tar.gz
SOURCE_URL=$GNU_URL/$MODULE
SOURCE_URL=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE</nowiki>
SOURCE_VFY=sha1:94d7ae9cb3aef05159cfff148265fc9ce0973980
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki>
ENTERED=20010922
UPDATED=20020529
SHORT="the extensible, self-documenting real-time display editor"

cat << EOF
Emacs is the extensible, customizable, self-documenting real-time
display editor.
EOF

Other SOURCE_URLS in lunar :
* $GNOME_URL : GNOME mirrors
* $GNU_URL : GNU mirrors
* $KDE_URL : KDE mirrors
* $SFORGE_URL : SourceForge mirrors
* $LRESORT_URL : lunar-linux mirrors
* $XFREE86_URL : XFree86 mirrors
* $XORG_URL : x.org packages mirrors
* $KERNEL_URL : kernel, kernel tools mirrors
* $PATCH_URL : the place for *.patch or *.diff files which are not downloadable from other public hosts.
** See [[Module Guidelines]] about creating patches for use in the BUILD file.
** Such patches may be sent unpacked to Lunar developers mailing list: lunar-dev (at) lunar-linux (dot) org so that a Lunar developer can check it, pack it as *.bz2 archive then upload it to $PATCH_URL server.
** Otherwise it may be copied to the module directory to be included as part of the '''lvu submit'''

The use of _URL mirrors is very important because:
* downloads are faster because mirror is usually very close to user
* if any mirror server fails there is another one on list so user is not left with broken download
* international Internet connections are less blocked

Other optional fields :
* If the application does not compile on more than one thread, add: PSAFE="no" or PSAFE=no
* If the tarball is not extracting into the default $MODULE-$VERSION (e.g. emacs-21.7), add: SOURCE_DIRECTORY=$BUILD_DIRECTORY/"$MODULE"_"$VERSION"_src
* If you want your name in the module and be listed as maintainer and like to be notified when somebody modifies the module, add : MAINTAINER=youremailadress
* If you have more than one SOURCE_URL, list them as: SOURCE_URL=, SOURCE_URL[1]=, SOURCE_URL[2]=, ...
* If you have more than one SOURCE, list them as: SOURCE ,SOURCE2, SOURCE3, ... (don't forget to tell the BUILD script what to do with it...) and add a SOURCE1_URL as well...
* If you want to force lunar to use the gcc4 compiler for this module, add: LUNAR_COMPILER=GCC_4_0 or GCC_3_4 for gcc3

Update the UPDATED field only when you have added something that will change the compile behaviour, updated the version or you added configure options... don't change it just for outlining the DETAILS or BUILD or... file, so in general don't force ppl to recompile if all you did what tweaking around a bit...
* Check [[Module_Guidelines]] for special handling of UPDATED for ''*-cvs'' or ''*-svn'' modules in '''zbeta'''.

The SOURCE_VFY field can be used to check that the downloaded source file has not been corrupted, or changed, since the module was last updated. It should be omitted for modules that download snapshots of sources from svn, cvs, git repositories or similar because the sources could change between downloads.
sha1 checksums are preferred, md5sums can be listed as SOURCE_VFY=md5:

If you find a MAINTAINER field please respect this and notify the person listed there that you will or have updated his module.

With comments, default values:

MODULE=emacs # Module name, yes it's redundant
VERSION=21.3 # Version, changes *often*
SOURCE=$MODULE-$VERSION.tar.gz # Source filename
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$MODULE-$VERSION # Where source unpacks
# ($BUILD_DIRECTORY=/usr/src)
SOURCE_URL[0]=$GNU_URL/$MODULE # Download URL
SOURCE_URL[1]=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE</nowiki> # Alternate URL(s)
SOURCE_VFY=sha1:94d7ae9cb3aef05159cfff148265fc9ce0973980 # Sets sha1 hash or pgp/gpg sig url
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki> # where to learn more
ENTERED=20010922 # First appearance in moonbase
UPDATED=20020529 # Date of latest change.
# Force update by setting this

# The remaining lines are used for input to the 'lvu what' command
# and are best copied from the source-maintainer's own description.

SHORT="the extensible, self-documenting real-time display editor"

cat << EOF
Emacs is the extensible, customizable, self-documenting real-time
display editor.
EOF

=== The DEPENDS script ===

The [[DEPENDS]] script is essential to configuration management, and is the key to the overall operation of lunar. Dependencies should be exactly specified, preferably not assuming the presence of any other modules, while knowing the sub-dependencies of the modules which are added and not adding those explictly where not needed.

'''Warning''' - Getting this right is difficult. Because the state of installed packages may vary widely, it's important to have a good understanding of what might be or not be installed on a target system.

'''Note''' - By convention Lunar does not include the X Window System, xfree86 or XOrg, in any dependency. There are two reasons for this choice. First we expect that users must understand that to use a graphical application locally, the X Window System must be installed. Second, due to the sligtly unusual definition of client and server used by X11, it is often in fact possible to build graphical applications and tools for remote display, without the server components locally installed. At some future date we may elect to provide a client-only installation of xfree86.

[[DEPENDS]] may include both required and optional dependencies. The '''depends()''' function statement simply determines one required package. The optional_depends function is a little more complex. It consists of the required package, necessary --options to give to <code>./configure</code> for yes and no respectively, and an explanatory comment telling the user the purpose of the option being presented. A typical [[DEPENDS]] file might appear as follows: (<code>/var/lib/lunar/moonbase/devel/subversion/DEPENDS</code>)

depends zlib
depends openssl
optional_depends "db4" "--with-berkeley-db" "" "for creating local repositories"
# ^ ^ ^ ^
# | | | |
# optional package if "Y" if "N" explanatory comment
# { ./configure strings }

Many old modules use '&&' in [[DEPENDS]] to be consistent with [[BUILD]] files, but the '&&' delimiter is not required and new [[DEPENDS]] files should not use it.

* '''Important''' - You may not use '''if module_installed...''' or other general bash programming in the [[DEPENDS]] file to handle conditional dependencies. This is to keep the dependency tracking code in the lunar tools as simple and fast as possible.

'''Aliases'''

Aliases are a mean to select a generic module. When you need a functionnality that can be provided by two or more softwares, you can select one of them to provide a correct dependency.

Example /var/lib/lunar/moonbase/aliases:
<code>
%APACHE:apache apache2 apache-mod_ssl
%FAM:fam gamin
%GECKO_RENDERER: firefox thunderbird mozilla
%GHOSTSCRIPT:espgs ghostscript
%MTA:postfix exim sendmail esmtp
%SLANG:slang slang2
%X:XOrg XOrg-test xfree86 xfree86-beta
%XMLRENDERER: libxml2 expat
%XSCREENSAVER:xscreensaver xscreensaver-gtk1 xscreensaver-kde
</code>

For example you can choose %X instead of XOrg in a module that would depends on any X server:
<code>
depends %X
</code>

=== The CONFLICTS script ===

This script is simply used to specify modules which will be removed when a given module is installed. An example would be: (<code>/var/lib/lunar/moonbase/editors/elvis/CONFLICTS</code>)

conflicts vim

=== The CONFIGURE script ===

The [[CONFIGURE]] script is used to collect interactive input from the user on optional parameters for the software build. use the '''query''' function and provide a default answer to each question. The results of the answers are then used to store configuration variables needed in configuration state files. An a simple example might be: (<code>/var/lib/lunar/moonbase/crypto/gnupg/CONFIGURE</code>)

if ! grep -q CONFIGURED $MODULE_CONFIG ; then
if query "Enable experimental external HKP keyserver interface? " n ; then
OPTS="$OPTS --enable-external-hkp"
fi
echo 'CONFIGURED="y"' >> $MODULE_CONFIG
echo 'OPTS='\"$OPTS\" >> $MODULE_CONFIG
fi

Another way is using '''mquery''' like the lilo module does:

mquery RUN_LILO "Run LILO automatically upon LILO upgrades?" y

mquery ENABLE_FOO "Enable foo?" n "--enable-foo --enable-foo2" "--disable-foo --disable-foo2"

Where "No" would be the default answer for the user. When he chooses to enable-foo, then answer "yes" would be stored in the ENABLE_FOO variable and --enable-foo and --enable-foo2 will get added to the ./configure command in the BUILD script.

=== The PRE_BUILD script ===

[[PRE_BUILD]] is used where special processing is needed before undertaking the actual build steps. Typical requirements include unpacking multiple sources, creating necessary system or source-tree direcotries and applying source patches. And example would be: (<code>/var/lib/lunar/moonbase/doc-tools/html2db/PRE_BUILD</code>)

mk_source_dir $SOURCE_DIRECTORY &&
unpack $SOURCE &&
cd $MODULE
unpack $SOURCE2
cd tidy
patch_it $SOURCE_CACHE/$SOURCE3 0
cd /usr/src/$MODULE

=== The BUILD script ===

[[BUILD]] is used where the '''default_build()''' function does not work for a given software package. For reference the commands run by default are:

Function '''default_build()''' calls '''default_config''' which executes:

./configure --build=$BUILD \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--infodir=/usr/share/info \
--mandir=/usr/share/man \
$OPTS

Next, '''default_build()''' calls '''default_make''' which executes:

make &&
prepare_install &&
make install

The '''prepare_install''' should only be called immediately before the '''make install''' phase, so that the package management system only tracks the installed files and not any intermediate build files.

2011-02-20: Be aware that several modules in the moonbase appear to get this wrong, so take care!

If you have modules from git,svn or cvs, the ''configure'' script is missing most of the time. You can then use the ''default_cvs_build()'' function. The commands run are:

./autogen.sh --prefix=/usr

it will then call ''default_make()''

Where this build configuration does not work, the [[BUILD]] script is used to provide the needed steps. About 75% of modules need a [[BUILD]] script. Two examples include: (<code>/var/lib/lunar/moonbase/archive/gzip/BUILD</code>)

(
./configure --build=$BUILD \
--prefix=/usr \
--bindir=/bin \
--infodir=/usr/share/info \
--mandir=/usr/share/man &&
make &&
prepare_install &&
make bindir=/bin install
) > $C_FIFO 2>&1

and: (<code>/var/lib/lunar/moonbase/editors/ex/BUILD</code>)

(
cd $SOURCE_DIRECTORY &&
sedit 's/usr.local/usr/' Makefile &&
sedit 's/= man/= share\/man/' Makefile &&
sedit 's/ucb/bin/' Makefile &&
sedit 's/= termlib/= ncurses/' Makefile &&
make &&
prepare_install &&
make install
) > $C_FIFO 2>&1

The first example is a build which needs non-standard 'configure' and 'make install' commands. The second is a build which does not use gnu auto-tools' 'configure' script.

In the examples above, the [[BUILD]] scripts contain multiple commands separated by '&&' to ensure that execution stops as soon as any command fails. The '&&' are 'and' operations: the command after the '&&' will only be run if the one before the '&&' completed successfully. The use of '&&' is '''required''' in multi-command [[BUILD]] scripts.

'''Note''' - [[BUILD]] scripts must execute inside a (), called a subshell invocation, construct and output is always directed to a named pipe (aka FIFO). Therefor all [[BUILD]] files take the follwing form:

(
# commands are put here
) > $C_FIFO 2>&1 # $C_FIFO holds the name of a fifo in /tmp used for 'voyeur'

=== The POST_BUILD script ===

[[POST_BUILD]] runs in place of the '''default_post_build''' routine which is used to install minor documentation and transfer/enable initialization scripts and similar system data, mostly into <code>/etc</code>.

[[POST_BUILD]] script usage is '''deprecated'''. You should install your config files in [[BUILD]] (remember not to overwrite previous config files!) or install defaults from [[POST_INSTALL]] (again, do not overwrite present files!). The ability to use a [[POST_BUILD]] script is purely for certain internal functions.

=== The POST_INSTALL script ===

[[POST_INSTALL]] has no equivalent functions, and is run to handle post-installation work in a general manner. An example is: (<code>/var/lib/lunar/moonbase/compilers/gcc/POST_INSTALL</code>)

cd /usr/lib/gcc-lib/$BUILD/$VERSION &&
ln -sf /usr/bin/cpp cpp &&
cd /lib/ &&
ln -sf /usr/bin/cpp cpp &&
if [ ! -e /usr/bin/cc ] ; then
ln -s gcc /usr/bin/cc
fi

As in the [[BUILD]] scripts, the '&&' represent 'and' operations, but their use in [[POST_INSTALL]] scripts is '''preferred''' rather than '''required'''.

== Package Removal Scripts ==

Module removal is handled by [[lrm]]. Because installation is monitored and backup tarballs are created using installwatch, most of package removal is handled automatically using the logs created by installwatch. However we provide for additional actions to be taken through the [[PRE_REMOVE]] and [[POST_REMOVE]] scripts.

=== The PRE_REMOVE script ===

[[PRE_REMOVE]] is needed to execute any tasks needed prior to the main task of removing all files installed by the module. An example would be: (<code>/var/lib/lunar/moonbase/mail/docbook-3.1/PRE_REMOVE</code>)

CENTRALIZED=/etc/sgml/catalog
DOCBOOK_INSTALL_DIR=/usr/share/sgml/docbook/$VERSION
install-catalog -r $CENTRALIZED $DOCBOOK_INSTALL_DIR/catalog

=== The POST_REMOVE Script ===

[[POST_REMOVE]] may be used to remove data not tracked by installwatch and to correctly adjust remaining configuration files and data. Examples would include: (<code>/var/lib/lunar/moonbase/devel/binutils/POST_REMOVE</code>)

install-info --delete as --info-dir /usr/info
install-info --delete bfd --info-dir /usr/info
install-info --delete binutils --info-dir /usr/info
install-info --delete configure --info-dir /usr/info
install-info --delete gasp --info-dir /usr/info
install-info --delete gprof --info-dir /usr/info
install-info --delete ld --info-dir /usr/info

or: (<code>/var/lib/lunar/moonbase/compilers/php/POST_REMOVE</code>)

if module_installed apache; then
cp /etc/httpd/httpd.conf /tmp/httpd.conf
grep -v "LoadModule php4_module" /tmp/httpd.conf |
grep -v "AddModule mod_php4.c" > /etc/httpd/httpd.conf
rm -f /tmp/httpd.conf
elif module_installed apache_mod_ssl; then
cp /etc/httpsd/httpd.conf /tmp/httpd.conf
grep -v "LoadModule php4_module" /tmp/httpd.conf |
grep -v "AddModule mod_php4.c" > /etc/httpsd/httpd.conf
rm -f /tmp/httpd.conf
fi

Module Submission for developers

2010-12-02T20:32:38Z

Engelsman: /* Reviewing module submissions */

===Module Submission for developers===

Why and how users should submit modules is described on the [[Module_Submission]] page. This page describes what a developer needs to do to handle these submissions. Or rather, it describes what works for me.

I'm no expert by any means and this is not intended to be a comprehensive guide to git. There is just enough information to get started, and to describe my workflow.

====Developer access====

Before you will be able to save anything back to the central git repository holding the [[Moonbase]], you will obviously need to apply for a username and password on the central machine. You will need to have been a regular, constructive contributor to the [irc://irc.freenode.net/lunar #lunar] IRC channel on [http://freenode.net/ Freenode.net], or the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List] or have successfully submitted modules in the past.

====Cloning your own moonbase.git====

Just like other source code management systems, git uses the concepts of a repository and working files. In the past git has allowed the repository and the working files to exist within the same top level directory structure. It seems that this has lead to some problems, so work is under way to separate out the repository and the working files. At the moment certain operations generate warning messages if you try to save to a combined repository and working directory. In the future you will need to have a "bare" repository and a separate working version. This article describes how to set up and use such a future-proof system.

I don't have a public server of my own on which I can make a repository available for sharing, testing and cherry-picking by others. Therefore I use a multi-stage repository and working directory system. If you have a public server, you may be able to work with just one.

I have three repositories: a remote copy of the main [[Lunar Linux]] [[Moonbase]] repository; a remote working copy; and a local working copy. The first one is optional, but it allows me to share files between the working copies without having to commit them to the main [[Moonbase]] repository first.

First of all I login to the main [[Lunar Linux]] machine, '''doppio''', using ssh, and set two important global git defaults:

doppio$ git config --global user.name "Full Name"
doppio$ git config --global user.email "username@lunar-linux.org"

Then I create the remote "bare" copy of the main [[Moonbase]] repository and configure two useful properties:

doppio$ git clone '''--bare''' git://lunar-linux.org/lunar/moonbase.git moonbase.git
doppio$ git config --get-regexp '^(remote|branch)\.'
doppio$ git config remote.origin.push master:master

Next I create a remote "working" repository that shadows the remote "bare" one, again on '''doppio''':

doppio$ git clone moonbase.git workbase.git
doppio$ cd workbase.git
doppio$ git config --get-regexp '^(remote|branch)\.'
doppio$ git config remote.origin.push master:master

The second git config command tells git that the default action for the "push" command is to push changes from the master branch of the current repository to the master branch of the parent repository. Otherwise you need to provide that information on the command line every time.

I have a local "working" repository on my private machine that also shadows the remote "bare" one. I shall call my local machine '''satellite''' so that it matches the instructions given in [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT With 20 Commands Or So] but see the Note at the end of the section.

satellite$ git config --global user.name "Full Name"
satellite$ git config --global user.email "username@lunar-linux.org"

satellite$ git clone ssh://username@lunar-linux.org/~username/moonbase.git workbase.git
satellite$ cd workbase.git
satellite$ git config --get-regexp '^(remote|branch)\.'
satellite$ git config remote.origin.push master:master

This repository setup allows the following workflow:

* first ensure that the my central repo is up to date:

doppio$ cd moonbase.git
doppio$ git fetch # note: fetch not pull

* then, either work in the remote working directory:

doppio$ cd workbase.git
doppio$ git checkout master
doppio$ git pull
doppio$ git checkout -b testing master
doppio$ ... edit files and commit ...
doppio$ git checkout master
doppio$ git merge testing
doppio$ git branch -D testing
doppio$ git push

* or work on the local working directory:

satellite$ cd workbase.git
satellite$ git checkout master
satellite$ git pull
satellite$ git checkout -b testing master
satellite$ ... edit files and commit ...
satellite$ git checkout master
satellite$ git merge testing
satellite$ git branch -D testing
satellite$ git push

* Finally I can update the central [[Moonbase]] repository, although I'm sure there must be a better way:

doppio$ cd moonbase.git
doppio$ git push /var/git/lunar/moonbase.git master

* I can only share files back and forth between the local and remote working repositories using this method. I can't pull from the working directory on satellite to the working directory on doppio because satellite is private and can only call out. I can't push from the working directory on satellite to the working directory on doppio either because it is not a bare repository.

''Note that [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT...] recommends having the following line instead:

satellite$ git config remote.origin.push master:refs/remotes/satellite/master

but this doesn't work with the bare repository system. Or rather, it does something, but I haven't worked out how to use the information in the remote repository.''

====Reviewing module submissions====

There is a neat script on '''doppio''' called '''review''' that you can use to view and apply the module submission patches directly to the current working copy of '''moonbase.git'''. The '''review''' script assumes that the submitter has already tested the patch and that if it applies cleanly it will be accepted, otherwise it will be rejected. One really cool feature of '''review''' is that the submitter gets the credit in the commit message. Unfortunately, if there are any problems in your working copy of '''moonbase.git''' - and there often were in mine - the script can delete the patch.

By default '''review''' will work through all of the modules in the [http://foo-projects.org/~sofar/queue.php submission queue] so it's best to specify the module that you are interested in. '''review''' will open an editor session containing the module patch file so that you can view the changes, and remove "Subject: " from the subject line and annotate what will become the text of the commit message. After you leave the editor, '''review''' checks whether the patch will apply to the current working copy of '''moonbase.git''' without problems, suggests what should be done with the patch, and waits for your input. If the patch applies cleanly, the default action is to ''accept'' it. You could still ''reject'' it for some other reason; because it does not conform to the [[Module_Guidelines]] for example. If the patch can't be applied - and that might mean that the submission was valid but that a developer has already updated that module in the moonbase - the action is to ''reject'' and another editor session will open so that you can explain why. The two other possible actions are ''defer'' and ''quit''.

You can also use ''/home/engelsman/review.new'' which gives the added option to ''thank'' someone for a submission that was valid but can no longer be applied because another developer has beaten them to it. It's a little less harsh than ''reject''.

doppio$ cd moonbase.git
doppio$ git fetch # make sure we are up to date
doppio$ cd ../workbase.git
doppio$ git pull # make sure working copy is also up to date
doppio$ git checkout -b testing master # create a test branch in case of problems
doppio$ review submitted_module # view patch in editor, then accept,reject,defer,quit

# if accepted:
doppio$ git checkout master # still in workbase.git
doppio$ git merge testing
doppio$ git branch -D testing
doppio$ git push
doppio$ cd ../moonbase.git
doppio$ git push /var/git/lunar/moonbase.git master

# else:
doppio$ git checkout master # still in workbase.git
doppio$ git branch -D testing

If all has gone smoothly, '''git status''' won't show any added, deleted or modified files. Take care to clean up if there are.

====Testing the submission locally before committing====

If you want to be really thorough - or paranoid - you should really check that the patch applies and builds on your own machine first. That takes a little more effort, because you will first need to grab the patch file, apply and test locally:

doppio$ cd moonbase.git
doppio$ git fetch # make sure up to date before pulling working copy

Make sure that your local moonbase is up-to-date before you try dealing with the patch:

satellite$ cd moonbase.git
satellite$ git pull
satellite$ git checkout -b testing master

and then use the method of your choice to grab the patch and apply it:

satellite$ # method 1
satellite$ scp username@doppio.lunar-linux.org:/var/anonymous/submissions/submitted_module.patch /tmp
satellite$ git am /tmp/submitted_module.patch

satellite$ # method 2
satellite$ wget -q <nowiki>"http://foo-projects.org/~sofar/submitted_module.patch"</nowiki> -O - | git am

satellite$ # method 3
satellite$ # browse to "http://foo-projects.org/~sofar/queue.php"
satellite$ # right click on patch and "save link as" /tmp/submitted_module.patch
satellite$ git am /tmp/submitted_module.patch

satellite$ # check '''lin submitted_module''' works as expected

At this point, if you want the submitter to get a feel-good "Your patch was accepted" message:

satellite$ git checkout master
satellite$ git branch -D testing

doppio$ # use '''git''' and '''review''' as described earlier

Otherwise, just continue with the usual git workflow:

satellite$ git checkout master
satellite$ git merge testing
satellite$ git branch -D testing
satellite$ git push

doppio$ cd moonbase.git
doppio$ git merge satellite/testing # see '''git config''' tip earlier
doppio$ git push /var/git/lunar/moonbase.git master
doppio$ review # patch already applied, so use '''review''' thank option

As mentioned earlier, run '''git status''', tidy up if required, and run '''git pull''' again.

===Is there a better way?===

I'm an apprentice rather than a wizard level developer, and I've just about understood git-101, but diagnosing git problems makes my head hurt.

So if you can see a better way of doing things, please add a section at the bottom and describe your workflow.

Module Submission for developers

2010-12-02T20:31:26Z

Engelsman: /* Reviewing module submissions */

===Module Submission for developers===

Why and how users should submit modules is described on the [[Module_Submission]] page. This page describes what a developer needs to do to handle these submissions. Or rather, it describes what works for me.

I'm no expert by any means and this is not intended to be a comprehensive guide to git. There is just enough information to get started, and to describe my workflow.

====Developer access====

Before you will be able to save anything back to the central git repository holding the [[Moonbase]], you will obviously need to apply for a username and password on the central machine. You will need to have been a regular, constructive contributor to the [irc://irc.freenode.net/lunar #lunar] IRC channel on [http://freenode.net/ Freenode.net], or the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List] or have successfully submitted modules in the past.

====Cloning your own moonbase.git====

Just like other source code management systems, git uses the concepts of a repository and working files. In the past git has allowed the repository and the working files to exist within the same top level directory structure. It seems that this has lead to some problems, so work is under way to separate out the repository and the working files. At the moment certain operations generate warning messages if you try to save to a combined repository and working directory. In the future you will need to have a "bare" repository and a separate working version. This article describes how to set up and use such a future-proof system.

I don't have a public server of my own on which I can make a repository available for sharing, testing and cherry-picking by others. Therefore I use a multi-stage repository and working directory system. If you have a public server, you may be able to work with just one.

I have three repositories: a remote copy of the main [[Lunar Linux]] [[Moonbase]] repository; a remote working copy; and a local working copy. The first one is optional, but it allows me to share files between the working copies without having to commit them to the main [[Moonbase]] repository first.

First of all I login to the main [[Lunar Linux]] machine, '''doppio''', using ssh, and set two important global git defaults:

doppio$ git config --global user.name "Full Name"
doppio$ git config --global user.email "username@lunar-linux.org"

Then I create the remote "bare" copy of the main [[Moonbase]] repository and configure two useful properties:

doppio$ git clone '''--bare''' git://lunar-linux.org/lunar/moonbase.git moonbase.git
doppio$ git config --get-regexp '^(remote|branch)\.'
doppio$ git config remote.origin.push master:master

Next I create a remote "working" repository that shadows the remote "bare" one, again on '''doppio''':

doppio$ git clone moonbase.git workbase.git
doppio$ cd workbase.git
doppio$ git config --get-regexp '^(remote|branch)\.'
doppio$ git config remote.origin.push master:master

The second git config command tells git that the default action for the "push" command is to push changes from the master branch of the current repository to the master branch of the parent repository. Otherwise you need to provide that information on the command line every time.

I have a local "working" repository on my private machine that also shadows the remote "bare" one. I shall call my local machine '''satellite''' so that it matches the instructions given in [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT With 20 Commands Or So] but see the Note at the end of the section.

satellite$ git config --global user.name "Full Name"
satellite$ git config --global user.email "username@lunar-linux.org"

satellite$ git clone ssh://username@lunar-linux.org/~username/moonbase.git workbase.git
satellite$ cd workbase.git
satellite$ git config --get-regexp '^(remote|branch)\.'
satellite$ git config remote.origin.push master:master

This repository setup allows the following workflow:

* first ensure that the my central repo is up to date:

doppio$ cd moonbase.git
doppio$ git fetch # note: fetch not pull

* then, either work in the remote working directory:

doppio$ cd workbase.git
doppio$ git checkout master
doppio$ git pull
doppio$ git checkout -b testing master
doppio$ ... edit files and commit ...
doppio$ git checkout master
doppio$ git merge testing
doppio$ git branch -D testing
doppio$ git push

* or work on the local working directory:

satellite$ cd workbase.git
satellite$ git checkout master
satellite$ git pull
satellite$ git checkout -b testing master
satellite$ ... edit files and commit ...
satellite$ git checkout master
satellite$ git merge testing
satellite$ git branch -D testing
satellite$ git push

* Finally I can update the central [[Moonbase]] repository, although I'm sure there must be a better way:

doppio$ cd moonbase.git
doppio$ git push /var/git/lunar/moonbase.git master

* I can only share files back and forth between the local and remote working repositories using this method. I can't pull from the working directory on satellite to the working directory on doppio because satellite is private and can only call out. I can't push from the working directory on satellite to the working directory on doppio either because it is not a bare repository.

''Note that [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT...] recommends having the following line instead:

satellite$ git config remote.origin.push master:refs/remotes/satellite/master

but this doesn't work with the bare repository system. Or rather, it does something, but I haven't worked out how to use the information in the remote repository.''

====Reviewing module submissions====

There is a neat script on '''doppio''' called '''review''' that you can use to view and apply the module submission patches directly to the current working copy of '''moonbase.git'''. The '''review''' script assumes that the submitter has already tested the patch and that if it applies cleanly it will be accepted, otherwise it will be rejected. One really cool feature of '''review''' is that the submitter gets the credit in the commit message. Unfortunately, if there are any problems in your working copy of '''moonbase.git''' - and there often were in mine - the script can delete the patch.

By default '''review''' will work through all of the modules in the [http://foo-projects.org/~sofar/queue.php submission queue] so it's best to specify the module that you are interested in. '''review''' will open an editor session containing the module patch file so that you can view the changes, and remove "Subject: " from the subject line and annotate what will become the text of the commit message. After you leave the editor, '''review''' checks whether the patch will apply to the current working copy of '''moonbase.git''' without problems, suggests what should be done with the patch, and waits for your input. If the patch applies cleanly, the default action is to ''accept'' it. You could still ''reject'' it for some other reason; because it does not conform to the [[Module_Guidelines]] for example. If the patch can't be applied - and that might mean that the submission was valid but that a developer has already updated that module in the moonbase - the action is to ''reject'' and another editor session will open so that you can explain why. The two other possible actions are ''defer'' and ''quit''.

You can also use '''/home/engelsman/review.new''' which gives the added option to ''thank'' someone for a submission that was valid but can no longer be applied because another developer has beaten them to it. It's a little less harsh than ''reject''.

doppio$ cd moonbase.git
doppio$ git fetch # make sure we are up to date
doppio$ cd ../workbase.git
doppio$ git pull # make sure working copy is also up to date
doppio$ git checkout -b testing master # create a test branch in case of problems
doppio$ review submitted_module # view patch in editor, then accept,reject,defer,quit

# if accepted:
doppio$ git checkout master # still in workbase.git
doppio$ git merge testing
doppio$ git branch -D testing
doppio$ git push
doppio$ cd ../moonbase.git
doppio$ git push /var/git/lunar/moonbase.git master

# else:
doppio$ git checkout master # still in workbase.git
doppio$ git branch -D testing

If all has gone smoothly, '''git status''' won't show any added, deleted or modified files. Take care to clean up if there are.

====Testing the submission locally before committing====

If you want to be really thorough - or paranoid - you should really check that the patch applies and builds on your own machine first. That takes a little more effort, because you will first need to grab the patch file, apply and test locally:

doppio$ cd moonbase.git
doppio$ git fetch # make sure up to date before pulling working copy

Make sure that your local moonbase is up-to-date before you try dealing with the patch:

satellite$ cd moonbase.git
satellite$ git pull
satellite$ git checkout -b testing master

and then use the method of your choice to grab the patch and apply it:

satellite$ # method 1
satellite$ scp username@doppio.lunar-linux.org:/var/anonymous/submissions/submitted_module.patch /tmp
satellite$ git am /tmp/submitted_module.patch

satellite$ # method 2
satellite$ wget -q <nowiki>"http://foo-projects.org/~sofar/submitted_module.patch"</nowiki> -O - | git am

satellite$ # method 3
satellite$ # browse to "http://foo-projects.org/~sofar/queue.php"
satellite$ # right click on patch and "save link as" /tmp/submitted_module.patch
satellite$ git am /tmp/submitted_module.patch

satellite$ # check '''lin submitted_module''' works as expected

At this point, if you want the submitter to get a feel-good "Your patch was accepted" message:

satellite$ git checkout master
satellite$ git branch -D testing

doppio$ # use '''git''' and '''review''' as described earlier

Otherwise, just continue with the usual git workflow:

satellite$ git checkout master
satellite$ git merge testing
satellite$ git branch -D testing
satellite$ git push

doppio$ cd moonbase.git
doppio$ git merge satellite/testing # see '''git config''' tip earlier
doppio$ git push /var/git/lunar/moonbase.git master
doppio$ review # patch already applied, so use '''review''' thank option

As mentioned earlier, run '''git status''', tidy up if required, and run '''git pull''' again.

===Is there a better way?===

I'm an apprentice rather than a wizard level developer, and I've just about understood git-101, but diagnosing git problems makes my head hurt.

So if you can see a better way of doing things, please add a section at the bottom and describe your workflow.

Module Submission for developers

2010-12-02T20:17:18Z

Engelsman: /* Testing the submission locally before committing */

===Module Submission for developers===

Why and how users should submit modules is described on the [[Module_Submission]] page. This page describes what a developer needs to do to handle these submissions. Or rather, it describes what works for me.

I'm no expert by any means and this is not intended to be a comprehensive guide to git. There is just enough information to get started, and to describe my workflow.

====Developer access====

Before you will be able to save anything back to the central git repository holding the [[Moonbase]], you will obviously need to apply for a username and password on the central machine. You will need to have been a regular, constructive contributor to the [irc://irc.freenode.net/lunar #lunar] IRC channel on [http://freenode.net/ Freenode.net], or the [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List] or have successfully submitted modules in the past.

====Cloning your own moonbase.git====

Just like other source code management systems, git uses the concepts of a repository and working files. In the past git has allowed the repository and the working files to exist within the same top level directory structure. It seems that this has lead to some problems, so work is under way to separate out the repository and the working files. At the moment certain operations generate warning messages if you try to save to a combined repository and working directory. In the future you will need to have a "bare" repository and a separate working version. This article describes how to set up and use such a future-proof system.

I don't have a public server of my own on which I can make a repository available for sharing, testing and cherry-picking by others. Therefore I use a multi-stage repository and working directory system. If you have a public server, you may be able to work with just one.

I have three repositories: a remote copy of the main [[Lunar Linux]] [[Moonbase]] repository; a remote working copy; and a local working copy. The first one is optional, but it allows me to share files between the working copies without having to commit them to the main [[Moonbase]] repository first.

First of all I login to the main [[Lunar Linux]] machine, '''doppio''', using ssh, and set two important global git defaults:

doppio$ git config --global user.name "Full Name"
doppio$ git config --global user.email "username@lunar-linux.org"

Then I create the remote "bare" copy of the main [[Moonbase]] repository and configure two useful properties:

doppio$ git clone '''--bare''' git://lunar-linux.org/lunar/moonbase.git moonbase.git
doppio$ git config --get-regexp '^(remote|branch)\.'
doppio$ git config remote.origin.push master:master

Next I create a remote "working" repository that shadows the remote "bare" one, again on '''doppio''':

doppio$ git clone moonbase.git workbase.git
doppio$ cd workbase.git
doppio$ git config --get-regexp '^(remote|branch)\.'
doppio$ git config remote.origin.push master:master

The second git config command tells git that the default action for the "push" command is to push changes from the master branch of the current repository to the master branch of the parent repository. Otherwise you need to provide that information on the command line every time.

I have a local "working" repository on my private machine that also shadows the remote "bare" one. I shall call my local machine '''satellite''' so that it matches the instructions given in [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT With 20 Commands Or So] but see the Note at the end of the section.

satellite$ git config --global user.name "Full Name"
satellite$ git config --global user.email "username@lunar-linux.org"

satellite$ git clone ssh://username@lunar-linux.org/~username/moonbase.git workbase.git
satellite$ cd workbase.git
satellite$ git config --get-regexp '^(remote|branch)\.'
satellite$ git config remote.origin.push master:master

This repository setup allows the following workflow:

* first ensure that the my central repo is up to date:

doppio$ cd moonbase.git
doppio$ git fetch # note: fetch not pull

* then, either work in the remote working directory:

doppio$ cd workbase.git
doppio$ git checkout master
doppio$ git pull
doppio$ git checkout -b testing master
doppio$ ... edit files and commit ...
doppio$ git checkout master
doppio$ git merge testing
doppio$ git branch -D testing
doppio$ git push

* or work on the local working directory:

satellite$ cd workbase.git
satellite$ git checkout master
satellite$ git pull
satellite$ git checkout -b testing master
satellite$ ... edit files and commit ...
satellite$ git checkout master
satellite$ git merge testing
satellite$ git branch -D testing
satellite$ git push

* Finally I can update the central [[Moonbase]] repository, although I'm sure there must be a better way:

doppio$ cd moonbase.git
doppio$ git push /var/git/lunar/moonbase.git master

* I can only share files back and forth between the local and remote working repositories using this method. I can't pull from the working directory on satellite to the working directory on doppio because satellite is private and can only call out. I can't push from the working directory on satellite to the working directory on doppio either because it is not a bare repository.

''Note that [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT...] recommends having the following line instead:

satellite$ git config remote.origin.push master:refs/remotes/satellite/master

but this doesn't work with the bare repository system. Or rather, it does something, but I haven't worked out how to use the information in the remote repository.''

====Reviewing module submissions====

There is a neat script on '''doppio''' called '''review''' that you can use to view and apply the module submission patches directly to the current working copy of '''moonbase.git'''. The '''review''' script assumes that the submitter has already tested the patch and that if it applies cleanly it will be accepted, otherwise it will be rejected. One really cool feature of '''review''' is that the submitter gets the credit in the commit message. Unfortunately, if there are any problems in your working copy of '''moonbase.git''' - and there often were in mine - the script can delete the patch.

By default '''review''' will work through all of the modules in the [http://foo-projects.org/~sofar/queue.php submission queue] so it's best to specify the module that you are interested in. '''review''' will open an editor session containing the module patch file so that you can view the changes, and potentially tidy the subject line and annotate what will become the text of the commit message. After you leave the editor, '''review''' checks whether the patch will apply to the current working copy of '''moonbase.git''' without problems, suggests what should be done with the patch, and waits for your input. If the patch applies cleanly, the default action is to ''accept'' it. You could still ''reject'' it for some other reason; because it does not conform to the [[Module_Guidelines]] for example. If the patch can't be applied - and that might mean that the submission was valid but that a developer has already updated that module in the moonbase - the action is to ''reject'' and another editor session will open so that you can explain why. The two other possible actions are ''defer'' and ''quit''.

doppio$ cd moonbase.git
doppio$ git fetch # make sure we are up to date
doppio$ cd ../workbase.git
doppio$ git pull # make sure working copy is also up to date
doppio$ git checkout -b testing master # create a test branch in case of problems
doppio$ review submitted_module # view patch in editor, then accept,reject,defer,quit

# if accepted:
doppio$ git checkout master # still in workbase.git
doppio$ git merge testing
doppio$ git branch -D testing
doppio$ git push
doppio$ cd ../moonbase.git
doppio$ git push /var/git/lunar/moonbase.git master

# else:
doppio$ git checkout master # still in workbase.git
doppio$ git branch -D testing

If all has gone smoothly, '''git status''' won't show any added, deleted or modified files. Take care to clean up if there are.

====Testing the submission locally before committing====

If you want to be really thorough - or paranoid - you should really check that the patch applies and builds on your own machine first. That takes a little more effort, because you will first need to grab the patch file, apply and test locally:

doppio$ cd moonbase.git
doppio$ git fetch # make sure up to date before pulling working copy

Make sure that your local moonbase is up-to-date before you try dealing with the patch:

satellite$ cd moonbase.git
satellite$ git pull
satellite$ git checkout -b testing master

and then use the method of your choice to grab the patch and apply it:

satellite$ # method 1
satellite$ scp username@doppio.lunar-linux.org:/var/anonymous/submissions/submitted_module.patch /tmp
satellite$ git am /tmp/submitted_module.patch

satellite$ # method 2
satellite$ wget -q <nowiki>"http://foo-projects.org/~sofar/submitted_module.patch"</nowiki> -O - | git am

satellite$ # method 3
satellite$ # browse to "http://foo-projects.org/~sofar/queue.php"
satellite$ # right click on patch and "save link as" /tmp/submitted_module.patch
satellite$ git am /tmp/submitted_module.patch

satellite$ # check '''lin submitted_module''' works as expected

At this point, if you want the submitter to get a feel-good "Your patch was accepted" message:

satellite$ git checkout master
satellite$ git branch -D testing

doppio$ # use '''git''' and '''review''' as described earlier

Otherwise, just continue with the usual git workflow:

satellite$ git checkout master
satellite$ git merge testing
satellite$ git branch -D testing
satellite$ git push

doppio$ cd moonbase.git
doppio$ git merge satellite/testing # see '''git config''' tip earlier
doppio$ git push /var/git/lunar/moonbase.git master
doppio$ review # patch already applied, so use '''review''' thank option

As mentioned earlier, run '''git status''', tidy up if required, and run '''git pull''' again.

===Is there a better way?===

I'm an apprentice rather than a wizard level developer, and I've just about understood git-101, but diagnosing git problems makes my head hurt.

So if you can see a better way of doing things, please add a section at the bottom and describe your workflow.

Lunar Linux:Installation/1.6.5

2010-11-27T15:25:31Z

Engelsman: /* Upgrade Moonbase */ - edited known problems

__TOC__

Lunar Linux is a revolutionary Linux distribution in that it is not binary based, as are most distributions, but is instead built entirely by compiling source code, using your own custom optimizations.

Essentially, it installs a complete bootstrap development system on your machine, and then you tell the Lunar package manager what tools you want, and it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward your specific needs.

The result is a leaner, meaner, refreshingly uncluttered, and strikingly faster operating system than most Linux distributions.

This installation guide is designed to get you through the installation process as painlessly as possible. It assumes that you have some experience with Linux or another Unix variant, and have a general idea of what you are doing. If you are unfamiliar with such things as partitions, or have never used Linux before, Lunar may not be the best introduction for you into the world of open source. There are always Lunar gods available on irc.freenode.net in the #lunar channel to answer any questions that this manual may not make quite clear enough.

With that said, we hope you enjoy using Lunar!

==About this installation manual==

Although this manual is not intended to be a full and complete overview of any situation you may be confronted with, given the wide diversity of hardware available these days, it is intended to be an introduction to the world of Lunar Linux. You will see examples that are not tailored towards your to-be built server or workstation, optimizations that are overly broad or too specific, and examples that don't apply to any real situations. We tried hard to give you the idea of how much power you have over how you can setup your system, but we are forgetting to tell you how to run your own server or desktop (or other system) at all. That means that the examples and steps taken most probably do not apply to your situation at all.

Do not despair: if you understand what is going on and you get the idea, the installer will allow you to do pretty much everything you want to do with your system. There are really (almost) no limits.

==Getting the ISO==

The primary site for retrieving the ISO is [http://www.lunar-linux.org/ lunar-linux.org]. There, you will find links to our US, EU, and Internet2 mirrors, as well as a Bittorrent link. As of this writing, the current version of the Lunar ISO is version 1.6.5-rc1, codename Mare Ingenii (20100709). (''Check the main site for the actual latest version!'')

Locate and retrieve the file lunar-1.6.5-rc1-i686.iso.bz2 (or lunar-1.6.5-rc1-x86_64.iso.bz2 if you have a 64-bit system). After downloading this file, you will need to unpack the ISO using bzip2. Windows users will need a program that can extract bzip2 archives, like WinZip (also capable of extracting bzip2 archives under windows are IZarc, Winrar, powerarchiver and 7-Zip). Mac should unzip the file by itself. Then all that is left to do is use your favorite program to burn the ISO to a cdrom and begin the installation. Lunar can also be installed without using a CD. If you need to do it this way, our [[FAQ]] provides simple instructions.

It should be noted that the 1.6.5 ISO and Lunar use udev for device management. The devfs system, and the "old-school" method of manually installing devices, are no longer supported.

We are assuming the you are installing Lunar as your primary OS. Make sure you have a backup of any important data that you need to retain. The Lunar Linux Project and its developers are not responsible in any way for any loss of data on your system!

==Booting the ISO==

Upon booting the ISO, the first thing you will see are options for booting the ISO kernel, or for performing RAM tests [Note: MemTest is not available on x86_64]. There is even a safe mode which will disable DMA, MTRR, RAID, LVM, USB keyboards, NTFS, HPFS, Advanced Partitions, and Firewire. Most folks, however, will be just fine pressing enter at the boot prompt and loading the default kernel.

To boot the iso with support for your usb keyboard:
''linux uhci-hcd ehci-hcd''

After loading the kernel, the first screen presents you with a few options. If there are extra modules you need to load in order continue with the install, they can be loaded here. There is also a shell option. However, if you are using this ISO for rescue purposes, you do not want to shell out here; rather continue booting and shell out in the next section. Most people will select "continue booting" here.

It should be noted that the 1.6.5 ISO tries to autodetect some hardware (mostly scsi drivers and network interfaces) during this stage. This will help you establish a network connection if you desire so during installation. For this reason the programs 'dhcpcd' and 'ftp' are already available at this stage.

==Virtual Consoles==

Once the ISO has booted into the installer, you can immediately shell out or switch to one of the other virtual consoles. These will have ready to go root shells and are available throughout the installer sequence. With these you can start rescue actions, setup networking or double check the install progress and make manual adjustments.

==Language and keyboard interface Settings==

After reading the introduction, you will be presented with options for choosing the proper font, keymap, and language for your install.
You will also need to choose an editor, as you are going to need one later on in the installation for setting up your lilo or grub configuration. The choices available are e3, [e3/emacs], joe, nano, vi, and zile. If you have never used a text editor in Linux before, nano is the best choice for you. If you skip the Native Language Support option, the system will install the default editor, nano, for you. When you have finished setting up your options, press cancel to return to the main setup menu.
Less important for most people is the ability to choose the console font, although it may help display some non-English characters. Most people will want to set the system-default language variable and editor though. All these values are unset by default, so make sure you set them now.
The keymap table allows people to use azerty and dvorak keyboards, and much more. This is especially required for non-English keyboards which provide many accented characters.
All these language and keymap settings might not apply to the lunar code itself, which (currently) does not have any international support, but most programs that run during the installer sequence, and after booting into your new system, will be affected properly.

Warning: the keymap entry appears to default to ANSI-dvorak so make sure that you really select what you want.

==Creating or editing Partitions==

The next step is to set up partitions on your hard drive. Upon selecting the "Partition Drive" option, you will be shown a list of all the discs the kernel has detected. For this guide, we will assume that you have one hard drive connected via an IDE channel, which will show up in the menu as "disc0". After selecting the disc to partition, you are given the option of using one of three partitioning programs. They are:

* cfdisk -- A menu driven partitioner, and very easy to use. If you are unfamiliar with various partitioning programs, this is the best option for you.
* fdisk -- Text based partitioner that requires a little more know-how than cfdisk. More experienced users will probably use this program. However new users should not be daunted, as it does have help offered at every step.
* parted -- Text based partitioner that is good for advanced users. Parted is excellent for resizing current partitions on your hard disk, however be forewarned that resizing partitions is an excellent way to hose your entire disc.

Note: under the <Settings> option on the main menu there is an option to configure the fstab mount style as DEV, LABEL or UUID. The first is the traditional Linux method, but can sometimes give problems if a kernel update causes the disk to be renamed. The default is UUID, which uses a unique marker on the partition to avoid this problem.

For our example, we have a 40GB IDE drive and we'll set up six partitions; /, /boot, /home, /usr, /var, and a swap partition. It's a good idea to keep certain directories, such as /var and /usr on separate partitions, as this can save you a lot of headache in the future in case your disk ever completely fails on you and you need to recover data (God forbid!). Also, when you have a separate /boot partition as we have in our example, you need to have your partitioning program mark that partition as active or bootable. In our example, if we were using fdisk, you would press "a" at the command line, and then select part1 as the active partition.

You might also want to install a /tmp partition. By default, Lunar will create a tempfs filesystem mounted on /tmp (tempfs minimizes filesystem fragmentation because it resides in volatile memory). This can be a good choice if you have a lot of memory on your machine. If memory is tight, we recommend creating a /tmp partition to minimize filesystem fragmentation.

It is important to note that you <span class="emphasis">''can not''</span> mount the directories /etc, /bin, /sbin, /dev, /lib and /proc on separate partitions. These directories need to be contained within the root ("/") directory. The installation program should block you from doing this, but it's best not to try.

Here's our partition setup:

1 /boot 100MB
2 / 4GB
3 swap 1GB
5 /usr 10GB
6 /var 10GB
7 /home 15GB

(''If you're wondering about this choice of partitions: it's really just an example. Read the [[FAQ#So_how_should_I_partition_my_disk.3F|FAQ]] on what makes sense in the real world''))

You'll notice that there is no fourth partition in our list above. In order for you to have more than four partitions on a single drive, the fourth partition is made into what is known as an extended or logical partition in which the fifth, sixth, and seventh (etc, etc) partitions reside. For our example above, if we were using fdisk, we would make the fourth partition an extended/logical partition that was 35GB, and then the fifth, sixth, and seventh partitions in our scheme resided within it. However, if we used cfdisk, we would just worry about creating six partitions, making sure that the first three are the primary type, and the last three logical.

Note that the names and mount points for these partitions will be assigned during the next step of this process, when you mount the partitions. Write down exactly what partitions you are planning to create because it can otherwise get confusing!

Lunar offers two choices when it comes to swap. You can set up a swap partition, as we have in our example, or you can set up a swapfile in the root directory. We recommend setting up a swap partition, as you will get better performance with it than with the swapfile. However, there may be a need for you to set up the swapfile instead, which can be setup and activated after you have mounted your other partitions.

==Selecting Partitions and Filesystems==

After creating your partitions, you need to select them and assign file systems. Select the menu option "Select Filesystems" and verify that you are indeed done creating partitions.

The partitions can be selected in random order with the new installer. First select the partition and then assign a filesystem and mountpoint to it. The installer will add this to the job queue and formatting and mounting takes place later so you can edit your selection. Here's a list of filesystems that are currently supported:

* ''ext4'' (Fourth Extended File System) -- Version 4 of the Extended File System, which was ... TO BE COMPLETED.
* ''ext3'' (Third Extended File System) -- Version 3 of the Extended File System, which is essentially just the journaled version of ext2. This filesystem is available with all kernels on the ISO.
* ''ext2'' (Second Extended File System) -- Version 2 of the Extended File System, which was designed for linux as a replacement for the Minix Filesystem. Ext2 is not a journaled filesystem, which means that you'll need to perform disc recovery operations after a power failure or other such system crash. This filesystem is available with all kernels on the ISO.
* ''reiserfs'' (Reiser Filesystem) -- Journaled filesystem created by Hans Reiser that is excellent for use with extremely small files. This filesystem is available with all kernels on the ISO.
* ''xfs'' -- Created by SGI for IRIX, SGI's brand of Unix, and later ported to linux under the GPL. A journaled filesystem that SGI claims is better than any other at handling extremely large files and sparse files. This filesystem is only available with the lunar or grsec patched kernels, which we will come to in a few steps.
* ''jfs'' (Journaled File System) -- Created by IBM for AIX, IBM's brand of Unix, and later ported to linux by IBM under the GPL. A journaled filesystem that is very good at handling high throughput issues. This filesystem is available with all kernels on the ISO.
* ''swap'' Swap (Virtual memory or paging filesystem) for swap partitions only!

After selecting the filesystem type you wish to use, you will be prompted through a series of steps to initialize the partition. You'll notice that the prompts are quite redundant in nature in order to be absolutely positive that you will not inadvertantly erase crucial data that you might have on a working filesystem. In addition, if you have more than four partitions, as we do in our example, you don't want to select any file systems on the fourth partition, as it is the extended partition that houses the fifth, sixth (and so on) partitions. (The installer will try to detect this and skip the extended partition from the list).

As we mentioned earlier, there is an option in the installation process to set up a swap file in the root partition instead of a swap partition as we have done in our example. The next option after selecting your filesystems is to select a swapfile if you so desire. <span class="emphasis">''If you have set up a swap partition already, as we have done, you can skip this step.''</span> Otherwise, you can set up your swap file here, and the only thing you need to tell the installer is how large you want the file to be. Running without swap completely is also possible of course.

'''Please note during this step, no modifications are made to your filesystem!'''

==Installing Lunar==

Next, we need to ''format'' your partitions, ''mount'' them in the right place, create ''swap'' and transfer the entire Lunar system to the partitions that you now have created. This happens all in one single step.

Select ''Install Lunar'', and the system will proceed to transfer all of the necessary files for you. The installer will display progress as packages are transferred to your system and you'll have some idea how long it will take. On normal machines, this should take about 5 minutes.

At the end of this step, the installer sets various system parameters like language, timezone and vital package configuration files in order for your machine.

==Setting Up Your Compiler Optimizations==

The compiler optimizations is a crucial step, since what you choose will make your system fly! However, it is important that you do not overdo it on you optimization settings, as certain selections can, in some instances, break code while compiling.

The first step is to choose your preferred compiler. There is only one version on the 1.6.5 ISO, so the only option here is GCC 4.4. However, once the main system installation is complete, it is possible to install GCC 3.x -- and even the deprecated GCC 2.x! If you don't intend to install those, you should go to the GCC_4_4 submenu now and set GCC 4.4 as the default compiler.

The GCC_4_4 menu also allows you to change other options:

* ''safe'' : allows you to turn off optimization safety, so you should leave this well alone unless you really know what you are doing. Turning this off will result in many more options appearing than are described below.
* ''bopt'' : allows you to change the base compile-time optimization. Your choice depends on what your needs are. Most folks will want to use -O2 here, as it is the wisest choice. More advanced users may want to use the -O3 option, but it's not for everyone. If you're short on disk space, you would take the -Os Small option. (As an example, we used -Os for the ISO since we were working within a confined amount of disc space.) Those of you with older or slower systems that wouldn't be able to take advantage of faster optimizations may choose a more conservative setting like -O1. For our example system, we will choose -O2.
* ''cpu'' : allows you to set your processor type. This may seem unimportant, but the GCC 4.x [and GCC 3.x] compiler has ways of optimizing code for certain processors
* ''cc_opt'' : allows you to set some limited C/C++ compiler settings. Very few people, if any, would need to turn off the -pipe option.

The unsafe optimizations are:
* ''xtra'' : CPU extensions
* ''spd'' : Specialized optimizations
* ''fpm'' : Floating point optimizations
* ''stack'' : Stack optimizations

==Adding Other Compiler Toolchain Optimizations==

'''You can safely SKIP this entire step!'''

The GNU_LD menu shows the screen for linker options, where you will find that "-s Strip" has already been checked off. Very few people will want to uncheck this option, so we will leave this screen as is.

The GNU_MAKE menu allows you to set the number of concurrent makes. As the hint mentions on the "Concurrent Makes" screen, you'll want to enter in the number of cpu's your machine has. Unless you have a machine with more than one processor, you'll want to leave this field blank.

We are now finished setting up our GCC optimizations! When you have you lunar system up and running, you can always change and tweak these GCC settings by typing "lunar" at the commandline prompt, and going to "Optimization Settings". In addition, if you aren't that familiar with what your processor is capable of using for optimizations, you can go to the shell out option on the ISO and type

cat /proc/cpuinfo

at the prompt and the system will show you all the optimizations that the processor reports it can handle.

==Configuring Your Bootloader==

=== Configuring LILO ===

If you chose to use lilo and also said yes to automatically configuring and running lilo, then most of the work is done for you. If you chose not to hand edit lilo.conf, however, be warned that the default configuration has the system set up to be password protected on boot. You can change this by selecting the option from the menu "Reconfigure LILO".

To turn off password protection, you will need to comment out (with the symbol "#") or delete two lines in your lilo.conf file. The first is "password=lunar", which is found in the top section of the file, and the other is "restricted" which is found right below the name of your kernel in the second section.

The other item of note is whether you want lilo to reside in your MBR (Master Boot Record) or on the first sector of your /boot partition. The line in your lilo.conf file to edit for this purpose is

boot=/dev/sda1

To make lilo get installed on the first sector of your /boot partition, you would leave this line as it is. If you want lilo to be written to your MBR, which is the recommended method, you would change the line to read

boot=/dev/sda

Of course, these examples are pertinent to our setup that we have been using thoughout this manual. Your actual lilo.conf file may be different.

=== Configuring GRUB ===

If you chose grub as your bootloader, you will need to set up the configuration file entirely on your own. An example would be:

default 0
timeout 30
color white/blue white/black
title linux-2.4.25
root (hd0,0)
kernel /vmlinubz-2.4.25-r5.0.0 root=/dev/sda2 devfs=nomount

As we mentioned earlier in the partitioning section, you would want to mark your /boot partition as active. With grub it is ''imperative'' that you mark your /boot partition as active, otherwise grub will not work at all when you are finished with the installation and reboot to your new system.

NOTE: The option to install grub is not available on the 1.6.5-rc1-x86_64 ISO because grub is not yet fully stable on 64-bit systems. If you really know what you are doing, the source tarball is saved to disk, so you can configure it manually once the main installation is complete.
==Installing kernels==

===Installing a precompiled kernel===

The ISO comes with a selection of precompiled kernels and modules that should work for most people. If you have problems getting your kernel to compile, install or getting the right drivers, or just want to get a quick start at lunar, we ''suggest'' that you use this option instead of compiling your own kernel. You can later of course compile as many kernels as you want, and indeed the first ''lunar update'' after the main installation might ask whether you want to update the kernel too. Why do it twice if you don't need to?

There are several kernels for you to choose from. They are:

* ''2.6.34.1'' -- Normal kernel (SMP, 4GB memory max) (RECOMMENDED).
* ''2.6.34.1-safe'' -- Very safe non-optimized minimal kernel (no ACPI, DMA, SMP, 1GB).
* ''2.6.34.1-server'' -- Server optimized (SELINUX, SMP, 64GB, no preempt).

===Building Your Customized Linux Kernel===

We have now come to the most important part of the installation; the configuration of the kernel. The kernel is the heart of Linux, and without it, nothing would work. Configuration is, actually, a rather simple process. All you need to remember is to not panic, and that lunar is going to do most of the work for you. Here are a few pointers that will make the configuration a breeze for you.

* Help is a click away! The people working on creating and maintaining the Linux kernel have help placed throughout the entire configuration process. If you're not sure what something does, just look at the help file for whatever item you're on, and it will almost certainly explain what it is and what it does. The most handy thing is that every help file will suggest whether you should really use the item or not. Many help files end with "If you're not sure, it is safe to say N here", thus letting you know that it is safe to leave that particular item out of the kernel.
* You can use the ISO kernel! The configuration used to make the kernel for the ISO is the same configuration you'll see when you start your kernel customization. If you leave the configuration the way it is, the only thing you truly have to worry about is your network and, if you want it, sound. There are also two additional default configurations available on the ISO that are available to you called "config.safe" and "config.server". We'll show you how to load these configurations in just a little bit. [TODO: check these files]
* Never build filesystems or core components as modules! Make sure that whatever filesystems you decided to use for your partitions earlier are built into the kernel, and are not separate modules. Likewise, make sure that certain crucial things like ide and scsi drivers are not modules, as this will make your machine unbootable. (This rule doesn't apply to the scsi low level drivers though; they can be modules.) Modules are kernel drivers that can be manually activated and deactivated after the system has been booted, but not during boot time. The kernel from the ISO already has all the filesystems available during the installation built into the kernel, so if you don't change anything there, you will be fine.

You will be shown two screens of information before you actually begin you kernel configuration, letting you know that you are going to need a few things built into the kernel in order to have Lunar run properly, and what options you have for boot loaders. Lunar comes with both lilo (LInux LOader) and grub (GRand Unified Bootloader).

If you don't have much experience with bootloaders, we suggest using lilo for now, as the installation program will set up the configuration file for you. If you would prefer to use grub, and we encourage folks to learn how to use it, be forewarned that the installation program does not set up any configuration at all for you.

[On the 1.6.5-rc1-x86_64 ISO] There is only one kernel available for you to choose from:

* ''linux-2.6.'' -- Latest 2.6 kernel with minor patchlevel patches (2.6.x.Y)

For our example, we are going to use linux-2.6.

Before you begin is which type of configuration method you would like to use.

* ''config'' -- The original way to configure the linux kernel. It is completely text based, and assumes you know what everything is. Unless you've been using linux since its inception, you probably don't want to use this method.
* ''menuconfig'' -- As the name implies, a menu driven version of the kernel configuration. This is the easiest, and by far the most popular way of configurating your kernel.
* ''xconfig'' -- If you have an X server running, you can use this option to configure your kernel using a nifty GUI interface. You won't be able to use this on the ISO, but once your system is up and running with X, you can use this option. If you do choose this option while installing from the ISO, the system will fall back to next available configuration method, in this case menuconfig, so there is no harm in selecting it if you do.

For our example, we are going to use menuconfig. Once Lunar is finished applying the patches for the kernel, which can take a minute or two, you'll be brought to the configuration screen for the linux kernel.

As we mentioned earlier, the configuration that was used to build the kernel for the ISO is the same configuration that you'll be presented with when you start. However, as we also mentioned earlier, there are two alternate kernel configurations available to you that you may want to use; config.safe and config.server. Both of these configurations can be found on the ISO, along with the original default config file, in /etc/lunar/local. When you are looking at the kernel menuconfig main page, scroll all the way to bottom, and you will find an option called "Load an Alternate Configuration File". Select this and then give the absolute path to the alternate configuration file, i.e. /etc/lunar/local/.config.server. As with all kernel configuration files, they are hidden files preceded with a ".", so make sure to not forget it.

Once you have completed configuring your kernel, you'll get one more prompt from the installer asking if you want to go back to the configuration in case you exited by mistake or forgot something. If everything is good to go, say no here and sit back for a few minutes while your kernel compiles.

==Setting Up Networking==

The final step is to set up networking. When you select the "Set Up Networking" option, you'll be prompted by a series of questions as to what kind of card you have (only needed if you built your networking device as a module, and not part of the kernel), if you need to set up wireless or not, and whether you'll need to use dhcp or not. You should be familiar enough with your network to set this up on your own, as the questions put to you are very straightforward.

* if you use dhcp, you don't need to set up the default gateway or DNS because dhcp will take care of them for you.
* you are using a wireless connection with wpa_supplicant, you might want to run "wpa_passphrase" to set up a simple /etc/wpa_supplicant.conf rather than try to edit the example file.

==Other settings==

The installer will prompt you now for some more settings. You should set a root password and generate ssh host keys to identify your box uniquely for later. You might also want to administrate services on the newly installed machine.

==Reboot!==

Once you have completed setting up your networking, you are finished installing Lunar Linux! Congratulations! Select the option "Done" and remove the cd from the drive when it ejects. Your Lunar system is now ready to go!

==Upgrade Moonbase==

After the initial installation and reboot, please follow the instructions given in '''man lfirsttime''' to bring your system up-to-date.

Congratulations! You now have a minimal system as a foundation on which to build.

==KNOWN PROBLEMS==

WARNING: the pre-compiled 2.6.35.3 kernel on the ISO is now out-of-date compared to the ''linux-2.6'' module in the moonbase, but you will
need to build it explicitly using '''lin linux-2.6''' because it won't be rebuilt as part of the first '''lunar update'''. If you didn't
recompile the kernel as part of the ISO installation, or if you experience problems with ALSA or NVIDIA, you should run '''lin linux-2.6'''
to rebuild the kernel explicitly. After you have built the kernel once, '''lunar update''' should then detect and install a newer versions
of the kernel as they become available in the moonbase.

WARNING: the ISO installs gcc-4.4 on your system, but gcc-4.5 will be installed as part of the '''man lfirsttime''' and '''lunar update'''
process. You will then need to run '''lunar''', select the '''Options / Optimize Architecture''' menu and set the gcc-4.5 options. Failure
to do so may result in ''"configure: error: C compiler cannot create executables"'' messages when building modules later.

==Where to go from here==
To install a desktop environment check out this page. [[Lunar_Linux:DesktopEnvironments]]

''Have Phun!!''

[http://www.gnu.org/copyleft/ Copyleft] 2004-2010 [http://lunar-linux.org/ The Lunar Penguin Team]

Lunar Installation Manual and Harassment of Lunar Developers by Drew Swayze (drew AT lunar-linux DOT org).

Edits and Nitpicking by Suzanne Burns (sburns AT lunar-linux DOT org).

Initial update for the 1.6.5 ISO by Duncan Gibson (engelsman AT lunar-linux DOT org).

Lunar Linux:Installation/1.6.5

2010-11-24T18:17:02Z

Engelsman: /* Upgrade Moonbase */ - added known problems

__TOC__

Lunar Linux is a revolutionary Linux distribution in that it is not binary based, as are most distributions, but is instead built entirely by compiling source code, using your own custom optimizations.

Essentially, it installs a complete bootstrap development system on your machine, and then you tell the Lunar package manager what tools you want, and it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward your specific needs.

The result is a leaner, meaner, refreshingly uncluttered, and strikingly faster operating system than most Linux distributions.

This installation guide is designed to get you through the installation process as painlessly as possible. It assumes that you have some experience with Linux or another Unix variant, and have a general idea of what you are doing. If you are unfamiliar with such things as partitions, or have never used Linux before, Lunar may not be the best introduction for you into the world of open source. There are always Lunar gods available on irc.freenode.net in the #lunar channel to answer any questions that this manual may not make quite clear enough.

With that said, we hope you enjoy using Lunar!

==About this installation manual==

Although this manual is not intended to be a full and complete overview of any situation you may be confronted with, given the wide diversity of hardware available these days, it is intended to be an introduction to the world of Lunar Linux. You will see examples that are not tailored towards your to-be built server or workstation, optimizations that are overly broad or too specific, and examples that don't apply to any real situations. We tried hard to give you the idea of how much power you have over how you can setup your system, but we are forgetting to tell you how to run your own server or desktop (or other system) at all. That means that the examples and steps taken most probably do not apply to your situation at all.

Do not despair: if you understand what is going on and you get the idea, the installer will allow you to do pretty much everything you want to do with your system. There are really (almost) no limits.

==Getting the ISO==

The primary site for retrieving the ISO is [http://www.lunar-linux.org/ lunar-linux.org]. There, you will find links to our US, EU, and Internet2 mirrors, as well as a Bittorrent link. As of this writing, the current version of the Lunar ISO is version 1.6.5-rc1, codename Mare Ingenii (20100709). (''Check the main site for the actual latest version!'')

Locate and retrieve the file lunar-1.6.5-rc1-i686.iso.bz2 (or lunar-1.6.5-rc1-x86_64.iso.bz2 if you have a 64-bit system). After downloading this file, you will need to unpack the ISO using bzip2. Windows users will need a program that can extract bzip2 archives, like WinZip (also capable of extracting bzip2 archives under windows are IZarc, Winrar, powerarchiver and 7-Zip). Mac should unzip the file by itself. Then all that is left to do is use your favorite program to burn the ISO to a cdrom and begin the installation. Lunar can also be installed without using a CD. If you need to do it this way, our [[FAQ]] provides simple instructions.

It should be noted that the 1.6.5 ISO and Lunar use udev for device management. The devfs system, and the "old-school" method of manually installing devices, are no longer supported.

We are assuming the you are installing Lunar as your primary OS. Make sure you have a backup of any important data that you need to retain. The Lunar Linux Project and its developers are not responsible in any way for any loss of data on your system!

==Booting the ISO==

Upon booting the ISO, the first thing you will see are options for booting the ISO kernel, or for performing RAM tests [Note: MemTest is not available on x86_64]. There is even a safe mode which will disable DMA, MTRR, RAID, LVM, USB keyboards, NTFS, HPFS, Advanced Partitions, and Firewire. Most folks, however, will be just fine pressing enter at the boot prompt and loading the default kernel.

To boot the iso with support for your usb keyboard:
''linux uhci-hcd ehci-hcd''

After loading the kernel, the first screen presents you with a few options. If there are extra modules you need to load in order continue with the install, they can be loaded here. There is also a shell option. However, if you are using this ISO for rescue purposes, you do not want to shell out here; rather continue booting and shell out in the next section. Most people will select "continue booting" here.

It should be noted that the 1.6.5 ISO tries to autodetect some hardware (mostly scsi drivers and network interfaces) during this stage. This will help you establish a network connection if you desire so during installation. For this reason the programs 'dhcpcd' and 'ftp' are already available at this stage.

==Virtual Consoles==

Once the ISO has booted into the installer, you can immediately shell out or switch to one of the other virtual consoles. These will have ready to go root shells and are available throughout the installer sequence. With these you can start rescue actions, setup networking or double check the install progress and make manual adjustments.

==Language and keyboard interface Settings==

After reading the introduction, you will be presented with options for choosing the proper font, keymap, and language for your install.
You will also need to choose an editor, as you are going to need one later on in the installation for setting up your lilo or grub configuration. The choices available are e3, [e3/emacs], joe, nano, vi, and zile. If you have never used a text editor in Linux before, nano is the best choice for you. If you skip the Native Language Support option, the system will install the default editor, nano, for you. When you have finished setting up your options, press cancel to return to the main setup menu.
Less important for most people is the ability to choose the console font, although it may help display some non-English characters. Most people will want to set the system-default language variable and editor though. All these values are unset by default, so make sure you set them now.
The keymap table allows people to use azerty and dvorak keyboards, and much more. This is especially required for non-English keyboards which provide many accented characters.
All these language and keymap settings might not apply to the lunar code itself, which (currently) does not have any international support, but most programs that run during the installer sequence, and after booting into your new system, will be affected properly.

Warning: the keymap entry appears to default to ANSI-dvorak so make sure that you really select what you want.

==Creating or editing Partitions==

The next step is to set up partitions on your hard drive. Upon selecting the "Partition Drive" option, you will be shown a list of all the discs the kernel has detected. For this guide, we will assume that you have one hard drive connected via an IDE channel, which will show up in the menu as "disc0". After selecting the disc to partition, you are given the option of using one of three partitioning programs. They are:

* cfdisk -- A menu driven partitioner, and very easy to use. If you are unfamiliar with various partitioning programs, this is the best option for you.
* fdisk -- Text based partitioner that requires a little more know-how than cfdisk. More experienced users will probably use this program. However new users should not be daunted, as it does have help offered at every step.
* parted -- Text based partitioner that is good for advanced users. Parted is excellent for resizing current partitions on your hard disk, however be forewarned that resizing partitions is an excellent way to hose your entire disc.

Note: under the <Settings> option on the main menu there is an option to configure the fstab mount style as DEV, LABEL or UUID. The first is the traditional Linux method, but can sometimes give problems if a kernel update causes the disk to be renamed. The default is UUID, which uses a unique marker on the partition to avoid this problem.

For our example, we have a 40GB IDE drive and we'll set up six partitions; /, /boot, /home, /usr, /var, and a swap partition. It's a good idea to keep certain directories, such as /var and /usr on separate partitions, as this can save you a lot of headache in the future in case your disk ever completely fails on you and you need to recover data (God forbid!). Also, when you have a separate /boot partition as we have in our example, you need to have your partitioning program mark that partition as active or bootable. In our example, if we were using fdisk, you would press "a" at the command line, and then select part1 as the active partition.

You might also want to install a /tmp partition. By default, Lunar will create a tempfs filesystem mounted on /tmp (tempfs minimizes filesystem fragmentation because it resides in volatile memory). This can be a good choice if you have a lot of memory on your machine. If memory is tight, we recommend creating a /tmp partition to minimize filesystem fragmentation.

It is important to note that you <span class="emphasis">''can not''</span> mount the directories /etc, /bin, /sbin, /dev, /lib and /proc on separate partitions. These directories need to be contained within the root ("/") directory. The installation program should block you from doing this, but it's best not to try.

Here's our partition setup:

1 /boot 100MB
2 / 4GB
3 swap 1GB
5 /usr 10GB
6 /var 10GB
7 /home 15GB

(''If you're wondering about this choice of partitions: it's really just an example. Read the [[FAQ#So_how_should_I_partition_my_disk.3F|FAQ]] on what makes sense in the real world''))

You'll notice that there is no fourth partition in our list above. In order for you to have more than four partitions on a single drive, the fourth partition is made into what is known as an extended or logical partition in which the fifth, sixth, and seventh (etc, etc) partitions reside. For our example above, if we were using fdisk, we would make the fourth partition an extended/logical partition that was 35GB, and then the fifth, sixth, and seventh partitions in our scheme resided within it. However, if we used cfdisk, we would just worry about creating six partitions, making sure that the first three are the primary type, and the last three logical.

Note that the names and mount points for these partitions will be assigned during the next step of this process, when you mount the partitions. Write down exactly what partitions you are planning to create because it can otherwise get confusing!

Lunar offers two choices when it comes to swap. You can set up a swap partition, as we have in our example, or you can set up a swapfile in the root directory. We recommend setting up a swap partition, as you will get better performance with it than with the swapfile. However, there may be a need for you to set up the swapfile instead, which can be setup and activated after you have mounted your other partitions.

==Selecting Partitions and Filesystems==

After creating your partitions, you need to select them and assign file systems. Select the menu option "Select Filesystems" and verify that you are indeed done creating partitions.

The partitions can be selected in random order with the new installer. First select the partition and then assign a filesystem and mountpoint to it. The installer will add this to the job queue and formatting and mounting takes place later so you can edit your selection. Here's a list of filesystems that are currently supported:

* ''ext4'' (Fourth Extended File System) -- Version 4 of the Extended File System, which was ... TO BE COMPLETED.
* ''ext3'' (Third Extended File System) -- Version 3 of the Extended File System, which is essentially just the journaled version of ext2. This filesystem is available with all kernels on the ISO.
* ''ext2'' (Second Extended File System) -- Version 2 of the Extended File System, which was designed for linux as a replacement for the Minix Filesystem. Ext2 is not a journaled filesystem, which means that you'll need to perform disc recovery operations after a power failure or other such system crash. This filesystem is available with all kernels on the ISO.
* ''reiserfs'' (Reiser Filesystem) -- Journaled filesystem created by Hans Reiser that is excellent for use with extremely small files. This filesystem is available with all kernels on the ISO.
* ''xfs'' -- Created by SGI for IRIX, SGI's brand of Unix, and later ported to linux under the GPL. A journaled filesystem that SGI claims is better than any other at handling extremely large files and sparse files. This filesystem is only available with the lunar or grsec patched kernels, which we will come to in a few steps.
* ''jfs'' (Journaled File System) -- Created by IBM for AIX, IBM's brand of Unix, and later ported to linux by IBM under the GPL. A journaled filesystem that is very good at handling high throughput issues. This filesystem is available with all kernels on the ISO.
* ''swap'' Swap (Virtual memory or paging filesystem) for swap partitions only!

After selecting the filesystem type you wish to use, you will be prompted through a series of steps to initialize the partition. You'll notice that the prompts are quite redundant in nature in order to be absolutely positive that you will not inadvertantly erase crucial data that you might have on a working filesystem. In addition, if you have more than four partitions, as we do in our example, you don't want to select any file systems on the fourth partition, as it is the extended partition that houses the fifth, sixth (and so on) partitions. (The installer will try to detect this and skip the extended partition from the list).

As we mentioned earlier, there is an option in the installation process to set up a swap file in the root partition instead of a swap partition as we have done in our example. The next option after selecting your filesystems is to select a swapfile if you so desire. <span class="emphasis">''If you have set up a swap partition already, as we have done, you can skip this step.''</span> Otherwise, you can set up your swap file here, and the only thing you need to tell the installer is how large you want the file to be. Running without swap completely is also possible of course.

'''Please note during this step, no modifications are made to your filesystem!'''

==Installing Lunar==

Next, we need to ''format'' your partitions, ''mount'' them in the right place, create ''swap'' and transfer the entire Lunar system to the partitions that you now have created. This happens all in one single step.

Select ''Install Lunar'', and the system will proceed to transfer all of the necessary files for you. The installer will display progress as packages are transferred to your system and you'll have some idea how long it will take. On normal machines, this should take about 5 minutes.

At the end of this step, the installer sets various system parameters like language, timezone and vital package configuration files in order for your machine.

==Setting Up Your Compiler Optimizations==

The compiler optimizations is a crucial step, since what you choose will make your system fly! However, it is important that you do not overdo it on you optimization settings, as certain selections can, in some instances, break code while compiling.

The first step is to choose your preferred compiler. There is only one version on the 1.6.5 ISO, so the only option here is GCC 4.4. However, once the main system installation is complete, it is possible to install GCC 3.x -- and even the deprecated GCC 2.x! If you don't intend to install those, you should go to the GCC_4_4 submenu now and set GCC 4.4 as the default compiler.

The GCC_4_4 menu also allows you to change other options:

* ''safe'' : allows you to turn off optimization safety, so you should leave this well alone unless you really know what you are doing. Turning this off will result in many more options appearing than are described below.
* ''bopt'' : allows you to change the base compile-time optimization. Your choice depends on what your needs are. Most folks will want to use -O2 here, as it is the wisest choice. More advanced users may want to use the -O3 option, but it's not for everyone. If you're short on disk space, you would take the -Os Small option. (As an example, we used -Os for the ISO since we were working within a confined amount of disc space.) Those of you with older or slower systems that wouldn't be able to take advantage of faster optimizations may choose a more conservative setting like -O1. For our example system, we will choose -O2.
* ''cpu'' : allows you to set your processor type. This may seem unimportant, but the GCC 4.x [and GCC 3.x] compiler has ways of optimizing code for certain processors
* ''cc_opt'' : allows you to set some limited C/C++ compiler settings. Very few people, if any, would need to turn off the -pipe option.

The unsafe optimizations are:
* ''xtra'' : CPU extensions
* ''spd'' : Specialized optimizations
* ''fpm'' : Floating point optimizations
* ''stack'' : Stack optimizations

==Adding Other Compiler Toolchain Optimizations==

'''You can safely SKIP this entire step!'''

The GNU_LD menu shows the screen for linker options, where you will find that "-s Strip" has already been checked off. Very few people will want to uncheck this option, so we will leave this screen as is.

The GNU_MAKE menu allows you to set the number of concurrent makes. As the hint mentions on the "Concurrent Makes" screen, you'll want to enter in the number of cpu's your machine has. Unless you have a machine with more than one processor, you'll want to leave this field blank.

We are now finished setting up our GCC optimizations! When you have you lunar system up and running, you can always change and tweak these GCC settings by typing "lunar" at the commandline prompt, and going to "Optimization Settings". In addition, if you aren't that familiar with what your processor is capable of using for optimizations, you can go to the shell out option on the ISO and type

cat /proc/cpuinfo

at the prompt and the system will show you all the optimizations that the processor reports it can handle.

==Configuring Your Bootloader==

=== Configuring LILO ===

If you chose to use lilo and also said yes to automatically configuring and running lilo, then most of the work is done for you. If you chose not to hand edit lilo.conf, however, be warned that the default configuration has the system set up to be password protected on boot. You can change this by selecting the option from the menu "Reconfigure LILO".

To turn off password protection, you will need to comment out (with the symbol "#") or delete two lines in your lilo.conf file. The first is "password=lunar", which is found in the top section of the file, and the other is "restricted" which is found right below the name of your kernel in the second section.

The other item of note is whether you want lilo to reside in your MBR (Master Boot Record) or on the first sector of your /boot partition. The line in your lilo.conf file to edit for this purpose is

boot=/dev/sda1

To make lilo get installed on the first sector of your /boot partition, you would leave this line as it is. If you want lilo to be written to your MBR, which is the recommended method, you would change the line to read

boot=/dev/sda

Of course, these examples are pertinent to our setup that we have been using thoughout this manual. Your actual lilo.conf file may be different.

=== Configuring GRUB ===

If you chose grub as your bootloader, you will need to set up the configuration file entirely on your own. An example would be:

default 0
timeout 30
color white/blue white/black
title linux-2.4.25
root (hd0,0)
kernel /vmlinubz-2.4.25-r5.0.0 root=/dev/sda2 devfs=nomount

As we mentioned earlier in the partitioning section, you would want to mark your /boot partition as active. With grub it is ''imperative'' that you mark your /boot partition as active, otherwise grub will not work at all when you are finished with the installation and reboot to your new system.

NOTE: The option to install grub is not available on the 1.6.5-rc1-x86_64 ISO because grub is not yet fully stable on 64-bit systems. If you really know what you are doing, the source tarball is saved to disk, so you can configure it manually once the main installation is complete.
==Installing kernels==

===Installing a precompiled kernel===

The ISO comes with a selection of precompiled kernels and modules that should work for most people. If you have problems getting your kernel to compile, install or getting the right drivers, or just want to get a quick start at lunar, we ''suggest'' that you use this option instead of compiling your own kernel. You can later of course compile as many kernels as you want, and indeed the first ''lunar update'' after the main installation might ask whether you want to update the kernel too. Why do it twice if you don't need to?

There are several kernels for you to choose from. They are:

* ''2.6.34.1'' -- Normal kernel (SMP, 4GB memory max) (RECOMMENDED).
* ''2.6.34.1-safe'' -- Very safe non-optimized minimal kernel (no ACPI, DMA, SMP, 1GB).
* ''2.6.34.1-server'' -- Server optimized (SELINUX, SMP, 64GB, no preempt).

===Building Your Customized Linux Kernel===

We have now come to the most important part of the installation; the configuration of the kernel. The kernel is the heart of Linux, and without it, nothing would work. Configuration is, actually, a rather simple process. All you need to remember is to not panic, and that lunar is going to do most of the work for you. Here are a few pointers that will make the configuration a breeze for you.

* Help is a click away! The people working on creating and maintaining the Linux kernel have help placed throughout the entire configuration process. If you're not sure what something does, just look at the help file for whatever item you're on, and it will almost certainly explain what it is and what it does. The most handy thing is that every help file will suggest whether you should really use the item or not. Many help files end with "If you're not sure, it is safe to say N here", thus letting you know that it is safe to leave that particular item out of the kernel.
* You can use the ISO kernel! The configuration used to make the kernel for the ISO is the same configuration you'll see when you start your kernel customization. If you leave the configuration the way it is, the only thing you truly have to worry about is your network and, if you want it, sound. There are also two additional default configurations available on the ISO that are available to you called "config.safe" and "config.server". We'll show you how to load these configurations in just a little bit. [TODO: check these files]
* Never build filesystems or core components as modules! Make sure that whatever filesystems you decided to use for your partitions earlier are built into the kernel, and are not separate modules. Likewise, make sure that certain crucial things like ide and scsi drivers are not modules, as this will make your machine unbootable. (This rule doesn't apply to the scsi low level drivers though; they can be modules.) Modules are kernel drivers that can be manually activated and deactivated after the system has been booted, but not during boot time. The kernel from the ISO already has all the filesystems available during the installation built into the kernel, so if you don't change anything there, you will be fine.

You will be shown two screens of information before you actually begin you kernel configuration, letting you know that you are going to need a few things built into the kernel in order to have Lunar run properly, and what options you have for boot loaders. Lunar comes with both lilo (LInux LOader) and grub (GRand Unified Bootloader).

If you don't have much experience with bootloaders, we suggest using lilo for now, as the installation program will set up the configuration file for you. If you would prefer to use grub, and we encourage folks to learn how to use it, be forewarned that the installation program does not set up any configuration at all for you.

[On the 1.6.5-rc1-x86_64 ISO] There is only one kernel available for you to choose from:

* ''linux-2.6.'' -- Latest 2.6 kernel with minor patchlevel patches (2.6.x.Y)

For our example, we are going to use linux-2.6.

Before you begin is which type of configuration method you would like to use.

* ''config'' -- The original way to configure the linux kernel. It is completely text based, and assumes you know what everything is. Unless you've been using linux since its inception, you probably don't want to use this method.
* ''menuconfig'' -- As the name implies, a menu driven version of the kernel configuration. This is the easiest, and by far the most popular way of configurating your kernel.
* ''xconfig'' -- If you have an X server running, you can use this option to configure your kernel using a nifty GUI interface. You won't be able to use this on the ISO, but once your system is up and running with X, you can use this option. If you do choose this option while installing from the ISO, the system will fall back to next available configuration method, in this case menuconfig, so there is no harm in selecting it if you do.

For our example, we are going to use menuconfig. Once Lunar is finished applying the patches for the kernel, which can take a minute or two, you'll be brought to the configuration screen for the linux kernel.

As we mentioned earlier, the configuration that was used to build the kernel for the ISO is the same configuration that you'll be presented with when you start. However, as we also mentioned earlier, there are two alternate kernel configurations available to you that you may want to use; config.safe and config.server. Both of these configurations can be found on the ISO, along with the original default config file, in /etc/lunar/local. When you are looking at the kernel menuconfig main page, scroll all the way to bottom, and you will find an option called "Load an Alternate Configuration File". Select this and then give the absolute path to the alternate configuration file, i.e. /etc/lunar/local/.config.server. As with all kernel configuration files, they are hidden files preceded with a ".", so make sure to not forget it.

Once you have completed configuring your kernel, you'll get one more prompt from the installer asking if you want to go back to the configuration in case you exited by mistake or forgot something. If everything is good to go, say no here and sit back for a few minutes while your kernel compiles.

==Setting Up Networking==

The final step is to set up networking. When you select the "Set Up Networking" option, you'll be prompted by a series of questions as to what kind of card you have (only needed if you built your networking device as a module, and not part of the kernel), if you need to set up wireless or not, and whether you'll need to use dhcp or not. You should be familiar enough with your network to set this up on your own, as the questions put to you are very straightforward.

* if you use dhcp, you don't need to set up the default gateway or DNS because dhcp will take care of them for you.
* you are using a wireless connection with wpa_supplicant, you might want to run "wpa_passphrase" to set up a simple /etc/wpa_supplicant.conf rather than try to edit the example file.

==Other settings==

The installer will prompt you now for some more settings. You should set a root password and generate ssh host keys to identify your box uniquely for later. You might also want to administrate services on the newly installed machine.

==Reboot!==

Once you have completed setting up your networking, you are finished installing Lunar Linux! Congratulations! Select the option "Done" and remove the cd from the drive when it ejects. Your Lunar system is now ready to go!

==Upgrade Moonbase==

After the initial installation and reboot, please follow the instructions given in '''man lfirsttime''' to bring your system up-to-date.

KNOWN PROBLEMS:

WARNING: the pre-compiled 2.6.35.3 kernel on the ISO is now out-of-date compared to the ''linux-2.6'' module in the moonbase, but you will
need to build it explicitly using '''lin linux-2.6''' because it won't be rebuilt as part of the first '''lunar update'''. If you didn't
recompile the kernel as part of the ISO installation, or if you experience problems with ALSA or NVIDIA, you should run '''lin linux-2.6'''
to rebuild the kernel explicitly. After you have built the kernel once, '''lunar update''' should then detect and install a newer versions
of the kernel as they become available in the moonbase.

WARNING: the ISO installs gcc-4.4 on your system, but gcc-4.5 will be installed as part of the '''man lfirsttime''' and '''lunar update'''
process. You will then need to run '''lunar''', select the '''Options / Optimize Architecture''' menu and set the gcc-4.5 options. Failure
to do so may result in ''"configure: error: C compiler cannot create executables"'' messages when building modules later.

Congratulations! You now have a minimal system as a foundation on which to build.

==Where to go from here==
To install a desktop environment check out this page. [[Lunar_Linux:DesktopEnvironments]]

''Have Phun!!''

[http://www.gnu.org/copyleft/ Copyleft] 2004-2010 [http://lunar-linux.org/ The Lunar Penguin Team]

Lunar Installation Manual and Harassment of Lunar Developers by Drew Swayze (drew AT lunar-linux DOT org).

Edits and Nitpicking by Suzanne Burns (sburns AT lunar-linux DOT org).

Initial update for the 1.6.5 ISO by Duncan Gibson (engelsman AT lunar-linux DOT org).

How long

2010-09-24T21:57:17Z

Engelsman: /* Estimating compile time */

==[[how_long|How long]] does it take...==
* To install a specific module?
* To install the ISO?
* To recompile all my modules?

These questions get asked a lot by new lunar users and it is a very logical question: Lunar is after all a source distro and requires you to compile all the applications from source, which can sometimes take an extremely long time!

===Influencing Factors===

* ''System(CPU) speed''
Double the CPU MHz, and you double the amount of instructions that a system can make per time unit. So, as a rule, a faster CPU results in faster compiles.

* ''Memory size''
Compiling may require large amounts of memory, especially when compiling C++ applications. Generally, a compilation will go 50% faster if you have double the memory. So, if you only have 128MB of memory, you will speed up your compiles by 225% by increasing the amount of memory to 512MB. This might be worth the trip to the hardware store.

* ''Idle time''
Compiling takes a long time. Every second that your system is doing something else, especially interactive tasks, reduces the amount of time that your system can compile applications.

* ''System architecture and components''
Needless to say that a compile on a SATA hard disk is a lot faster than on a ATA-33 system. Especially with larger modules this is a very important factor.

* ''Parallel make jobs''
If you enable multiple parallel make jobs using '''lunar / Options / Optimize Architecture''' and you have a machine with more than one processor or core, most modules will build in a lot less time. Similarly if you have multiple machines and make use of '''distcc''' to share the build processes among your systems.

===Some basic numbers===

The following numbers are from a Pentium 4 system running at 2.9 GHz, with 1 GB of memory, which /proc/cpuinfo rates at 5864 bogomips. This was a fairly normal system back in 2005 and if you wish to compare it with your own system, you should keep in mind that this system might be relatively slower or faster based on the influencing factors mentioned earlier.

The modules listed below are very common modules, so they should give you some good insight in how long it takes to compile and install something. Based on the size you can make rough estimates for new modules that you wish to install.

module source size installed size compile time
gcc 61540 KB 97188 KB 80m35s
glibc 15340 KB 138268 KB 32m47s
gtk+-2 18672 KB 64884 KB 15m56s
perl 14792 KB 56844 KB 9m43s

However, it is not easy to see whether there is any correlation between source size, installed size and compile time from such a small sample. Not all modules are built and installed in the same way. The gcc compiler has a very elaborate bootstrap phase that takes almost half the time it takes to compile the target compiler. The glibc shown here includes all possible locales. gtk+-2 comes with a lot of bitmaps and documentation. Many many module-specific factors are at work here.

===Estimating compile time===

If we plot the compile time against the size of the installed product or the source code size (in compressed form easily available), we get a very loose correlation shown in the graph below, where the straight lines are produced using gnuplot's ''fit'' function:

http://lunar-linux.org/~engelsman/how-long/module-compile-times-raw.jpg

The plot shows that there are an awful lot more small modules than large ones in the 400+ modules installed on this machine, but the range of values obscures any details. If we plot the same basic data using LOG values, we get the following graph:

http://lunar-linux.org/~engelsman/how-long/module-compile-times-log.jpg

As you can see there is a faint correlation possible using either installed size or source size, but it's more interesting to predict compile times based on source size because once we have the installed size we already know the compile time anyway. Where the source size line crosses the x-axis, LOG(Compile time) is 0.0 and LOG(Source size) is almost 3.0, so Compile time is 1s and Source size is approx 20KB! [Note: that's LOG to base e, not LOG to base 10] This gives you a very crude compile speed of 20 KB/s, and allows you to pre-estimate the compile time, assuming that your system is the same speed as my reference system.

In fact, if I divide the total size of all of the sources by the total compile time, the average compile speed is 24.8 KB/s, so the estimate isn't too far off.

===Indexing modules===

We can do some more elaborate math on this and calculate an "index" for all modules. The index of a module could be easily calculated by dividing the actual compile speed for a module by the average compile speed:

gcc - 61520 KB of compressed source code compiled and installed in 80m35s, i.e. speed is 12.7 KB/s and index is 0.51
glibc - 15340 KB of compressed source code compiled and installed in 32m47s, i.e. speed is 7.8 KB/s and index is 0.31
gtk+-2 - 18672 KB of compressed source code compiled and installed in 15m56s, i.e. speed is 19.5 KB/s and index is 0.80
perl - 14792 KB of compressed source code compiled and installed in 9m43s, i.e. speed is 25.4 KB/s and index is 1.02

We could, of course, do this for all modules, but this would involve someone actually downloading and installing every one of them, and this just isn't realistic as there are currently more than 3600 modules in the moonbase. [I tried to download all modules once using '''lget -a''' and it came to 15GB. Using the approximate compile speed of 20KB/s it would take more than 8 days to build everything]

===From ISO install to desktop===

Just out of curiosity, and for information to others, I decided to time how long it took to install a "minimal" desktop system from scratch from the 1.6.5 ISO on a relatively new system and a 9-year-old relic. I might add this 5-year-old box in the future.

It's clear that you probably don't want to install Lunar on really old hardware, unless you have a lot of patience, or can use <code>distcc</code>.

{| border="1"
! System
! CPUs*bogomips [1]
! RAM
! Disk [2]
! Install
! lin gcc...
! lin linux-2.6
! lunar update
! lin XOrg7
! lin xfce4
! TOTAL
|- align="center"
| Acer AX5810
| 4 * 4988
| 6 Gb
| 1681 / 129 MB/s
| 0h11
| 1h01
| 0h12
| 0h20
| 0h23
| 0h14
! 2h21
|- align="center"
| Vaio FX401
| 1 * 1600
| 512Mb
| 179 / 17 MB/s
| 0h18
| 11h26
| 3h37
| 2h44
| 3h12
| 2h15
! 23h32
|}

# <code>grep bogomips /proc/cpuinfo</code>
# <code>hdparm -t -T /dev/sdX</code>

The basic procedure:
* install from the ISO, and take the pre-compiled kernel, and reboot
* run <code>lin moonbase</code>
* run <code>lunar</code> and set number of parallel makes to 4 in ''Options / Optimize Architecture''
* do the <code>lin gcc glibc gcc bash coreutils tar wget</code> dance from <code>man lfirsttime</code>
* use <code>lin linux-2.6</code> to explicitly build a new kernel, and reboot
* run <code>lunar update</code> to rebuild any outdated parts of the core system
* run <code>lin XOrg7</code> to build X
* run <code>lin xfce4</code> to build Xfce4

After the first reboot I primed the system by copying sources from /var/spool/lunar on another up-to-date machine to avoid download delays and glitches.

When asked questions about optional depends, etc. I simply hit return to accept the default values. I did not reconfigure the kernel. I used <code>lin --deps</code> for the XOrg7 and xfce4 builds to pre-answer the questions before kicking off the real builds so I could leave them unattended without adding delays for prompts to timeout.

NOTE: this procedure is for timing purposes only, I still have to go back and install the correct drivers for X, etc.

How long

2010-09-24T18:27:10Z

Engelsman: updated index section and added ISO to desktop timings

==[[how_long|How long]] does it take...==
* To install a specific module?
* To install the ISO?
* To recompile all my modules?

These questions get asked a lot by new lunar users and it is a very logical question: Lunar is after all a source distro and requires you to compile all the applications from source, which can sometimes take an extremely long time!

===Influencing Factors===

* ''System(CPU) speed''
Double the CPU MHz, and you double the amount of instructions that a system can make per time unit. So, as a rule, a faster CPU results in faster compiles.

* ''Memory size''
Compiling may require large amounts of memory, especially when compiling C++ applications. Generally, a compilation will go 50% faster if you have double the memory. So, if you only have 128MB of memory, you will speed up your compiles by 225% by increasing the amount of memory to 512MB. This might be worth the trip to the hardware store.

* ''Idle time''
Compiling takes a long time. Every second that your system is doing something else, especially interactive tasks, reduces the amount of time that your system can compile applications.

* ''System architecture and components''
Needless to say that a compile on a SATA hard disk is a lot faster than on a ATA-33 system. Especially with larger modules this is a very important factor.

* ''Parallel make jobs''
If you enable multiple parallel make jobs using '''lunar / Options / Optimize Architecture''' and you have a machine with more than one processor or core, most modules will build in a lot less time. Similarly if you have multiple machines and make use of '''distcc''' to share the build processes among your systems.

===Some basic numbers===

The following numbers are from a Pentium 4 system running at 2.9 GHz, with 1 GB of memory, which /proc/cpuinfo rates at 5864 bogomips. This was a fairly normal system back in 2005 and if you wish to compare it with your own system, you should keep in mind that this system might be relatively slower or faster based on the influencing factors mentioned earlier.

The modules listed below are very common modules, so they should give you some good insight in how long it takes to compile and install something. Based on the size you can make rough estimates for new modules that you wish to install.

module source size installed size compile time
gcc 61540 KB 97188 KB 80m35s
glibc 15340 KB 138268 KB 32m47s
gtk+-2 18672 KB 64884 KB 15m56s
perl 14792 KB 56844 KB 9m43s

However, it is not easy to see whether there is any correlation between source size, installed size and compile time from such a small sample. Not all modules are built and installed in the same way. The gcc compiler has a very elaborate bootstrap phase that takes almost half the time it takes to compile the target compiler. The glibc shown here includes all possible locales. gtk+-2 comes with a lot of bitmaps and documentation. Many many module-specific factors are at work here.

===Estimating compile time===

If we plot the compile time against the size of the installed product or the source code size (in compressed form easily available), we get a very loose correlation shown in the graph below, where the straight lines are produced using gnuplot's ''fit'' function:

http://lunar-linux.org/~engelsman/how-long/module-compile-times-raw.jpg

The plot shows that there are an awful lot more small modules than large ones in the 400+ modules installed on this machine, but the range of values obscures any details. If we plot the same basic data using LOG values, we get the following graph:

http://lunar-linux.org/~engelsman/how-long/module-compile-times-raw.jpg

As you can see there is a faint correlation possible using either installed size or source size, but it's more interesting to predict compile times based on source size because once we have the installed size we already know the compile time anyway. Where the source size line crosses the x-axis, LOG(Compile time) is 0.0 and LOG(Source size) is almost 3.0, so Compile time is 1s and Source size is approx 20KB! [Note: that's LOG to base e, not LOG to base 10] This gives you a very crude compile speed of 20 KB/s, and allows you to pre-estimate the compile time, assuming that your system is the same speed as my reference system.

In fact, if I divide the total size of all of the sources by the total compile time, the average compile speed is 24.8 KB/s, so the estimate isn't too far off.

===Indexing modules===

We can do some more elaborate math on this and calculate an "index" for all modules. The index of a module could be easily calculated by dividing the actual compile speed for a module by the average compile speed:

gcc - 61520 KB of compressed source code compiled and installed in 80m35s, i.e. speed is 12.7 KB/s and index is 0.51
glibc - 15340 KB of compressed source code compiled and installed in 32m47s, i.e. speed is 7.8 KB/s and index is 0.31
gtk+-2 - 18672 KB of compressed source code compiled and installed in 15m56s, i.e. speed is 19.5 KB/s and index is 0.80
perl - 14792 KB of compressed source code compiled and installed in 9m43s, i.e. speed is 25.4 KB/s and index is 1.02

We could, of course, do this for all modules, but this would involve someone actually downloading and installing every one of them, and this just isn't realistic as there are currently more than 3600 modules in the moonbase. [I tried to download all modules once using '''lget -a''' and it came to 15GB. Using the approximate compile speed of 20KB/s it would take more than 8 days to build everything]

===From ISO install to desktop===

Just out of curiosity, and for information to others, I decided to time how long it took to install a "minimal" desktop system from scratch from the 1.6.5 ISO on a relatively new system and a 9-year-old relic. I might add this 5-year-old box in the future.

It's clear that you probably don't want to install Lunar on really old hardware, unless you have a lot of patience, or can use <code>distcc</code>.

{| border="1"
! System
! CPUs*bogomips [1]
! RAM
! Disk [2]
! Install
! lin gcc...
! lin linux-2.6
! lunar update
! lin XOrg7
! lin xfce4
! TOTAL
|- align="center"
| Acer AX5810
| 4 * 4988
| 6 Gb
| 1681 / 129 MB/s
| 0h11
| 1h01
| 0h12
| 0h20
| 0h23
| 0h14
! 2h21
|- align="center"
| Vaio FX401
| 1 * 1600
| 512Mb
| 179 / 17 MB/s
| 0h18
| 11h26
| 3h37
| 2h44
| 3h12
| 2h15
! 23h32
|}

# <code>grep bogomips /proc/cpuinfo</code>
# <code>hdparm -t -T /dev/sdX</code>

The basic procedure:
* install from the ISO, and take the pre-compiled kernel, and reboot
* run <code>lin moonbase</code>
* run <code>lunar</code> and set number of parallel makes to 4 in ''Options / Optimize Architecture''
* do the <code>lin gcc glibc gcc bash coreutils tar wget</code> dance from <code>man lfirsttime</code>
* use <code>lin linux-2.6</code> to explicitly build a new kernel, and reboot
* run <code>lunar update</code> to rebuild any outdated parts of the core system
* run <code>lin XOrg7</code> to build X
* run <code>lin xfce4</code> to build Xfce4

After the first reboot I primed the system by copying sources from /var/spool/lunar on another up-to-date machine to avoid download delays and glitches.

When asked questions about optional depends, etc. I simply hit return to accept the default values. I did not reconfigure the kernel. I used <code>lin --deps</code> for the XOrg7 and xfce4 builds to pre-answer the questions before kicking off the real builds so I could leave them unattended without adding delays for prompts to timeout.

NOTE: this procedure is for timing purposes only, I still have to go back and install the correct drivers for X, etc.

How long

2010-09-22T23:27:54Z

Engelsman: update for new sizes, times and graphs

==[[how_long|How long]] does it take...==
* To install a specific module?
* To install the ISO?
* To recompile all my modules?

These questions get asked a lot by new lunar users and it is a very logical question: Lunar is after all a source distro and requires you to compile all the applications from source, which can sometimes take an extremely long time!

===Influencing Factors===

* ''System(CPU) speed''
Double the CPU MHz, and you double the amount of instructions that a system can make per time unit. So, as a rule, a faster CPU results in faster compiles.

* ''Memory size''
Compiling may require large amounts of memory, especially when compiling C++ applications. Generally, a compilation will go 50% faster if you have double the memory. So, if you only have 128MB of memory, you will speed up your compiles by 225% by increasing the amount of memory to 512MB. This might be worth the trip to the hardware store.

* ''Idle time''
Compiling takes a long time. Every second that your system is doing something else, especially interactive tasks, reduces the amount of time that your system can compile applications.

* ''System architecture and components''
Needless to say that a compile on a SATA hard disk is a lot faster than on a ATA-33 system. Especially with larger modules this is a very important factor.

* ''Parallel make jobs''
If you enable multiple parallel make jobs using '''lunar / Options / Optimize Architecture''' and you have a machine with more than one processor or core, most modules will build in a lot less time. Similarly if you have multiple machines and make use of '''distcc''' to share the build processes among your systems.

===Some basic numbers===

The following numbers are from a Pentium 4 system running at 2.9 GHz, with 1 GB of memory, which /proc/cpuinfo rates at 5864 bogomips. This was a fairly normal system back in 2005 and if you wish to compare it with your own system, you should keep in mind that this system might be relatively slower or faster based on the influencing factors mentioned earlier.

The modules listed below are very common modules, so they should give you some good insight in how long it takes to compile and install something. Based on the size you can make rough estimates for new modules that you wish to install.

module source size installed size compile time
gcc 61540 KB 97188 KB 80m35s
glibc 15340 KB 138268 KB 32m47s
gtk+-2 18672 KB 64884 KB 15m56s
perl 14792 KB 56844 KB 9m43s

However, it is not easy to see whether there is any correlation between source size, installed size and compile time from such a small sample. Not all modules are built and installed in the same way. The gcc compiler has a very elaborate bootstrap phase that takes almost half the time it takes to compile the target compiler. The glibc shown here includes all possible locales. gtk+-2 comes with a lot of bitmaps and documentation. Many many module-specific factors are at work here.

===Estimating compile time===

If we plot the compile time against the size of the installed product or the source code size (in compressed form easily available), we get a very loose correlation shown in the graph below, where the straight lines are produced using gnuplot's ''fit'' function:

http://lunar-linux.org/~engelsman/how-long/module-compile-times-raw.jpg

The plot shows that there are an awful lot more small modules than large ones in the 400+ modules installed on this machine, but the range of values obscures any details. If we plot the same basic data using LOG values, we get the following graph:

http://lunar-linux.org/~engelsman/how-long/module-compile-times-raw.jpg

As you can see there is a faint correlation possible using either installed size or source size, but it's more interesting to predict compile times based on source size because once we have the installed size we already know the compile time anyway. Where the source size line crosses the x-axis, LOG(Compile time) is 0.0 and LOG(Source size) is almost 3.0, so Compile time is 1s and Source size is approx 20KB! This gives you a very crude compile speed, and allows you to pre-estimate the compile time, assuming that your system is the same speed as my reference system.

We can do some more elaborate math on this and calculate the "index" for all modules. The index of a module would be easily calculated by the amount of time it took for lunar to compile and install 10kB of compressed source code. So we divide the total compile/install time (seconds) by the number of kilobytes that the compressed source package was:

gcc took 80m35s to compile + install 61520 KB of compressed source code, i.e. approx 13 KB/s
glibc took 32m47s to compile + install 15340 KB of compressed source code, i.e. approx 8 KB/s
gtk+-2 took 15m56s to compile + install 18672 KB of compressed source code, i.e. approx 19 KB/s
perl took 9m43s to compile + install 14792 KB of compressed source code, i.e. approx 25 KB/s

TO BE UPDATED...
If we do this for all modules we end up with the average index of about 27, which means that on average, lunar compiles and installs 27kB of compressed source code per second. Since the size of my /var/spool/lunar is about 1.4gB, it would take me about 51851 seconds to compile and install all of this source code files. That's about 14.5 hours! Of course that number really is not right - we haven't taken into account that larger modules might have a lower index and thus take much longer to compile.

===Indexing modules===

We should be able to index the numbers of all modules right now, so it pays off to pay a closer look at the numbers a bit. Most importantly, the 27 index is averaged across all modules, but we know that this number is off for bigger modules. For modules larger than 100kB source size, it's already 32, and for modules over 1000kB, it's up to 52. This seriously changes perspective and shows you that smaller modules take relatively longer to install, and this is not surprising: the overhead is usually much larger for them, as all the autoconf and administrativa needs to be performed for smaller modules as well.

User talk:Engelsman

2010-09-18T23:18:56Z

Engelsman: /* 1.6.5 Installation Times */

__TOC__

<p>I have moved the original contents of this page elsewhere, reformatting and updating on the way.
However, I have provided so many references to this page in the
[http://forums.lunar-linux.org Lunar Forums] that I can't remove it completely, and so I leave a skeleton to show the way, just like Billy Bones in Treasure Island.
</p>

<p>Please follow the appropriate link to the updated page.
</p>

==A Newbie's experience installing, and upgrading, Lunar Linux 1.5.1==
<p>I started using Unix V7 on a PDP-11/70 back in 1983, even modifying some existing kernel drivers for the [http://en.wikipedia.org/wiki/Cambridge_Ring Cambridge Ring] local area network. After that I dabbled in system administration of various Sun and Apollo systems until 1991, and HP boxes up until 2000, but my main task has always been application software development, nothing on the hardware or kernel side. Since 2000 we've had dedicated system administrators at work. We had switched from NCD X-terminals over to Linux desktops (first RedHat, but then Lunar) and I realized that what little I knew had become well out of date. I installed RedHat on an old 90MHz PC at home more than five years ago, but without a LAN or modem connection it was too difficult to keep up to date, I lost interest, and that died. Since then I've had an itch to develop a spiffy [http://www.fltk.org FLTK] user interace for some old command line tools using Cygwin/Mingw on a WinXP laptop (with modem) but the machine is (a) painfully slow, and (b) painfully Windows. The time had come to get some new hardware, install an operating system that doesn't thwart you at every turn, and set up a programming environment of my own choice.
[[User Reports:Engelsman|Read more]]...
</p>

==Installing Lunar Linux 1.6.0 (coming soon, maybe)==
<p>In April 2006, the
[http://www.lunar-linux.org/index.php?option=com_content&task=view&id=39&Itemid=2 Lunar-1.6.0-i686 ISO] was released,
but I don't have enough spare time to look at installing it. Not just yet anyway.
</p>

==Installing Lunar Linux 1.6.4 (Lacus Autumni)==
<p>Lunar Linux 1.6.4 (Lacus Autumni) was [http://foo-projects.org/pipermail/lunar/2008-December/008144.html announced] in December 2008, and installation and update was initially pretty smooth and uneventful. But as 2009 rolled on, and new versions of certain key modules were rolled out and were out of step with each other, upgrading from the 1.6.4 ISO became difficult. Here's the [http://foo-projects.org/pipermail/lunar-dev/2009-September/006906.html Update Workaround HOWTO] that I put together in September. This is no longer required! Soon after this, other key module releases brought harmony again, and these instructions became obsolete.</p>
<p>In February 2010, with the 2.6.32.8 kernel, updating udev from 141 to 151 caught me out. I don't remember the exact wording, but udev-151 requires that SYSFS_DEPRECATED is disabled in the kernel configuration. Finding SYSFS_DEPRECATED_V2 in the kernel didn't take long, but it took a lot longer to track down that GFS_FS also needed to be disabled...</p>
<p>Also in February 2010, installed 1.6.4 on a new Acer-AX5810 box with NVIDIA GeForce G210 card. This obviously requires the some kernel settings, and to install the NVIDIA module. All well and good, but after every kernel update and reboot you need to '''lrm NVIDIA''', and then '''lin -rc NVIDIA''' again otherwise it won't install properly. This has bitten me several times after a '''lunar update'''...</p>

==Installing Lunar Linux 1.6.5 (Mare Ingenii)==
After corruption of the superblock on my /boot partition on an HP Pavilion t3190(?), I decided to installed the 1.6.5-beta1 ISO. The initial installation and update went without problem. XOrg7 appeared to install OK, but when I ran 'startx' the console went blank. Searching the web, and asking on #lunar revealed that I needed the i915 driver for my Intel graphics card, with an entry in /etc/modules for 'i915 modeset=1'. Close, but no cigar! That's when my troubles started, with the console going into powersave mode on reboot. After much trial and error, I discovered that the kernel requires:

CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
CONFIG_FRAMEBUFFER_CONSOLE=m

The first would imply having i915 in /etc/modules, but in fact it is trumped by the second, and you don't need the i915 module at all. But the KMS line also enables ACPI in the kernel, which causes the console blanking. To solve that problem, you do need to have fbcon in /etc/modules. Or to disable the powersave mode settings while you configure all of this, you need a lilo.conf entry such as the following

image = /boot/2.6.32.9-i686
label = 2.6.32.9-acpi
append="acpi=off"

At a certain point, there was an update to the linux-2.6 module that took it from 2.6.33.4 to 2.6.34.1, which I duly installed on my new test box, only to find that I couldn't reboot. The previous kernels had identified the disk as /dev/sda, but the new kernel decided it was /dev/sdb instead. This could be overcome by adding 'root=/dev/sdb3' on the lilo boot line, but then gave problems with /etc/fstab. To cut a long story short, I rebooted to the old kernel and changed /dev/fstab to use UUID instead. To find/create the UUIDs:

tune2fs -l /dev/sda1
swapoff -a # I'm lazy
mkswap /dev/sda2 # mkswap creates with UUID by default
swapon -a
tune2fs -l /dev/sda3

I even updated /etc/lilo.conf to add an 'append="root=/dev/sdb3"' for the 2.6.34.1 entry, and I could reboot, *and* mount the file systems.

Soon after this the 1.6.5-rc1 ISO was released, and as this was a test box anyway, with nothing really installed on it except for gnome test system that was inconsistent and didn't work, I wiped the system and re-installed from scratch.

===1.6.5 Installation Times===

Just out of curiosity, and for information to others, I decided to time how long it took to install a "minimal" desktop system from scratch
on a relatively new system and a 9-year-old relic. I have two 5-year-old boxes I might add in the future.

It's clear that you probably don't want to install Lunar on really old hardware, unless you have a lot of patience, or can use <code>distcc</code>.

{| border="1"
! System
! CPUs*bogomips [1]
! RAM
! Disk [2]
! Install
! lin gcc...
! lin linux-2.6
! lunar update
! lin XOrg7
! lin xfce4
! TOTAL
|- align="center"
| Acer AX5810
| 4 * 4988
| 6 Gb
| 1681 / 129 MB/s
| 0h11
| 1h01
| 0h12
| 0h20
| 0h23
| 0h14
! 2h21
|- align="center"
| Vaio FX401
| 1 * 1600
| 512Mb
| 179 / 17 MB/s
| 0h18
| 11h26
| 3h37
| 2h44
| 3h12
| 2h15
! 23h32
|}

# <code>grep bogomips /proc/cpuinfo</code>
# <code>hdparm -t -T /dev/sdX</code>

The basic procedure:
* install from the ISO, and take the pre-compiled kernel, and reboot
* run <code>lin moonbase</code>
* run <code>lunar</code> and set number of parallel makes to 4 in ''Options / Optimize Architecture''
* do the <code>lin gcc glibc gcc bash coreutils tar wget</code> dance from <code>man lfirsttime</code>
* use <code>lin linux-2.6</code> to explicitly build a new kernel, and reboot
* run <code>lunar update</code> to rebuild any outdated parts of the core system
* run <code>lin XOrg7</code> to build X
* run <code>lin xfce4</code> to build Xfce4

After the first reboot I primed the system by copying sources from /var/spool/lunar on another up-to-date machine to avoid download delays and glitches.

When asked questions about optional depends, etc. I simply hit return to accept the default values. I did not reconfigure the kernel. I used <code>lin --deps</code> for the XOrg7 and xfce4 builds to pre-answer the questions before kicking off the real builds so I could leave them unattended without adding delays for prompts to timeout.

NOTE: this procedure is for timing purposes only, I still have to go back and install the correct drivers for X, etc.

'''To be continued...'''

User talk:Engelsman

2010-09-18T18:12:09Z

Engelsman: minor reformatting

__TOC__

<p>I have moved the original contents of this page elsewhere, reformatting and updating on the way.
However, I have provided so many references to this page in the
[http://forums.lunar-linux.org Lunar Forums] that I can't remove it completely, and so I leave a skeleton to show the way, just like Billy Bones in Treasure Island.
</p>

<p>Please follow the appropriate link to the updated page.
</p>

==A Newbie's experience installing, and upgrading, Lunar Linux 1.5.1==
<p>I started using Unix V7 on a PDP-11/70 back in 1983, even modifying some existing kernel drivers for the [http://en.wikipedia.org/wiki/Cambridge_Ring Cambridge Ring] local area network. After that I dabbled in system administration of various Sun and Apollo systems until 1991, and HP boxes up until 2000, but my main task has always been application software development, nothing on the hardware or kernel side. Since 2000 we've had dedicated system administrators at work. We had switched from NCD X-terminals over to Linux desktops (first RedHat, but then Lunar) and I realized that what little I knew had become well out of date. I installed RedHat on an old 90MHz PC at home more than five years ago, but without a LAN or modem connection it was too difficult to keep up to date, I lost interest, and that died. Since then I've had an itch to develop a spiffy [http://www.fltk.org FLTK] user interace for some old command line tools using Cygwin/Mingw on a WinXP laptop (with modem) but the machine is (a) painfully slow, and (b) painfully Windows. The time had come to get some new hardware, install an operating system that doesn't thwart you at every turn, and set up a programming environment of my own choice.
[[User Reports:Engelsman|Read more]]...
</p>

==Installing Lunar Linux 1.6.0 (coming soon, maybe)==
<p>In April 2006, the
[http://www.lunar-linux.org/index.php?option=com_content&task=view&id=39&Itemid=2 Lunar-1.6.0-i686 ISO] was released,
but I don't have enough spare time to look at installing it. Not just yet anyway.
</p>

==Installing Lunar Linux 1.6.4 (Lacus Autumni)==
<p>Lunar Linux 1.6.4 (Lacus Autumni) was [http://foo-projects.org/pipermail/lunar/2008-December/008144.html announced] in December 2008, and installation and update was initially pretty smooth and uneventful. But as 2009 rolled on, and new versions of certain key modules were rolled out and were out of step with each other, upgrading from the 1.6.4 ISO became difficult. Here's the [http://foo-projects.org/pipermail/lunar-dev/2009-September/006906.html Update Workaround HOWTO] that I put together in September. This is no longer required! Soon after this, other key module releases brought harmony again, and these instructions became obsolete.</p>
<p>In February 2010, with the 2.6.32.8 kernel, updating udev from 141 to 151 caught me out. I don't remember the exact wording, but udev-151 requires that SYSFS_DEPRECATED is disabled in the kernel configuration. Finding SYSFS_DEPRECATED_V2 in the kernel didn't take long, but it took a lot longer to track down that GFS_FS also needed to be disabled...</p>
<p>Also in February 2010, installed 1.6.4 on a new Acer-AX5810 box with NVIDIA GeForce G210 card. This obviously requires the some kernel settings, and to install the NVIDIA module. All well and good, but after every kernel update and reboot you need to '''lrm NVIDIA''', and then '''lin -rc NVIDIA''' again otherwise it won't install properly. This has bitten me several times after a '''lunar update'''...</p>

==Installing Lunar Linux 1.6.5 (Mare Ingenii)==
After corruption of the superblock on my /boot partition on an HP Pavilion t3190(?), I decided to installed the 1.6.5-beta1 ISO. The initial installation and update went without problem. XOrg7 appeared to install OK, but when I ran 'startx' the console went blank. Searching the web, and asking on #lunar revealed that I needed the i915 driver for my Intel graphics card, with an entry in /etc/modules for 'i915 modeset=1'. Close, but no cigar! That's when my troubles started, with the console going into powersave mode on reboot. After much trial and error, I discovered that the kernel requires:

CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
CONFIG_FRAMEBUFFER_CONSOLE=m

The first would imply having i915 in /etc/modules, but in fact it is trumped by the second, and you don't need the i915 module at all. But the KMS line also enables ACPI in the kernel, which causes the console blanking. To solve that problem, you do need to have fbcon in /etc/modules. Or to disable the powersave mode settings while you configure all of this, you need a lilo.conf entry such as the following

image = /boot/2.6.32.9-i686
label = 2.6.32.9-acpi
append="acpi=off"

At a certain point, there was an update to the linux-2.6 module that took it from 2.6.33.4 to 2.6.34.1, which I duly installed on my new test box, only to find that I couldn't reboot. The previous kernels had identified the disk as /dev/sda, but the new kernel decided it was /dev/sdb instead. This could be overcome by adding 'root=/dev/sdb3' on the lilo boot line, but then gave problems with /etc/fstab. To cut a long story short, I rebooted to the old kernel and changed /dev/fstab to use UUID instead. To find/create the UUIDs:

tune2fs -l /dev/sda1
swapoff -a # I'm lazy
mkswap /dev/sda2 # mkswap creates with UUID by default
swapon -a
tune2fs -l /dev/sda3

I even updated /etc/lilo.conf to add an 'append="root=/dev/sdb3"' for the 2.6.34.1 entry, and I could reboot, *and* mount the file systems.

Soon after this the 1.6.5-rc1 ISO was released, and as this was a test box anyway, with nothing really installed on it except for gnome test system that was inconsistent and didn't work, I wiped the system and re-installed from scratch.

===1.6.5 Installation Times===

Just out of curiosity, and for information to others, I decided to time how long it took to install a "minimal" desktop system from scratch
on a relatively new system and a 9-year-old relic. I have two 5-year-old boxes I might add in the future.

It's clear that you probably don't want to install Lunar on really old hardware, unless you have a lot of patience, or can use <code>distcc</code>.

{| border="1"
! System
! CPUs*bogomips [1]
! RAM
! Disk [2]
! Install
! lin gcc...
! lin linux-2.6
! lunar update
! lin XOrg7
! lin xfce4
! TOTAL
|- align="center"
| Acer AX5810
| 4 * 4988
| 6 Gb
| 1681 / 129 MB/s
| 0h11
| 1h01
| 0h12
| 0h20
| 0h23
| 0h14
! 2h21
|- align="center"
| Vaio FX401
| 1 * 1600
| 512Mb
| 179 / 17 MB/s
| 0h18
| 11h26
| 3h37
| 2h44
| 3h12
| 2h15
! 23h32
|}

# <code>grep bogomips /proc/cpuinfo</code>
# <code>hdparm -r -T /dev/sdX</code>

The basic procedure:
* install from the ISO, and take the pre-compiled kernel, and reboot
* run <code>lin moonbase</code>
* run <code>lunar</code> and set number of parallel makes to 4 in ''Options / Optimize Architecture''
* do the <code>lin gcc glibc gcc bash coreutils tar wget</code> dance from <code>man lfirsttime</code>
* use <code>lin linux-2.6</code> to explicitly build a new kernel, and reboot
* run <code>lunar update</code> to rebuild any outdated parts of the core system
* run <code>lin XOrg7</code> to build X
* run <code>lin xfce4</code> to build Xfce4

After the first reboot I primed the system by copying sources from /var/spool/lunar on another up-to-date machine to avoid download delays and glitches.

When asked questions about optional depends, etc. I simply hit return to accept the default values. I did not reconfigure the kernel. I used <code>lin --deps</code> for the XOrg7 and xfce4 builds to pre-answer the questions before kicking off the real builds so I could leave them unattended without adding delays for prompts to timeout.

NOTE: this procedure is for timing purposes only, I still have to go back and install the correct drivers for X, etc.

'''To be continued...'''

User talk:Engelsman

2010-09-18T18:10:14Z

Engelsman: /* Installing Lunar Linux 1.6.5 (Mare Ingenii) */ installation times

__TOC__

<p>I have moved the original contents of this page elsewhere, reformatting and updating on the way.
However, I have provided so many references to this page in the
[http://forums.lunar-linux.org Lunar Forums] that I can't remove it completely, and so I leave a skeleton to show the way, just like Billy Bones in Treasure Island.
</p>

<p>Please follow the appropriate link to the updated page.
</p>

==A Newbie's experience installing, and upgrading, Lunar Linux 1.5.1==
<p>I started using Unix V7 on a PDP-11/70 back in 1983, even modifying some existing kernel drivers for the [http://en.wikipedia.org/wiki/Cambridge_Ring Cambridge Ring] local area network. After that I dabbled in system administration of various Sun and Apollo systems until 1991, and HP boxes up until 2000, but my main task has always been application software development, nothing on the hardware or kernel side. Since 2000 we've had dedicated system administrators at work. We had switched from NCD X-terminals over to Linux desktops (first RedHat, but then Lunar) and I realized that what little I knew had become well out of date. I installed RedHat on an old 90MHz PC at home more than five years ago, but without a LAN or modem connection it was too difficult to keep up to date, I lost interest, and that died. Since then I've had an itch to develop a spiffy [http://www.fltk.org FLTK] user interace for some old command line tools using Cygwin/Mingw on a WinXP laptop (with modem) but the machine is (a) painfully slow, and (b) painfully Windows. The time had come to get some new hardware, install an operating system that doesn't thwart you at every turn, and set up a programming environment of my own choice.
[[User Reports:Engelsman|Read more]]...
</p>

==Installing Lunar Linux 1.6.0 (coming soon, maybe)==
<p>In April 2006, the
[http://www.lunar-linux.org/index.php?option=com_content&task=view&id=39&Itemid=2 Lunar-1.6.0-i686 ISO] was released,
but I don't have enough spare time to look at installing it. Not just yet anyway.
</p>

==Installing Lunar Linux 1.6.4 (Lacus Autumni)==
<p>Lunar Linux 1.6.4 (Lacus Autumni) was [http://foo-projects.org/pipermail/lunar/2008-December/008144.html announced] in December 2008, and installation and update was initially pretty smooth and uneventful. But as 2009 rolled on, and new versions of certain key modules were rolled out and were out of step with each other, upgrading from the 1.6.4 ISO became difficult. Here's the [http://foo-projects.org/pipermail/lunar-dev/2009-September/006906.html Update Workaround HOWTO] that I put together in September. This is no longer required! Soon after this, other key module releases brought harmony again, and these instructions became obsolete.</p>
<p>In February 2010, with the 2.6.32.8 kernel, updating udev from 141 to 151 caught me out. I don't remember the exact wording, but udev-151 requires that SYSFS_DEPRECATED is disabled in the kernel configuration. Finding SYSFS_DEPRECATED_V2 in the kernel didn't take long, but it took a lot longer to track down that GFS_FS also needed to be disabled...</p>
<p>Also in February 2010, installed 1.6.4 on a new Acer-AX5810 box with NVIDIA GeForce G210 card. This obviously requires the some kernel settings, and to install the NVIDIA module. All well and good, but after every kernel update and reboot you need to '''lrm NVIDIA''', and then '''lin -rc NVIDIA''' again otherwise it won't install properly. This has bitten me several times after a '''lunar update'''...</p>

==Installing Lunar Linux 1.6.5 (Mare Ingenii)==
After corruption of the superblock on my /boot partition on an HP Pavilion t3190(?), I decided to installed the 1.6.5-beta1 ISO. The initial installation and update went without problem. XOrg7 appeared to install OK, but when I ran 'startx' the console went blank. Searching the web, and asking on #lunar revealed that I needed the i915 driver for my Intel graphics card, with an entry in /etc/modules for 'i915 modeset=1'. Close, but no cigar! That's when my troubles started, with the console going into powersave mode on reboot. After much trial and error, I discovered that the kernel requires:

CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
CONFIG_FRAMEBUFFER_CONSOLE=m

The first would imply having i915 in /etc/modules, but in fact it is trumped by the second, and you don't need the i915 module at all. But the KMS line also enables ACPI in the kernel, which causes the console blanking. To solve that problem, you do need to have fbcon in /etc/modules. Or to disable the powersave mode settings while you configure all of this, you need a lilo.conf entry such as the following

image = /boot/2.6.32.9-i686
label = 2.6.32.9-acpi
append="acpi=off"

At a certain point, there was an update to the linux-2.6 module that took it from 2.6.33.4 to 2.6.34.1, which I duly installed on my new test box, only to find that I couldn't reboot. The previous kernels had identified the disk as /dev/sda, but the new kernel decided it was /dev/sdb instead. This could be overcome by adding 'root=/dev/sdb3' on the lilo boot line, but then gave problems with /etc/fstab. To cut a long story short, I rebooted to the old kernel and changed /dev/fstab to use UUID instead. To find/create the UUIDs:

tune2fs -l /dev/sda1
swapoff -a # I'm lazy
mkswap /dev/sda2 # mkswap creates with UUID by default
swapon -a
tune2fs -l /dev/sda3

I even updated /etc/lilo.conf to add an 'append="root=/dev/sdb3"' for the 2.6.34.1 entry, and I could reboot, *and* mount the file systems.

Soon after this the 1.6.5-rc1 ISO was released, and as this was a test box anyway, with nothing really installed on it except for gnome test system that was inconsistent and didn't work, I wiped the system and re-installed from scratch.

'''1.6.5 Installation Times'''

Just out of curiosity, and for information to others, I decided to time how long it took to install a "minimal" desktop system from scratch
on a relatively new system and a 9-year-old relic. I have two 5-year-old boxes I might add in the future.

It's clear that you probably don't want to install Lunar on really old hardware, unless you have a lot of patience, or can use <code>distcc</code>.

{| border="1"
! System
! CPUs*bogomips [1]
! RAM
! Disk [2]
! Install
! lin gcc...
! lin linux-2.6
! lunar update
! lin XOrg7
! lin xfce4
! TOTAL
|- align="center"
| Acer AX5810
| 4 * 4988
| 6 Gb
| 1681 / 129 MB/s
| 0h11
| 1h01
| 0h12
| 0h20
| 0h23
| 0h14
! 2h21
|- align="center"
| Vaio FX401
| 1 * 1600
| 512Mb
| 179 / 17 MB/s
| 0h18
| 11h26
| 3h37
| 2h44
| 3h12
| 2h15
! 23h32
|}

# <code>grep bogomips /proc/cpuinfo</code>
# <code>hdparm -r -T /dev/sdX</code>

The basic procedure:
* install from the ISO, and take the pre-compiled kernel, and reboot
* run <code>lin moonbase</code>
* run <code>lunar</code> and set number of parallel makes to 4 in ''Options / Optimize Architecture''
* do the <code>lin gcc glibc gcc bash coreutils tar wget</code> dance from <code>man lfirsttime</code>
* use <code>lin linux-2.6</code> to explicitly build a new kernel, and reboot
* run <code>lunar update</code> to rebuild any outdated parts of the core system
* run <code>lin XOrg7</code> to build X
* run <code>lin xfce4</code> to build Xfce4

After the first reboot I primed the system by copying sources from /var/spool/lunar on another up-to-date machine to avoid download delays and glitches.

'''To be continued...'''
When asked questions about optional depends, etc. I simply hit return to accept the default values. I did not reconfigure the kernel. I used <code>lin --deps</code> for the XOrg7 and xfce4 builds to pre-answer the questions before kicking off the real builds so I could leave them unattended without adding delays for prompts to timeout.

NOTE: this procedure is for timing purposes only, I still have to go back and install the correct drivers for X, etc.

User talk:Engelsman

2010-09-17T22:38:03Z

Engelsman: /* Installing Lunar Linux 1.6.5 (Mare Ingenii) */

__TOC__

<p>I have moved the original contents of this page elsewhere, reformatting and updating on the way.
However, I have provided so many references to this page in the
[http://forums.lunar-linux.org Lunar Forums] that I can't remove it completely, and so I leave a skeleton to show the way, just like Billy Bones in Treasure Island.
</p>

<p>Please follow the appropriate link to the updated page.
</p>

==A Newbie's experience installing, and upgrading, Lunar Linux 1.5.1==
<p>I started using Unix V7 on a PDP-11/70 back in 1983, even modifying some existing kernel drivers for the [http://en.wikipedia.org/wiki/Cambridge_Ring Cambridge Ring] local area network. After that I dabbled in system administration of various Sun and Apollo systems until 1991, and HP boxes up until 2000, but my main task has always been application software development, nothing on the hardware or kernel side. Since 2000 we've had dedicated system administrators at work. We had switched from NCD X-terminals over to Linux desktops (first RedHat, but then Lunar) and I realized that what little I knew had become well out of date. I installed RedHat on an old 90MHz PC at home more than five years ago, but without a LAN or modem connection it was too difficult to keep up to date, I lost interest, and that died. Since then I've had an itch to develop a spiffy [http://www.fltk.org FLTK] user interace for some old command line tools using Cygwin/Mingw on a WinXP laptop (with modem) but the machine is (a) painfully slow, and (b) painfully Windows. The time had come to get some new hardware, install an operating system that doesn't thwart you at every turn, and set up a programming environment of my own choice.
[[User Reports:Engelsman|Read more]]...
</p>

==Installing Lunar Linux 1.6.0 (coming soon, maybe)==
<p>In April 2006, the
[http://www.lunar-linux.org/index.php?option=com_content&task=view&id=39&Itemid=2 Lunar-1.6.0-i686 ISO] was released,
but I don't have enough spare time to look at installing it. Not just yet anyway.
</p>

==Installing Lunar Linux 1.6.4 (Lacus Autumni)==
<p>Lunar Linux 1.6.4 (Lacus Autumni) was [http://foo-projects.org/pipermail/lunar/2008-December/008144.html announced] in December 2008, and installation and update was initially pretty smooth and uneventful. But as 2009 rolled on, and new versions of certain key modules were rolled out and were out of step with each other, upgrading from the 1.6.4 ISO became difficult. Here's the [http://foo-projects.org/pipermail/lunar-dev/2009-September/006906.html Update Workaround HOWTO] that I put together in September. This is no longer required! Soon after this, other key module releases brought harmony again, and these instructions became obsolete.</p>
<p>In February 2010, with the 2.6.32.8 kernel, updating udev from 141 to 151 caught me out. I don't remember the exact wording, but udev-151 requires that SYSFS_DEPRECATED is disabled in the kernel configuration. Finding SYSFS_DEPRECATED_V2 in the kernel didn't take long, but it took a lot longer to track down that GFS_FS also needed to be disabled...</p>
<p>Also in February 2010, installed 1.6.4 on a new Acer-AX5810 box with NVIDIA GeForce G210 card. This obviously requires the some kernel settings, and to install the NVIDIA module. All well and good, but after every kernel update and reboot you need to '''lrm NVIDIA''', and then '''lin -rc NVIDIA''' again otherwise it won't install properly. This has bitten me several times after a '''lunar update'''...</p>

==Installing Lunar Linux 1.6.5 (Mare Ingenii)==
After corruption of the superblock on my /boot partition on an HP Pavilion t3190(?), I decided to installed the 1.6.5-beta1 ISO. The initial installation and update went without problem. XOrg7 appeared to install OK, but when I ran 'startx' the console went blank. Searching the web, and asking on #lunar revealed that I needed the i915 driver for my Intel graphics card, with an entry in /etc/modules for 'i915 modeset=1'. Close, but no cigar! That's when my troubles started, with the console going into powersave mode on reboot. After much trial and error, I discovered that the kernel requires:

CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
CONFIG_FRAMEBUFFER_CONSOLE=m

The first would imply having i915 in /etc/modules, but in fact it is trumped by the second, and you don't need the i915 module at all. But the KMS line also enables ACPI in the kernel, which causes the console blanking. To solve that problem, you do need to have fbcon in /etc/modules. Or to disable the powersave mode settings while you configure all of this, you need a lilo.conf entry such as the following

image = /boot/2.6.32.9-i686
label = 2.6.32.9-acpi
append="acpi=off"

At a certain point, there was an update to the linux-2.6 module that took it from 2.6.33.4 to 2.6.34.1, which I duly installed on my new test box, only to find that I couldn't reboot. The previous kernels had identified the disk as /dev/sda, but the new kernel decided it was /dev/sdb instead. This could be overcome by adding 'root=/dev/sdb3' on the lilo boot line, but then gave problems with /etc/fstab. To cut a long story short, I rebooted to the old kernel and changed /dev/fstab to use UUID instead. To find/create the UUIDs:

tune2fs -l /dev/sda1
swapoff -a # I'm lazy
mkswap /dev/sda2 # mkswap creates with UUID by default
swapon -a
tune2fs -l /dev/sda3

I even updated /etc/lilo.conf to add an 'append="root=/dev/sdb3"' for the 2.6.34.1 entry, and I could reboot, *and* mount the file systems.

Soon after this the 1.6.5-rc1 ISO was released, and as this was a test box anyway, with nothing really installed on it except for gnome test system that was inconsistent and didn't work, I wiped the system and re-installed from scratch.

'''To be continued...'''

{| border="1"
! System
! CPUs*bogomips [1]
! RAM
! Disk [2]
! Install [3]
! lin gcc... [4]
! lin linux-2.6 [5]
! lunar update
! lin XOrg7
! lin Xfce4
! TOTAL
|- align="center"
| Acer AX5810
| 4 * 4988
| 6 Gb
| 1681 / 129 MB/s
| 0:11
| 1:01
| 0:12
| 0:20
| ?:??
| ?:??
| ?:??
|- align="center"
| Vaio FX401
| 1 * 1600
| 512Mb
| 179 / 17 MB/s
| 0:18
| ?:??
| ?:??
| ?:??
| ?:??
| ?:??
| ?:??
|}

# <code>grep bogomips /proc/cpuinfo</code>
# <code>hdparm -r -T /dev/sdX</code>
# install from Lunar ISO, with precompiled kernel only
# <code>lin -rc gcc glibc gcc bash coreutils tar wget</code>
# <code>lin linux-2.6</code> but use the existing configuration

Lunar Linux:FAQ

2010-09-11T11:44:07Z

Engelsman: /* error: download failed - broken URL */

These are the '''F'''requently '''A'''sked '''Q'''uestions for Lunar Linux. You have a question about Lunar? You might get your answer below.<br /><br />

__TOC__

==General==

===What is Lunar Linux?===
What exactly is Lunar Linux?

'''Answer:'''
* Please read [[Lunar Linux:About|About Lunar Linux]].

===Can I run Lunar Linux in 64-bit mode?===
Can I run Lunar Linux on my new 64-bit system?

'''Answer:'''

Yes you can. You can run Lunar Linux in '''either''' 64-bit '''or''' 32-bit mode, but there is no multi-lib mode. Be aware that some applications are still only available for 32-bit mode!

===Where can I find how to ...?===
Where can I find how to customize the kernel under Lunar Linux? Or the desktop...

'''Answer:'''

The Lunar Wiki only offers details specific to Lunar Linux. Many other resources already exist for general Linux problem solving. For example, information on how to customize the Linux kernel can be found at:
* http://kernelnewbies.org/
* http://en.wikipedia.org/wiki/Linux_kernel_mailing_list

==Optimizations==

===How do I set optimizations?===
How do I set these optimizations for my machine?

'''Answer:'''

Run <code>lunar optimize</code>. You'll be taken through an interactive menu that explains all the options. Remember to optimize safely.

===What are safe optimizations?===
What are the recomended safe optimizations for [[Lunar Linux]]?

'''Answer:'''

The default sure fire optimizations that are recommended are:

* '''C'''
** <code>-pipe</code>
* '''C++'''
** <code>-pipe</code>
* '''CPU Architecture'''
** You should pick the correct architecture for your own system (defaults to x86 for most people).
* '''Basic Optimzations'''
** Faster (-O2, the default).
* '''CPU'''
** This, of course, should be set to your own cpu, or the cpu of the machine you plan to run this install on. If you want to be able to run this install on many machines, you should be safe with I686.
* '''Speed Optimizations'''
** If you want to be 100% sure that there won't be optimization problems you shouldn't select any of these.
* '''Extra features'''
** It is not recommended to use any of these optimizations, even for modules known to be able to handle them, since they cause many apps to break.
* '''Floating Point Math'''
** None. If your architecture is x86 and you don't own a 386SX and 486SX, it's safe to select x387.
* '''Linker Options'''
** Strip.
* '''Addon Program Support'''
** CCache. Make sure to install it first.

These settings should work for almost everyone, and there is a lot room for pushing these optimizations more, at the risk of problems with some applications. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations may cause problems?===
What optimizations are known to cause problems in some setups?

'''Answer:'''

Some optimizations that are known to cause problems on x86 with many applications, and even a entire system:

* <code>-funroll-loops</code>
* <code>-fstrict-aliasing</code>
* <code>-ffast-math</code>
* <code>-ffloat-store</code>

These are sorted from the least unstable to most unstable. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations can give some speed without issues?===
What optimizations can I use to gain some speed but without major risks?

'''Answer:'''

Start with the basic optimizations in [[Lunar Linux:FAQ#What_are_safe_optimizations.3F|FAQ #2.2]] and change the Basic Optimizations to Faster or Fastest if you know that gcc will generate correct code for that cpu. -O2 obviously takes more compile time than -O1, and -O3 takes the most time to compile. Then select the cpu you will run it on. Some of the speed optimizations that should be decent and shouldn't cause too many problems, if any, are: -fomit-frame-pointer. A safe bet for floating point math on a x86 would be x387, if you know your cpu has a floating point unit. Check <code>cat /proc/cpuinfo</code> to see if your cpu supports SSE or SSE2. If your cpu does have sse or sse2 then you can also add that to the math optimizations.

Your results may vary. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations should I avoid?===
What optimizations should I stay away from?

'''Answer:'''

All the ones listed in the [[Lunar Linux:FAQ#What_optimizations_may_cause_problems.3F|FAQ #2.3]] plus:
* <code>-fprofile-arcs</code>
* <code>-fbranching-probabilities</code>

Please read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it. The Lunar developers will not respond to bug reports of broken compiles by users with risky optimizations.

==Installing modules==

===Can I compile several modules at once?===
Is it possible to install multiple modules at the same time without breaking things?

'''Answer:'''

Yes, Lunar even promotes it. However doing so will cause installs compile slower of course. Lunar will not install core system modules like gcc and glibc while something else is installing and will wait until the rest is finished. Also, you cannot install applications while those major modules are installing, they will wait their turn until it's safe and continue to install them automatically.

===error : download failed - broken URL===
I tried to install a module, but the download failed due to a broken URL. What do I do now?

'''Answer:'''

There are three possible reasons why the download failed:
# You are trying to download from one of a set of mirror sites, and the mirror you are using is either busy or incomplete.
#* Run "lunar" as root, select Options / Software Mirrors, and change the mirror to something closer to you.
#* Note: there seems to be a consistent problem with the SFORGE mirror: http://osdn.dl.sourceforge.net
# You are trying to download from a particular site, but the location of the file has changed [or the site is temporarily off-line].
#* Browse the module's website (see "lvu website") [or search the web for the tarball],
#* Download it manually, copy it to /var/spool/lunar, and try to run "lin" again,
#* Run "lvu edit" to create a [[zlocal]] copy, and edit that copy with the new location [or secondary URL]
# You are trying to download a version that has been removed because a newer version exists.
#* Browse the module's website to discover the new version number,
#* Run "lvu edit" to create a [[zlocal]] copy, and edit that copy with the new location, version number, sha1sum, etc.
#* Note: you could first try to run "lin -w newVersion" and hope that it builds without problems.
If you do create your own [[zlocal]] copy, please consider submitting it using "lvu submit". (See [[Module Submission]])

===error : C compiler cannot create executables===
What does this error mean and how can I fix it?
* <code>C compiler cannot create executables</code>

'''Answer:'''

Read the next topic - this is basically the same problem: There are kernel headers missing that are vital to compilation. You will have to restore them. Below is explained how to do that.

===configure: error: C preprocessor "/lib/cpp" fails sanity check===
What does this error mean and how can I fix it?
* <code>configure: error: C preprocessor "/lib/cpp" fails sanity check</code>

'''Answer:'''

This is an include file problem. Sometimes ''/usr/include/gnu/stubs.h'' is missing, this can be found in the glibc source tarball. Most of the time the following applies:

Your kernel headers are missing from <code>/usr/include</code>. This means the C PreProcessor cannot verify that it has the proper cached copies of those vital header files. You need to install the proper ones manually. Here's how:

lin kernel-headers-2.4

This might work for you! (Use the 2.6 version if needed of course)

Otherwise:

mkdir -p /usr/include/{linux,asm}

to create the two target dirs, if needed. Then execute:

cp -av /usr/src/linux/include/linux /usr/include/
cp -av /usr/src/linux/include/asm/* /usr/include/asm/

to copy the files manually. Be warned that the second command has to be done this way since <code>/usr/src/linux/include/asm</code> is a softlink to your arch asm header files, asm points to asm-i386, on x86 machines. So if, on the other hand, you had copied

cp -av /usr/src/linux/include/asm /usr/include/

you would then get a softlink to nowhere under <code>/usr/include/</code>.

Last, you can always try to unpack the kernel tarball you have into <code>/usr/src/linux</code> and manaully link or copy the headers over yourself.

===Can I add more window managers to gdm?===
How do I add other window managers to the sessions list on gdm?

'''Answer:'''

Copy the desktop startup files to <code>/etc/X11/dm/Sessions/</code>. That works with gdm. For kdm you will have to copy them to <code>$KDE_PREFIX/share/apps/kdm/sessions</code>.

===How do I get Flash to work in Mozilla or Firefox?===
How do I get Flash to work in Mozilla or Firefox?

'''Answer:'''

If you are using Mozilla or Firefox, then you can simply do a <code>lin flash-plugin</code> and that will download and install the Macromedia Flash plugin that works with a gtk+ based mozilla through the old abi wrappers.

The flash plugin does ''not'' work with Galeon. The Galeon developers have declined to provide the "old" abi wrappers needed for the plugin to work.

===How do I install Java?===
How do I get Java for my Lunar box?

'''Answer:'''

You will have to download the Java source code from Sun yourself and you have to "click" to agree on their license. You have to compile it yourself too. We don't have a Sun Java module as we currently have no way to automate the "click" to agree to the Sun Java license. See this URL for some handy info:

http://www.linuxfromscratch.org/~tushar/hints/javafromscratch.txt

There is a j2sdk module in moonbase which is the Blackdown port of Sun's Java Virtual Machine.

==Lunar core tools==

===How can I recompile my module with new options?===
How do I force lunar to recompile my modules with different options?

'''Answer:'''

Try:

lin -r ''MODULE''

The -r switch will allow you to select new configuration and dependencies for modules.

===How can I make modules recompile instead of resurrecting?===
How do I tell lunar to recompile my application instead of resurrecting it?

'''Answer:'''

Try doing:

lin -c ''MODULE''

The -c option means tells <code>lin</code> to compile this module even if there is an install cache copy available in <code>/var/cache/lunar</code>.

===How can I tell lunar that module X no longer depends on module Y?===
Module X no longer depends on module Y, but lunar insists on reinstalling module Y too. How can I get tell lunar to remove that dependency?

'''Answer:'''

Lunar adds a module's dependencies to a cache when you install it. You can't remove a dependency automatically, but you can rebuild the dependency cache to reflect the current dependencies of the modules that are now installed.

lsh create_module_index
lsh create_depends_cache
lunar fixdepends

Note: Dependencies of modules in [[zlocal]] are ignored. If module X in the main moonbase depends on module Y then the dependency cache will still contain that dependency.

===My moonbase is gone and I can't install anything.===
How do I fix problems with my moonbase when it's missing or damaged?

'''Answer:'''

Simple solution to this is just running:

lin moonbase

This will download the latest moonbase from the internet, and restore it to working order.

===What is a module?===
What is a [[module]] and what does it do??

'''Answer:'''

A [[module]] is a set of files that tell the core tools the following:

* What name, version, and other properties a package has
* Where to download all needed source files
* What other modules are required, or conflict with this one
* How to unpack the source files, how to patch
* How to configure the code
* How to compile
* How to install everything
* What else to do with it

The [[module]] is coded in a set of files in a directory structure, and scripted in bash.

===What is the Moonbase?===
What is that thing you call [[Moonbase]]?

'''Answer:'''

The [[Moonbase]] is a database with [[modules]]. In this database there are description of packages that tell the core tools where to download, how to compile, and how install a [[module]]. You can consider this the lunar equivalent of portage, grimoire, ports, etc.

===What is theedge?===
What is theedge?

'''Answer:'''

[[theedge]] is the same as lunar, and also known as the core code. Theedge is just another version of lunar. These two pieces of code install your packages, but they do not contain package descriptions. Those are defined in moonbase.

[[Theedge]] is a development version of [[lunar]]. Often there are much more features in theedge, and bugs are fixed quicker as well. However, if you do not like all this tweaking on your system, we advice you to use the stable lunar core tools instead on your system.

You can install [[theedge]] by issuing:

lin theedge

Theedge is automatically updated if you do a <code>lunar renew</code> or <code>lunar update</code>.

==Lunar-Linux Installation==

===My usb keyboard is not recognized===
At the boot prompt type ''linux uhci-hcd ehci-hcd'' to make sure those modules are loaded during startup. Those will then enable your usb keyboard.

===So how should I partition my disk?===
I'm setting up lunar from scratch, but how should I partition my disk for a server or desktop system?

'''Answer:'''

Server systems have very different demands than desktops. It's all about flexibility. First desktops:

''desktops'' commonly have one hard disk. You don't want to reformat or repartition often, so you just want to be done with it at once. The easiest is just to setup 2 (two) partitions: one root filesystem big enough for all lunar software, and the rest for <code>/home</code>. Typically, lunar occupies between 4 and 12 gb based on how many applications you install. If you clean up often you can manage with 8gb, but you should keep some extra space. I certainly advise to use a swapfile instead of a swap partition: you can always later delete the swap, or move the swapfile to another disk or partition. A swap partition is harder to relocate.

''Servers'' have different needs. First of all <code>/home</code> doesn't need to be that large, but you will want to setup space for logfiles that cannot cause problems if they grow too fast. Putting <code>/var/tmp</code> and <code>/var/log</code> on separate partitions is quite normal. <code>/tmp</code> can be abused similarly, and is mostly run in [[tmpfs]] to avoid cluttering and give fast access times. Then <code>/usr</code> will be separate and the usual separate <code>rootfs</code>. As you can see this list is already getting quite big! Most users will actually want to make the <code>rootfs</code> quite small (as small as 200mb sometimes!) and thus <code>/home</code> also needs to be on a separate partition.

===Kernel features, built-in or module?===
When I compile a kernel, should I compile drivers that I need in the kernel image or as module?

'''Answer:'''

There are many schools of thought on kernel compiling. One is to build everything into the main kernel without modules. The other one takes building modules to the extreme. Here is a suggestion, if it's not needed to boot it's a module. Thus usb, input, sound, mice ACPI, network, and also cdrom, floppy, and all the non boot file systems, all get built as modules. This reduces the size of the main kernel so it can be put on a floppy. Another thing to consider is that not everything works perfectly, and some features can cause your kernel to misbehave, so if some feature is built-in, the bad behavior is practically inevitible. Instead, with a module you can choose not to load it and thus be left with a working system.

Please note that some people need to make some features built into their kernel and vice versa, do whatever works best for you.

===QEMU and Lunar ISO testing===
How do I use qemu to try out lunar ISO's?

'''Answer:'''

Just a quick note on how to use qemu for testing a Lunar Linux installation. See <code>/var/lib/lunar/moonbase/devel/qemu/DETAILS</code> for a description of qemu. Think of it as a low-cost (''read: free'') version of a virtual machine, that has quite a few useful features and is under active development.

A very simple way to just test a Lunar ISO for booting purposes is:

qemu -cdrom lunar-1.5.0-i686.iso -boot d

If you want to test a full install, then create a 512 megabyte sparse root_fs image with this <code>dd</code> command:

dd if=/dev/zero of=hda.img bs=$((1024 * 1024)) count=0 seek=512

Now invoke qemu:

qemu -cdrom lunar-1.5.0-i686.iso -boot d -hda hda.img

You can then proceed to test your Lunar install. Refer the qemu homepage for further tips and tricks. qemu can also be quite easily used to test if your brand new kernel is bootable or not, which is quite neat.

Note that you should say yes to using SDL as an optional_depends. The gui version of qemu is ''very'' nice in its own little X11 window.

==Other==

===How do I unpack an .RPM file in lunar?===
How do I install RPM files in lunar? Is that possible?

'''Answer:'''

The easiest way to unpack a rpm file is to use the module called <code>rpmunpack</code>. Simply run <code>rpmupack ''XYZ''.rpm</code> for your RPM. This will create a cpio file (''XYZ.cpio.gz'' and ''XYZ.cpio.bz2'' are not uncommon). Once you perform any additional uncompression with <code>gunzip</code> or <code>bunzip2</code>, you can then extract it using <code>cpio -i -d < XYZ.cpio</code> -- After all that you should be all done. If you are trying to rpmunpack a source RPM (i.e. .src.rpm) file then ''XYZ.cpio'' may further contain a tar.bz2 or tar.gz source tarball.

In the zbeta section of moonbase, there is an '''''unsupported''''' module called <code>rpm</code> for those of you that are really desperate.

You might want to do <code>man cpio</code>, to check out additional cpio parameters that may interest you, such as the -L switch.

===What is that in the Lunar-Linux logo?===
What is that logo of yours? It looks like a <nowiki>[cat|ferret|dog|owl|insert nutty animal here]</nowiki>!

'''Answer:'''

The logo is a [[wikipedia:Southern Rockhopper Penguin|Rockhopper Penguin]]. It's a kind of nasty penguin, the one that crowd up in thousands to take over the continent. They have a few long feathers sticking out at their "ears" sideway, just like some owl species do.

You can check out [http://images.google.com/images?q=Rockhopper+Penguin Google Images] for lots of Rockhopper Penguin pictures!

The current logo has been designed by Michael Schindler in 2003 and appeared as the official logo of the Lunar Linux project in 2004.

Lunar Linux:Installation/1.6.5

2010-08-25T18:42:52Z

Engelsman: /* Upgrade Moonbase */

__TOC__

Lunar Linux is a revolutionary Linux distribution in that it is not binary based, as are most distributions, but is instead built entirely by compiling source code, using your own custom optimizations.

Essentially, it installs a complete bootstrap development system on your machine, and then you tell the Lunar package manager what tools you want, and it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward your specific needs.

The result is a leaner, meaner, refreshingly uncluttered, and strikingly faster operating system than most Linux distributions.

This installation guide is designed to get you through the installation process as painlessly as possible. It assumes that you have some experience with Linux or another Unix variant, and have a general idea of what you are doing. If you are unfamiliar with such things as partitions, or have never used Linux before, Lunar may not be the best introduction for you into the world of open source. There are always Lunar gods available on irc.freenode.net in the #lunar channel to answer any questions that this manual may not make quite clear enough.

With that said, we hope you enjoy using Lunar!

==About this installation manual==

Although this manual is not intended to be a full and complete overview of any situation you may be confronted with, given the wide diversity of hardware available these days, it is intended to be an introduction to the world of Lunar Linux. You will see examples that are not tailored towards your to-be built server or workstation, optimizations that are overly broad or too specific, and examples that don't apply to any real situations. We tried hard to give you the idea of how much power you have over how you can setup your system, but we are forgetting to tell you how to run your own server or desktop (or other system) at all. That means that the examples and steps taken most probably do not apply to your situation at all.

Do not despair: if you understand what is going on and you get the idea, the installer will allow you to do pretty much everything you want to do with your system. There are really (almost) no limits.

==Getting the ISO==

The primary site for retrieving the ISO is [http://www.lunar-linux.org/ lunar-linux.org]. There, you will find links to our US, EU, and Internet2 mirrors, as well as a Bittorrent link. As of this writing, the current version of the Lunar ISO is version 1.6.5-rc1, codename Mare Ingenii (20100709). (''Check the main site for the actual latest version!'')

Locate and retrieve the file lunar-1.6.5-rc1-i686.iso.bz2 (or lunar-1.6.5-rc1-x86_64.iso.bz2 if you have a 64-bit system). After downloading this file, you will need to unpack the ISO using bzip2. Windows users will need a program that can extract bzip2 archives, like WinZip (also capable of extracting bzip2 archives under windows are IZarc, Winrar, powerarchiver and 7-Zip). Mac should unzip the file by itself. Then all that is left to do is use your favorite program to burn the ISO to a cdrom and begin the installation. Lunar can also be installed without using a CD. If you need to do it this way, our [[FAQ]] provides simple instructions.

It should be noted that the 1.6.5 ISO and Lunar use udev for device management. The devfs system, and the "old-school" method of manually installing devices, are no longer supported.

We are assuming the you are installing Lunar as your primary OS. Make sure you have a backup of any important data that you need to retain. The Lunar Linux Project and its developers are not responsible in any way for any loss of data on your system!

==Booting the ISO==

Upon booting the ISO, the first thing you will see are options for booting the ISO kernel, or for performing RAM tests [Note: MemTest is not available on x86_64]. There is even a safe mode which will disable DMA, MTRR, RAID, LVM, USB keyboards, NTFS, HPFS, Advanced Partitions, and Firewire. Most folks, however, will be just fine pressing enter at the boot prompt and loading the default kernel.

To boot the iso with support for your usb keyboard:
''linux uhci-hcd ehci-hcd''

After loading the kernel, the first screen presents you with a few options. If there are extra modules you need to load in order continue with the install, they can be loaded here. There is also a shell option. However, if you are using this ISO for rescue purposes, you do not want to shell out here; rather continue booting and shell out in the next section. Most people will select "continue booting" here.

It should be noted that the 1.6.5 ISO tries to autodetect some hardware (mostly scsi drivers and network interfaces) during this stage. This will help you establish a network connection if you desire so during installation. For this reason the programs 'dhcpcd' and 'ftp' are already available at this stage.

==Virtual Consoles==

Once the ISO has booted into the installer, you can immediately shell out or switch to one of the other virtual consoles. These will have ready to go root shells and are available throughout the installer sequence. With these you can start rescue actions, setup networking or double check the install progress and make manual adjustments.

==Language and keyboard interface Settings==

After reading the introduction, you will be presented with options for choosing the proper font, keymap, and language for your install.
You will also need to choose an editor, as you are going to need one later on in the installation for setting up your lilo or grub configuration. The choices available are e3, [e3/emacs], joe, nano, vi, and zile. If you have never used a text editor in Linux before, nano is the best choice for you. If you skip the Native Language Support option, the system will install the default editor, nano, for you. When you have finished setting up your options, press cancel to return to the main setup menu.
Less important for most people is the ability to choose the console font, although it may help display some non-English characters. Most people will want to set the system-default language variable and editor though. All these values are unset by default, so make sure you set them now.
The keymap table allows people to use azerty and dvorak keyboards, and much more. This is especially required for non-English keyboards which provide many accented characters.
All these language and keymap settings might not apply to the lunar code itself, which (currently) does not have any international support, but most programs that run during the installer sequence, and after booting into your new system, will be affected properly.

Warning: the keymap entry appears to default to ANSI-dvorak so make sure that you really select what you want.

==Creating or editing Partitions==

The next step is to set up partitions on your hard drive. Upon selecting the "Partition Drive" option, you will be shown a list of all the discs the kernel has detected. For this guide, we will assume that you have one hard drive connected via an IDE channel, which will show up in the menu as "disc0". After selecting the disc to partition, you are given the option of using one of three partitioning programs. They are:

* cfdisk -- A menu driven partitioner, and very easy to use. If you are unfamiliar with various partitioning programs, this is the best option for you.
* fdisk -- Text based partitioner that requires a little more know-how than cfdisk. More experienced users will probably use this program. However new users should not be daunted, as it does have help offered at every step.
* parted -- Text based partitioner that is good for advanced users. Parted is excellent for resizing current partitions on your hard disk, however be forewarned that resizing partitions is an excellent way to hose your entire disc.

Note: under the <Settings> option on the main menu there is an option to configure the fstab mount style as DEV, LABEL or UUID. The first is the traditional Linux method, but can sometimes give problems if a kernel update causes the disk to be renamed. The default is UUID, which uses a unique marker on the partition to avoid this problem.

For our example, we have a 40GB IDE drive and we'll set up six partitions; /, /boot, /home, /usr, /var, and a swap partition. It's a good idea to keep certain directories, such as /var and /usr on separate partitions, as this can save you a lot of headache in the future in case your disk ever completely fails on you and you need to recover data (God forbid!). Also, when you have a separate /boot partition as we have in our example, you need to have your partitioning program mark that partition as active or bootable. In our example, if we were using fdisk, you would press "a" at the command line, and then select part1 as the active partition.

You might also want to install a /tmp partition. By default, Lunar will create a tempfs filesystem mounted on /tmp (tempfs minimizes filesystem fragmentation because it resides in volatile memory). This can be a good choice if you have a lot of memory on your machine. If memory is tight, we recommend creating a /tmp partition to minimize filesystem fragmentation.

It is important to note that you <span class="emphasis">''can not''</span> mount the directories /etc, /bin, /sbin, /dev, /lib and /proc on separate partitions. These directories need to be contained within the root ("/") directory. The installation program should block you from doing this, but it's best not to try.

Here's our partition setup:

1 /boot 100MB
2 / 4GB
3 swap 1GB
5 /usr 10GB
6 /var 10GB
7 /home 15GB

(''If you're wondering about this choice of partitions: it's really just an example. Read the [[FAQ#So_how_should_I_partition_my_disk.3F|FAQ]] on what makes sense in the real world''))

You'll notice that there is no fourth partition in our list above. In order for you to have more than four partitions on a single drive, the fourth partition is made into what is known as an extended or logical partition in which the fifth, sixth, and seventh (etc, etc) partitions reside. For our example above, if we were using fdisk, we would make the fourth partition an extended/logical partition that was 35GB, and then the fifth, sixth, and seventh partitions in our scheme resided within it. However, if we used cfdisk, we would just worry about creating six partitions, making sure that the first three are the primary type, and the last three logical.

Note that the names and mount points for these partitions will be assigned during the next step of this process, when you mount the partitions. Write down exactly what partitions you are planning to create because it can otherwise get confusing!

Lunar offers two choices when it comes to swap. You can set up a swap partition, as we have in our example, or you can set up a swapfile in the root directory. We recommend setting up a swap partition, as you will get better performance with it than with the swapfile. However, there may be a need for you to set up the swapfile instead, which can be setup and activated after you have mounted your other partitions.

==Selecting Partitions and Filesystems==

After creating your partitions, you need to select them and assign file systems. Select the menu option "Select Filesystems" and verify that you are indeed done creating partitions.

The partitions can be selected in random order with the new installer. First select the partition and then assign a filesystem and mountpoint to it. The installer will add this to the job queue and formatting and mounting takes place later so you can edit your selection. Here's a list of filesystems that are currently supported:

* ''ext4'' (Fourth Extended File System) -- Version 4 of the Extended File System, which was ... TO BE COMPLETED.
* ''ext3'' (Third Extended File System) -- Version 3 of the Extended File System, which is essentially just the journaled version of ext2. This filesystem is available with all kernels on the ISO.
* ''ext2'' (Second Extended File System) -- Version 2 of the Extended File System, which was designed for linux as a replacement for the Minix Filesystem. Ext2 is not a journaled filesystem, which means that you'll need to perform disc recovery operations after a power failure or other such system crash. This filesystem is available with all kernels on the ISO.
* ''reiserfs'' (Reiser Filesystem) -- Journaled filesystem created by Hans Reiser that is excellent for use with extremely small files. This filesystem is available with all kernels on the ISO.
* ''xfs'' -- Created by SGI for IRIX, SGI's brand of Unix, and later ported to linux under the GPL. A journaled filesystem that SGI claims is better than any other at handling extremely large files and sparse files. This filesystem is only available with the lunar or grsec patched kernels, which we will come to in a few steps.
* ''jfs'' (Journaled File System) -- Created by IBM for AIX, IBM's brand of Unix, and later ported to linux by IBM under the GPL. A journaled filesystem that is very good at handling high throughput issues. This filesystem is available with all kernels on the ISO.
* ''swap'' Swap (Virtual memory or paging filesystem) for swap partitions only!

After selecting the filesystem type you wish to use, you will be prompted through a series of steps to initialize the partition. You'll notice that the prompts are quite redundant in nature in order to be absolutely positive that you will not inadvertantly erase crucial data that you might have on a working filesystem. In addition, if you have more than four partitions, as we do in our example, you don't want to select any file systems on the fourth partition, as it is the extended partition that houses the fifth, sixth (and so on) partitions. (The installer will try to detect this and skip the extended partition from the list).

As we mentioned earlier, there is an option in the installation process to set up a swap file in the root partition instead of a swap partition as we have done in our example. The next option after selecting your filesystems is to select a swapfile if you so desire. <span class="emphasis">''If you have set up a swap partition already, as we have done, you can skip this step.''</span> Otherwise, you can set up your swap file here, and the only thing you need to tell the installer is how large you want the file to be. Running without swap completely is also possible of course.

'''Please note during this step, no modifications are made to your filesystem!'''

==Installing Lunar==

Next, we need to ''format'' your partitions, ''mount'' them in the right place, create ''swap'' and transfer the entire Lunar system to the partitions that you now have created. This happens all in one single step.

Select ''Install Lunar'', and the system will proceed to transfer all of the necessary files for you. The installer will display progress as packages are transferred to your system and you'll have some idea how long it will take. On normal machines, this should take about 5 minutes.

At the end of this step, the installer sets various system parameters like language, timezone and vital package configuration files in order for your machine.

==Setting Up Your Compiler Optimizations==

The compiler optimizations is a crucial step, since what you choose will make your system fly! However, it is important that you do not overdo it on you optimization settings, as certain selections can, in some instances, break code while compiling.

The first step is to choose your preferred compiler. There is only one version on the 1.6.5 ISO, so the only option here is GCC 4.4. However, once the main system installation is complete, it is possible to install GCC 3.x -- and even the deprecated GCC 2.x! If you don't intend to install those, you should go to the GCC_4_4 submenu now and set GCC 4.4 as the default compiler.

The GCC_4_4 menu also allows you to change other options:

* ''safe'' : allows you to turn off optimization safety, so you should leave this well alone unless you really know what you are doing. Turning this off will result in many more options appearing than are described below.
* ''bopt'' : allows you to change the base compile-time optimization. Your choice depends on what your needs are. Most folks will want to use -O2 here, as it is the wisest choice. More advanced users may want to use the -O3 option, but it's not for everyone. If you're short on disk space, you would take the -Os Small option. (As an example, we used -Os for the ISO since we were working within a confined amount of disc space.) Those of you with older or slower systems that wouldn't be able to take advantage of faster optimizations may choose a more conservative setting like -O1. For our example system, we will choose -O2.
* ''cpu'' : allows you to set your processor type. This may seem unimportant, but the GCC 4.x [and GCC 3.x] compiler has ways of optimizing code for certain processors
* ''cc_opt'' : allows you to set some limited C/C++ compiler settings. Very few people, if any, would need to turn off the -pipe option.

The unsafe optimizations are:
* ''xtra'' : CPU extensions
* ''spd'' : Specialized optimizations
* ''fpm'' : Floating point optimizations
* ''stack'' : Stack optimizations

==Adding Other Compiler Toolchain Optimizations==

'''You can safely SKIP this entire step!'''

The GNU_LD menu shows the screen for linker options, where you will find that "-s Strip" has already been checked off. Very few people will want to uncheck this option, so we will leave this screen as is.

The GNU_MAKE menu allows you to set the number of concurrent makes. As the hint mentions on the "Concurrent Makes" screen, you'll want to enter in the number of cpu's your machine has. Unless you have a machine with more than one processor, you'll want to leave this field blank.

We are now finished setting up our GCC optimizations! When you have you lunar system up and running, you can always change and tweak these GCC settings by typing "lunar" at the commandline prompt, and going to "Optimization Settings". In addition, if you aren't that familiar with what your processor is capable of using for optimizations, you can go to the shell out option on the ISO and type

cat /proc/cpuinfo

at the prompt and the system will show you all the optimizations that the processor reports it can handle.

==Configuring Your Bootloader==

=== Configuring LILO ===

If you chose to use lilo and also said yes to automatically configuring and running lilo, then most of the work is done for you. If you chose not to hand edit lilo.conf, however, be warned that the default configuration has the system set up to be password protected on boot. You can change this by selecting the option from the menu "Reconfigure LILO".

To turn off password protection, you will need to comment out (with the symbol "#") or delete two lines in your lilo.conf file. The first is "password=lunar", which is found in the top section of the file, and the other is "restricted" which is found right below the name of your kernel in the second section.

The other item of note is whether you want lilo to reside in your MBR (Master Boot Record) or on the first sector of your /boot partition. The line in your lilo.conf file to edit for this purpose is

boot=/dev/sda1

To make lilo get installed on the first sector of your /boot partition, you would leave this line as it is. If you want lilo to be written to your MBR, which is the recommended method, you would change the line to read

boot=/dev/sda

Of course, these examples are pertinent to our setup that we have been using thoughout this manual. Your actual lilo.conf file may be different.

=== Configuring GRUB ===

If you chose grub as your bootloader, you will need to set up the configuration file entirely on your own. An example would be:

default 0
timeout 30
color white/blue white/black
title linux-2.4.25
root (hd0,0)
kernel /vmlinubz-2.4.25-r5.0.0 root=/dev/sda2 devfs=nomount

As we mentioned earlier in the partitioning section, you would want to mark your /boot partition as active. With grub it is ''imperative'' that you mark your /boot partition as active, otherwise grub will not work at all when you are finished with the installation and reboot to your new system.

NOTE: The option to install grub is not available on the 1.6.5-rc1-x86_64 ISO because grub is not yet fully stable on 64-bit systems. If you really know what you are doing, the source tarball is saved to disk, so you can configure it manually once the main installation is complete.
==Installing kernels==

===Installing a precompiled kernel===

The ISO comes with a selection of precompiled kernels and modules that should work for most people. If you have problems getting your kernel to compile, install or getting the right drivers, or just want to get a quick start at lunar, we ''suggest'' that you use this option instead of compiling your own kernel. You can later of course compile as many kernels as you want, and indeed the first ''lunar update'' after the main installation might ask whether you want to update the kernel too. Why do it twice if you don't need to?

There are several kernels for you to choose from. They are:

* ''2.6.34.1'' -- Normal kernel (SMP, 4GB memory max) (RECOMMENDED).
* ''2.6.34.1-safe'' -- Very safe non-optimized minimal kernel (no ACPI, DMA, SMP, 1GB).
* ''2.6.34.1-server'' -- Server optimized (SELINUX, SMP, 64GB, no preempt).

===Building Your Customized Linux Kernel===

We have now come to the most important part of the installation; the configuration of the kernel. The kernel is the heart of Linux, and without it, nothing would work. Configuration is, actually, a rather simple process. All you need to remember is to not panic, and that lunar is going to do most of the work for you. Here are a few pointers that will make the configuration a breeze for you.

* Help is a click away! The people working on creating and maintaining the Linux kernel have help placed throughout the entire configuration process. If you're not sure what something does, just look at the help file for whatever item you're on, and it will almost certainly explain what it is and what it does. The most handy thing is that every help file will suggest whether you should really use the item or not. Many help files end with "If you're not sure, it is safe to say N here", thus letting you know that it is safe to leave that particular item out of the kernel.
* You can use the ISO kernel! The configuration used to make the kernel for the ISO is the same configuration you'll see when you start your kernel customization. If you leave the configuration the way it is, the only thing you truly have to worry about is your network and, if you want it, sound. There are also two additional default configurations available on the ISO that are available to you called "config.safe" and "config.server". We'll show you how to load these configurations in just a little bit. [TODO: check these files]
* Never build filesystems or core components as modules! Make sure that whatever filesystems you decided to use for your partitions earlier are built into the kernel, and are not separate modules. Likewise, make sure that certain crucial things like ide and scsi drivers are not modules, as this will make your machine unbootable. (This rule doesn't apply to the scsi low level drivers though; they can be modules.) Modules are kernel drivers that can be manually activated and deactivated after the system has been booted, but not during boot time. The kernel from the ISO already has all the filesystems available during the installation built into the kernel, so if you don't change anything there, you will be fine.

You will be shown two screens of information before you actually begin you kernel configuration, letting you know that you are going to need a few things built into the kernel in order to have Lunar run properly, and what options you have for boot loaders. Lunar comes with both lilo (LInux LOader) and grub (GRand Unified Bootloader).

If you don't have much experience with bootloaders, we suggest using lilo for now, as the installation program will set up the configuration file for you. If you would prefer to use grub, and we encourage folks to learn how to use it, be forewarned that the installation program does not set up any configuration at all for you.

[On the 1.6.5-rc1-x86_64 ISO] There is only one kernel available for you to choose from:

* ''linux-2.6.'' -- Latest 2.6 kernel with minor patchlevel patches (2.6.x.Y)

For our example, we are going to use linux-2.6.

Before you begin is which type of configuration method you would like to use.

* ''config'' -- The original way to configure the linux kernel. It is completely text based, and assumes you know what everything is. Unless you've been using linux since its inception, you probably don't want to use this method.
* ''menuconfig'' -- As the name implies, a menu driven version of the kernel configuration. This is the easiest, and by far the most popular way of configurating your kernel.
* ''xconfig'' -- If you have an X server running, you can use this option to configure your kernel using a nifty GUI interface. You won't be able to use this on the ISO, but once your system is up and running with X, you can use this option. If you do choose this option while installing from the ISO, the system will fall back to next available configuration method, in this case menuconfig, so there is no harm in selecting it if you do.

For our example, we are going to use menuconfig. Once Lunar is finished applying the patches for the kernel, which can take a minute or two, you'll be brought to the configuration screen for the linux kernel.

As we mentioned earlier, the configuration that was used to build the kernel for the ISO is the same configuration that you'll be presented with when you start. However, as we also mentioned earlier, there are two alternate kernel configurations available to you that you may want to use; config.safe and config.server. Both of these configurations can be found on the ISO, along with the original default config file, in /etc/lunar/local. When you are looking at the kernel menuconfig main page, scroll all the way to bottom, and you will find an option called "Load an Alternate Configuration File". Select this and then give the absolute path to the alternate configuration file, i.e. /etc/lunar/local/.config.server. As with all kernel configuration files, they are hidden files preceded with a ".", so make sure to not forget it.

Once you have completed configuring your kernel, you'll get one more prompt from the installer asking if you want to go back to the configuration in case you exited by mistake or forgot something. If everything is good to go, say no here and sit back for a few minutes while your kernel compiles.

==Setting Up Networking==

The final step is to set up networking. When you select the "Set Up Networking" option, you'll be prompted by a series of questions as to what kind of card you have (only needed if you built your networking device as a module, and not part of the kernel), if you need to set up wireless or not, and whether you'll need to use dhcp or not. You should be familiar enough with your network to set this up on your own, as the questions put to you are very straightforward.

* if you use dhcp, you don't need to set up the default gateway or DNS because dhcp will take care of them for you.
* you are using a wireless connection with wpa_supplicant, you might want to run "wpa_passphrase" to set up a simple /etc/wpa_supplicant.conf rather than try to edit the example file.

==Other settings==

The installer will prompt you now for some more settings. You should set a root password and generate ssh host keys to identify your box uniquely for later. You might also want to administrate services on the newly installed machine.

==Reboot!==

Once you have completed setting up your networking, you are finished installing Lunar Linux! Congratulations! Select the option "Done" and remove the cd from the drive when it ejects. Your Lunar system is now ready to go!

==Upgrade Moonbase==

After the initial installation and reboot, please follow the instructions given in '''man lfirsttime''' to bring your system up-to-date.

Congratulations! You now have a minimal system as a foundation on which to build.

WARNING: while the pre-compiled 2.6.35.3 kernel on the ISO is the same as the one in the moonbase, it won't be rebuilt as part of the first
'''lunar update'''. If you experience problems with ALSA or NVIDIA, you may need to run '''lin linux-2.6''' to rebuild the kernel explicitly.
This problem should go away once a newer version of the kernel is available.

==Where to go from here==
To install a desktop environment check out this page. [[Lunar_Linux:DesktopEnvironments]]

''Have Phun!!''

[http://www.gnu.org/copyleft/ Copyleft] 2004-2010 [http://lunar-linux.org/ The Lunar Penguin Team]

Lunar Installation Manual and Harassment of Lunar Developers by Drew Swayze (drew AT lunar-linux DOT org).

Edits and Nitpicking by Suzanne Burns (sburns AT lunar-linux DOT org).

Initial update for the 1.6.5 ISO by Duncan Gibson (engelsman AT lunar-linux DOT org).

Template:Main Page:About

2010-08-22T10:51:24Z

Engelsman:

<div style="float: right; padding-top: 0.1em; padding-right: 15px;">
{{ed|Main_Page:About|}}
</div>

==[[Lunar Linux:About|'''About Lunar Linux''']]==

'''Lunar Linux''' is a [[wikipedia:source code|source]] based [[wikipedia:Linux distribution|Linux distribution]]. It is built entirely by [[wikipedia:compiler|compiling]] [[wikipedia:source code|source code]], using custom [[wikipedia:Optimization (computer_science)|optimizations]].

It installs a complete [[wikipedia:Bootstrap#Computing|bootstrap]] development system first. After telling the Lunar package manager which software will be required, it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward the users specific needs.
This should result in a lean and optimized [[wikipedia:operating system|operating system]]. On the downside, compiling a whole distribution from scratch may be time-consuming and complicate the task of keeping the packages up to date.

Currently, Lunar only supports the [[wikipedia:X86|x86]] and [[wikipedia:X86-64|x86-64]] architectures.

Lunar Linux is licensed under the GPLv2.

'''2010-08-22''': Despite appearances, Lunar Linux is still very much alive. There was a 1.6.5-rc1 ISO release on 2010-07-09 and the official 1.6.5 ISO release is expected shortly. The Forums and Wiki are inactive because they were locked after prolonged spam-bot vandalism. If you require help, simply go to the #lunar irc channel and ask!

<div style="text-align: right; font-variant: small-caps; padding-right: 15px;">
[[Lunar Linux:About|More Information]]
</div>

User talk:Engelsman

2010-07-29T19:30:05Z

Engelsman: 2.6.33.4 to 2.6.34.1 update needed UUIDs

Lunar Linux:DesktopEnvironments

2010-07-25T11:42:54Z

Engelsman: fixed typo

==Desktop Environments==

__TOC__

===Minimal Installation===

Once you have successfully completed the installation of the ISO '''and''' completed the post-install tasks described in [[Installation:lfirsttime.8.manpage|man lfirsttime]], what you are left with is a pretty minimal installation -- this is deliberate! [[Lunar Linux]] now gives you the power and the freedom to customize your system to your own specific needs.

* If you want to set up a lean, mean server you don't have to uninstall lots of things and hope that you have closed any potential security holes, you have a secure system on which to build. You probably don't need to read the rest of this article either.
* If you want to set up a full desktop environment, or a light-weight window manager, then you still have a little work to do.

===Tips for new users===

If you have a "standard" hardware configuration, and you stick to the defaults, the installation of [[Lunar Linux]] should be straightforward, and therefore appears deceptively simple. There are some things that you can do to keep things running smoothly:

* Keep it simple.
* Take it one step at a time.
* Build a working system first.
* Add the bells and whistles later.

In Lunar, modules have explicit dependencies on those things that are really needed, so installing 'a' will first install 'b' and 'c' for you. Some modules have explicit optional dependencies on ''nice-to-have'' features, so if 'd' isn't already installed you will be asked whether you want to install it too. Saying yes could mean installing all of those modules that 'd' depends on as well. In addition, each module's own configuration process may detect what is, and isn't installed, and adapt itself accordingly. Note that you can preview what will be built and pre-answer the installation questions by using 'lin -r --deps' before running the real 'lin'.

Usually all of this Just Works[TM], but sometimes a module fails to build. Sometimes dependencies have changed, or are missing, and you may need to install the missing module explicitly before trying again. If it's an optional dependency, re-run with 'lin -rc' and this time say yes, or maybe even no. If it can't download the source file, Go to the website for that package and see if you can download it manually, and save it in /var/spool/lunar. If you have persistent problems downloading source files, run 'lunar' and check whether changing the mirror site helps.

The ISO comes with ''screen'' for switching between virtual terminals, an ascii-based web browser called ''lynx'' and the IRC clients ''irssi'' and ''ircii'', so you may be able to find sources and additional help yourself. If you do have problems, please join the #lunar channel and maybe someone will be available in your timezone who will be able to help you:

irssi -c irc.freenode.net # /join lunar

===First install X explicitly===

Even though [[Lunar Linux]] isn't aimed at new Linux users and assumes that you have some idea what you are doing, many people installing for the first time forget to install X first. ''Wait!'' I hear you gasp, ''Isn't X installed automatically? No? Why not?'' The reason is simple: adding the dependency tracking to all modules that might need to use X would be an awful lot of work, would lead to a very dense dependency tree that would be hard to manage, and would affect all users, even if they wanted to run a lean, mean, headless server. And as Lunar users are supposed to know what they are doing, you should also know that if you want to run graphical applications, you should first install the graphical environment.

You don't need to install all of the X components one by one, although you are free to do so if you really want. [[Lunar Linux]] provides a ''profile module'' called XOrg7 that is a sort of dummy module that doesn't do anything itself, but it depends on a lot of other modules. Installing a ''profile module'' therefore installs all of the modules that it depends on. To install a "standard" X environment simply:

lin XOrg7 ; lin additional drivers...

You can find the additional drivers under /var/lib/lunar/moonbase/xorg7/drivers, or run ''lvu section xorg7/drivers''.

However, this doesn't install all possible X applications. There are some, like xterm, xhost and the desktop environments, of course, that you will need to install separately.

At this point you can run 'startx' to have a very basic session in the 'twm' window manager. You might now want to install an X-based web browser and IRC client before going further.

===XFCE===

[http://www.xfce.org Xfce] is a lightweight desktop environment for various *NIX systems. In the past, many of the Lunar developers were also Xfce developers, so Xfce has traditionally been the best integrated into [[Lunar Linux]]. You can install all of the components one by one, or you can install the "standard" environment in one go using the xfce4 ''profile module'':

lin xfce4

===KDE===

[http://www.kde.org KDE] has one Lunar developer who is actively following the official releases, and therefore updates to the KDE modules in Lunar usually occur within a few days of the official release. You can install the "standard" environment using the kde4 ''profile module'':

lin kde4

===GNOME===

[http://www.gnome.org] is not so popular with the Lunar developers and as a result it is not as up-to-date as Xfce and KDE. In fact, we could really use some help! You can install the "standard" environment using the gnome2 ''profile module'' but be prepared to give it a helping hand:

lin gnome2

===Lightweight Window Managers===

As well as the "big three" above, [[Lunar Linux]] also provides modules for several lightweight window managers, although these are not guaranteed to be up-to-date. You can find many of them under /var/lib/lunar/moonbase/x11-wm or by using ''lvu section x11-wm''. Some of these come from [[Module Submission|module submissions]] by Lunar users.

Note that some cutting-edge developments can also be found in the [[Moonbase#Sections|zbeta]] section of the [[Moonbase]] but are not guaranteed to be stable.

Lunar Linux:DesktopEnvironments

2010-07-25T11:38:01Z

Engelsman: added section Tips for new users

==Desktop Environments==

__TOC__

===Minimal Installation===

Once you have successfully completed the installation of the ISO '''and''' completed the post-install tasks described in [[Installation:lfirsttime.8.manpage|man lfirsttime]], what you are left with is a pretty minimal installation -- this is deliberate! [[Lunar Linux]] now gives you the power and the freedom to customize your system to your own specific needs.

* If you want to set up a lean, mean server you don't have to uninstall lots of things and hope that you have closed any potential security holes, you have a secure system on which to build. You probably don't need to read the rest of this article either.
* If you want to set up a full desktop environment, or a light-weight window manager, then you still have a little work to do.

===Tips for new users===

If you have a "standard" hardware configuration, and you stick to the defaults, the installation of [[Lunar Linux]] should be straightforward, and therefore appears deceptively simple. There are some things that you can do to keep things running smoothly:

* Keep it simple.
* Take it one step at a time.
* Build a working system first.
* Add the bells and whistles later.

In Lunar, modules have explicit dependencies on those things that are really needed, so installing 'a' will first install 'b' and 'c' for you. Some modules have explicit optional dependencies on ''nice-to-have'' features, so if 'd' isn't already installed you will be asked whether you want to install it too. Saying yes could mean installing all of those modules that 'd' depends on as well. In addition, each module's own configuration process may detect what is, and isn't installed, and adapt itself accordingly. Note that you can preview what will be built and pre-answer the installation questions by using 'lin -r --deps' before running the real 'lin'.

Usually all of this Just Works[TM], but sometimes a module fails to build. Sometimes dependencies have changed, or are missing, and you may need to install the missing module explicitly before trying again. If it's an optional dependency, re-run with 'lin -rc' and this time say yes, or maybe even no. If it can't download the source file, Go to the website for that package and see if you can download it manually, and save it in /var/spool/lunar. If you have persistent problems downloading source files, run 'lunar' and check whether changing the mirror site helps.

The ISO comes with ''screen'' for switching between virtual terminals, an ascii-based web browser called ''lynx'' and the IRC clients ''irssi'' and ''ircii'', so you may be able to find sources and additional help yourself. If you do have problems, please join the #lunar channel and maybe someone will be available in your timezone who will be able to help you:

irssi -c irc.freenode.net # /join lunar

===First install X explicitly===

Even though [[Lunar Linux]] isn't aimed at new Linux users and assumes that you have some idea what you are doing, many people installing for the first time forget to install X first. ''Wait!'' I hear you gasp, ''Isn't X installed automatically? No? Why not?'' The reason is simple: adding the dependency tracking to all modules that might need to use X would be an awful lot of work, would lead to a very dense dependency tree that would be hard to manage, and would affect all users, even if they wanted to run a lean, mean, headless server. And as Lunar users are supposed to know what they are doing, you should also know that if you want to run graphical applications, you should first install the graphical environment.

You don't need to install all of the X components one by one, although you are free to do so if you really want. [[Lunar Linux]] provides a ''profile module'' called XOrg7 that is a sort of dummy module that doesn't do anything itself, but it depends on a lot of other modules. Installing a ''profile module'' therefore installs all of the modules that it depends on. To install a "standard" X environment simply:

lin XOrg7 ; lin additional drivers...

You can find the additional drivers under /var/lib/lunar/moonbase/xorg7/drivers, or run ''lvu section xorg7/drivers''.

However, this doesn't install all possible X applications. There are some, like xterm, xhost and the desktop environments, of course, that you will need to install separately.

At this point you can run 'startx' to have a very basic session in the 'twm' window manager. You might now want to install an X-based web browser and IRC client before going further.

===XFCE===

[http://www.xfce.org Xfce] is a lightweight desktop environment for various *NIX systems. In the past, many of the Lunar developers were also Xfce developers, so Xfce has traditionally been the best integrated into [[Lunar Linux]]. You can install all of the components one by one, or you can install the "standard" environment in one go using the xfce4 ''profile module'':

lin xfce4

===KDE===

[http://www.kde.org KDE] has one Lunar developer who is actively following the official releases, and therefore updates to the KDE modules in Lunar usually occur within a few days of the official release. You can install the "standard" environment using the kde4 ''profile module'':

lin kde4

===GNOME===

[http://www.gnome.org] is not so popular with the Lunar developers and as a result it is not as up-to-date as Xfce and KDE. In fact, we could really use some help! You can install the "standard" environment using the gnome2 ''profile module'' but be prepared to give it a helping hand:

lin gnome2

===Lightweight Window Managers===

As well as the "big three" above, [[Lunar Linux]] also provides modules for several lightweight window managers, although these are not guaranteed to be up-to-date. You can find many of them under /var/lib/lunar/moonbase/x11-wm or by using ''lvu section x11-wm''.Some of these come from [[Module Submission|module submissions] by Lunar users.

Note that some cutting-edge developments can also be found in the [[Moonbase#Sections|zbeta]] section of the [[Moonbase]] but are not guaranteed to be stable.

Lunar Linux:DesktopEnvironments

2010-07-24T18:34:43Z

Engelsman: initial draft

==Desktop Environments==

__TOC__

===Minimal Installation===

Once you have sucessfully completed the installation of the ISO '''and''' completed the post-install tasks described in [[Installation:lfirsttime.8.manpage|man lfirsttime]], what you are left with is a pretty minimal installation -- this is deliberate! [[Lunar Linux]] now gives you the power and the freedom to customize your system to your own specific needs.

* If you want to set up a lean, mean server you don't have to uninstall lots of things and hope that you have closed any potential security holes, you have a secure system on which to build. You probably don't need to read the rest of this article either.
* If you want to set up a full desktop environment, or a light-weight window manager, then you still have a little work to do.

===First install X explicitly===

Even though [[Lunar Linux]] isn't aimed at new Linux users and assumes that you have some idea what you are doing, many people installing for the first time forget to install X first. ''Wait!'' I hear you gasp, ''Isn't X installed automatically? No? Why not?'' The reason is simple: adding the dependency tracking to all modules that might need to use X would be an awful lot of work, would lead to a very dense dependency tree that would be hard to manage, and would affect all users, even if they wanted to run a lean, mean, headless server. And as Lunar users are supposed to know what they are doing, you should also know that if you want to run graphical applications, you should first install the graphical environment.

You don't need to install all of the X components one by one, although you are free to do so if you really want. [[Lunar Linux]] provides a ''profile module'' called XOrg7 that is a sort of dummy module that doesn't do anything itself, but it depends on a lot of other modules. Installing a ''profile module'' therefore installs all of the modules that it depends on. To install a "standard" X environment simply:

lin XOrg7 ; lin additional drivers...

You can find the additional drivers under /var/lib/lunar/moonbase/xorg7/drivers, or run ''lvu section xorg7/drivers''.

However, this doesn't install all possible X applications. There are some, like xterm, xhost and the desktop environments, of course, that you will need to install separately.

===XFCE===

[http://www.xfce.org Xfce] is a lightweight desktop environment for various *NIX systems. In the past, many of the Lunar developers were also Xfce developers, so Xfce has traditionally been the best integrated into [[Lunar Linux]]. You can install all of the components one by one, or you can install the "standard" environment in one go using the xfce4 ''profile module'':

lin xfce4

===KDE===

[http://www.kde.org KDE] has one Lunar developer who is actively following the official releases, and therefore updates to the KDE modules in Lunar usually occur within a few days of the official release. You can install the "standard" environment using the kde4 ''profile module'':

lin kde4

===GNOME===

[http://www.gnome.org] is not so popular with the Lunar developers and as a result it is not as up-to-date as Xfce and KDE. In fact, we could really use some help! You can install the "standard" environment using the gnome2 ''profile module'' but be prepared to give it a helping hand:

lin gnome2

===Lightweight Window Managers===

As well as the "big three", [[Lunar Linux]] also provides modules for several lightweight window managers, although these are not guaranteed to be up-to-date. You can find many of them under /var/lib/lunar/moonbase/x11-wm or by using ''lvu section x11-wm''.

Note that some cutting-edge developments can also be found in the [[Moonbase#Sections|zbeta]] section of the [[Moonbase]] but are not guaranteed to be stable.

Lunar Linux:DesktopEnvironments

2010-07-24T17:10:29Z

Engelsman: initial draft

==Desktop Environments==

__TOC__

===Minimal Installation===
Once you have sucessfully completed the installation of the ISO '''and''' the tasks described in [[Installation:lfirsttime.8.manpage|man lfirsttime]] what you are left with is a pretty minimal installation -- this is deliberate! [[Lunar Linux]] now gives you the power and the freedom to customize your system to your own specific needs.

* If you want to set up a lean, mean server you don't have to uninstall lots of things and hope that you have closed all security holes, you have a secure system on which to build. You probably don't need to read the rest of this article either.
* If you want to set up a full desktop environment, or a light-weight window manager, then you still have a little work to do.

===Explicitly install X first===

Even though [[Lunar Linux]] isn't aimed at new Linux users and assumes that you have some idea what you are doing, many people installing for the first time forget to install X first. ''Wait!'' I hear you gasp, ''Isn't X installed automatically? Why not?'' The reason is simple: adding the dependency tracking to all modules that might need to use X would be an awful lot of work, would lead to a very dense dependency tree that would be hard to manage, and would affect all users, even if they wanted to run a lean, mean, headless server. And as Lunar users are supposed to know what they are doing, you should also know that if you want to run graphical applications, you should first install the graphical environment.

You don't need to install all of the X components one by one, although you are free to do so if you really want. [[Lunar Linux]] provides a '''profile module''' called XOrg7 that is a sort of dummy module that doesn't do anything itself, but it depends on a lot of other modules. Installing a '''profile module''' therefore installs all of the modules that it depends on. To install a "standard" X environment simply:

lin XOrg7 ; lin additional drivers...

You can find the additional drivers under /var/lib/lunar/moonbase/xorg7/drivers, or run ''lvu section xorg7/drivers''.

However, this doesn't install all possible X applications. There are some, like xterm and xhost, that you will need to install manually.

Template:Main Page:Documentation

2010-07-24T16:31:35Z

Engelsman: link to new Desktop Environment page

<div style="float: right; padding-top: 0.1em; padding-right: 15px;">
{{ed|Main_Page:Documentation|}}
</div>

<h2 style="font-variant: small-caps;">[[Lunar Linux/Documentation|Documentation]]</h2>

<h4>General</h4>
* [[Lunar Linux:FAQ|Frequently Asked Questions]]

<h4>Installation</h4>
* [[Lunar Linux:Installation-1.6.5|Installation-1.6.5 (latest)]]
* [[Lunar Linux:Installation|Installation-1.5.0 (old)]]
* [[Lunar Linux:DesktopEnvironments|Desktop Environments, etc]]

<h4>Moonbase</h4>
* [[Moonbase|The Lunar Moonbase]]
* [[Module Basics|A basic module outline]]
* [[Module Writing|Writing Lunar-Linux Modules]]
* [[Module Functions|Module Function List]]
* [[Module Submission|Submitting modules]]

<h4>Other</h4>
* [irc://irc.freenode.net/lunar #Lunar] on [http://freenode.net/ Freenode.net]
* [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List] [http://lunar-linux.org/pipermail/lunar/ (archive)]
* [http://lunar-linux.org/pipermail/lunar-bugs/ Lunar Bugs Mailing-List] [http://lunar-linux.org/mailman/listinfo/lunar-bugs (archive)]
* [http://lunar-linux.org/pipermail/lunar-commits/ Lunar Commits Mailing-List] [http://lunar-linux.org/mailman/listinfo/lunar-commits (archive)]

<div style="text-align: right; font-variant: small-caps; padding-right: 15px;">
[[Lunar Linux/Documentation|More Information]]
</div>

Template:Main Page:Documentation

2010-07-23T20:08:38Z

Engelsman: added link to Installation-1.6.5

<div style="float: right; padding-top: 0.1em; padding-right: 15px;">
{{ed|Main_Page:Documentation|}}
</div>

<h2 style="font-variant: small-caps;">[[Lunar Linux/Documentation|Documentation]]</h2>

<h4>General</h4>
* [[Lunar Linux:FAQ|Frequently Asked Questions]]

<h4>Installation</h4>
* [[Lunar Linux:Installation-1.6.5|Installation-1.6.5 (latest)]]
* [[Lunar Linux:Installation|Installation-1.5.0 (old)]]

<h4>Moonbase</h4>
* [[Moonbase|The Lunar Moonbase]]
* [[Module Basics|A basic module outline]]
* [[Module Writing|Writing Lunar-Linux Modules]]
* [[Module Functions|Module Function List]]
* [[Module Submission|Submitting modules]]

<h4>Other</h4>
* [irc://irc.freenode.net/lunar #Lunar] on [http://freenode.net/ Freenode.net]
* [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List] [http://lunar-linux.org/pipermail/lunar/ (archive)]
* [http://lunar-linux.org/pipermail/lunar-bugs/ Lunar Bugs Mailing-List] [http://lunar-linux.org/mailman/listinfo/lunar-bugs (archive)]
* [http://lunar-linux.org/pipermail/lunar-commits/ Lunar Commits Mailing-List] [http://lunar-linux.org/mailman/listinfo/lunar-commits (archive)]

<div style="text-align: right; font-variant: small-caps; padding-right: 15px;">
[[Lunar Linux/Documentation|More Information]]
</div>

Template:Main Page:Documentation

2010-07-23T20:06:32Z

Engelsman: added link to Installation-1.6.5

<div style="float: right; padding-top: 0.1em; padding-right: 15px;">
{{ed|Main_Page:Documentation|}}
</div>

<h2 style="font-variant: small-caps;">[[Lunar Linux/Documentation|Documentation]]</h2>

<h4>General</h4>
* [[Lunar Linux:FAQ|Frequently Asked Questions]]

<h4>Installation</h4>
* [[Lunar Linux:Installation|Installation-1.6.5 (latest)]]
* [[Lunar Linux:Installation|Installation-1.5.0 (old)]]

<h4>Moonbase</h4>
* [[Moonbase|The Lunar Moonbase]]
* [[Module Basics|A basic module outline]]
* [[Module Writing|Writing Lunar-Linux Modules]]
* [[Module Functions|Module Function List]]
* [[Module Submission|Submitting modules]]

<h4>Other</h4>
* [irc://irc.freenode.net/lunar #Lunar] on [http://freenode.net/ Freenode.net]
* [http://lunar-linux.org/mailman/listinfo/lunar Lunar Mailing-List] [http://lunar-linux.org/pipermail/lunar/ (archive)]
* [http://lunar-linux.org/pipermail/lunar-bugs/ Lunar Bugs Mailing-List] [http://lunar-linux.org/mailman/listinfo/lunar-bugs (archive)]
* [http://lunar-linux.org/pipermail/lunar-commits/ Lunar Commits Mailing-List] [http://lunar-linux.org/mailman/listinfo/lunar-commits (archive)]

<div style="text-align: right; font-variant: small-caps; padding-right: 15px;">
[[Lunar Linux/Documentation|More Information]]
</div>

Lunar Linux:Installation/1.6.5

2010-07-23T20:01:20Z

Engelsman: Initial update for 1.6.5-rc1 ISO

__TOC__

Lunar Linux is a revolutionary Linux distribution in that it is not binary based, as are most distributions, but is instead built entirely by compiling source code, using your own custom optimizations.

Essentially, it installs a complete bootstrap development system on your machine, and then you tell the Lunar package manager what tools you want, and it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward your specific needs.

The result is a leaner, meaner, refreshingly uncluttered, and strikingly faster operating system than most Linux distributions.

This installation guide is designed to get you through the installation process as painlessly as possible. It assumes that you have some experience with Linux or another Unix variant, and have a general idea of what you are doing. If you are unfamiliar with such things as partitions, or have never used Linux before, Lunar may not be the best introduction for you into the world of open source. There are always Lunar gods available on irc.freenode.net in the #lunar channel to answer any questions that this manual may not make quite clear enough.

With that said, we hope you enjoy using Lunar!

==About this installation manual==

Although this manual is not intended to be a full and complete overview of any situation you may be confronted with, given the wide diversity of hardware available these days, it is intended to be an introduction to the world of Lunar Linux. You will see examples that are not tailored towards your to-be built server or workstation, optimizations that are overly broad or too specific, and examples that don't apply to any real situations. We tried hard to give you the idea of how much power you have over how you can setup your system, but we are forgetting to tell you how to run your own server or desktop (or other system) at all. That means that the examples and steps taken most probably do not apply to your situation at all.

Do not despair: if you understand what is going on and you get the idea, the installer will allow you to do pretty much everything you want to do with your system. There are really (almost) no limits.

==Getting the ISO==

The primary site for retrieving the ISO is [http://www.lunar-linux.org/ lunar-linux.org]. There, you will find links to our US, EU, and Internet2 mirrors, as well as a Bittorrent link. As of this writing, the current version of the Lunar ISO is version 1.6.5-rc1, codename Mare Ingenii (20100709). (''Check the main site for the actual latest version!'')

Locate and retrieve the file lunar-1.6.5-rc1-i686.iso.bz2 (or lunar-1.6.5-rc1-x86_64.iso.bz2 if you have a 64-bit system). After downloading this file, you will need to unpack the ISO using bzip2. Windows users will need a program that can extract bzip2 archives, like WinZip (also capable of extracting bzip2 archives under windows are Winrar, powerarchiver and 7-Zip). Mac should unzip the file by itself. Then all that is left to do is use your favorite program to burn the ISO to a cdrom and begin the installation. Lunar can also be installed without using a CD. If you need to do it this way, our [[FAQ]] provides simple instructions.

It should be noted that the 1.6.5 ISO and Lunar use udev for device management. The devfs system, and the "old-school" method of manually installing devices, are no longer supported.

We are assuming the you are installing Lunar as your primary OS. Make sure you have a backup of any important data that you need to retain. The Lunar Linux Project and its developers are not responsible in any way for any loss of data on your system!

==Booting the ISO==

Upon booting the ISO, the first thing you will see are options for booting the ISO kernel, or for performing RAM tests [Note: MemTest is not available on x86_64]. There is even a safe mode which will disable DMA, MTRR, RAID, LVM, USB keyboards, NTFS, HPFS, Advanced Partitions, and Firewire. Most folks, however, will be just fine pressing enter at the boot prompt and loading the default kernel.

To boot the iso with support for your usb keyboard:
''linux uhci-hcd ehci-hcd''

After loading the kernel, the first screen presents you with a few options. If there are extra modules you need to load in order continue with the install, they can be loaded here. There is also a shell option. However, if you are using this ISO for rescue purposes, you do not want to shell out here; rather continue booting and shell out in the next section. Most people will select "continue booting" here.

It should be noted that the 1.6.5 ISO tries to autodetect some hardware (mostly scsi drivers and network interfaces) during this stage. This will help you establish a network connection if you desire so during installation. For this reason the programs 'dhcpcd' and 'ftp' are already available at this stage.

==Virtual Consoles==

Once the ISO has booted into the installer, you can immediately shell out or switch to one of the other virtual consoles. These will have ready to go root shells and are available throughout the installer sequence. With these you can start rescue actions, setup networking or double check the install progress and make manual adjustments.

==Language and keyboard interface Settings==

After reading the introduction, you will be presented with options for choosing the proper font, keymap, and language for your install.
You will also need to choose an editor, as you are going to need one later on in the installation for setting up your lilo or grub configuration. The choices available are e3, [e3/emacs], joe, nano, vi, and zile. If you have never used a text editor in Linux before, nano is the best choice for you. If you skip the Native Language Support option, the system will install the default editor, nano, for you. When you have finished setting up your options, press cancel to return to the main setup menu.
Less important for most people is the ability to choose the console font, although it may help display some non-English characters. Most people will want to set the system-default language variable and editor though. All these values are unset by default, so make sure you set them now.
The keymap table allows people to use azerty and dvorak keyboards, and much more. This is especially required for non-English keyboards which provide many accented characters.
All these language and keymap settings might not apply to the lunar code itself, which (currently) does not have any international support, but most programs that run during the installer sequence, and after booting into your new system, will be affected properly.

Warning: the keymap entry appears to default to ANSI-dvorak so make sure that you really select what you want.

==Creating or editing Partitions==

The next step is to set up partitions on your hard drive. Upon selecting the "Partition Drive" option, you will be shown a list of all the discs the kernel has detected. For this guide, we will assume that you have one hard drive connected via an IDE channel, which will show up in the menu as "disc0". After selecting the disc to partition, you are given the option of using one of three partitioning programs. They are:

* cfdisk -- A menu driven partitioner, and very easy to use. If you are unfamiliar with various partitioning programs, this is the best option for you.
* fdisk -- Text based partitioner that requires a little more know-how than cfdisk. More experienced users will probably use this program. However new users should not be daunted, as it does have help offered at every step.
* parted -- Text based partitioner that is good for advanced users. Parted is excellent for resizing current partitions on your hard disk, however be forewarned that resizing partitions is an excellent way to hose your entire disc.

Note: under the <Settings> option on the main menu there is an option to configure the fstab mount style as DEV, LABEL or UUID. The first is the traditional Linux method, but can sometimes give problems if a kernel update causes the disk to be renamed. The default is UUID, which uses a unique marker on the partition to avoid this problem.

For our example, we have a 40GB IDE drive and we'll set up six partitions; /, /boot, /home, /usr, /var, and a swap partition. It's a good idea to keep certain directories, such as /var and /usr on separate partitions, as this can save you a lot of headache in the future in case your disk ever completely fails on you and you need to recover data (God forbid!). Also, when you have a separate /boot partition as we have in our example, you need to have your partitioning program mark that partition as active or bootable. In our example, if we were using fdisk, you would press "a" at the command line, and then select part1 as the active partition.

You might also want to install a /tmp partition. By default, Lunar will create a tempfs filesystem mounted on /tmp (tempfs minimizes filesystem fragmentation because it resides in volatile memory). This can be a good choice if you have a lot of memory on your machine. If memory is tight, we recommend creating a /tmp partition to minimize filesystem fragmentation.

It is important to note that you <span class="emphasis">''can not''</span> mount the directories /etc, /bin, /sbin, /dev, /lib and /proc on separate partitions. These directories need to be contained within the root ("/") directory. The installation program should block you from doing this, but it's best not to try.

Here's our partition setup:

1 /boot 100MB
2 / 4GB
3 swap 1GB
5 /usr 10GB
6 /var 10GB
7 /home 15GB

(''If you're wondering about this choice of partitions: it's really just an example. Read the [[FAQ#So_how_should_I_partition_my_disk.3F|FAQ]] on what makes sense in the real world''))

You'll notice that there is no fourth partition in our list above. In order for you to have more than four partitions on a single drive, the fourth partition is made into what is known as an extended or logical partition in which the fifth, sixth, and seventh (etc, etc) partitions reside. For our example above, if we were using fdisk, we would make the fourth partition an extended/logical partition that was 35GB, and then the fifth, sixth, and seventh partitions in our scheme resided within it. However, if we used cfdisk, we would just worry about creating six partitions, making sure that the first three are the primary type, and the last three logical.

Note that the names and mount points for these partitions will be assigned during the next step of this process, when you mount the partitions. Write down exactly what partitions you are planning to create because it can otherwise get confusing!

Lunar offers two choices when it comes to swap. You can set up a swap partition, as we have in our example, or you can set up a swapfile in the root directory. We recommend setting up a swap partition, as you will get better performance with it than with the swapfile. However, there may be a need for you to set up the swapfile instead, which can be setup and activated after you have mounted your other partitions.

==Selecting Partitions and Filesystems==

After creating your partitions, you need to select them and assign file systems. Select the menu option "Select Filesystems" and verify that you are indeed done creating partitions.

The partitions can be selected in random order with the new installer. First select the partition and then assign a filesystem and mountpoint to it. The installer will add this to the job queue and formatting and mounting takes place later so you can edit your selection. Here's a list of filesystems that are currently supported:

* ''ext4'' (Fourth Extended File System) -- Version 4 of the Extended File System, which was ... TO BE COMPLETED.
* ''ext3'' (Third Extended File System) -- Version 3 of the Extended File System, which is essentially just the journaled version of ext2. This filesystem is available with all kernels on the ISO.
* ''ext2'' (Second Extended File System) -- Version 2 of the Extended File System, which was designed for linux as a replacement for the Minix Filesystem. Ext2 is not a journaled filesystem, which means that you'll need to perform disc recovery operations after a power failure or other such system crash. This filesystem is available with all kernels on the ISO.
* ''reiserfs'' (Reiser Filesystem) -- Journaled filesystem created by Hans Reiser that is excellent for use with extremely small files. This filesystem is available with all kernels on the ISO.
* ''xfs'' -- Created by SGI for IRIX, SGI's brand of Unix, and later ported to linux under the GPL. A journaled filesystem that SGI claims is better than any other at handling extremely large files and sparse files. This filesystem is only available with the lunar or grsec patched kernels, which we will come to in a few steps.
* ''jfs'' (Journaled File System) -- Created by IBM for AIX, IBM's brand of Unix, and later ported to linux by IBM under the GPL. A journaled filesystem that is very good at handling high throughput issues. This filesystem is available with all kernels on the ISO.
* ''swap'' Swap (Virtual memory or paging filesystem) for swap partitions only!

After selecting the filesystem type you wish to use, you will be prompted through a series of steps to initialize the partition. You'll notice that the prompts are quite redundant in nature in order to be absolutely positive that you will not inadvertantly erase crucial data that you might have on a working filesystem. In addition, if you have more than four partitions, as we do in our example, you don't want to select any file systems on the fourth partition, as it is the extended partition that houses the fifth, sixth (and so on) partitions. (The installer will try to detect this and skip the extended partition from the list).

As we mentioned earlier, there is an option in the installation process to set up a swap file in the root partition instead of a swap partition as we have done in our example. The next option after selecting your filesystems is to select a swapfile if you so desire. <span class="emphasis">''If you have set up a swap partition already, as we have done, you can skip this step.''</span> Otherwise, you can set up your swap file here, and the only thing you need to tell the installer is how large you want the file to be. Running without swap completely is also possible of course.

'''Please note during this step, no modifications are made to your filesystem!'''

==Installing Lunar==

Next, we need to ''format'' your partitions, ''mount'' them in the right place, create ''swap'' and transfer the entire Lunar system to the partitions that you now have created. This happens all in one single step.

Select ''Install Lunar'', and the system will proceed to transfer all of the necessary files for you. The installer will display progress as packages are transferred to your system and you'll have some idea how long it will take. On normal machines, this should take about 5 minutes.

At the end of this step, the installer sets various system parameters like language, timezone and vital package configuration files in order for your machine.

==Setting Up Your Compiler Optimizations==

The compiler optimizations is a crucial step, since what you choose will make your system fly! However, it is important that you do not overdo it on you optimization settings, as certain selections can, in some instances, break code while compiling.

The first step is to choose your preferred compiler. There is only one version on the 1.6.5 ISO, so the only option here is GCC 4.4. However, once the main system installation is complete, it is possible to install GCC 3.x -- and even the deprecated GCC 2.x! If you don't intend to install those, you should go to the GCC_4_4 submenu now and set GCC 4.4 as the default compiler.

The GCC_4_4 menu also allows you to change other options:

* ''safe'' : allows you to turn off optimization safety, so you should leave this well alone unless you really know what you are doing. Turning this off will result in many more options appearing than are described below.
* ''bopt'' : allows you to change the base compile-time optimization. Your choice depends on what your needs are. Most folks will want to use -O2 here, as it is the wisest choice. More advanced users may want to use the -O3 option, but it's not for everyone. If you're short on disk space, you would take the -Os Small option. (As an example, we used -Os for the ISO since we were working within a confined amount of disc space.) Those of you with older or slower systems that wouldn't be able to take advantage of faster optimizations may choose a more conservative setting like -O1. For our example system, we will choose -O2.
* ''cpu'' : allows you to set your processor type. This may seem unimportant, but the GCC 4.x [and GCC 3.x] compiler has ways of optimizing code for certain processors
* ''cc_opt'' : allows you to set some limited C/C++ compiler settings. Very few people, if any, would need to turn off the -pipe option.

The unsafe optimizations are:
* ''xtra'' : CPU extensions
* ''spd'' : Specialized optimizations
* ''fpm'' : Floating point optimizations
* ''stack'' : Stack optimizations

==Adding Other Compiler Toolchain Optimizations==

'''You can safely SKIP this entire step!'''

The GNU_LD menu shows the screen for linker options, where you will find that "-s Strip" has already been checked off. Very few people will want to uncheck this option, so we will leave this screen as is.

The GNU_MAKE menu allows you to set the number of concurrent makes. As the hint mentions on the "Concurrent Makes" screen, you'll want to enter in the number of cpu's your machine has. Unless you have a machine with more than one processor, you'll want to leave this field blank.

We are now finished setting up our GCC optimizations! When you have you lunar system up and running, you can always change and tweak these GCC settings by typing "lunar" at the commandline prompt, and going to "Optimization Settings". In addition, if you aren't that familiar with what your processor is capable of using for optimizations, you can go to the shell out option on the ISO and type

cat /proc/cpuinfo

at the prompt and the system will show you all the optimizations that the processor reports it can handle.

==Configuring Your Bootloader==

=== Configuring LILO ===

If you chose to use lilo and also said yes to automatically configuring and running lilo, then most of the work is done for you. If you chose not to hand edit lilo.conf, however, be warned that the default configuration has the system set up to be password protected on boot. You can change this by selecting the option from the menu "Reconfigure LILO".

To turn off password protection, you will need to comment out (with the symbol "#") or delete two lines in your lilo.conf file. The first is "password=lunar", which is found in the top section of the file, and the other is "restricted" which is found right below the name of your kernel in the second section.

The other item of note is whether you want lilo to reside in your MBR (Master Boot Record) or on the first sector of your /boot partition. The line in your lilo.conf file to edit for this purpose is

boot=/dev/sda1

To make lilo get installed on the first sector of your /boot partition, you would leave this line as it is. If you want lilo to be written to your MBR, which is the recommended method, you would change the line to read

boot=/dev/sda

Of course, these examples are pertinent to our setup that we have been using thoughout this manual. Your actual lilo.conf file may be different.

=== Configuring GRUB ===

If you chose grub as your bootloader, you will need to set up the configuration file entirely on your own. An example would be:

default 0
timeout 30
color white/blue white/black
title linux-2.4.25
root (hd0,0)
kernel /vmlinubz-2.4.25-r5.0.0 root=/dev/sda2 devfs=nomount

As we mentioned earlier in the partitioning section, you would want to mark your /boot partition as active. With grub it is ''imperative'' that you mark your /boot partition as active, otherwise grub will not work at all when you are finished with the installation and reboot to your new system.

NOTE: The option to install grub is not available on the 1.6.5-rc1-x86_64 ISO because grub is not yet fully stable on 64-bit systems. If you really know what you are doing, the source tarball is saved to disk, so you can configure it manually once the main installation is complete.
==Installing kernels==

===Installing a precompiled kernel===

The ISO comes with a selection of precompiled kernels and modules that should work for most people. If you have problems getting your kernel to compile, install or getting the right drivers, or just want to get a quick start at lunar, we ''suggest'' that you use this option instead of compiling your own kernel. You can later of course compile as many kernels as you want, and indeed the first ''lunar update'' after the main installation might ask whether you want to update the kernel too. Why do it twice if you don't need to?

There are several kernels for you to choose from. They are:

* ''2.6.34.1'' -- Normal kernel (SMP, 4GB memory max) (RECOMMENDED).
* ''2.6.34.1-safe'' -- Very safe non-optimized minimal kernel (no ACPI, DMA, SMP, 1GB).
* ''2.6.34.1-server'' -- Server optimized (SELINUX, SMP, 64GB, no preempt).

===Building Your Customized Linux Kernel===

We have now come to the most important part of the installation; the configuration of the kernel. The kernel is the heart of Linux, and without it, nothing would work. Configuration is, actually, a rather simple process. All you need to remember is to not panic, and that lunar is going to do most of the work for you. Here are a few pointers that will make the configuration a breeze for you.

* Help is a click away! The people working on creating and maintaining the Linux kernel have help placed throughout the entire configuration process. If you're not sure what something does, just look at the help file for whatever item you're on, and it will almost certainly explain what it is and what it does. The most handy thing is that every help file will suggest whether you should really use the item or not. Many help files end with "If you're not sure, it is safe to say N here", thus letting you know that it is safe to leave that particular item out of the kernel.
* You can use the ISO kernel! The configuration used to make the kernel for the ISO is the same configuration you'll see when you start your kernel customization. If you leave the configuration the way it is, the only thing you truly have to worry about is your network and, if you want it, sound. There are also two additional default configurations available on the ISO that are available to you called "config.safe" and "config.server". We'll show you how to load these configurations in just a little bit. [TODO: check these files]
* Never build filesystems or core components as modules! Make sure that whatever filesystems you decided to use for your partitions earlier are built into the kernel, and are not separate modules. Likewise, make sure that certain crucial things like ide and scsi drivers are not modules, as this will make your machine unbootable. (This rule doesn't apply to the scsi low level drivers though; they can be modules.) Modules are kernel drivers that can be manually activated and deactivated after the system has been booted, but not during boot time. The kernel from the ISO already has all the filesystems available during the installation built into the kernel, so if you don't change anything there, you will be fine.

You will be shown two screens of information before you actually begin you kernel configuration, letting you know that you are going to need a few things built into the kernel in order to have Lunar run properly, and what options you have for boot loaders. Lunar comes with both lilo (LInux LOader) and grub (GRand Unified Bootloader).

If you don't have much experience with bootloaders, we suggest using lilo for now, as the installation program will set up the configuration file for you. If you would prefer to use grub, and we encourage folks to learn how to use it, be forewarned that the installation program does not set up any configuration at all for you.

[On the 1.6.5-rc1-x86_64 ISO] There is only one kernel available for you to choose from:

* ''linux-2.6.'' -- Latest 2.6 kernel with minor patchlevel patches (2.6.x.Y)

For our example, we are going to use linux-2.6.

Before you begin is which type of configuration method you would like to use.

* ''config'' -- The original way to configure the linux kernel. It is completely text based, and assumes you know what everything is. Unless you've been using linux since its inception, you probably don't want to use this method.
* ''menuconfig'' -- As the name implies, a menu driven version of the kernel configuration. This is the easiest, and by far the most popular way of configurating your kernel.
* ''xconfig'' -- If you have an X server running, you can use this option to configure your kernel using a nifty GUI interface. You won't be able to use this on the ISO, but once your system is up and running with X, you can use this option. If you do choose this option while installing from the ISO, the system will fall back to next available configuration method, in this case menuconfig, so there is no harm in selecting it if you do.

For our example, we are going to use menuconfig. Once Lunar is finished applying the patches for the kernel, which can take a minute or two, you'll be brought to the configuration screen for the linux kernel.

As we mentioned earlier, the configuration that was used to build the kernel for the ISO is the same configuration that you'll be presented with when you start. However, as we also mentioned earlier, there are two alternate kernel configurations available to you that you may want to use; config.safe and config.server. Both of these configurations can be found on the ISO, along with the original default config file, in /etc/lunar/local. When you are looking at the kernel menuconfig main page, scroll all the way to bottom, and you will find an option called "Load an Alternate Configuration File". Select this and then give the absolute path to the alternate configuration file, i.e. /etc/lunar/local/.config.server. As with all kernel configuration files, they are hidden files preceded with a ".", so make sure to not forget it.

Once you have completed configuring your kernel, you'll get one more prompt from the installer asking if you want to go back to the configuration in case you exited by mistake or forgot something. If everything is good to go, say no here and sit back for a few minutes while your kernel compiles.

==Setting Up Networking==

The final step is to set up networking. When you select the "Set Up Networking" option, you'll be prompted by a series of questions as to what kind of card you have (only needed if you built your networking device as a module, and not part of the kernel), if you need to set up wireless or not, and whether you'll need to use dhcp or not. You should be familiar enough with your network to set this up on your own, as the questions put to you are very straightforward.

* if you use dhcp, you don't need to set up the default gateway or DNS because dhcp will take care of them for you.
* you are using a wireless connection with wpa_supplicant, you might want to run "wpa_passphrase" to set up a simple /etc/wpa_supplicant.conf rather than try to edit the example file.

==Other settings==

The installer will prompt you now for some more settings. You should set a root password and generate ssh host keys to identify your box uniquely for later. You might also want to administrate services on the newly installed machine.

==Reboot!==

Once you have completed setting up your networking, you are finished installing Lunar Linux! Congratulations! Select the option "Done" and remove the cd from the drive when it ejects. Your Lunar system is now ready to go!

==Upgrade Moonbase==

After the initial installation and reboot, please follow the instructions given in '''man lfirsttime''' to bring your system up-to-date.

Congratulations! You now have a minimal system as a foundation on which to build.

''Have Phun!!''

[http://www.gnu.org/copyleft/ Copyleft] 2004-2010 [http://lunar-linux.org/ The Lunar Penguin Team]

Lunar Installation Manual and Harassment of Lunar Developers by Drew Swayze (drew AT lunar-linux DOT org).

Edits and Nitpicking by Suzanne Burns (sburns AT lunar-linux DOT org).

Initial update for the 1.6.5 ISO by Duncan Gibson (engelsman AT lunar-linux DOT org).

Lunar Linux:Installation/1.6.5

2010-07-23T16:11:30Z

Engelsman: Initial copy of the Installation[-1.5.0] page

__TOC__

Lunar Linux is a revolutionary linux distribution in that it is not binary based, as are most distributions, but is instead built entirely by compiling sourcecode, using your own custom optimizations.

Essentially, it installs a complete bootstrap development system on your machine, and then you tell the Lunar package manager what tools you want, and it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward your specific needs.

The result is a leaner, meaner, refreshingly uncluttered, and strikingly faster operating system than most linux distributions.

This installation guide is designed to get you through the installation process as painlessly as possible. It assumes that you have some experience with linux or another Unix variant, and have a general idea of what you are doing. If you are unfamiliar with such things as partitions, or have never used linux before, Lunar may not be the best introduction for you into the world of open source. There are always Lunar gods available on irc.freenode.net in the #lunar channel to answer any questions that this manual may not make quite clear enough.

With that said, we hope you enjoy using Lunar!

==About this installation manual==

Although this manual is not intended to be a full and complete overview of any situation you may be confronted with, given the wide diversity of hardware available these days, it is intended to be an introduction to the world of Lunar Linux. You will see examples that are not tailored towards your to-be built server or workstation, optimizations that are overly broad or too specific, and examples that don't apply to any real situations. We tried hard to give you the idea of how much power you have over how you can setup your system, but we are forgetting to tell you how to run your own server or desktop (or other system) at all. That means that the examples and steps taken most probably do not apply to your situation at all.

Do not despair: if you understand what is going on and you get the idea, the installer will allow you to do pretty much everything you want to do with your system. There are really (almost) no limits.

==Getting the ISO==

The primary site for retrieving the ISO is [http://www.lunar-linux.org/ lunar-linux.org]. There, you will find links to our US, EU, and Internet2 mirrors, as well as a Bittorrent link. As of this writing, the current version of the Lunar ISO is version 1.5.0. (''Check the main site for the actual latest version!'')

Locate and retrieve the file lunar-1.5.0-i686.iso.bz2. After downloading this file, you will need to unpack the ISO using bzip2. Windows users will need a program that can extract bzip2 archives, like WinZip (also capable of extracting bzip2 archives under windows are Winrar, powerarchiver and 7-Zip). Mac should unzip the file by itself. Then all that is left to do is use your favorite program to burn the ISO to a cdrom and begin the installation. Lunar can also be installed without using a CD. If you need to do it this way, our [[FAQ]] provides simple instructions.

It should be noted that this ISO and Lunar use devfs for device management. If you prefer the "old-school" method of manually installing devices, there is an ISO available with this option at [http://thing.fwsystems.com/build/lunar/lunar-1.3_stddev.iso.bz2 thing.fwsystems.com].

We are assuming the you are installing Lunar as your primary OS. Make sure you have a backup of any important data that you need to retain. The Lunar Linux Project and its developers are not responsible in any way for any loss of data on your system!

==Booting the ISO==
Upon booting the ISO, the first thing you will see are options for booting the ISO kernel, or for performing RAM tests. There is even a safe mode which will disable DMA, MTRR, RAID, LVM, USB keyboards, NTFS, HPFS, Advanced Partitions, and Firewire. Most folks, however, will be just fine pressing enter at the boot prompt and loading the default kernel.

To boot the iso with support for your usb keyboard:
''linux uhci-hcd ehci-hcd''

After loading the kernel, the first screen presents you with a few options. If there are extra modules you need to load in order continue with the install, they can be loaded here. There is also a shell option. However, if you are using this ISO for rescue purposes, you do not want to shell out here; rather continue booting and shell out in the next section. Most people will select "continue booting" here.

It should be noted that since 1.5.0, the iso tries to autodetect some hardware (mostly scsi drivers and network interfaces) during this stage. This will help you establish a network connection if you desire so during installation. For this reason the programs 'dhcpcd' and 'ftp' are already available at this stage.

==Virtual Consoles==
Once the ISO has booted into the installer, you can immediately shell out or switch to one of the other virtual consoles. These will have ready to go root shells and are available throughout the installer sequence. With these you can start rescue actions, setup networking or double check the install progress and make manual adjustments.

==Language and keyboard interface Settings==

After reading the introduction, you will be presented with options for choosing the proper font, keymap, and language for your install.
You will also need to choose an editor, as you are going to need one later on in the installation for setting up your lilo or grub configuration. The three choices available are vi, joe, and nano. If you have never used a text editor in linux before, nano is the best choice for you. If you skip the Native Language Support option, the system will install the default editor, nano, for you. When you have finished setting up your options, press cancel to return to the main setup menu.
Less important for most people is the ability to choose the console font, although it may help display some non-english characters. Most people will want to set the system-default language variable and editor though. All these values are unset by default, so make sure you set them now.
The keymap table allows people to use azerty and dvorak keyboards, and much more. This is especially required for non-english keyboards which provide many accented characters.
All these language and keymap settings might not apply to the lunar code itself, which (currently) does not have any international support, but most programs that run during the installer sequence, and after booting into your new system, will be affected properly.
==Creating or editing Partitions==

The next step is to set up partitions on your hard drive. Upon selecting the "Partition Drive" option, you will be shown a list of all the discs the kernel has detected. For this guide, we will assume that you have one hard drive connected via an IDE channel, which will show up in the menu as "disc0". After selecting the disc to partition, you are given the option of using one of three partitioning programs. They are:

* cfdisk -- A menu driven partitioner, and very easy to use. If you are unfamiliar with various partitioning programs, this is the best option for you.
* fdisk -- Text based partitioner that requires a little more know-how than cfdisk. More experienced users will probably use this program. However new users should not be daunted, as it does have help offered at every step.
* parted -- Text based partitioner that is good for advanced users. Parted is excellent for resizing current partitions on your hard disk, however be forewarned that resizing partitions is an excellent way to hose your entire disc.

For our example, we have a 40GB IDE drive and we'll set up six partitions; /, /boot, /home, /usr, /var, and a swap partition. It's a good idea to keep certain directories, such as /var and /usr on separate partitions, as this can save you a lot of headache in the future incase your disk ever completely fails on you and you need to recover data (god forbid!). Also, when you have a separate /boot partition as we have in our example, you need to have your partitioning program mark that partion as active or bootable. In our example, if we were using fdisk, you would press "a" at the command line, and then select part1 as the active partition.

You might also want to install a /tmp partition. By default, Lunar will create a tempfs filesystem mounted on /tmp (tempfs minimizes filesystem fragmentation because it resides in volatile memory). This can be a good choice if you have a lot of memory on your machine. If memory is tight, we recommend creating a /tmp partition to minimize filesystem fragmentation.

It is important to note that you <span class="emphasis">''can not''</span> mount the directories /etc, /bin, /sbin, /dev, /lib and /proc on separate partitions. These directories need to be contained within the root ("/") directory. The installation program should block you from doing this, but it's best not to try.

Here's our partition setup:

1 /boot 100MB
2 / 4GB
3 swap 1GB
5 /usr 10GB
6 /var 10GB
7 /home 15GB

(''If you're wondering about this choice of partitions: it's really just an example. Read the [[FAQ#So_how_should_I_partition_my_disk.3F|FAQ]] on what makes sense in the real world''))

You'll notice that there is no fourth partition in our list above. In order for you to have more than four partitions on a single drive, the fourth partition is made into what is known as an extended or logical partition in which the fifth, sixth, and seventh (etc, etc) partitions reside. For our example above, if we were using fdisk, we would make the fourth partition an extended/logical partition that was 35GB, and then the fifth, sixth, and seventh partitions in our scheme resided within it. However, if we used cfdisk, we would just worry about creating six partitions, making sure that the first three are the primary type, and the last three logical.

Note that the names and mount points for these partitions will be assigned during the next step of this process, when you mount the partitions. Write down exactly what partitions you are planning to create because it can otherwise get confusing!

Lunar offers two choices when it comes to swap. You can set up a swap partition, as we have in our example, or you can set up a swapfile in the root directory. We recommend setting up a swap partition, as you will get better performance with it than with the swapfile. However, there may be a need for you to set up the swapfile instead, which can be setup and activated after you have mounted your other partitions.

==Selecting Partitions and Filesystems==

After creating your partitions, you need to select them and assign file systems. Select the menu option "Select Filesystems" and verify that you are indeed done creating partitions.

The partitions can be selected in random order with the new installer. First select the partition and then assign a filesystem and mountpoint to it. The installer will add this to the job queue and formatting and mounting takes place later so you can edit your selection. Here's a list of filesystems that are currently supported:

* ''ext2'' (Second Extended File System) -- Version 2 of the Extended File System, which was designed for linux as a replacement for the Minix Filesystem. Ext2 is not a journaled filesystem, which means that you'll need to perform disc recovery operations after a power failure or other such system crash. This filesystem is available with all kernels on the ISO.
* ''ext3'' (Third Extended File System) -- Version 3 of the Extended File System, which is essentially just the journaled version of ext2. This filesystem is available with all kernels on the ISO.
* ''reiserfs'' (Reiser Filesystem) -- Journaled filesystem created by Hans Reiser that is excellent for use with extremely small files. This filesystem is available with all kernels on the ISO.
* ''jfs'' (Journaled File System) -- Created by IBM for AIX, IBM's brand of Unix, and later ported to linux by IBM under the GPL. A journaled filesystem that is very good at handling high throughput issues. This filesystem is available with all kernels on the ISO.
* ''xfs'' -- Created by SGI for IRIX, SGI's brand of Unix, and later ported to linux under the GPL. A journaled filesystem that SGI claims is better than any other at handling extremely large files and sparse files. This filesystem is only available with the lunar or grsec patched kernels, which we will come to in a few steps.

After selecting the filesystem type you wish to use, you will be prompted through a series of steps to initialize the partition. You'll notice that the prompts are quite redundant in nature in order to be absolutely positive that you will not inadvertantly erase crucial data that you might have on a working filesystem. In addition, if you have more than four partitions, as we do in our example, you don't want to select any file systems on the fourth partition, as it is the extended partition that houses the fifth, sixth (and so on) partitions. (The installer will try to detect this and skip the extended partition from the list).

As we mentioned earlier, there is an option in the installation process to set up a swap file in the root partition instead of a swap partition as we have done in our example. The next option after selecting your filesystems is to select a swapfile if you so desire. <span class="emphasis">''If you have set up a swap partition already, as we have done, you can skip this step.''</span> Otherwise, you can set up your swap file here, and the only thing you need to tell the installer is how large you want the file to be. Running without swap completely is also possible of course.

'''Please note during this step, no modifications are made to your filesystem!'''

==Installing Lunar==

Next, we need to ''format'' your partitions, ''mount'' them in the right place, create ''swap'' and transfer the entire Lunar system to the partitions that you now have created. This happens all in one single step.

Select ''Install Lunar'', and the system will proceed to transfer all of the neccessary files for you. The installer will display progress as packages are transferred to your system and you'll have some idea how long it will take. On normal machines, this should take about 5 minutes.

At the end of this step, the installer sets various system parameters like language, timezone and vital package configuration files in order for your machine.

==Setting Up Your GCC Architecture Optimizations==

The architecture optimizations is a crucial step, since what you choose will make your system fly! However, it is important that you do not overdo it on you optimization settings, as certain selections can, in some instances, break code while compiling.

The first step is to choose your preferred compiler. The default choice here is GCC 3.x, and is the preferred choice as GCC 2.x is no longer under development, and GCC 3.x is known to make compiled code run faster. For our example, we are going to use GCC 3.x.

Next are options for the C and C++ compiler, called -pipe, that have already been checked off. Very few people, if any, would need to turn off the -pipe option, so in our example we are going to leave them checked.

Next we have the platform selection. This question would seem to be rather silly, since our ISO only boots up on x86 systems, but we like to plan for the future. You'll want to say x86 here.

Now we move onto the Basic Optimization screen. As you can see, the options speak for themselves. Your choice depends on what your needs are. Most folks will want to use -O2 here, as it is the wisest choice. More advanced users may want to use the -O3 option, but it's not for everyone. If you're short on disk space, you would take the -Os Small option. (As an example, we used -Os for the ISO since we were working within a confined amount of disc space.) Those of you with older or slower systems that wouldn't be able to take advantage of faster optimizations may choose a more conservative setting like -O1. For our example system, we will choose -O2.

After choosing your basic optimization level, you'll need to tell the compiler what type of processor you have. This may seem unimportant, however the GCC 3.x compiler has ways of optimizing code for certain processors, even though they all may be x86 based. For example, GCC 3.x has certain optimizations it can perform on code for Pentium 4 machines, but not for Pentium 3. Our example machine is a Pentium 3, so we are going to select that.

We could also select i686, as a Pentium 3 or Pentium Pro falls within that architecture. Choosing i686 is a more conservative choice than Pentium 3, as GCC 3.x will not try certain optimizations with a more general choice like i686.

==Adding Additional GCC Optimizations==

'''You can safely SKIP this entire step!'''

Next up are some extra speed optimizations you can add in to tweak your code even futher. There are too many to go into much detail here, but suffice to say that you should choose carefully. As we mentioned in the prior section, certain optimizations will cause compilation errors or even failures. An optimization such as "-ffast-math" is very risky because it breaks certain rules to get faster code, and would only be used by the bravest of souls looking to endure lots of pain. More information about GCC 3.x optimization strings can be found on the [http://gnu.org/software/gcc/gcc.html gnu.org] website.

The same rule applies on the next screen, where you are asked about some extra features that you may want further optimized, and on the following screen asking about floating point math optimizations. Some options may not pose a problem at all, while others may break things.

Moving on to the next few screens, we have options to enable or disable C and C++ compiler warnings. Most people will want to leave these boxes unchecked as deprecation warnings can be very useful some of the time. Following that is the screen for linker options, where you will find that "-s Strip" has already been checked off. Very few people will want to uncheck this option, so we will leave this screen as is. After that, we have some addons for compiler caching and distributed compiler support. Most folks will not need either one of these.

The final few steps involve setting up the number of concurrent makes and stack parameters. As the hint mentions on the "Concurrent Makes" screen, you'll want to enter in the number of cpu's your machine has. Unless you have a machine with more than one processor, you'll want to leave this field blank. The stack parameters is also fairly straightforward. The warning on that screen says that this field is best left empty, and so that is exactly what we will do with our example.

We are now finished setting up our GCC optimizations! When you have you lunar system up and running, you can always change and tweak these GCC settings by typing "lunar" at the commandline prompt, and going to "Optimization Settings". In addition, if you aren't that familiar with what your processor is capable of using for optimizations, you can go to the shell out option on the ISO and type

cat /proc/cpuinfo

at the prompt and the system will show you all the optimizations that the processor reports it can handle.

==Configuring Your Bootloader==

=== Configuring LILO ===

If you chose to use lilo and also said yes to automatically configuring and running lilo, then most of the work is done for you. If you chose not to hand edit lilo.conf, however, be warned that the default configuration has the system set up to be password protected on boot. You can change this by selecting the option from the menu "Reconfigure LILO".

To turn off password protection, you will need to comment out (with the symbol "#") or delete two lines in your lilo.conf file. The first is "password=lunar", which is found in the top section of the file, and the other is "restricted" which is found right below the name of your kernel in the second section.

The other item of note is whether you want lilo to reside in your MBR (Master Boot Record) or on the first sector of your /boot partition. The line in your lilo.conf file to edit for this purpose is

boot=/dev/hda1

To make lilo get installed on the first sector of your /boot partition, you would leave this line as it is. If you want lilo to be written to your MBR, which is the recommended method, you would change the line to read

boot=/dev/hda

Of course, these examples are pertinent to our setup that we have been using thoughout this manual. Your actual lilo.conf file may be different.

=== Configuring GRUB ===

If you chose grub as your bootloader, you will need to set up the configuration file entirely on your own. An example would be:

default 0
timeout 30
color white/blue white/black
title linux-2.4.20
root (hd0,0)
kernel /vmlinubz-2.4.25-r5.0.0 root=/dev/hda2 devfs=nomount

As we mentioned earlier in the partitioning section, you would want to mark your /boot partition as active. With grub it is ''imperative'' that you mark your /boot partition as active, otherwise grub will not work at all when you are finished with the installation and reboot to your new system.

==Installing kernels==

===Installing a precompiled kernel===

The ISO's come with a variation of precompiled kernels and modules that should work for most people. If you have problems getting your kernel to compile, install or getting the right drivers, or just want to get a quick start at lunar, we ''suggest'' that you use this option instead of compiling your own kernel. You can later of course compile as many kernels as you want.

===Building Your Customized Linux Kernel===

We have now come to the most important part of the installation; the configuration of the kernel. The kernel is the heart of linux, and without it, nothing would work. Configuration is, actually, a rather simple process. All you need to remember is to not panic, and that lunar is going to do most of the work for you. Here are a few pointers that will make the configuration a breeze for you.

* Help is a click away! The people working on creating and maintaining the linux kernel have help placed throughout the entire configuration process. If you're not sure what something does, just look at the help file for whatever item you're on, and it will almost certainly explain what it is and what it does. The most handy thing is that every help file will suggest whether you should really use the item or not. Many help files end with "If you're not sure, it is safe to say N here", thus letting you know that it is safe to leave that particular item out of the kernel.
* You can use the ISO kernel! The configuration used to make the kernel for the ISO is the same configuration you'll see when you start your kernel customization. If you leave the configuration the way it is, the only thing you truly have to worry about is your network and, if you want it, sound. There are also two additional default configurations available on the ISO that are available to you called "config.safe" and "config.server". We'll show you how to load these configurations in just a little bit.
* Never build filesystems or core components as modules! Make sure that whatever filesystems you decided to use for your partitions earlier are built into the kernel, and are not separate modules. Likewise, make sure that certain crucial things like ide and scsi drivers are not modules, as this will make your machine unbootable. (This rule doesn't apply to the scsi low level drivers though; they can be modules.) Modules are kernel drivers that can be manually activated and deactivated after the system has been booted, but not during boot time. The kernel from the ISO already has all the filesystems available during the installation built into the kernel, so if you don't change anything there, you will be fine.

You will be shown two screens of information before you actually begin you kernel configuration, letting you know that you are going to need a few things built into the kernel in order to have Lunar run properly, and what options you have for boot loaders. Lunar comes with both lilo (LInux LOader) and grub (GRand Unified Bootloader).

If you don't have much experience with bootloaders, we suggest using lilo for now, as the installation program will set up the configuration file for you. If you would prefer to use grub, and we encourage folks to learn how to use it, be forewarned that the installation program does not set up any configuration at all for you.

There are serveral kernels for you to choose from. They are:

* ''linux-2.4'' -- The default kernel for Lunar which is the Linus tree with some handy patches for the xfs filesystem, firewire, ext3, and several other fixes.
* ''linux-2.4-agr'' -- The aggressive patch includes everything from the standard patchset as well as the low latency, pre-emptive, and gcc 3.x architecture type patches.
* ''linux-2.4-grsec'' -- This is almost the same as linux, but with grsecurity, cpu frequency scaling, gcc 3.x architecture types, and crypto support.
* ''linux-2.4-stable'' -- This is the Linus tree with only critical patches for certain drivers that were created after the 2.4.20 kernel was released.
* ''linux-2.4-vanilla'' -- A completely unpatched kernel tree.
* ''linux-2.4-om'' -- A kernel specifically meant for clustering use.

For our example, we are going to use linux-2.4-agr.

Before you begin is which type of configuration method you would like to use.

* ''config'' -- The original way to configure the linux kernel. It is completely text based, and assumes you know what everything is. Unless you've been using linux since its inception, you probably don't want to use this method.
* ''menuconfig'' -- As the name implies, a menu driven version of the kernel configuration. This is the easiest, and by far the most popular way of configurating your kernel.
* ''xconfig'' -- If you have an X server running, you can use this option to configure your kernel using a nifty GUI interface. You won't be able to use this on the ISO, but once your system is up and running with X, you can use this option. If you do choose this option while installing from the ISO, the system will fall back to next available configuration method, in this case menuconfig, so there is no harm in selecting it if you do.

For our example, we are going to use menuconfig. Once Lunar is finished applying the patches for the kernel, which can take a minute or two, you'll be brought to the configuration screen for the linux kernel.

As we mentioned earlier, the configuration that was used to build the kernel for the ISO is the same configuration that you'll be presented with when you start. However, as we also mentioned earlier, there are two alternate kernel configurations available to you that you may want to use; config.safe and config.server. Both of these configurations can be found on the ISO, along with the original default config file, in /etc/lunar/local. When you are looking at the kernel menuconfig main page, scroll all the way to bottom, and you will find an option called "Load an Alternate Configuration File". Select this and then give the absolute path to the alternate configuration file, i.e. /etc/lunar/local/.config.server. As with all kernel configuration files, they are hidden files preceeded with a ".", so make sure to not forget it.

Once you have completed configuring your kernel, you'll get one more prompt from the installer asking if you want to go back to the configuration in case you exited by mistake or forgot something. If everything is good to go, say no here and sit back for a few minutes while your kernel compiles.

==Setting Up Networking==

The final step is to set up networking. When you select the "Set Up Networking" option, you'll be prompted by a series of questions as to what kind of card you have (only needed if you built your networking device as a module, and not part of the kernel), if you need to set up wireless or not, and whether you'll need to use dhcp or not. You should be familiar enough with your network to set this up on your own, as the questions put to you are very straightforward.
coa

==Other settings==

The installer will prompt you now for some more settings. You should set a root password and generate ssh host keys to identify your box uniquely for later. You might also want to administrate services on the newly installed machine.

==Reboot!==

Once you have completed setting up your networking, you are finished installing Lunar Linux! Congratulations! Select the option "Done" and remove the cd from the drive when it ejects. Your Lunar system is now ready to go!

==Upgrade Moonbase==
Following the initial installation and reboot, there are some key things that still need to be updated.

If you have installed from the 1.6.4-alpha or 1.6.4-beta ISO series from September-October 2008, all you should need to do now is follow the instructions given in '''man lfirsttime''' to bring your system up-to-date.

If you have installed from the out-of-date 1.6.2-beta1 ISO from July 2007, it is imperative that you follow the additional instructions given in the [http://www.lunar-linux.org/index.php/en/news-sections/68-general/58-lunar-linux-iso-install-guide.html 1.6.2-beta1 ISO Installation Guide] otherwise you are very likely to break your system before you even get started.

''However, you are strongly advised to install from the most recent ISO to avoid problems!''

''Have Phun!!''

[http://www.gnu.org/copyleft/ Copyleft] 2004 [http://lunar-linux.org/ The Lunar Penguin Team]

Lunar Installation Manual and Harassment of Lunar Developers by Drew Swayze (drew AT lunar-linux DOT org).

Edits and Nitpicking by Suzanne Burns (sburns AT lunar-linux DOT org).

Lunar Linux:FAQ

2010-07-04T20:51:03Z

Engelsman: /* Where can I find how to...? */

These are the '''F'''requently '''A'''sked '''Q'''uestions for Lunar Linux. You have a question about Lunar? You might get your answer below.<br /><br />

__TOC__

==General==

===What is Lunar Linux?===
What exactly is Lunar Linux?

'''Answer:'''
* Please read [[Lunar Linux:About|About Lunar Linux]].

===Can I run Lunar Linux in 64-bit mode?===
Can I run Lunar Linux on my new 64-bit system?

'''Answer:'''

Yes you can. You can run Lunar Linux in '''either''' 64-bit '''or''' 32-bit mode, but there is no multi-lib mode. Be aware that some applications are still only available for 32-bit mode!

===Where can I find how to ...?===
Where can I find how to customize the kernel under Lunar Linux? Or the desktop...

'''Answer:'''

The Lunar Wiki only offers details specific to Lunar Linux. Many other resources already exist for general Linux problem solving. For example, information on how to customize the Linux kernel can be found at:
* http://kernelnewbies.org/
* http://en.wikipedia.org/wiki/Linux_kernel_mailing_list

==Optimizations==

===How do I set optimizations?===
How do I set these optimizations for my machine?

'''Answer:'''

Run <code>lunar optimize</code>. You'll be taken through an interactive menu that explains all the options. Remember to optimize safely.

===What are safe optimizations?===
What are the recomended safe optimizations for [[Lunar Linux]]?

'''Answer:'''

The default sure fire optimizations that are recommended are:

* '''C'''
** <code>-pipe</code>
* '''C++'''
** <code>-pipe</code>
* '''CPU Architecture'''
** You should pick the correct architecture for your own system (defaults to x86 for most people).
* '''Basic Optimzations'''
** Faster (-O2, the default) or Fastest (Note that fastest doesn't work on all systems, i.e. k6).
* '''CPU'''
** This, of course, should be set to your own cpu, or the cpu of the machine you plan to run this install on. If you want to be able to run this install on many machines, you should be safe with I686.
* '''Speed Optimizations'''
** If you want to be 100% sure that there won't be optimization problems you shouldn't select any of these.
* '''Extra features'''
** It is not recommended to use any of these optimizations, even for modules known to be able to handle them, since they cause many apps to break.
* '''Floating Point Math'''
** None. If your architecture is x86 and you don't own a 386SX and 486SX, it's safe to select x387.
* '''Linker Options'''
** Strip.
* '''Addon Program Support'''
** CCache. Make sure to install it first.

These settings should work for almost everyone, and there is a lot room for pushing these optimizations more, at the risk of problems with some applications. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations may cause problems?===
What optimizations are known to cause problems in some setups?

'''Answer:'''

Some optimizations that are known to cause problems on x86 with many applications, and even a entire system:

* <code>-funroll-loops</code>
* <code>-fstrict-aliasing</code>
* <code>-ffast-math</code>
* <code>-ffloat-store</code>

These are sorted from the least unstable to most unstable. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations can give some speed without issues?===
What optimizations can I use to gain some speed but without major risks?

'''Answer:'''

Start with the basic optimizations in [[Lunar Linux:FAQ#What_are_safe_optimizations.3F|FAQ #2.2]] and change the Basic Optimizations to Faster or Fastest if you know that gcc will generate correct code for that cpu. -O2 obviously takes more compile time than -O1, and -O3 takes the most time to compile. Then select the cpu you will run it on. Some of the speed optimizations that should be decent and shouldn't cause too many problems, if any, are: -fomit-frame-pointer. A safe bet for floating point math on a x86 would be x387, if you know your cpu has a floating point unit. Check <code>cat /proc/cpuinfo</code> to see if your cpu supports SSE or SSE2. If your cpu does have sse or sse2 then you can also add that to the math optimizations.

Your results may vary. Read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it.

===What optimizations should I avoid?===
What optimizations should I stay away from?

'''Answer:'''

All the ones listed in the [[Lunar Linux:FAQ#What_optimizations_may_cause_problems.3F|FAQ #2.3]] plus:
* <code>-fprofile-arcs</code>
* <code>-fbranching-probabilities</code>

Please read <code>info gcc</code> and make sure you understand a given optimization ''before'' you enable it. The Lunar developers will not respond to bug reports of broken compiles by users with risky optimizations.

==Installing modules==

===Can I compile several modules at once?===
Is it possible to install multiple modules at the same time without breaking things?

'''Answer:'''

Yes, Lunar even promotes it. However doing so will cause installs compile slower of course. Lunar will not install core system modules like gcc and glibc while something else is installing and will wait until the rest is finished. Also, you cannot install applications while those major modules are installing, they will wait their turn until it's safe and continue to install them automatically.

===error : C compiler cannot create executables===
What does this error mean and how can I fix it?
* <code>C compiler cannot create executables</code>

'''Answer:'''

Read the next topic - this is basically the same problem: There are kernel headers missing that are vital to compilation. You will have to restore them. Below is explained how to do that.

===configure: error: C preprocessor "/lib/cpp" fails sanity check===
What does this error mean and how can I fix it?
* <code>configure: error: C preprocessor "/lib/cpp" fails sanity check</code>

'''Answer:'''

This is an include file problem. Sometimes ''/usr/include/gnu/stubs.h'' is missing, this can be found in the glibc source tarball. Most of the time the following applies:

Your kernel headers are missing from <code>/usr/include</code>. This means the C PreProcessor cannot verify that it has the proper cached copies of those vital header files. You need to install the proper ones manually. Here's how:

lin kernel-headers-2.4

This might work for you! (Use the 2.6 version if needed of course)

Otherwise:

mkdir -p /usr/include/{linux,asm}

to create the two target dirs, if needed. Then execute:

cp -av /usr/src/linux/include/linux /usr/include/
cp -av /usr/src/linux/include/asm/* /usr/include/asm/

to copy the files manually. Be warned that the second command has to be done this way since <code>/usr/src/linux/include/asm</code> is a softlink to your arch asm header files, asm points to asm-i386, on x86 machines. So if, on the other hand, you had copied

cp -av /usr/src/linux/include/asm /usr/include/

you would then get a softlink to nowhere under <code>/usr/include/</code>.

Last, you can always try to unpack the kernel tarball you have into <code>/usr/src/linux</code> and manaully link or copy the headers over yourself.

===Can I add more window managers to gdm?===
How do I add other window managers to the sessions list on gdm?

'''Answer:'''

Copy the desktop startup files to <code>/etc/X11/dm/Sessions/</code>. That works with gdm. For kdm you will have to copy them to <code>$KDE_PREFIX/share/apps/kdm/sessions</code>.

===How do I get Flash to work in Mozilla or Firefox?===
How do I get Flash to work in Mozilla or Firefox?

'''Answer:'''

If you are using Mozilla or Firefox, then you can simply do a <code>lin flash-plugin</code> and that will download and install the Macromedia Flash plugin that works with a gtk+ based mozilla through the old abi wrappers.

The flash plugin does ''not'' work with Galeon. The Galeon developers have declined to provide the "old" abi wrappers needed for the plugin to work.

===How do I install Java?===
How do I get Java for my Lunar box?

'''Answer:'''

You will have to download the Java source code from Sun yourself and you have to "click" to agree on their license. You have to compile it yourself too. We don't have a Sun Java module as we currently have no way to automate the "click" to agree to the Sun Java license. See this URL for some handy info:

http://www.linuxfromscratch.org/~tushar/hints/javafromscratch.txt

There is a j2sdk module in moonbase which is the Blackdown port of Sun's Java Virtual Machine.

==Lunar core tools==

===How can I recompile my module with new options?===
How do I force lunar to recompile my modules with different options?

'''Answer:'''

Try:

lin -r ''MODULE''

The -r switch will allow you to select new configuration and dependencies for modules.

===How can I make modules recompile instead of resurrecting?===
How do I tell lunar to recompile my application instead of resurrecting it?

'''Answer:'''

Try doing:

lin -c ''MODULE''

The -c option means tells <code>lin</code> to compile this module even if there is an install cache copy available in <code>/var/cache/lunar</code>.

===How can I tell lunar that module X no longer depends on module Y?===
Module X no longer depends on module Y, but lunar insists on reinstalling module Y too. How can I get tell lunar to remove that dependency?

'''Answer:'''

Lunar adds a module's dependencies to a cache when you install it. You can't remove a dependency automatically, but you can rebuild the dependency cache to reflect the current dependencies of the modules that are now installed.

lsh create_module_index
lsh create_depends_cache
lunar fixdepends

Note: Dependencies of modules in [[zlocal]] are ignored. If module X in the main moonbase depends on module Y then the dependency cache will still contain that dependency.

===My moonbase is gone and I can't install anything.===
How do I fix problems with my moonbase when it's missing or damaged?

'''Answer:'''

Simple solution to this is just running:

lin moonbase

This will download the latest moonbase from the internet, and restore it to working order.

===What is a module?===
What is a [[module]] and what does it do??

'''Answer:'''

A [[module]] is a set of files that tell the core tools the following:

* What name, version, and other properties a package has
* Where to download all needed source files
* What other modules are required, or conflict with this one
* How to unpack the source files, how to patch
* How to configure the code
* How to compile
* How to install everything
* What else to do with it

The [[module]] is coded in a set of files in a directory structure, and scripted in bash.

===What is the Moonbase?===
What is that thing you call [[Moonbase]]?

'''Answer:'''

The [[Moonbase]] is a database with [[modules]]. In this database there are description of packages that tell the core tools where to download, how to compile, and how install a [[module]]. You can consider this the lunar equivalent of portage, grimoire, ports, etc.

===What is theedge?===
What is theedge?

'''Answer:'''

[[theedge]] is the same as lunar, and also known as the core code. Theedge is just another version of lunar. These two pieces of code install your packages, but they do not contain package descriptions. Those are defined in moonbase.

[[Theedge]] is a development version of [[lunar]]. Often there are much more features in theedge, and bugs are fixed quicker as well. However, if you do not like all this tweaking on your system, we advice you to use the stable lunar core tools instead on your system.

You can install [[theedge]] by issuing:

lin theedge

Theedge is automatically updated if you do a <code>lunar renew</code> or <code>lunar update</code>.

==Lunar-Linux Installation==

===My usb keyboard is not recognized===
At the boot prompt type ''linux uhci-hcd ehci-hcd'' to make sure those modules are loaded during startup. Those will then enable your usb keyboard.

===So how should I partition my disk?===
I'm setting up lunar from scratch, but how should I partition my disk for a server or desktop system?

'''Answer:'''

Server systems have very different demands than desktops. It's all about flexibility. First desktops:

''desktops'' commonly have one hard disk. You don't want to reformat or repartition often, so you just want to be done with it at once. The easiest is just to setup 2 (two) partitions: one root filesystem big enough for all lunar software, and the rest for <code>/home</code>. Typically, lunar occupies between 4 and 12 gb based on how many applications you install. If you clean up often you can manage with 8gb, but you should keep some extra space. I certainly advise to use a swapfile instead of a swap partition: you can always later delete the swap, or move the swapfile to another disk or partition. A swap partition is harder to relocate.

''Servers'' have different needs. First of all <code>/home</code> doesn't need to be that large, but you will want to setup space for logfiles that cannot cause problems if they grow too fast. Putting <code>/var/tmp</code> and <code>/var/log</code> on separate partitions is quite normal. <code>/tmp</code> can be abused similarly, and is mostly run in [[tmpfs]] to avoid cluttering and give fast access times. Then <code>/usr</code> will be separate and the usual separate <code>rootfs</code>. As you can see this list is already getting quite big! Most users will actually want to make the <code>rootfs</code> quite small (as small as 200mb sometimes!) and thus <code>/home</code> also needs to be on a separate partition.

===Kernel features, built-in or module?===
When I compile a kernel, should I compile drivers that I need in the kernel image or as module?

'''Answer:'''

There are many schools of thought on kernel compiling. One is to build everything into the main kernel without modules. The other one takes building modules to the extreme. Here is a suggestion, if it's not needed to boot it's a module. Thus usb, input, sound, mice ACPI, network, and also cdrom, floppy, and all the non boot file systems, all get built as modules. This reduces the size of the main kernel so it can be put on a floppy. Another thing to consider is that not everything works perfectly, and some features can cause your kernel to misbehave, so if some feature is built-in, the bad behavior is practically inevitible. Instead, with a module you can choose not to load it and thus be left with a working system.

Please note that some people need to make some features built into their kernel and vice versa, do whatever works best for you.

===QEMU and Lunar ISO testing===
How do I use qemu to try out lunar ISO's?

'''Answer:'''

Just a quick note on how to use qemu for testing a Lunar Linux installation. See <code>/var/lib/lunar/moonbase/devel/qemu/DETAILS</code> for a description of qemu. Think of it as a low-cost (''read: free'') version of a virtual machine, that has quite a few useful features and is under active development.

A very simple way to just test a Lunar ISO for booting purposes is:

qemu -cdrom lunar-1.5.0-i686.iso -boot d

If you want to test a full install, then create a 512 megabyte sparse root_fs image with this <code>dd</code> command:

dd if=/dev/zero of=hda.img bs=$((1024 * 1024)) count=0 seek=512

Now invoke qemu:

qemu -cdrom lunar-1.5.0-i686.iso -boot d -hda hda.img

You can then proceed to test your Lunar install. Refer the qemu homepage for further tips and tricks. qemu can also be quite easily used to test if your brand new kernel is bootable or not, which is quite neat.

Note that you should say yes to using SDL as an optional_depends. The gui version of qemu is ''very'' nice in its own little X11 window.

==Other==

===How do I unpack an .RPM file in lunar?===
How do I install RPM files in lunar? Is that possible?

'''Answer:'''

The easiest way to unpack a rpm file is to use the module called <code>rpmunpack</code>. Simply run <code>rpmupack ''XYZ''.rpm</code> for your RPM. This will create a cpio file (''XYZ.cpio.gz'' and ''XYZ.cpio.bz2'' are not uncommon). Once you perform any additional uncompression with <code>gunzip</code> or <code>bunzip2</code>, you can then extract it using <code>cpio -i -d < XYZ.cpio</code> -- After all that you should be all done. If you are trying to rpmunpack a source RPM (i.e. .src.rpm) file then ''XYZ.cpio'' may further contain a tar.bz2 or tar.gz source tarball.

In the zbeta section of moonbase, there is an '''''unsupported''''' module called <code>rpm</code> for those of you that are really desperate.

You might want to do <code>man cpio</code>, to check out additional cpio parameters that may interest you, such as the -L switch.

===What is that in the Lunar-Linux logo?===
What is that logo of yours? It looks like a <nowiki>[cat|ferret|dog|owl|insert nutty animal here]</nowiki>!

'''Answer:'''

The logo is a [[wikipedia:Southern Rockhopper Penguin|Rockhopper Penguin]]. It's a kind of nasty penguin, the one that crowd up in thousands to take over the continent. They have a few long feathers sticking out at their "ears" sideway, just like some owl species do.

You can check out [http://images.google.com/images?q=Rockhopper+Penguin Google Images] for lots of Rockhopper Penguin pictures!

The current logo has been designed by Michael Schindler in 2003 and appeared as the official logo of the Lunar Linux project in 2004.

User talk:Hirager

2010-06-23T11:54:10Z

Engelsman: initial placeholder page

Edit me!

User:Hirager

2010-06-23T11:53:34Z

Engelsman: initial placeholder page

Edit me!

Template:Main Page:About

2010-06-20T19:07:53Z

Engelsman: Lunar is alive

<div style="float: right; padding-top: 0.1em; padding-right: 15px;">
{{ed|Main_Page:About|}}
</div>

==[[Lunar Linux:About|'''About Lunar Linux''']]==

'''Lunar Linux''' is a [[wikipedia:source code|source]] based [[wikipedia:Linux distribution|Linux distribution]]. It is built entirely by [[wikipedia:compiler|compiling]] [[wikipedia:source code|source code]], using custom [[wikipedia:Optimization (computer_science)|optimizations]].

It installs a complete [[wikipedia:Bootstrap#Computing|bootstrap]] development system first. After telling the Lunar package manager which software will be required, it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward the users specific needs.
This should result in a lean and optimized [[wikipedia:operating system|operating system]]. On the downside, compiling a whole distribution from scratch may be time-consuming and complicate the task of keeping the packages up to date.

Currently, Lunar only supports the [[wikipedia:X86|x86]] and [[wikipedia:X86-64|x86-64]] architectures.

Lunar Linux is licensed under the GPLv2.

'''2010-06-20''': Despite appearances, Lunar Linux is still very much alive. The Forums and Wiki are inactive because they were locked after prolonged spam-bot vandalism. If you require help, simply go to the #lunar irc channel and ask!

<div style="text-align: right; font-variant: small-caps; padding-right: 15px;">
[[Lunar Linux:About|More Information]]
</div>

Template:Main Page:Misc

2010-06-06T13:40:52Z

Engelsman: removed obsolete 3rd Party link to lunar-linux.interhact.net

<div style="float: right; padding-top: 0.1em; padding-right: 15px;">
{{ed|Main_Page:Misc|}}
</div>

<h2 style="font-variant: small-caps;">[[Lunar Linux:Misc|Other Information]]</h2>

<h4>Howto Articles</h4>
* [[Installation:No CD|No CD installation]]
* [[Installation:No network|No network installation]]
* [[Installation:The_kernel_commandline_/dev_params_mini-HowTo|The kernel commandline /dev params mini-HowTo]]
* [[Installation:Software Raid|Installation on software RAID]]
* [[Install_XOrg7|XOrg7 Installation guide]]
* '''''[[Howto Articles|more...]]'''''

<h4>Reviews</h4>
* [http://goran.krampe.se/articles/lunar.html Review of Lunar Linux] • by Göran Krampe
* [http://distrocenter.linux.com/distrocenter/05/07/25/1319212.shtml?tid=127 Lunar Linux Review] • by Preston St Pierre on [http://linux.com/ Linux.com]

<h4>Facts about Lunar</h4>
* [[User Reports|User reports]] about their success with Lunar Linux
* [[how_long|How long does it take]] to install something on lunar?

<div style="text-align: right; font-variant: small-caps; padding-right: 15px;">
[[Lunar Linux:Misc|More Information]]
</div>

User talk:Engelsman

2010-04-05T14:17:49Z

Engelsman: /* Installing Lunar Linux 1.6.4 (Lacus Autumni) */

User talk:Engelsman

2010-03-15T23:25:05Z

Engelsman: /* Installing Lunar Linux 1.6.4 (Lacus Autumni) */

User talk:Engelsman

2010-03-15T23:24:07Z

Engelsman: Observations on 1.6.4 and 1.6.5

Tools:lvu

2010-03-04T18:12:49Z

Engelsman: Reverted edits by ErmanSham (Talk); changed back to last version by Engelsman

The '''lvu''' command is a multi-purpose Lunar package viewing utility, and is the 'Swiss Army knife' of the Lunar Linux package management tools.

The '''lvu''' command provides options to:
* search for modules and keywords in the '''moonbase'''
* show the long description of a module
* show general information about a module in the '''moonbase''' and its installation history
* show which modules are installed, and their versions
* show which modules need to be updated when a new '''moonbase''' is download
* and much more

==== Manual Pages ====

For more information see the [[Tools:lvu.1.manpage|lvu(1)]] man page

Template:Main Page:About

2010-03-01T19:21:52Z

Engelsman: removed reference to Sparc, PPC and Alpha

<div style="float: right; padding-top: 0.1em; padding-right: 15px;">
{{ed|Main_Page:About|}}
</div>

==[[Lunar Linux:About|'''About Lunar Linux''']]==
'''Lunar Linux''' is a [[wikipedia:source code|source]] based [[wikipedia:Linux distribution|Linux distribution]]. It is built entirely by [[wikipedia:compiler|compiling]] [[wikipedia:source code|source code]], using custom [[wikipedia:Optimization (computer_science)|optimizations]].

It installs a complete [[wikipedia:Bootstrap#Computing|bootstrap]] development system first. After telling the Lunar package manager which software will be required, it builds the entire system by downloading current source code and locally compiling an optimized system tailored toward the users specific needs.
This should result in a lean and optimized [[wikipedia:operating system|operating system]]. On the downside, compiling a whole distribution from scratch may be time-consuming and complicate the task of keeping the packages up to date.

Currently, Lunar only supports the [[wikipedia:X86|x86]] and [[wikipedia:X86-64|x86-64]] architectures.

Lunar Linux is licensed under the GPLv2.

<div style="text-align: right; font-variant: small-caps; padding-right: 15px;">
[[Lunar Linux:About|More Information]]
</div>

Installation:lfirsttime.8.manpage

2010-02-27T11:11:54Z

Engelsman: added formatting disclaimer

=== Disclaimer: ===

This page may not be in synchronization with the man pages available on a Lunar-Linux system.

The initial version was a cut'n'paste from the man command, which produces weird wiki formatting.

----

lfirsttime(8) Lunar Linux for the first time lfirsttime(8)

NAME
lfirsttime - or 'What to do after a successful installation?'

SYNOPSIS
This manual page has been written in order to ease the life of the system administrator after the
installation part of Lunar Linux.

DO NOT PANIC!
These are the suggested tasks you should accomplish immediately after the first boot of a newly
installed Lunar box.

All of the lunar related commands mentioned below either feature a whole manpage or at least a very
useful helpscreen. If you need immediate assistance regarding any of those commands, issue:

man 'command' or 'command' --help

at your console.

The operations described below follow a strict logic and they should be executed in sequence.

Please remember that the Lunar Install/Rescue ISO is not a full featured system.

NETWORK SETTINGS
This step is crucial to your future success with Lunar Linux. If you haven't set up your network card
yet try it with lnet. Remember, you need to know about your current network card's driver and have the
kernel build the appropriate modules for it.

Check your network settings

Once you've set up your network card correctly, try to ping out.

Example: ping google.com

If it doesn't work you may be having a name resolution problem, try pinging to the IP address instead
of the name.

Example: ping 216.239.57.99

If pinging to IP is working but pinging to name fails, check the /etc/resolv.conf file and see if the
nameserver entries are there. You may also want to check the man page, man resolv.conf if you are not
familiar with the entries which should be in that file.

Check the network device

If pinging the IP address fails, check to see if your network interface is up and running. You may use
the command ifconfig to see the interface's status. You must be able to see the details of your network
interface in the output of ifconfig.

If you cannot, then check if your NIC (network interface card) module is loaded (assuming you are using
a modular kernel); use the command lsmod to see the already loaded modules and see wether the module
for your network card is already loaded.

If you do not know for sure what type of network card you have try executing the command: cat
/proc/pci|grep Ethernet or lspci. This should give the manufacturer and model name of your ethernet
card.

If your NIC module is there but your interface is not up, reconfigure the interface with lnet and test
again. If your NIC module is still not listed in the output of lsmod, the chances are you have miscon-
figured the kernel or misconfigured your network. To check the kernel modules, try ls -l /lib/mod-
ules/`uname -r`/kernel/drivers/net to see the network modules available with the current kernel. If the
your NIC's kernel module doesn't show up you probably have to reconfigure and recompile your current
kernel to include the appropriate module(s).

lnet or manual configuration

Your network setting can be configured completely using lnet; just make sure you set up your interface
correctly as needed. If you encounter problems after having configured your network with lnet you prob-
ably want to adjust the configuration manually.

The network configuration file for your Lunar installation may be found in /etc/config.d/net-
work/'interface' (f.e. 'eth0' -> /etc/config.d/network/eth0). Any time you adjust your interface's con-
figuration manually or through lnet you will have to restart the network to make use of any changes
that have been done in the meantime. The init script used to start/stop/restart network is
/etc/init.d/network.

Example: /etc/init.d/network restart

Good luck and please remember that you have to to be able to ping f.e. 'google.com' to install any
other packages or update your system!

CORE UPDATES AND SETUP
Since Lunar Linux is a source based distribution, some of the binaries and/or modules on the CD may
have been upgraded to newer versions already. Here are the first steps you should take to get an
up-to-date, smoothly running and fast system:

Update your coretools

You need to get the most recent version of the available coretools. The coretools are the heart of
every Lunar Linux system. They provide you with all the necessary commands to maintain a working
installation thus it's always recommended to have the latest version installed. There are two different
choices:

lunar or theedge

lunar is the stable branch of the lunar coretools. It's meant to run with stable production environ-
ments. theedge is the unstable branch. It might occasionally contain bugs, however it's generally used
to test out new features and bugfixes before they're migrated to the stable branch. If you'd like to
help out with the lunar development or you discovered a bug in lunar you might want to give theedge a
try.

Since the ISO ships with theedge preinstalled you have to update theedge before you do anything else --
even if you're planning to use lunar later on!

Execute: lin theedge

If you want to keep Lunar Linux as stable as possible you need to install the stable coretools branch
now by running

Execute: lin lunar

Core Components

A very brief explanation of the most important coretool components. For further information regarding
the referenced parts please refer to their manpages (i.e. man <part>):

lin; usage: lin <module>
Install a package/module.

lvu; usage: lvu <options> <module>
Gather information about a package/module.

lrm; usage: lrm <module>
Remove a package/module.

lunar; usage: lunar <options>
Lunar configuration utility

Update your moonbase

The package repository from where the coretools gather their package information is called moonbase.
Also, packages are usually referred to as modules. Since the moonbase on your installation is probably
outdated it's strongly recommended to update your moonbase right after your coretools.

Execute: lin moonbase

Set your preferences

Lunar Linux can easily be customized and is highly configurable. For changing the options that affect
your system you may use the menu driven lunar configuration utility. It's based upon ncurses which
means you can even run it in the console of your choice. You need to become root to use it.

Optimizations
Set the right optimizations for your computer. Be aware that changing your optimizations to the
wrong values might actually break your whole installation so be really careful about what you're
choosing. The ISO has been built with a minimum of available optimizations to ensure the highest
amount of flexibility. To see whether or not your processor supports a certain feature try a cat
/proc/cpu. It usually shows the available settings that suit your machine.

Integrity checking
Lunar is performing a range of security checks on tarballs and installed packages to prevent faulty
tarballs and possible intruders from taking over your system. It also ensures that none of your
currently installed packages is broken.

You may select the amount of checks from the Integrity checking submenu at the Options menu. It's
generally recommended to at least chose FIND_CHECK and LDD_CHECK.

Feature menu
As mentioned before, Lunar is highly configurable. Thus you have a whole menu to select its fea-
tures from. It's strongly advised to at least take a look at it and get used to them. Explanations
are usually displayed as soon as you select an item.

Apart from that
Take a look at the lunar configuration tool. It can be a powerful companion while achieving the
goal of setting up your system.

GENERAL UPDATES
Right now you're set to update your whole system. Before you do that make sure you have the most recent
coretools and moonbase installed.

The next step can be omitted -- however, it is highly recommended that you rebuild the following mod-
ules in the right order to ensure that your system is working right.

Here we go:

Execute: lin -cr gcc glibc gcc bash coreutils tar wget

Explanation:

lin is obviously used to install a module. It also accepts multiple modules in a row. The '-cr' switch
means 'compile (c)' and 'reconfigure (r)'. They're explained at the manpage. One needs to update gcc
thus the first gcc statement. Right after that one should recompile glibc to ensure that it's working
well with the latest compiled gcc. And finally gcc again to make use of the newly compiled glibc. The
modules right afterwards are used by Lunar Linux itself thus they need to be up-to-date and compiled
against the latest available gcc and glibc.

A complete update

Now, to update your whole system you need to issue the following

Execute: lunar update

It's going to compare your system's installed modules against the moonbases' definitions and update the
installed modules accordingly. It's going to give you a list of modules that are going to be updated.
If you're not sure wether you want a certain module to be updated remove it from the list. Once you're
done the coretools are going to start the update which usually is going to take a very long time on a
freshly installed system since most of its components will probably be outdated. So grab a coffee
and/or a book and wait for it to finish ;-)

Once it is done it is going to present you with a summary about how many module where successfully
updated and which of them failed. lvu ('lvu activity') is going to show you which of them failed and
usually why. lvu ('lvu compile <module>') is also going to show you the compilation's logfile which
should clearly point you to the error that led to the failure of the module's compilation.

The first thing to do would be to 're'lin' (i.e. execute lin -c once more. It is always advised to use
the -c and the -r switch in case a module fails to compile) all the failed modules by hand. If you
think you will not be able to resolve the matter on your own you can still file a bugreport at the
Lunar Linux bugtracker http://bugs.lunar-linux.org or report the error to the Lunar Linux mailinglist.
However, you will have to subscribe to the list at http://foo-projects.org/mailman/listinfo/lunar
before being able to post any mail to it.

Once the update has been completed successfully you may go ahead and customize your installation to
suit your own needs. Well done!

HINTS
TAB-completion
All of the coretools are able to do tab-completion. Say, you want to install the module
'xfce4-panel' just go ahead and type 'lin xfce4-p<TAB>' and lin is going to append the rest of the
module's name to the command. Once there are too few characters to resolve the name into one single
module you just need to hit TAB twice to get a list of all the modules starting with the characters
you just typed i.e. 'lin xfce<TAB><TAB>' is going to give you a list of all modules starting with
'xfce'.

Leftovers
In case of a compilation failure the sources of the failed module are left in $BUILD_DIRECTORY
(usually /usr/src/). Moreover, a few tracking files lunar creates to monitor the running installa-
tion process might be left in /tmp. Make sure you tidy up these two locations from time to time.

CAUTION: Directories like 'linux-2.x' are kernel source directories and _must_ be left intact. Oth-
erwise your system is going to break! Only delete them if you're absolutely sure that they don't
belong to your currently running kernel.

Running coretools processes
If you're interrupting a module installation process (f.e. by pressing 'CTRL-C) you should check if
there are any running coretools processes running in the background as another try to install the
module might fail because of them. Have a closer look at ps aux and kill/killall all the remaining
coretools instances of a failed installation attempt.

CAUTION: Lunar allows you to run multiple installations independently. Be sure about the processes'
purpose you're terminating!

IRC channel
The fastest help you get is by chatting with the developers directly. Join the Lunar Linux IRC
channel at freenode

irc://irc.freenode.net/#lunar

NOTES
This is merely an introduction to what should be done to get a ready-to-go Lunar system. Please consult
the documentation at the Lunar website for more information.

SEE ALSO
Documentation at the Lunar Linux website at http://lunar-linux.org

lunar(8), moonbase(1), lin(8), lvu(1), lget(8), lrm(8), lnet(8)

DISCLAIMER
The information and examples given here are for illustrative purposes. If you encounter any inaccura-
cies please send an email to the authors.

COPYRIGHT
This document is originally Copyrighted Kagan Kongar 2002.

Portions of this document Copyrighted (C) 2003-2004 Terry Chan

It has been almost completely rewritten by Moritz Heiber for the Lunar Linux development team under the
Creative Commons License, (C) 2005

AUTHORS
Kagan Kongar <kongar@tsrsb.org.tr>

Terry Chan <tchan@lunar-linux.org>

Moritz Heiber <moe@lunar-linux.org>

Moritz Heiber 2005-03-09 lfirsttime(8)