Difference between revisions of "Bering-uClibc 4.x - User Guide - Basic Configuration - Basic System Configuration"

From bering-uClibc
Jump to: navigation, search
(Added navigation links for new "Booting for the First Time" Sub-Chapter)
(Added Section "Add kernel Modules for your hardware")
Line 7: Line 7:
 
|}
 
|}
 
----
 
----
 +
 +
 +
==Add kernel Modules for your hardware==
 +
The default modules Package (<code class="filename">moddb.lrp</code>) contains kernel Modules (device drivers) for some common hardware devices such as network interface cards and disk interfaces.
 +
However, you will probably find that the default modules Package does not contain the device drivers for all of your hardware.
 +
 +
A big change from [[Bering-uClibc 3.x]] is that kernel Module detection and loading is now much more automated.
 +
At boot time, any Modules present in <code class="filename">/lib/modules/</code> which are compatible with the installed hardware are automatically loaded into the running kernel.
 +
(See [[Bering-uClibc 4.x - User Guide - Appendices - Overview of the Startup Sequence|this Appendix]] for details of how this is achieved.)
 +
The important thing is therefore to ensure that directory <code class="filename">/lib/modules/</code> contains the right kernel Module files for your hardware.
 +
 +
===Automatic hardware detection===
 +
The easiest approach is to use the new hardware auto-detection utility.
 +
Run '''lrcfg''' to display the LEAF configuration menu:
 +
 +
                        LEAF configuration menu
 +
 +
 +
        1) Network configuration
 +
 +
        2) System configuration
 +
 +
        3) Packages configuration
 +
 +
  s) Save configuration
 +
m) Backup modules
 +
f) Find & load modules for hardware
 +
 +
c) Show configuration changes since last save
 +
d) Show configuration changes from defaults
 +
 
 +
h) Help
 +
  q) quit
 +
  ----------------------------------------------------------------------------
 +
Selection:
 +
 +
Option "<tt>f) Find & load modules for hardware</tt>" is new for [[Bering-uClibc 4.x]].
 +
Type '''<tt>f</tt>''' to initiate the automatic processing. You will see output similar to the following:
 +
Extracting modules... Done
 +
Probing modaliases... 7 devices has modules.
 +
Copying modules to /lib/modules... Done.
 +
    Press return...
 +
 +
The number of modules found (7 in this case) is completely dependent on your hardware and the existing contents of <code class="filename">/lib/modules/</code> so can vary considerably.
 +
 +
In summary, this process:
 +
* Extracts the contents of <code class="filename">modules.tgz</code> (on the boot media) into a temporary location on the RAM disk.
 +
** '''Note:''' This requires more than 20MB of available space on the RAM disk. As a result it is unlikely to work on systems with less than 64MB RAM.
 +
* Looks at the hardware devices connected to the system and checks whether any of the Modules in the temporary location provide extra device drivers for that hardware.
 +
* If any new device drivers are found, copies the kernel Module <code class="filename">.ko</code> files to <code class="filename">/lib/modules/</code>.
 +
Note that the files are only copied to <code class="filename">/lib/modules/</code>, not also saved to <code class="filename">modules.lrp</code>. This needs to be done separately (using option "<tt>m) Backup modules</tt>").
 +
 +
===Manual addition of Modules===
 +
If you do not wish to use the automatic hardware detection process, or cannot because of insufficient RAM (and hence RAM disk space) you can always manually add the necessary Modules to <code class="filename">/lib/modules/</code>. They will still be loaded automatically at boot time.
 +
Unlike with [[Bering-uClibc 3.x]] there is no need to list all the Modules in file <code class="filename">/etc/modules</code>; any hardware-related Modules will be loaded automatically.
 +
 +
'''Note:''' Any Modules which are not hardware device drivers will '''not''' be loaded automatically. These still need to be specified in <code class="filename">/etc/modules</code>.
  
  
Line 20: Line 77:
 
   
 
   
 
   q) quit
 
   q) quit
Type 1 to get access to the <tt>/etc/default/keyboard</tt> script where you will have to replace the <tt>KEYMAP</tt> variable (default="us.map") by the appropriate keyboard setting.
+
Type '''<tt>1</tt>''' to get access to the <tt>/etc/default/keyboard</tt> script where you will have to replace the <tt>KEYMAP</tt> variable (default="us.map") by the appropriate keyboard setting.
  
 
The KEYMAP variable must be chosen among the following entries:
 
The KEYMAP variable must be chosen among the following entries:

Revision as of 12:40, 4 December 2010

Basic Configuration - Basic System Configuration
Prev Bering-uClibc 4.x - User Guide Next


Add kernel Modules for your hardware

