From Bubble

Contents 1 Kernel 2 Boot process 2.1 High level description 2.2 Boot media 2.3 Initrd 2.4 About ramdisk 2.5 Pivot Root 2.6 Boot Device identification

Kernel

The development is based on the latest 2.4.

See Linux kernel for more details.

Boot process

High level description

1. Load kernel (including initrd)
2. Get configuration file
3. Create ramdisk
4. Copy base system from initrd to ramdisk
5. Load packages into ramdisk as specified in the configuration file
6. switchroot and start the system from ramdisk

Boot media

Bubble supports the following boot media:

• Network boot
  • Directly via DHCP/BootP if the hardware supports it
  • Via PXEBoot (using PXELinux)
  • Via Etherboot
• CD-ROM (Using ISOLinux)
• SysLinux boot: boot from a FAT filesystem (Using SysLinux)
  It allows too boot from:
  • A floppy disk
  • A compact Flash (Via an IDE/CF bridge)

The boot media contains:

• Kernel image
• Initrd image (bundled with the kernel in case of a network boot)
• The Bubble configuration file
• The packages

Initrd

The kernel is booted through an initial ram disk.

There is no alternative since:

• We need to be able to load the right network module in case of network boot or exotic hardware
• The root fs is a ramdisk which is generated at run time

About ramdisk

It took me some time to realize that the ramdisk_size kernel parameter is just there to set an upper bound to the ramdisks.
It does not mean that this amount of memory is allocated when a ramdisk is created.

In DiskLess we are setting the ramdisk_size to the size of the initrd ramdisk. This is not wrong, but it actually limits the size of all ramdisks!

In Bubble, we want a small initrd, so we cannot do this anymore!
We just set the ramdisk_size to an arbitrary high value -- this does not matter too much.

Pivot Root

When the new ramdisk is ready, we need to swap the root devices. This is done by the `pivot_root` command.

I had to experiment a bit to get it right:

1. BusyBox will not start init if does not have pid 1.
   The workaround is to launch the linuxrc applet
2. As consequence of #1, linuxrc need to be enabled in BusyBox. This makes that at install time, BusyBox will overwrite the linuxrc of the initrd, which is not what we need.
   To circumvent this, we will simply copy our linuxrc scripts in the fixups...

For reference, the snipped of CVS:buildroot/sources/target_skeleton/linuxrc.sh which does the trick:

echo "---------- Pivot Root --------------------------------------------------"
/bin/umount /proc
cd $ROOT
/sbin/pivot_root . initrd

echo "---------- Stating init ------------------------------------------------"
ln -s sbin/init linuxrc
exec chroot . ./linuxrc <dev/console >dev/console 2>&1

echo "---------- Init could not be started!!! --------------------------------"

Boot Device identification

Another difficulty is to identify the boot device!
This information is just not available as such.
We need this information to load our configuration file and the packages that need to be installed

There are several possibilities:

1. Try all the possible combinations (based on /proc/devices and /proc/filesystems)
   This is not bullet proof, a wrong device can match...
2. Scan the PCI bus to find a network card
   Again here, we may get a wrong one!
3. Pass the information on the command line

The last one may require manual configuration, but it will work as-is most of the time:

• Network boot: We are doing a new DHCP request to get all the information from the DHCP server (no configuration required).
  IP can be passed on the command line, but unfortunately this does not help too much, since we are missing information about the BootP server. Therefore we have to re-query the DHCP server. The following information is given for reference, but is not used in Bubble.
  • Etherboot: use the `--ip=rom` option in mkelf-linux
  • PXELinux: set `IPAPPEND 1`in the configuration file
• Floppy/CD-Rom/CF: all are SysLinux -- we add the device in the configuration file (`APPEND` parameter).