Difference between revisions of "Bering-uClibc 4.x - User Guide - Basic Configuration - Booting for the First Time"
Davidmbrooke (Talk | contribs) m (→Successful First Boot: - Corrected 4.0.0 Rev number (9 -> 12)) |
Davidmbrooke (Talk | contribs) (→Troubleshooting: - Added Hardware Device Driver Issues section) |
||
Line 47: | Line 47: | ||
Some specific issues, with solutions / workarounds, are listed below. | Some specific issues, with solutions / workarounds, are listed below. | ||
+ | |||
+ | ===Hardware Device Driver Issues=== | ||
+ | There are two main types of problem with hardware device driver kernel Modules failing to load: | ||
+ | * The necessary kernel Module files might be present in the default <code class="filename">initrd.lrp</code> RAM Disk image but are not being loaded automatically. | ||
+ | * The necessary kernel Module files might be missing from the default <code class="filename">initrd.lrp</code> RAM Disk image. | ||
+ | |||
+ | ====Hardware Auto-Detection Issues==== | ||
+ | Some older hardware is not fully compatible with the [[Bering-uClibc 4.x]] auto-detection logic which loads hardware device driver Modules at boot time. As a result, some required kernel Modules may not be loaded automatically even they are present in the default <code class="filename">initrd.lrp</code>. | ||
+ | |||
+ | The solution is to force the necessary module(s) to be loaded (more like the [[Bering-uClibc 3.x]] behaviour) and the easiest way to do that is to specify a value for the "<tt>KMODULES</tt>" kernel command line argument which takes a comma-separated list of modules. | ||
+ | To do this edit <code class="filename">{iso|pxe|sys}linux.cfg</code> and change the "<tt>APPEND</tt>" line. | ||
+ | For example, to force the "<tt>floppy</tt>" and "<tt>i2c-core</tt>" kernel Modules to be loaded change this line to read something like the following: | ||
+ | APPEND reboot=bios KMODULES=floppy,i2c-core | ||
+ | |||
+ | ====Module Files Missing From <code class="filename">initrd.lrp</code>==== | ||
+ | The default <code class="filename">initrd.lrp</code> files include a good range of kernel Modules, covering the majority of hardware devices. | ||
+ | For more unusual hardware you may find that some modules required for boot are missing. | ||
+ | Provided these are present in <code class="filename">modules.tgz</code> these can be added to <code class="filename">initrd.lrp</code> as described on the [[Bering-uClibc 4.x - User Guide - Advanced Topics - Modifying initrd.lrp|Modifying initrd.lrp]] page. Once the files are added the hardware auto-detection logic should load them automatically but in exceptional cases they may need to be loaded explicitly using the procedure documented above. | ||
+ | |||
+ | For really unusual hardware the required driver may not even be included in the kernel build configuration file and so may be missing from <code class="filename">modules.tgz</code> as well. In such cases you should report the problem to the <tt>leaf-user</tt> mailing list. | ||
+ | |||
===DMA Issues=== | ===DMA Issues=== |
Latest revision as of 10:44, 22 May 2011
Basic Configuration - Booting for the First Time | ||
---|---|---|
Bering-uClibc 4.x - User Guide | Next |
Contents
Install Media and Boot
Insert the prepared boot media into the system which is to run Bering-uClibc 4.x and power it on.
Successful First Boot
If everything works properly you should see lots of diagnostic output followed by a login prompt similar to the following:
LEAF Bering-uClibc 4.0.0 Rev 12 uClibc 0.9.30.3 firewall tty1 firewall login:
Login as user "root" (no password required at this point). You will be prompted to set a password for the root account (twice). You will then be presented with 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:
Troubleshooting
In the event of problems it is worth reviewing the Appendix which describes the Bering-uClibc startup logic to assess how far the boot progressed before failing.
Some specific issues, with solutions / workarounds, are listed below.
Hardware Device Driver Issues
There are two main types of problem with hardware device driver kernel Modules failing to load:
- The necessary kernel Module files might be present in the default
initrd.lrp
RAM Disk image but are not being loaded automatically. - The necessary kernel Module files might be missing from the default
initrd.lrp
RAM Disk image.
Hardware Auto-Detection Issues
Some older hardware is not fully compatible with the Bering-uClibc 4.x auto-detection logic which loads hardware device driver Modules at boot time. As a result, some required kernel Modules may not be loaded automatically even they are present in the default initrd.lrp
.
The solution is to force the necessary module(s) to be loaded (more like the Bering-uClibc 3.x behaviour) and the easiest way to do that is to specify a value for the "KMODULES" kernel command line argument which takes a comma-separated list of modules.
To do this edit {iso|pxe|sys}linux.cfg
and change the "APPEND" line.
For example, to force the "floppy" and "i2c-core" kernel Modules to be loaded change this line to read something like the following:
APPEND reboot=bios KMODULES=floppy,i2c-core
Module Files Missing From initrd.lrp
The default initrd.lrp
files include a good range of kernel Modules, covering the majority of hardware devices.
For more unusual hardware you may find that some modules required for boot are missing.
Provided these are present in modules.tgz
these can be added to initrd.lrp
as described on the Modifying initrd.lrp page. Once the files are added the hardware auto-detection logic should load them automatically but in exceptional cases they may need to be loaded explicitly using the procedure documented above.
For really unusual hardware the required driver may not even be included in the kernel build configuration file and so may be missing from modules.tgz
as well. In such cases you should report the problem to the leaf-user mailing list.
DMA Issues
Some drives, especially some Compact Flash drive / adaptor combinations, do not properly support DMA. The symptoms of problems are boot messages like the following, accompanied by delays while the drive access times out and it reverts to non-DMA operation:
[ 36.768088] ata1: lost interrupt (Status 0x58) [ 36.769016] ata1: drained 4096 bytes to clear DRQ. [ 36.772872] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 36.773075] ata1.00: failed command: READ DMA [ 36.773261] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in [ 36.773273] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 36.773752] ata1.00: status: { DRDY } [ 36.773970] ata1: soft resetting link [ 36.931430] ata1.00: configured for MWDMA2 [ 36.931597] ata1.00: device reported invalid CHS sector 0 [ 36.931772] ata1: EH complete
The solution is to disable any attempt to use DMA for the relevant device by setting options for the libata driver.
The following is a small extract from linux-2.6.35.8/Documentation/kernel-parameters.txt
(part of the kernel source distribution):
libata.dma= [LIBATA] DMA control libata.dma=0 Disable all PATA and SATA DMA libata.dma=1 PATA and SATA Disk DMA only libata.dma=2 ATAPI (CDROM) DMA only libata.dma=4 Compact Flash DMA only Combinations also work, so libata.dma=3 enables DMA for disks and CDROMs, but not CFs.
So, assuming the problem affects only Compact Flash devices, these can have DMA disabled by using kernel argument libata.dma=3.
This should be specified by editing file syslinux.cfg
:
- Mount the boot drive: mount /dev/sda1 /mnt
- Edit
syslinux.cfg
: edit /mnt/syslinux/syslinux.cfg - Add libata.dma=3 to the APPEND line so that the complete line reads: APPEND reboot=bios libata.dma=3
- Unmount the boot drive: umount /mnt
- Reboot
Up | Next |