The default modules Package (moddb.lrp) contains kernel Modules (device drivers) for some common hardware devices such as network interface cards and disk interfaces. However, you will probably find that the default modules Package does not contain the device drivers for all of your hardware.

A big change from Bering-uClibc 3.x is that kernel Module detection and loading is now much more automated. At boot time, any Modules present in /lib/modules/ which are compatible with the installed hardware are automatically loaded into the running kernel. (See this Appendix for details of how this is achieved.) The important thing is therefore to ensure that directory /lib/modules/ contains the right kernel Module files for your hardware.

Automatic hardware detection

The easiest approach is to use the new hardware auto-detection utility. Run lrcfg to display the LEAF configuration menu:

                       LEAF configuration menu


       1) Network configuration

       2) System configuration

       3) Packages configuration

 				s) Save configuration
				m) Backup modules
				f) Find & load modules for hardware

				c) Show configuration changes since last save
				d) Show configuration changes from defaults
 
				h) Help
 q) quit
 ----------------------------------------------------------------------------
	Selection: 

Option "f) Find & load modules for hardware" is new for Bering-uClibc 4.x. Type f to initiate the automatic processing. You will see output similar to the following:

Extracting modules... Done
Probing modaliases... 7 devices has modules.
Copying modules to /lib/modules... Done.
    Press return...

The number of modules found (7 in this case) is completely dependent on your hardware and the existing contents of /lib/modules/ so can vary considerably.

In summary, this process:

  • Extracts the contents of modules.tgz (on the boot media) into a temporary location on the RAM disk.
    • Note: This requires more than 20MB of available space on the RAM disk. As a result it is unlikely to work on systems with less than 64MB RAM.
  • Looks at the hardware devices connected to the system and checks whether any of the Modules in the temporary location provide extra device drivers for that hardware.
  • If any new device drivers are found, copies the kernel Module .ko files to /lib/modules/.

Note that the files are only copied to /lib/modules/, not also saved to modules.lrp. This needs to be done separately (using option "m) Backup modules").

Manual addition of Modules

If you do not wish to use the automatic hardware detection process, or cannot because of insufficient RAM (and hence RAM disk space) you can always manually add the necessary Modules to /lib/modules/. They will still be loaded automatically at boot time. Unlike with Bering-uClibc 3.x there is no need to list all the Modules in file /etc/modules; any hardware-related Modules will be loaded automatically.

Note: Any Modules which are not hardware device drivers will not be loaded automatically. These still need to be specified in /etc/modules.


Configure your Keyboard

If you are a non US user you will probably need one of the alternative keyboard layouts provided in the keyboard.lrp package.

To configure the keyboard layout run lrcfg, go to the LEAF Packages configuration menu and choose keyboard.

The following menu will appear:

			keyboard configuration files

	1) change keyboard language maps

  q) quit

Type 1 to get access to the /etc/default/keyboard script where you will have to replace the KEYMAP variable (default="us.map") by the appropriate keyboard setting.

The KEYMAP variable must be chosen among the following entries:

azerty.map   de.map       gr.map       lt.map       ru.map       trq.map
be.map       dk.map       hu.map       mk.map       se.map       ua.map
bg.map       dvorak.map   il.map       nl.map       sg.map       uk.map
br-a.map     es.map       is.map       no.map       sk-y.map     us.map
cf.map       et.map       it.map       pl.map       sk-z.map     wangbe.map
croat.map    fi.map       jp.map       pt.map       slovene.map
cz.map       fr.map       la.map       ro.map       trf.map

To activate the new keyboard map get access to the Linux shell and type:

svi keyboard start


Important: To save your modification(s) do not forget to save the configuration!


Configure your Editor

All standard editors are based on e3, which provides five emulation modes:

e3em emacs mode
e3ne nedit mode
e3pi pico mode
e3vi vi mode
e3ws wordstar mode


The default editor for lrcfg is edit which is a small shell script that reads the environment variable EDITOR and calls e3 with the chosen emulation mode.

To change the editor emulation mode directly, modify EDITOR in /etc/profile.

Alternatively run lrcfg, go to the LEAF System configuration menu and choose System wide profile.

Change the EDITOR setting to your preferred editor, for example:

#Set the desired editor (e3ne, e3em, e3pi, e3vi, e3ws)
export EDITOR=e3ne

The desired editor mode is available with the next login.

You can always use another editor mode from the command line by calling it with the proper symlink - see table above.

The main objective for the e3 editor is small size, not complete emulation of the other editors. If you have the disk space and memory resources consider installing elvis.lrp for a better vi experience than is provided by e3vi. In this case set EDITOR to vi.


Important: To save your modification(s) do not forget to save the configuration!


Configure your Timezone

