Bering-uClibc 5.x - User Guide - Basic Configuration - Basic System Configuration
| Basic Configuration - Basic System Configuration | ||
|---|---|---|
| Prev | Bering-uClibc 5.x - User Guide | Next |
Contents
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 in Bering-uClibc 4.x has been the kernel Module detection and, to a large extent, automated loading.
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 with 5.2 and above
tbc
Automatic hardware detection until 5.2
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" was new for Bering-uClibc 4.x. Type f to initiate the automatic processing. You will see output similar to the following (this example is for a PC Engines ALIX2D13 board):
Extracting modules from modules.tgz... Done.
Probing modaliases... Done.
12 devices have modules.
Copying new modules to /lib/modules...
Adding option.ko
Adding usb_wwan.ko
Adding usbserial.ko
Adding leds-alix2.ko
Adding geode-aes.ko
Adding geode-rng.ko
Adding rng-core.ko
Adding pcspkr.ko
Done.
Checking entries in /etc/modules...
Adding sch_prio.ko
Done.
Press return...
The list of modules found 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(located on the boot media) into a temporary location under/lib/modules/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, loads their Modules into the running kernel and checks whether further Modules should be loaded.
- Copies any new kernel Module
.kofiles to/lib/modules/. - Ensures that all of the Modules listed in
/etc/moduleshave the corresponding.kofiles present in/lib/modules/.- If you do need to add any entries to
/etc/modulesit is best to do that before running this process, so that the.kofiles are copied automatically.
- If you do need to add any entries to
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").
Tip: If you normally add a lot of optional .lrp Packages which, when loaded, occupy a lot of RAM disk space, you may have more success running automatic hardware detection before adding those extra Packages into leaf.cfg. You can always add them later, when the required Modules have been identified and added to moddb.lrp.
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.
Any Modules which are not hardware device drivers will usually also be loaded automatically when they are required, provided the relevant .ko files (and all of their dependencies) are present in /lib/modules/. As a result they do not need to be specified in /etc/modules.
The following Modules do still need to be listed in /etc/modules:
- tun, the network tunnel driver (required for AICCU and OpenVPN).
- lp, the line printer driver (required for the p9100 Package).
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. Note that "standard" here means the standard post-2007 USA rules (Wikipedia description here) so for locations outside the USA it is usually necessary to explicitly specify the "rule" as described below.
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 second Sunday of March at 2:00 A.M. and ends on the first Sunday of November at 2:00 A.M. (according to the post-2007 USA daylight savings rules).
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 |
