The BIOS (Basic Input Output System) is located in a memory chip of the motherboard and is the program that is started when the PC boots. It performs checks and signals failures with beeps but also puts error codes to the IO port address 80 that can be captured using special PC cards. After a successful boot, it looks for a disk drive as a hard disk and reads there the 512 Byte big Master Boot Record (boot sector) and starts it. This program from the 512 Byte boot sector then can read a partition and load more code into memory and then start it. Boot loaders as Grub will get alive like this.
Boot loaders are therefore limited to understand partition schemes (MBR) and reading filesystems. Therefore it is common for a simple Linux system to have 2 partitions.
/dev/sda1 the boot partition about 128MByte size ext2 formatted to hold the bootloader and the Linux kernels to be read and loaded by the boot loader.
/dev/sda2 then is better more advanced as ext4 formatted and can hold all the data and is called the root partition.
More partitions can be added as a swap partition. However in the time of having SSD swapping to SSD might not be desired. It should also be noted that a swap file can be used instead of a swap partition. Often the swap partition is /dev/sda2 so the root partition will be /dev/sda3. It is also common to split the root partition into more partition or having more than on physical drive (a SSD drive and a big hard disk).
No Floppy drive, no CD drive (or BIOS does not support it), no Windows, no DOS just Linux and the BIOS update comes with a DOS program?
Download (and unzip) a boot-able floppy image as from http://www.bootdisk.com/bootdisk.htm
http://www.linurs.org/download/floppy.img.gz.
To create a boot-able floppy image yourself you should have a computer with a floppy disk drive. But having a floppy disk drive makes updating the BIOS easy and the following steps would not be necessary. However the time will come when you probably do not have a floppy disk drive anymore and storing the created floppy image is much easier than storing historic computer hardware. Therefore here the instructions. Create or find a bootable floppy disk. If you do not have a Microsoft operating system available, then use alternatives as the CD from http://www.freedos.org/. When having a boot-able floppy it can be converted into a floppy image file: cat /dev/fd0 ><name of floppy image>
Copy the floppy image to /boot
and add the following to your grub.conf
:
Note: /boot/memdisk might be necessary in the path, depending how your Linux is setup
memdisk is the floppy emulator and can be obtained by emerge syslinux and cp /usr/share/syslinux/memdisk /boot.
Now its worth to try out FreeDOS, boot it and you should find yourself in DOS. When done, the good old Ctrl Alt Del brings you back.
Reboot the PC in Linux and add the BIOS update utility to FreeDos. To do this create a mounting point mkdir /mnt/floppy and mount the image:
mount -o loop /boot/<name of floppy image>
/mnt/floppy
Now cd /mnt/floppy and copy the DOS BIOS utility (e.g. AWDFLASH.EXE) and the new BIOS (e.g. M2N-SLI-Deluxe-1701.BIN or rename it to have it DOS style 8 characters and character extension) to the floppy image. Check where the floppy is mounted cat /etc/mtab and then unmount it umount /dev/loop<n>
, reboot from FreeDos and update the BIOS.
When done it is wise to mount -o loop /boot/boot/<name of floppy image>
/mnt/floppy and delete the BIOS update utility from there, since updating BIOS is a critical task that can badly hurt your PC when it crashes, or gets interrupted by a power failure.
If BIOS update was successful but the motherboard does not start, try to reset the CMOS setup as documented in the motherboard manual or remove the battery.
Unified Extensible Firmware Interface (UEFI) replaced Extensible Firmware Interface (EFI) and therefore the classic BIOS. https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface. https://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/
The partition is GPT this means GUID Partition Table and GUID stands for Globally Unique Identifier.
Instead of a boot sector, UEFI is able to read a FAT 32 formated file system acting as the EFI system partition (ESP). There is no mystery about the ESP it is just a FAT32 formated partition on a GTP disk with its boot flag turned on. Unfortunately FAT32 does not support symlinks.
The intention of EFI is using a boot entry on the motherboards BIOS to start a efi application on a disks partition acting as the ESP and nothing else. To boot something else (as live CD without ESP) a bootloader acting as efi application has to be used that boots something other than a efi application.
For backward and fallback reasons most motherboards have the CSM, the Compatibility Support Module within UEFI. So a UEFI motherboard can boot as a good old BIOS when using a MBR partitioned disk. GTP partitioned disks with CSM is also possible but more complicated.
The BIOS on the motherboard has boot entries that point to efi applications in the ESP (boot partition formatted with FAT 32). Typically there is a efi directory in the ESP where every efi application has its own subdirectory. If the ESP is after booting mounted to /boot
those efi applications appear as /boot/efi/boot/bootx64.efi
.
UEFI applications are usually boot loaders as grub (acting as efi application) that will find on the ESP the kernels to be loaded. /EFI/gentoo/grubx64.efi
on the ESP
or /boot/EFI/shell/grubx64.efi
on the root file system is the grub executable.
Unfortunately EFI is complex and some motherboards behave not as desired. /efi/boot/bootx64.efi should be able to be started.
UEFI can boot directly a Linux kernel that is compiled as stub kernel knowing all its boot parameter as where the root filesystem is and therefore having the need of a boot loader obsolete.
An other efi application is the efi shell where its source code can or binary can be obtained https://sourceforge.net/projects/efi-shell/
http://www.rodsbooks.com/refind/getting.html has a efi bootable CD image
https://svn.code.sf.net/p/edk2/code/branches/UDK2014.SP1/ShellBinPkg/UefiShell/X64/
The binary can then be added to /EFI/shell/
on the ESP
or <binary>
.efi/boot/EFI/shell/
on the root file system. <binary>
.efi
To start a efi application a boot entry is required. Some BIOS versions have nice gui support to deal and create those boot entries other have nothing. If there is no boot entry to boot from a hard disk then booting from a hard disk is not possible. In such cases a boot entry must be done in the motherboards BIOS non volatile memory.
A nice gui BIOS might be nice to look at but might not do what is desired. It might also be picky to accept path names as /EFI/gentoo/grubx64.efi
and accept just paths as /boot/efi/boot/bootx64.efi
It is possible to communicate after a EFI boot (not a CSM boot) with EFI via the EFI Variables. This requires the Kernel settings Pseudo File System > EFI Variable filesystem. The kernel module might be required to be loaded modprobe efivars to have then access mount -t efivarfs none /sys/firmware/efi/efivars. Finally access is via /sys/firmware/efi/efivars/
To work with the boot entries (add, view, edit, delete) there is the efibootmgr. efibootmgr accesses the efivars this means the PC must have be booted with efi (make sure the live CD supports this and the motherboards BIOS is set to just do a efi boot). efibootmgr -v shows the boot entries. A boot entry needs to know
what disk as --disk /dev/sda
what partition as --part 1
a label as --label "hello it me"
a path to the efi application on the disk and partition as --loader "\efi\boot\grubx64.efi"
The following adds a boot entry to the motherboards BIOS on the first hard disks first partition that has the label Gentoo and calls grub efibootmgr --create --disk /dev/sda --part 1 --label "Gentoo" --loader "\efi\boot\grubx64.efi"
Or
efibootmgr --create --disk /dev/sdb --part 1 --label "Gentoo" --loader "\efi\gentoo\grubx64.efi"
\ needs to be used to separate directories in the path for everything that goes to UEFI
To change the order the boot entries try to boot use: efibootmgr -o 2,1,3,0 . The numbers are the (1 or 4 digit) numbers shown by efibootmgr. It is a good sign if writing fails due to read-only file system error. If so, remount the efivars mount -o remount /sys/firmware/efi/efivars -o rw,nosuid,nodev,noexec,noatime
efibootmgr -t 10 set a timout
efibootmgr -T delete the timeout
efibootmgr -b 1 -B to delete the boot entry Boot0001 as shown by efibootmgr
A efi GTP disk and be simply partitioned and formatted as follows
mkfs.fat -F 32 /dev/sda1 to format FAT32 the first partition as ESP with about 128M. Within parted, set 1 boot on turns the boot flag on
/dev/sda2
the ext4 rootfs partition
Once grub starts, grub can call other installed efi applications as the efi shell. As example add to /etc/grub.d/51_efishell
the following
#!/bin/sh exec tail -n +3 $0 menuentry "EFI shell" { chainloader /EFI/shell/Shell_Full.efi }
Secure Boot is used with the Unified Extensible Firmware Interface to restrict booting just from signed bootloaders. For Linux this means no more compiling the bootloader since then it is no more binary equal and therefore not signed. Such signed binary bootloaders are Shim and PreLoader.
The package fwts allows to see what is stored in the BIOS: fwts uefidump - | less
On MBR partitions the boot loader does not fit into the bootsector. The bootsector has just everything necessary to start the bootloader that is somewhere else on the disk. Usually the boot loader starts the operation system and the PC is ready to go. Chainloading is when the boot loader calls an other bootloader instead. As example when doing a major update to a bootloader, it might be advisable to have the old well working bootloader calling the new one, the new one could fails and crash the PC, a simple reboot will bring back the old old bootloader where you could select now to boot directly into the system.
There are different boot loaders available. For booting from hard disks (or any disks except CD/DVD or embedded solutions) grub is mostly used.
For gentoo add
GRUB_PLATFORMS="efi-64"
to /etc/portage/make.conf
before emerging it to have efi support by doing it manually or echo 'GRUB_PLATFORMS="efi-64"' >> /etc/portage/make.conf.
After Grub is installed grub-install --target=x86_64-efi --efi-directory=/boot need to be executed to create the /boot/grub
and /boot/EFI
directories.
If it fails due to no write access, remount the efivars mount -o remount /sys/firmware/efi/efivars -o rw,nosuid,nodev,noexec,noatime
If boot fails try grub-install --target=x86_64-efi --efi-directory=/boot --removable that remounts the EFI directory
grub uses the configuration file /boot/grub/grub.cfg
to start. Furthermore this file should not be edited since it is normally produced automatically by the grub-mkconfig program from the files found in the directory /etc/grub.d
and settings from /etc/default/grub
where settings as the following can be done:
background image:
GRUB_BACKGROUND="/boot/grub/themes/starfield/starfield.png"
Don't forget to run grub-mkconfig -o /boot/grub/grub.cfg to get an effect.
kernel parameters as disabling the Predictable Network Interface Names and force to use the traditional network names (as eth0):
GRUB_CMDLINE_LINUX="net.ifnames=0"
grub-mkconfig -o /boot/grub/grub.cfg will automatically detect files in /boot/kernel-<version and text>
as kernels and adds them to the grub configuration. /etc/grub.d/40_custom
can hold things that are not automatically detected.
Optionally the packet os-prober could be installed that checks for other than Linux operating systems.
And finally a custom file as /etc/grub.d/50_freedos
could be made
#!/bin/sh exec tail -n +3 $0 menuentry "FREEDOS" { root=hd0,0 linux /memdisk initrd (loop)/FDSTD.288 }
When grub starts an error might pop up for a fraction of a second, telling the file /grub/locale/en.gmo can not be found. This seems to be a bug that can be fixed by
cp /usr/share/locale/<language>
/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo
or
cp /boot/grub/locale/<what every you have>
. mo /boot/grub/locale/en.mo
The file extension here is mo not gmo
During boot the c key brings grub into its command line mode where things can be observed.
ls (hd0,2) shows information about this hard disk partition
ls (hd0,2)/ shows files and directory on this hard disk partition
linux (hd0,2)/kernel-<x>
root=/dev/sda4 ro followed by boot select a kernel and the boots it.
grub supports the <tab> key for file completion
U-boot from http://www.denx.de/en/News/WebHome is a boot loader mainly targeted for embedded systems. Many of those do not have a screen. However u-boot uses a serial link (115200 baud) where a terminal program as gtkterm can be attached. Pressing a key during boot brings up the u-boot console, where commands as help can be typed. printenv gives a lot of information about what u-boot sees and what it will do. setenv modifies them and saveenv makes it persistent. mmc list shows the mmc/sd cards mmc dev 0 sets the one listed as 0. mmc part shows partition table. fatinfo mmc 0:1 gives fat info of disk 0 partition 1. fatls mmc 0:1 shows the files and directories in there. For ext2 there is ext2ls mmc 0:1
minicom is more suited to be used than gtkterm to work with u-boot. However some tricks when copy, modify and past back long commands to u-boot. Setting W to wrap long lines that then can be copied and pasted into an editor, where the syntax of what came out using printenv must be modified from bootargs=console=ttymxc0,115200 <and more>
to sentenv bootargs 'console=ttymxc0,115200 <and more>
' and watch out to remove the CR minicom has eventually put in when it wrapped the line. Then the command can be cut and pasted back to u-boot. It is worth to verifying the change with printenv before saveenv takes it persistent. It can happen that the memory where those environmental variables are stored gets corrupt or never got initialized. Then u-boot refuses to use it and puts out a warning: *** Warning - bad CRC or MMC, using default environment
entering the u-boot menu verify printenv and saveenv can fix that.
Uboot script files can be made as:
mkimage -A arm -T script -O linux -d boot.txt boot.scr