Bering-uClibc 4.x - User Guide - Basic Configuration - Booting for the First Time

From bering-uClibc
Jump to: navigation, search
Basic Configuration - Booting for the First Time
Bering-uClibc 4.x - User Guide Next

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  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


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- (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:

  1. Mount the boot drive: mount /dev/sda1 /mnt
  2. Edit syslinux.cfg: edit /mnt/syslinux/syslinux.cfg
  3. Add libata.dma=3 to the APPEND line so that the complete line reads: APPEND reboot=bios libata.dma=3
  4. Unmount the boot drive: umount /mnt
  5. Reboot

Up Next