Mastering GrUB – Part 3 – Grub Booting and Images

Booting GRUB from the network

The following instructions don’t work for *-emu, i386-qemu,i386-coreboot, i386-multiboot,mips_loongson, mips-arc and mips_qemu_mips

to generate a netbootable directory, run:  

    grub2-mknetdir –net-directory=/srv/tftp –subdir=/boot/grub -d /usr/lib/grub/<platform>

E.g.  for i386-pc:

    grub2-mknetdir –net-directory=/srv/tftp –subdir=/boot/grub -d /usr/lib/grub/i386-pc

Then follow instructions printed out by grub2-mknetdir on configuring your DHCP server.

After GRUB has started, files on the TFTP server will be accessible via the ‘(tftp)’ device.

The server IP address can be controlled by changing the ‘(tftp)’ device name to ‘(tftp,SERVER-IP)’.  Note that this should be changed both in the prefix and in any references to the device name in the configuration

GRUB provides several environment variables which may be used to inspect or change the behaviour of the PXE device.  In the following description <INTERFACE> is placeholder for the name of network interface
(platform dependent):

  •     ‘net_<INTERFACE>_ip’ The network interface’s IP address.  Read-only.
  •     ‘net_<INTERFACE>_mac’ The network interface’s MAC address.  Read-only.
  •     ‘net_<INTERFACE>_hostname’ The client host name provided by DHCP. Read-only.
  •     ‘net_<INTERFACE>_domain’ The client domain name provided by DHCP. Read-only.
  •     ‘net_<INTERFACE>_rootpath’ The path to the client’s root disk provided by DHCP. Read-only.
  •     ‘net_<INTERFACE>_extensionspath’ The path to additional DHCP vendor extensions provided by DHCP. Read-only.
  •     ‘net_<INTERFACE>_boot_      The boot file name provided by DHCP. Read-only.
  •     ‘net_<INTERFACE>_dhcp_server_name’ The name of the DHCP server responsible for these boot parameters. Read-only.
  •     ‘net_default_interface’ Initially set to name of network interface that was used to load grub.  Read-write, although setting it affects only interpretation of ‘net_default_ip’ and ‘net_default_mac’
  •    ‘net_default_ip’ The IP address of default interface.  Read-only.  This is alias for the ‘net_${net_default_interface}_ip’.
  •    ‘net_default_mac’ The default interface’s MAC address.  Read-only.  This is alias for the ‘net_${net_default_interface}_mac’.
  •    ‘net_default_server’ The default server used by network drives (*note Device syntax::). Read-write, although setting this is only useful before opening a network device.

 

2. Using GRUB via a serial line

This Section describes how to use the serial terminal support in GRUB.

If you have many computers or computers with no display/keyboard, it could be very useful to control the computers through serial communications.  To connect one computer with another via a serial line, you need to prepare a null-modem (cross) serial cable, and you may need to have multiport serial boards, if your computer doesn’t have extra serial ports.  In  addition, a terminal emulator is also required, such as minicom.  Refer to a manual of your operating system, for more information.  As for GRUB, the instruction to set up a serial terminal is quite simple.   Here is an example:

    grub> serial –unit=0 –speed=9600 grub> terminal_input serial; terminal_output serial

The command ‘serial’ initializes the serial unit 0 with the speed 9600bps.  The serial unit 0 is usually called ‘COM1’, so, if you want to use COM2, you must specify ‘–unit=1’ instead.  