In Bering-uClibc /etc/timezone and the whole zoneinfo directory tree are not supported. To set the timezone, edit the /etc/TZ file and set the timezone in a single line, ending with a newline, as specified in http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html.

Warning: Be sure to have no empty line at the end of /etc/TZ otherwise your timezone will be set to back UTC.

For example: CST6CDT means Central Standard Time which is 6 hours earlier than Coordinated Universal Time (UTC) and that standard rules for adjustment to Daylight Savings Time are to be applied. The first letters preceding the offset are actually nothing more than the descriptor used by programs such as "date" when displaying the time. Use whatever letters are meaningful in your area. The offset number is what is used to actually calculate the difference from UTC. The last three letters again can be anything that represents a meaningful adjustment to the offset given. A "tongue in cheek" example:

MCT-6CDT

is "legal" and might refer to Martian Canal Time which is defined as being 6 hours later than Coordinated Universal Time (UTC) and modified by one hour to Canal Daylight Time on the standard date.

Examples for TZ values

To give you an idea how to build your local TZ value, a few more examples provided by Erik Anderson:

MDT6

This means that MDT (Mountain Daylight Time) is 6 hours earlier than Coordinated Universal Time (UTC) and does not have daylight saving time.

JST-9

This means that Japanese Standard Time (JST) is 9 hours earlier than Coordinated Universal Time (UTC) and does not have daylight saving time.

MST7MDT

This means that Mountain Standard Time (MST) is 7 hours earlier than Coordinated Universal Time (UTC). Both standard time and daylight saving time apply to this locale. By default Mountain Daylight Time (MDT) is one hour ahead of MST. Since it isn't otherwise specified, daylight saving time starts on the first Sunday of April at 2:00 A.M. and ends on the last Sunday of October at 2:00 A.M.

NST3:30NDT1:30

This means that Newfoundland Standard Time (NST) is 3.5 hours earlier than Coordinated Universal Time (UTC). Both standard time and daylight saving time apply to this locale. Newfoundland Daylight Time is 1.5 hours earlier than Coordinated Universal Time (UTC).

MET-1METDST-2,M3.5.0/02:00:00,M10.5.0/03:00:00

This example has been sent by Jacques Nilo and provides a complete example for MET, METDST (summer time) and the date and daytime it will be changed.

Specification of the TZ variable

This section is an extract from SUSv3 specification and the technical background how a TZ value is built.

The value of TZ is of the form:

std offset dst offset, rule

The format is as follows:

stdoffset[dst[offset][,start[/time],end[/time]]]

Where:

  • std and dst: Indicate no less than three, nor more than {TZNAME_MAX}, bytes that are the designation for the standard ( std) or the alternative ( dst -such as Daylight Savings Time) timezone. Only std is required; if dst is missing, then the alternative time does not apply in this locale.
  • std and dst: Indicate no less than three, nor more than {TZNAME_MAX}, bytes that are the designation for the standard ( std) or the alternative ( dst -such as Daylight Savings Time) timezone. Only std is required; if dst is missing, then the alternative time does not apply in this locale.
  • offset: Indicates the value added to the local time to arrive at Coordinated Universal Time. The offset has the form: hh[:mm[:ss]]The minutes ( mm) and seconds ( ss) are optional. The hour ( hh) shall be required and may be a single digit. The offset following std shall be required. If no offset follows dst, the alternative time is assumed to be one hour ahead of standard time. One or more digits may be used; the value is always interpreted as a decimal number. The hour shall be between zero and 24, and the minutes (and seconds)-if present-between zero and 59. The result of using values outside of this range is unspecified. If preceded by a '-', the timezone shall be east of the Prime Meridian; otherwise, it shall be west (which may be indicated by an optional preceding '+' ).
  • rule: Indicates when to change to and back from the alternative time. The rule has the form: date[/time],date[/time]where the first date describes when the change from standard to alternative time occurs and the second date describes when the change back happens. Each time field describes when, in current local time, the change to the other time is made.The format of date is one of the following:
    • Jn: The Julian day n (1 <= n <= 365). Leap days shall not be counted. That is, in all years-including leap years-February 28 is day 59 and March 1 is day 60. It is impossible to refer explicitly to the occasional February 29.
    • n: The zero-based Julian day (0 <= n <= 365). Leap days shall be counted, and it is possible to refer to February 29.
    • Mm.n.d: The d'th day (0 <= d <= 6) of week n of month m of the year (1 <= n <= 5, 1 <= m <= 12, where week 5 means "the last d day in month m" which may occur in either the fourth or the fifth week). Week 1 is the first week in which the d'th day occurs. Day zero is Sunday. The time has the same format as offset except that no leading sign ( '-' or '+' ) is allowed. The default, if time is not given, shall be 02:00:00.



Prev Up Next