| 3.7. Pre-Installation Hardware and Operating System Setup | ||
|---|---|---|
 |
Chapter 3. Before Installing Ubuntu | 
|
| 3.7. Pre-Installation Hardware and Operating System Setup | ||
|---|---|---|
|
|
Chapter 3. Before Installing Ubuntu |
|
This section will walk you through pre-installation hardware setup, if any, that you will need to do prior to installing Ubuntu. Generally, this involves checking and possibly changing BIOS/system firmware settings for your system. The “BIOS” or “system firmware” is the core software used by the hardware; it is most critically invoked during the bootstrap process (after power-up).
As already mentioned before, there is unfortunately no standard for system firmware on ARM systems. Even the behaviour of different systems which use nominally the same firmware can be quite different. This results from the fact that a large part of the devices using the ARM architecture are embedded systems, for which the manufacturers usually build heavily customized firmware versions and include device-specific patches. Unfortunately the manufacturers often do not submit their changes and extensions back to the mainline firmware developers, so their changes are not integrated into newer versions of the original firmware.
As a result even newly sold systems often use a firmware that is based on a years-old manufacturer-modified version of a firmware whose mainline codebase has evolved a lot further in the meantime and offers additional features or shows different behaviour in certain aspects. In addition to that, the naming of onboard devices is not consistent between different manufacturer-modified versions of the same firmware, therefore it is nearly impossible to provide usable product-independend instructions for ARM-based systems.
The MAC address of every ethernet interface should normally be globally unique, and it technically has to be unique within its ethernet broadcast domain. To achieve this, the manufacturer usually allocates a block of MAC addresses from a centrally-administered pool (for which a fee has to be paid) and preconfigures one of these addresses on each item sold.
In the case of development boards, sometimes the manufacturer wants to avoid paying these fees and therefore provides no globally unique addresses. In these cases the users themselves have to define MAC addresses for their systems. When no MAC address is defined for an ethernet interface, some network drivers generate a random MAC address that can change on every boot, and if this happens, network access would be possible even when the user has not manually set an address, but e.g. assigning semi-static IP addresses by DHCP based on the MAC address of the requesting client would obviously not work reliably.
To avoid conflicts with existing officially-assigned MAC addresses, there is an address pool which is reserved for so-called “locally administered” addresses. It is defined by the value of two specific bits in the first byte of the address (the article “MAC address” in the English language Wikipedia gives a good explanation). In practice this means that e.g. any address starting with hexadecimal ca (such as ca:ff:ee:12:34:56) can be used as a locally administered address.
On systems using U-Boot as system firmware, the ethernet MAC address is placed in the “ethaddr” environment variable. It can be checked at the U-Boot command prompt with the command “printenv ethaddr” and can be set with the command “setenv ethaddr ca:ff:ee:12:34:56”. After setting the value, the command “saveenv” makes the assignment permanent.
On some systems with older U-Boot versions there can be problems with properly relocating the Linux kernel, the initial ramdisk and the device-tree blob in memory during the boot process. In this case, U-Boot shows the message “Starting kernel ...”, but the system freezes afterwards without further output. These issues have been solved with newer U-Boot versions from v2014.07 onwards.
If the system has originally used a U-Boot version older than v2014.07 and has been upgraded to a newer version later, the problem might still occur even after upgrading U-Boot. Upgrading U-Boot usually does not modify the existing U-Boot environment variables and the fix requires an additional environment variable (bootm_size) to be set, which U-Boot does automatically only on fresh installations without existing environment data. It is possible to manually set bootm_size to the new U-Boot's default value by running the command “env default bootm_size; saveenv” at the U-Boot prompt.
Another possibility to circumvent relocation-related problems is to run the command “setenv fdt_high ffffffff; setenv initrd_high 0xffffffff; saveenv” at the U-Boot prompt to completely disable the relocation of the initial ramdisk and the device-tree blob.
UEFI (“Unified Extensible Firmware Interface”) is a new kind of system firmware that is used on many modern systems and is - among other uses - intended to replace the classic PC BIOS.
Currently most PC systems that use UEFI also have a so-called “Compatibility Support Module” (CSM) in the firmware, which provides excatly the same interfaces to an operating system as a classic PC BIOS, so that software written for the classic PC BIOS can be used unchanged. Nonetheless UEFI is intended to one day completely replace the old PC BIOS without being fully backwards-compatible and there are already a lot of systems with UEFI but without CSM.
On systems with UEFI there are a few things to take into consideration when installing an operating system. The way the firmware loads an operating system is fundamentally different between the classic BIOS (or UEFI in CSM mode) and native UEFI. One major difference is the way the harddisk partitions are recorded on the harddisk. While the classic BIOS and UEFI in CSM mode use a DOS partition table, native UEFI uses a different partitioning scheme called “GUID Partition Table” (GPT). On a single disk, for all practical purposes only one of the two can be used and in case of a multi-boot setup with different operating systems on one disk, all of them must therefore use the same type of partition table. Booting from a disk with GPT is only possible in native UEFI mode, but using GPT becomes more and more common as hard disk sizes grow, because the classic DOS partition table cannot address disks larger than about 2 Terabytes while GPT allows for far larger disks. The other major difference between BIOS (or UEFI in CSM mode) and native UEFI is the location where boot code is stored and in which format it has to be. This means that different bootloaders are needed for each system.
The latter becomes important when booting debian-installer on a UEFI system with
CSM because debian-installer checks whether it was started on a BIOS- or on a
native UEFI system and installs the corresponding bootloader.
Normally this simply works but there can be a problem in multi-boot
environments. On some UEFI systems with CSM the default boot mode for
removable devices can be different from what is actually used when
booting from hard disk, so when booting the installer from a USB stick
in a different mode from what is used when booting another already
installed operating system from the hard disk, the wrong bootloader
might be installed and the system might be unbootable after finishing
the installation. When choosing the boot device from a firmware boot
menu, some systems offer two seperate choices for each device, so that
the user can select whether booting shall happen in CSM or in native
UEFI mode.
|
|
 |
|
| 3.6. Pre-Partitioning for Multi-Boot Systems |  |
Chapter 4. Obtaining System Installation Media |