The commands ‘terminal_input’ and ‘terminal_output’ ( choose which type of terminal you want to use.  In the case above, the terminal will be a serial terminal, but you can also pass ‘console’ to the command, as ‘terminal_input serial console’.  In this case, a terminal in which you press any key will be selected as a GRUB terminal. 

In the example above, note that you need to put both commands on the same command line, as you will lose the ability to type commands on the console after the first command.

However, note that GRUB assumes that your terminal emulator is compatible with VT100 by default.  This is true for most terminal emulators nowadays, but you should pass the option ‘–dumb’ to the command if your terminal emulator is not VT100-compatible or implements few VT100 escape sequences.  If you specify this option then GRUB provides you with an alternative menu interface, because the normal menu
requires several fancy features of your terminal.

3. Working with GRUB images

GRUB consists of several images: a variety of bootstrap images for starting GRUB in various ways, a kernel image, and a set of modules which are combined with the kernel image to form a core image.  Here is a short overview of them.

‘boot.img’          On PC BIOS systems, this image is the first part of GRUB to start. It is written to a master boot record (MBR) or to the boot sector of a partition.  Because a PC boot sector is 512 bytes, the size of this image is exactly 512 bytes.

The sole function of ‘boot.img’ is to read the first sector of the core image from a local disk and jump to it.  Because of the size restriction, ‘boot.img’ cannot understand any structure, so ‘grub2-install’ hardcodes the location of the first sector of the core image into ‘boot.img’ when installing GRUB.

‘diskboot.img’     This image is used as the first sector of the core image when booting from a hard disk.  It reads the rest of the core image into memory and starts the kernel.  Since  yet available, it encodes the location of the core image using a block list format.

‘cdboot.img’        This image is used as the first sector of the core image when booting from a CD-ROM drive.  It performs a similar function to ‘diskboot.img’.

‘pxeboot.img’       This image is used as the start of the core image when booting from the network using PXE.

‘lnxboot.img’        This image may be placed at the start of the core image in order to make GRUB look enough like a Linux kernel that it can be booted by LILO using an ‘image=’ section.

‘kernel.img’         This image contains GRUB’s basic run-time facilities: frameworks for device and  mode command-line parser, and so on.  It is rarely used directly, but is built into all core images.

‘core.img’           This is the core image of GRUB. It is built dynamically from the kernel image and an arbitrary list of modules by the ‘grub2-mkimage’ program.  Usually, it contains enough modules to access ‘/boot/grub’, and loads everything else (including menu handling, the ability to load target operating systems, and so on) from the  to be kept small, since the areas of disk where it must be installed are often as small as 32KB.
‘*.mod’               Everything else in GRUB resides in dynamically loadable modules. These are often loaded automatically, or built into the core image if they are essential, but may also be loaded manually using the ‘insmod’ command.

3.1 For GRUB Legacy users

GRUB 2 has a different design from GRUB Legacy, and so correspondences with the images it used cannot be exact.  Nevertheless, GRUB Legacy users often ask questions in the terms they are familiar with, and so here is a brief guide to how GRUB 2’s images relate to that.

‘stage1’            Stage 1 from GRUB Legacy was very similar to ‘boot.img’ in GRUB 2, and they serve the same function.

‘*_stage1_5’     In GRUB Legacy, Stage 1.5’s function was to include enough  ordinary  ‘core.img’ in GRUB 2.  However, ‘core.img’ is much more capable than Stage 1.5 was; since it offers a rescue shell, it is sometimes possible to recover manually in the event that it is unable to load any other modules, for example if partition numbers have changed. ‘core.img’ is built in a more flexible way, allowing GRUB 2 to support reading modules from advanced disk types such as LVM and RAID.
     GRUB Legacy could run with only Stage 1 and Stage 2 in some limited configurations, while GRUB 2 requires ‘core.img’ and cannot work without it.

‘stage2’             GRUB 2 has no single Stage 2 image.  Instead, it loads modules from ‘/boot/grub’ at run-time.

‘stage2_eltorito’   In GRUB 2, images for booting from CD-ROM drives are now constructed using ‘cdboot.img’ and ‘core.img’, making sure that the core image contains the ‘iso9660’ module.  It is usually best to use the ‘grub2-mkrescue’ program for this.

‘nbgrub’               There is as yet no equivalent for ‘nbgrub’ in GRUB 2; it was used by Etherboot and some other network boot loaders.

‘pxegrub’              In GRUB 2, images for PXE network booting are now constructed using ‘pxeboot.img’ and ‘core.img’, making sure that the core image contains the ‘pxe’ and ‘pxecmd’ modules.

 

3.2 Core image size limitation

  • 386-pc (normal and PXE): the core image size (compressed) is limited by 458240 bytes.  kernel.img (.text + .data + .bss, uncompressed) is limited by 392704 bytes.  module size
         (uncompressed) + kernel.img (.text + .data, uncompressed) is limited by the size of contiguous chunk at 1M address.
  • i386-pc (normal and PXE): the core image size (compressed) is limited by 458240 bytes.  kernel.img (.text + .data + .bss, uncompressed) is limited by 392704 bytes.  module size (uncompressed) + kernel.img (.text + .data, uncompressed) is limited by the size of contiguous chunk at 1M address.
  • sparc64-ieee1275: kernel.img (.text + .data + .bss) + modules + 256K (stack) + 2M (heap) is limited by space available at 0x4400. On most platforms it’s just 3 or 4M since ieee1275 maps only so much.
  • i386-ieee1275: kernel.img (.text + .data + .bss) + modules is limited by memory available at 0x10000, at most 596K

Lightly limited platforms:

  •  *-xen: limited only by adress space and RAM size.
  •  i386-qemu: kernel.img (.text + .data + .bss) is limited by 392704 bytes.  (core.img would be limited by ROM size but it’s unlimited on qemu
  •  All EFI platforms: limited by contiguous RAM size and possibly firmware bugs
  •  Coreboot and multiboot.  kernel.img (.text + .data + .bss) is limited by 392704 bytes.  module size is limited by the size of contiguous chunk at 1M address.
  •  mipsel-loongson (ELF), mips(el)-qemu_mips (ELF): if uncompressed: kernel.img (.text + .data) + modules is limited by the space from 80200000 forward if compressed: kernel.img (.text + .data, uncompressed) + modules (uncompressed) + (modules + kernel.img (.text + .data)) (compressed) + decompressor is limited by the space from 80200000 forward
  •  mipsel-loongson (Flash), mips(el)-qemu_mips (Flash): kernel.img (.text + .data) + modules is limited by the space from 80200000 forward core.img (final) is limited by flash size (512K on yeeloong and fulooong)
  •  mips-arc: if uncompressed: kernel.img (.text + .data) is limited by the space from 8bd00000 forward modules + dummy decompressor is limited by the space from 8bd00000 backward if compressed: kernel.img (.text + .data, uncompressed) is limited by the space from 8bd00000 forward modules (uncompressed) + (modules + kernel.img (.text + .data)) (compressed, aligned to 1M) + 1M (decompressor + scratch space) is limited by the space from 8bd00000 backward
  •  powerpc-ieee1275: kernel.img (.text + .data + .bss) + modules is limited by space available at 0x200000

 

Ramdev

Ramdev

I have started unixadminschool.com ( aka gurkulindia.com) in 2009 as my own personal reference blog, and later sometime i have realized that my leanings might be helpful for other unixadmins if I manage my knowledge-base in more user friendly format. And the result is today's' unixadminschool.com. You can connect me at - https://www.linkedin.com/in/unixadminschool/

1 Response

  1. October 6, 2015

    […] Mastering GrUB – Part 3 – Grub Booting and Images […]

What is in your mind, about this post ? Leave a Reply

Close
  Our next learning article is ready, subscribe it in your email

What is your Learning Goal for Next Six Months ? Talk to us