Boot Manager and this document were written by André Fischer and are now maintained in the ETH SVN repository under the ETH license. The seven pertinent files there have names beginning with "BootManager".
The Bluebottle Boot Manager and how it relates to similar products - Feb. 13, 2008
Brief introduction to the theory of the boot mechanism
editStarting an operating system can be seen as a sequence of three processes:
▪ A machine-centered process: BIOS locates a bootable volume
When a computer is turned on, the computer's BIOS finds the primary bootable device, as defined by the user in the BIOS setup, and transfers control to the Master Boot Record (MBR), the first sector (512 bytes) of the first track on the boot volume. With the advent of Solid State Devices/Disks competing with conventional hard disks, the more general term "volume" is preferred to "hard disk", "device" or "HDD". DOM (Disk On Module) and flash drives too are mass storage devices linearly organized. With nothing being mechanically driven in a flash drive, the name is a misnomer. Indeed, a partition is sometimes called a "volume" but that seems inappropriate.
A volume is either partitioned or has a single partition. The latter case, where the volume may be called a "superfloppy", is ignored here. The term "block", generally used in Bluebottle (see LBA Logical Block Address), is equivalent to "sector" which relates to the physical shape of a hard disk. A block stores 512 bytes. A partition is either a primary or an extended partition. The latter is a container that can hold one or more logical drives. According to Microsoft, logical drives function like primary partitions except that they cannot be used to start an OS. For the AOS system the term "logical drive" is more appropriately replaced by "logical partition" since the container is transparent.
Remarks
AMI, Asus, Award, Gigabyte, Intel, Phoenix and other BIOSes behave differently and exist in many versions. Various levels of support for USB complicate further. Some PCs can boot from USB while others have USB but can not boot from it. When booting from a USB device fails, either the PC or the device is at fault. Hardware and software exist in an indefinite number of combinations and prediction of boot manager behaviour in a specific environment is difficult or impossible. The remaining text is scattered with examples of special situations encountered with various product brands. In spite of the difficulties, the boot manager has been used successfully with a number of Shuttle, Qbic and ASUS machines and Intel boards.
▪ A boot manager-centered process: the user selects a partition to boot into.
The conventional way to start an operating system is by loading and executing the code in the MBR and then the code in partition boot record (PBR) of the "active" partition, as noted in the partition table in the MBR. This notion only applies to a primary partition, not to a logical one, and is ignored by this boot manager. The alternative offered by this boot manager is to load and execute the MBR of another volume just as when BIOS transfers control to the boot volume's MBR.
The MBR contains the Boot Manager Stage 1. Given the small size of the MBR, Stage 1 does little more than to load and transfer control to Stage 2 located in the first volume track, immediately following the MBR (see section 1 below). Stage 1 also verifies, by means of a unique signature, that the loaded Stage 2 is valid.
After Stage 2 receives control, it presents a textual menu of available OSes to boot. Selecting the target OS causes to boot. It is also prepared to automatically start the operating system selected last prior to the restart in progress (see User friendliness).
At system start, only the BIOS drivers are available to access volumes and luckily modern BIOS include P-ATA, S-ATA, ATAPI and USB drivers, enough to start OSes from a variety of volumes. Firewire BIOS support is currently rare and was not explored. The Boot Manager supports Logical Block Address (32-bit LBA) mode when the BIOS supports the extended INT 13h. The CHS mode of the simple INT 13h imposes that a PBR (first block of any partition) resides below the 8.4GB boundary. The 32-bit LBA mode makes it possible to address 2TB of storage. The 48-bit LBA mode is not supported. A BIOS setting controls the addressing mode.
▪ An OS-centered process: the PBR transfers control to the OS-specific bootloader which locates and loads the kernel. The OS starts.
For example, the Bluebottle bootloader OBL.Bin, located at the beginning of a partition, locates and loads a kernel matching the characteristics of the boot volume, that is:
▪ AosIDE.Bin on a P-ATA/S-ATA mass storage device
▪ AosIDE.Bin on an ATAPI CD-ROM, for producing a live CD - https://en.wikipedia.org/wiki/Live_CD
▪ AosUSB.Bin on a USB mass storage device, for producing a live USB - https://en.wikipedia.org/wiki/LiveUSB
Trace is the very first kernel module executed after the bootloader relinquishes control. Until the end of 2007 the first kernel module executed was Machine.
Summary of features
editNon-invasive multiple multi-boot manager designed to control up to 12 primary or logical partitions on each of up to 8 volumes attached, that is, recognized by BIOS on machine start-up.
Can co-exist with other boot managers present on other volumes of a machine. Detects the presence of GAG, GRUB, LILO and Windows in an MBR of a volume.
Installed using Bluebottle, also from a live CD as is used for installing Bluebottle, on various volumes:
▪ a bootable CD-ROM can be burned from the BootManager.iso file included
▪ a bootable floppy diskette can be created from the BootManager.Bin file included
▪ or directly installed with WMInstaller on the MBR of a volume
Preserves the integrity of the MBR's partition table and the integrity of the disk signature used by Windows Vista in the MBR.
Does not require a dedicated partition.
Can be installed on and run from any volume, internal or external, fixed or removable, including USB-FDD and CD-ROM.
Capable of starting an OS installed in a partition below a boundary of 2TB (32-bit LBA mode).
Combines ease of use in daily routine work and very technical inspection of machine equipment and volume control in connexion with ubiquitous external USB and other storage devices.
Written in assembly language (Nasm syntax) with open source code included in a Bluebottle release.
This documentation details how it relates to, and how it can co-exist with, a few other competing boot managers.
Detail of features
editThe Bluebottle boot manager is designed around a legacy MBR, as is found on a majority of machines, offering space for four 16-byte partition table entries in the partition table. One entry may be used by an extended partition to which logical partitions may be chained in any number. A boot manager such as the Ranish Partition Manager with another partition table organization for breaking the limit of 4 was not considered. Also the proposed Intel EFI standard was not considered.
1. Physical location on a given volume
It comprises an MBR at LBA=0 and a small number of blocks located in the remaining space of "track 0". The blocks in that range are usually left unused and filled with 0s, unless a third party boot manager is installed. That is, for instance, the case for GRUB and Boot-US. "Track" is related to the physical organization of a volume as it used to exist earlier. Today the number of sectors per track is a logical value.
The first partition is normally created and formatted during the installation of an operating system which fixes the first LBA used. In most cases, a factory new volume is formatted and an OS is preinstalled. The first LBA number used varies with the volume geometry, more precisely the number of sectors per track. The following values can be observed as first used LBA number:
▪ LBA = 2048 on large capacity volume, with Windows Vista installed for example
▪ LBA = 63 is standard for USB and HD volumes < 100 GB
▪ LBA = 32 on a CD-ROM FDD emulation (see next section) and on a factory new ZIP 100 volume
▪ LBA = 16 on a factory new 32MB Disk On Module (DOM)
At present, 13 blocks are occupied by code and data, two blocks are dedicated work areas.
2. Volumes on which it can be installed
It can be installed on and run from any volume, internal or external, fixed or removable, of a PC. This has been tested with a wide range of media: 3.5" floppy diskette (USB-FDD only), 2.5" and 3.5" HDD (P-ATA, S-ATA), CD-ROM emulating a FDD (burned with Bluebottle,Nero, Magic ISO), USB flash memory (SD, CF), Solid State Disk (e.g. DOM) and USB-ZIP (tested with Iomega ZIP 100MB only). It can be installed on its own, without the need of partitioning a volume or installing an operating system, as can be understood from the listed floppy diskette with an extremely small 1.44MB capacity. When installed on its own on a CD-ROM or USB-FDD it can be used without disturbing the MBR, or boot manager, of the usual boot volume. Installing it on the usual boot volume can be decided at a later time. It is very generic and since it can be installed on multiple volumes of the same machine it qualifies as multi multiboot manager.
Each of volume on which it is installed, provided it is accessible/bootable by the BIOS (see the remarks in the Introduction), can take control of the machine for the purpose of starting a particular operating system. Evidently, the device priority sequence in BIOS setup will have defined which volume to boot first and the order in which they will be accessed.
Volume hosting a Bluebottle partition
Bluebottle has a very small footprint which means that one will either find several Bluebottle partitions, possibly co-existing with other OSes, on a sizeable volume or a single partition on a small size volume - from a minimum of 62MB and up. In the latter case, a USB-HDD flash memory (USB stick) is the ideal storage medium to host the entire OS with its applications. No need to drag an unwieldy personal computer to the office or on business trip. Just plug the stick to a personal computer and start Bluebottle. Given the fast data transfer, high capacity and other technological gains, USB flash drives (UFD) enjoy an increasing popularity. As long as the BIOS and the USB device itself support booting from USB, one can take over the machine without ever accessing (writing!) the machine's internal storage and without committing to a permanent installation on an internal hard drive. If booting from USB is not possible (e.g. an old BIOS could prohibit it), boot from a CD-ROM or a USB-FDD to bootstrap the USB device (see section 5).
A special situation is worth mentioning here: on a volume of very small size, say 64 or 128MB, it is not only unreasonable to envisage more than one partition, also a single working Bluebottle would only just fit leaving no space for user data. In that case, it is preferable to format a single partition without kernel and programs. Such a partition is then exclusively useable as data storage and is never bootable. It will however show up in the partition list.
BIOS volume detection and enumeration
While under control of the Boot Manager, USB devices are conditioned by the BIOS which detects and enumerates them. See "Compaq, Intel, Phoenix BIOS Boot Specification 1.1". In this respect, BIOS demonstrate an unfriendly behavior, since the volume enumeration depends on the characteristics of the different volumes: some are recognized others not..
The volumes are listed left to right and two groups are discernible:
▪ HDDs identified as 80h, 81h, 82h, ... - traditional "fixed" disks and now
including removable media devices that support change-line
▪ FDD identified as 00h - traditional "removable" disk (CD-ROM, USB-FDD, USB-ZIP).
Only one is taken into account: it will be the CD-ROM when it is the boot device or it will be the USB-FDD if it is recognized as such by the BIOS
The boot volume appears always first and its type (HDD or FDD) determines which of the two groups is listed first. A maximum of 8 volumes can be controlled simultaneously. This is an important design consideration in a time where a large number of external USB storage devices, inexpensive and ubiquitous, can be attached to a PC (see section 3).
Booting from CD-ROM (FDD emulated)
The CD-ROM must conform to the El Torito bootable CD format using a file on the CD to emulate a floppy diskette. BIOS identifies the boot volume as 00h, which comes first and alone in its group, followed by ATA HDDs and USB-HDDs. The included BootManager.iso file is the best vehicle for distributing the Bluebottle boot manager.
Booting from USB-FDD
A floppy diskette can only be used when loaded into a USB-FDD. Considering that PCs are nowadays rarely equipped with a legacy FDD, these devices are no longer supported and simply ignored. If an FDD is present it is not even necessary to disable it in the BIOS setup.
Booting from internal P-ATA HDD
BIOS identifies the boot volume as 80h, then come the remaining ATA HDDs, followed by USB-HDDs.
Booting from external USB-HDD or USB-ZIP
BIOS identifies the boot volume as 80h, then come the ATA HDDs and the remaining USB-HDDs come last.
On one machine, the volumes were marked "n.a." for "non-accessible" (no explanation for this odd situation, where BIOS returns a correct volume count but cannot access them).
When a high speed USB 2.0 device is attached to an USB 2.0 hub, this device is supported in USB 1.1 speed - 12MB/s. Only later, when the operating system installs the driver, the high-speed data transfer will be established. The speed difference can be observed on a Disk2go device which signals a 12MB/s speed with a green LED, lit in red at high speed.
BIOS boot volume order controlled by BIOS setup
Depending on the BIOS, the setup is invoked by pressing DEL, PF2 or PF1. The boot volume order can be changed. While modifying the setup, remember to disable the FDDs and if "Plug and play OS" is offered for choice, use "No". Alternatively, the BIOS setup can be left as is and the boot volume can be selected after invoking the BIOS boot menu (usually by pressing ESC or PF8 at system start, depending on the BIOS).
Refer to the User Guide (section BIOS setup) belonging to the machine.
Support for large volume size
The LBA addressing scheme is used with 32 bits reserved in each partition table entry. Given a block size of 512 bytes, a volume of up to 2'048 GB can be addressed. The boot manager can also operate using the CHS addressing scheme by mapping LBAs to their CHS equivalent. Testing for the presence of the extended INT 13h support indicates whether mapping is required or not. The volume size is limited to 8GB when the CHS addressing scheme is used (with a 24-bit address), a rare situation in today's environment.
3. Independent from the host operating system
Provided a PC and the attached USB flash memory can boot from USB, a user plugging a flash memory with an installed Bluebottle will find the best and safest situation for using the hardware without ever using or altering the machine resident operating system or a possible third-party boot manager. The utmost safety is given when the USB volume is configured, necessarily with a AosUSB.Bin kernel, but without access to the IDE volumes. If needed, the IDE driver module can be activated by executing ATADisks.Install ~. After that, any IDE partition can be mounted and accessed at the user's own risk.
All that is possible with a very primitive MBR but the Bluebottle boot manager offers the added value of being able to take full control of the machine volumes and partitions and thus to perform, to some extent, as the host.
When that is not possible, it allows to transfer control to the host MBR manager without otherwise interfering and without a need to reboot. The Bluebottle boot manager is cooperative and non-invasive (see section 5).
Those who might hesitate to install the Bluebottle boot manager, may opt to include Bluebottle in the boot menu of some third party OS such as Windows Vista.
4. User guidance
Here is a example menu which can be accessed when BootManager starts.
====================================================== Bluebottle BootManager 28/01/2008 GenuineIntel Intel(R) Pentium(R) 4 CPU 3.0GHz 64-bit processor Family 0Fh Model 04h Cores: 1 Logicals: 2 HT: Y BIOS/MBR 80 detected volumes: >80 117M >81 19G >82 9G USB IDE IDE ^^^^^^ Volume 80 (Mode LBA 5) - MBR: Bluebottle - Vol. signature @ 1B8h: 66 0D 67 0D Partitions: (those marked in red cannot be accessed) 1 OBERON 4C Enter one of the following: the number of a partition hosting an OS to start Set ScrollLock to halt Bluebottle start-up. Selection will replace current default vol. xx , part. yy n(ext) or p(revious) volume ^^^^^^ v to toggle graphic VBE info i to toggle PCI vendor/device info l to toggle 25/50 lines s to switch to MBR on selected volume ======================================================
Whenever it is started, the boot manager reports the CPU characteristics:
▪ CPU type: Intel, AMD, Via (formally IDT/Centaur) or other
Note: it was tested will a small sample of CPUs only.
▪ speed
▪ width (32 or 64-bit)
▪ hyperthreading or not
▪ number or cores, logical processors, threads
The next line (highlighted in red) tells from which volume the MBR/Boot Manager was extracted. It is this code which produces the report presented to the user. Most of the time, it is the MBR of the boot volume unless the user requested to switch to the MBR of another volume (see below, response 's').
On a follow up line, all the volumes detected by the BIOS are listed from left to right, starting with the boot volume (section 2). In addition, the partition table, if any, of that volume is inspected and a list of all the residing partitions is displayed. From there, a suitable partition can be selected to start an operating system, provided it is correctly installed. Else, another volume, if any, can be selected and the same process of partition table inspection is repeated for it. The volumes are selected by entering "n" for "next" or "p" for "previous". The volume currently selected is underscored by a string of 6 "^" characters on the next line.
For each volume accessed, the type of Master Boot Record (MBR) is displayed. The presence of a Bluebottle, GRUB, LILO or Windows (indicated by "Foreign") boot manager is detected. It is thus not necessary to install the Bluebottle boot manager on all volumes. Other existing MBRs and boot managers can still be invoked and are fully operational. This is done by responding with "s" to the prompt text, and that applies to the bootmanager itself.
On request it also displays
▪ a list of VBE VESA modes supported by the graphic controller (enter "v" in response to the prompt). Bluebottle requires the availability of a VESA mode using a linear frame buffer. A list of suitable modes is produced where the modes appear as 3-digit green values. Such a value is an important parameter of the configuration data element "Init=". When Bluebottle is installed, "Init=117" is established as default value, corresponding to a resolution of 1024 x 768 x 16, available on most graphic controllers. The user may want to select a VESA mode with a better resolution in the list for use when Bluebottle is started.
▪ a list of the installed PCI devices (enter "i" in response to the prompt)
The text is displayed on 50 80-character lines compared to the default 25-line layout. Entering 'l' toggles the number of lines. The boot manager enforces a 50-line mode against the default 25-line mode. Experience shows that toggling is not really needed, except in the eventuality that the 50-line mode is not supported by the graphic controller (a situation not encountered yet).
Any invalid input is acknowledged with: "invalid input, retry"'
In summary, it guides a user
▪ daily to start the preferred operating system
▪ daily to select and start an operating system among several, may be different ones, installed
▪ at times to recover an operating system rendered inaccessible by a volume master boot record damage
▪ occasionally to inspect the machine equipment and decide if it is apt to run Bluebottle, in particular when contemplating a purchase. Remember to verify that the machine allows booting from USB, a very useful and recommendable capability indeed. See also section 5.
5. OS it can start
It can start an operating system located
▪ on the volume where it is located and
▪ on another volume.
The TUI allows to choose a volume and to choose which OS to start, irrespective of a boot sequence as is usually defined in other similar systems. The OS is started by accessing the PBR in the same fashion as the BIOS, in cooperation with the MBR, would otherwise do.
A maximum of 12 partitions can be listed per volume selected. Keep in mind that an extended partition cannot be accessed but will appear in red in the list.
Let us assume that a USB-HDD with an installed bootable AOS is plugged into a machine which cannot boot from USB, then it might still possible to boot from a CD-ROM and then to start the AOS on USB. No alteration of the machine is required except the boot sequence.
Compatible with all Windows versions. Compatible with x64 (AMD62/EM64T) and Windows 64-bit (non-GPT).
Last but not least, the boot manager on any volume can be used to start an OS residing on another volume with a different boot manager, e.g. GRUB, or a volume with corrupted MBR but with intact partition table.
6. No special partition required
It does neither occupy a partition nor is it placed within a partition (see section 1)
7. User friendliness
The Boot Manager will report all it can on the volumes and their partitions which exist on a machine. It does not rely for that on configuration data supplied by the user and must not be configured. However true the report, it will not be all the truth, as in the case of a partition defined but without installed and bootable OS. The Boot Manager cannot cope with such user's responsibilty situations and will abort without fallback or warning.
It gracefully memorizes, in one of its blocks (LBA number 12), the volume and partition finally selected to start the desired OS, except if it is run from a CD-ROM, for an obvious reason, or from a FD, because the FD is considered to be useful only to start an OS and not really bound to any machine.
The next time the machine is started, the same OS is automatically started without user intervention.
However, if, the user wishes to start a different OS, setting ScrollLock, immediately before the MBR takes over control, halts the Boot Manager execution and a prompt text is presented for selecting other options.
When freshly installed, the default volume and partition are undefined and its execution will necessarily halt for interaction with the user.
It will (should!) not damage a foreign boot manager (GRUB, Boot-US) installed on the first track of a volume.
8. No "active" partition concept
It allows starting an OS, by a chainloading mechanism, without relying on the detection of an "active" partition (not even a Windows partition).
Material included in the release delivery
edit 1. BootManager.Text - this documentation
2. BootManager.Asm - source code in Nasm syntax
3. BootManager.Bin - the assembled BootManager = Stage 1 + Stage2
4. BootManager.iso - ISO file for burning a CD-ROM
5. BootManagerNull.Bin- 512-byte help file for producing BootManager.iso
Stock files BootManager.Bin, BootManagerMBR.Bin and BootManagerTail.Bin are available from the repository, https://svn-dept.inf.ethz.ch/svn/lecturers/a2/trunk/source/. Submit username infsvn.anonymous and password anonymous. Instructions to create these files follow.
How to create, install and start the boot manager
edit1. Write the assembler code using the Network Assembler syntax
Written in Nasm code, to operate in real-mode. Receives control from the BIOS with the following interface:
▪ the MBR is loaded at address 7c00h
▪ the register dl contains the boot volume identifier. It will be either 0 when booting from a CD-ROM or USB-FDD or 80h for a partitioned volume.
When the boot manager is in control, the user is offered the choice to transfer control:
▪ either to a PBR of a bootable partition to start an OS, assuming it was correctly installed,
▪ or to an MBR in another volume (it can even transfer control to itself).
2. Assemble the code
2.1 In Oberon, transform the Oberon text to pure ASCII, in preparation of a Windows/DOS processing, with: Miscellaneous.MakeDOSText name.Asm => name.ASC ~
2.2a In DOS: assemble the source text *.ASC with the Network Assembler
2.2b In Windows: use ansmw.exe in the DOS box. Command parameter details with: nasmw -h
2.3 In Oberon, read the .BIN file with Backup.ReadFiles name.BIN ~
At this point at this point you have BootManager.Bin containing 6656 bytes[1]. That is 13 blocks of 512 bytes each. A BootManager.Bin is available from the repository, https://svn-dept.inf.ethz.ch/svn/lecturers/a2/trunk/source/.
3. Produce the installation data
3.1 For a partitioned volume, BootManager.Bin obtained in step 2 is processed by WMInstaller and split into:
▪ one block placed in the MBR and
▪ 12 blocks placed in the blocks with LBA 1 to 12.
These two sections are also available, ready to use, from the repository as files BootManagerMBR.Bin and BootManagerTail.Bin.
3.2 For a FD, BootManager.Bin obtained in step 2 can be used as is without further ado (go to 4.3).
3.3 ISO image file for burning a bootable CD-ROM
The same process as is found in I386.Aos.Tool for creating a new release is used. In Oberon, execute these commands
Configuration.DoCommands OFSTools.Mount SYS RamFS 200000 4096 ~ System.DeleteFiles AOS:BootManager.iso ~ FileDisks.Open SYS:AosCD.Dsk 600 ~ Partitions.Format SYS:AosCD.Dsk#0 AosFS 0 BootManagerNull.Bin ~ (boot file reserve size must be multiple of 4) Partitions.FileToPartition SYS:AosCD.Dsk#0 BootManager.Bin 0 13 FileDisks.Close SYS:AosCD.Dsk ~ Aos.Call \w IsoImages.Make AOS:BootManager.iso SYS:AosCD.Dsk ~ OFSTools.Unmount SYS ~
Note: BootManagerNull.Bin, a 512-byte file filled with 00h, takes the place of AosIDE.Bin or some other kernel.
The image file BootManager.iso included in the release is then used to burn a bootable CD-ROM (see section 4.4).
4. Install the boot manager
4.1 Planning the installation
If a volume already hosts a number of operating systems, one should plan first
▪ to gather information on the current volume organization: volume size, number of partitions, operating system types, presence of boot manager.
All this is easily done with the Bluebottle Partitions tool: follow Main menu > Files > Partitions or with the Oberon Partitions.Tool: execute Partitions.Show detail ~
▪ to backup the current volume MBR and when necessary the remaining blocks in track 0 used by some boot manager.
This can be done with the Bluebottle Partitions tool as above, then selecting "ToFile" or with the Oberon Partitions.Tool: execute Partitions.PartitionToFile dev#0 MBRBackup.Bin 0 1 ~ More than 1 block may have to be saved. This file can be inspected by executing: Hex.Open MBRBackup.Bin ~
In case of trouble, the MBRBackup.Bin file can be restored by executing:
Partitions.WriteMBR dev#0 MBRBackup.Bin ~
4.2 On a partitioned volume execute, in AOS:
WMInstaller.Open ~
and follow the instructions.
Alternatively, use these commands in Oberon or in AOS.
Partitions.WriteMBR dev#0 BootManagerMBR.Bin ~ Partitions.FileToPartition dev#0 BootManagerTail.Bin 1 12 ~
4.3 On a bootable CD-ROM
On the Main menu follow > Files > CDRecorder > Tools > Burn Iso Image
Then browse to locate BootManager.iso and burn a CD-ROM. The CD_ROM so created is not guaranteed to be readable on any machine though. The use of a third-party software such as Nero should be preferred. MagicISO is yet another such software.
4.4 On a floppy diskette
Enabling an FDD might be needed only temporarily to install the boot manager on a floppy diskette for use on a USB-FDD.
Insert a DOS formatted FD in the FDD and execute, in AOS: Diskettes.Install ~
Navigate > Files > Partitions > Select a partition > Partitions > From File >
Filename: BootManager.Bin / Offset: 0 / NumBlocks: 13
or in Oberon:
Diskettes.Install ~ Partitions.FileToPartition Diskette0#0 BootManager.Bin 0 13 ~
(13 = 1 MBR + 12 blocks)
5. Start the boot manager
Start the PC and direct it (via BIOS setup or boot menu) to boot from the volume where it resides.
To open the BootManager menu, use the ScrollLock key or hold down Ctrl, Alt or Shift as described in the table and footnotes (2a) and (5) under A2 Start-up Sequencing.
6. What happens to a Bluebottle boot manager when a new operating system is installed?
If another operating system is installed or re-installed which overwrites/replaces the MBR for its own purpose, the Bluebottle MBR can easily be restored. For example, a Windows install effectively replaces the MBR. Consequently, before re-installing a Bluebottle MBR user handling is required to guarantee the integrity of Windows, or else the Windows install will have failed. If an OS such as Ubuntu suggests to install GRUB, two situations can emerge: GRUB is installed in the MBR an it eventually overwrites a Bluebottle boot manager or it is installed in a partition (possibly a dedicated one) where it does not interfere.
7. How to restore the original MBR of an operating system
In Oberon, execute Partitions.WriteMBR dev#0 MBRBackup.Bin ~
8. How to access other volumes when Bluebottle is started
Usually, Bluebottle is configured to include the disk driver for the volume it resides on, that is, the kernel used is either AosIDE.Bin or AosUSB.Bin . Thus make sure to install another driver when needed. The commands are
▪ ATADisks.Install
▪ UsbHubDriver.Install followed by UsbUhci.Install
Competing boot managers
editA great variety of boot managers are proposed for controlling a multiboot system. Here is a non-exhaustive enumeration: built-in boot manager of Windows (of all kinds), GRUB, GAG, LILO, BootIt, Boot-US. To choose a good one is not easy but in most cases one, or even two, is part of an OS distribution. A good bet is to delegate the choice and installation of the boot manager to the OS installer procedure. At the time of an installation it might not be much of a concern but the implications should be well understood.
Boot managers are competing for the space in the first track or, at the minimum, for the MBR. The hard fact is that one boot manager can wipe another out. Some installers take care of mending a damage by integrating existing OSes in the boot menu. That is the case for most Linux distributions offering to install GRUB or LILO (detecting the presence of Windows and other Linux partitions) but is not the case for Windows which ignores all OSes except itself. Windows wipes the MBR out without telling. Unfortunately and understandably, neither GRUB, nor LILO, nor Windows detect the presence of AOS partition(s).
At the time of an OS installation, one may decide to not install a proposed boot manager but that supposes that one knows how to trim the boot menu of an existing boot manager. For those who do not wish to adopt the Bluebottle boot manager, instructions are given how to bind AOS in their preferred boot manager. See "How to start AOS with a different boot manager". By and large, these instructions also apply to other OSes.
Boot managers are installed in many ways summarized here:
▪ in the MBR (LBA=0) and the following blocks within the limit of the first track. GRUB is an example thereof and the Bluebottle boot manager is another one. LILO occupies the MBR and no more.
▪ in a dedicated primary partition, occupying one entry of the 4 possible ones in the partition table of the MBR. GRUB is an example thereof.
▪ in the partition hosting an OS. Windows Vista and other Windows kinds install their boot manager in that manner. Also GRUB can be installed in a Linux partition, an even on a swap partition. LILO is installed in a Linux partition.
In the end, the boot manager which will prevail, most importantly concerning the MBR, will be determined by the order in which OSes are installed on a volume.
Recommendations
Whether the order of installation is decided by the user or dictated by the circumstances, a reasonable strategy for sequencing the installation of OSes is desirable. Windows is often the stumbling stone.
The complexity of the operations involved in the installation of multiple OSes is such that only minimal information is provided here.
The NeoSmart site documents all the steps needed to reach the goal successfully, installing Vista first or after Linux:
▪ Adding Linux to the the Vista Bootloader - https://neosmart.net/wiki/display/EBCD/linux
▪ Dual-booting Ubuntu Linux and Windows Vista - https://neosmart.net/wiki/display/EBCD/Ubuntu
▪ Dual-booting Fedora Linux and Windows Vista - https://neosmart.net/wiki/display/EBCD/Fedora
In conclusion, whenever possible install Windows Vista first and other OSes after that.
The Bluebottle boot manager's multi-boot capability is based on the chainloading mechanism: the boot manager hands off the boot process to another (boot manager or bootloader). It asks the Vista boot manager, GRUB, LILO, GAG or whatever to complete the boot process, minimizing configuration requirements and ensuring maximum compatibility with various OSes.
Under these conditions, can start:
▪ AOS anywhere
▪ Windows Vista installed in a primary partition
▪ Linux with GRUB, LILO, GAG or whatever installed in the Linux partition
During a Linux installation, follow the procedure described in the NeoSmart document:
when prompted to set up the bootloader, make sure to specify to install GRUB, LILO, GAG or whatever, in the partition that Linux is being installed to and not to the MBR of the volume. The bootloader is stored in what Linux calls "Superblock" at the beginning of the partition.
If that is not the case, i.e. the boot loader was placed in the MBR, the Linux partition cannot be started. That partition will show up in the Bluebottle boot menu in red with the mention "no PBR".
To mend the situation proceed as follows:
1. - boot from a live CD, such as that of Ubuntu or Knoppix
2. - open a terminal
3. - enter: sudo grub
4. - to the prompt reply with:
root (hdX, Y) setup (hdX,Y) quit
X is the drive number where the Linux partition resides - drives are recognized by BIOS at boot time and numbered starting from 0
Y is the partition number
setup uses an "install" command in the background to install GRUB into the specified root device.
The Bluebottle boot manager can chainload the partition's PBR. At that instant control is transferred to the resident boot manager which will start an OS either directly or indirectly via a prepared boot menu. One always arrange to avoid the presentation of an intermediate boot menu.
Rationale for developing the Bluebottle boot manager
editOne may question the need for developping yet another boot manager given the wide choice of similar ones being proposed. So what makes the Bluebottle Boot Manager different? this is reviewed in the next section.
The boot menu is entirely constructed by extracting the relevant information from the MBR and PBRs of all the volumes detected by the BIOS at boot time.
Now that external volumes are easily plugged to a machine (USB interface for example), one can easily see how unflexible a boot menu as conceived by other boot managers can be.
Other boot managers are controlled by a boot menu, residing somewhere in a file system, constructed by an installation program and later on edited by the user under control of the hosting OS. GRUB for example creates menu.lst and so does LILO.
The major disadvantage of such a boot menu really shows up when partitions are added or removed with a reordering thus forcing to edit the menu(s).
Hence there is nothing to edit, customize or personalize a multiboot system neither in advance nor at boot time and also no notion of superuser (sudo) needed.
A similar editing task arises when a partition is moved: another boot manager cannot find the PBR anymore and must be re-installed. Likewise, editing is required when partitions are renumbered after a partition creation or deletion. The impact of such modification is considerably less time-consuming for a Bluebottle boot manager. A Bluebottle partition may require to modify the BootVol1= value in the configuration data for example.
There are no options to specify in cryptic commands to enter at the time the boot menu appears on the screen. A few sample commands appear in a section entitled GRUB below, but there are plenty more such commands. On the contrary to that the TUI is a simple prompting text in English awaiting a single character reply from the keyboard. Keyboard in any language is suitable, no mouse required.
The sleek, short-lived TUI cannot be decorated with splash graphics.
It operates strictly and only with the BIOS drivers and volume identifiers: 00h, 80h, 81h, ...
A user does not not have to fight with the idiosyncrasies of various OS in relation with the mapping of the devices: [hd0, hd1, hd2, ...] or [sda, sdb, sdc, ...] or other depending on the boot manager.
The loss of a partition hosting the boot menu of a competing boot manager is catastrophic. With the help of a Bluebottle boot manager residing on another volume, most of the other OSes on the same volume can still be booted as long as the partition table is not damaged.
Similarly, the intrusion of a root kit virus in the MBR of a boot volume will be signalled. Here also most of the OSes can still be started until the volume is repaired, possibly with AOS.
None of other boot managers tested offers the possibility to transfer control to another boot manager on a different volume and make it behave as if it was the boot volume. In a way, the BIOS boot menu becomes superfluous. Other boot managers only allow to start an OS on a different volume.
Recovering a damaged MBR can be the source of frustration and headache: what is a repair system or recovery diskette? (at a time when diskettes have practically disappeared) which documentation found on the web is relevant for the OS release which installed the MBR at a much earlier time?
Windows Vista boot manager
While under Windows XP it sufficient to edit boot.ini to start another OS, Vista requires much more from a user to persuade its boot manager to cooperate with other OSes. The relatively easily configurable boot.ini file was replaced by a binary file which must be edited using a console application named bcdedit.exe. This might reveal itself as a tedious task preferably performed with an add-on application such EasyBCD. When Bluebottle resides on another volume that is questionable.
The Vista boot manager resides in the Vista partition and has the following quirks (see: http://linux.wordpress.com/2007/02/17/vista-and-solaris-express-dual-boot [dead link]):
1.- The Vista installer requires that no partition be active (or bootable) on a volume. If an active partition is found, the installer says something like "This volume is not suitable for installing Windows" and refuses to proceed.
2.- Vista requires that the Windows partition be active in order to boot.
3.- Vista requires that the disk signature (4 bytes at offset 1b8h used by the installer) be present in the MBR in order to boot else it will refuse to boot saying that winload.exe is corrupt. This is because Vista's boot loader checks for it.
The Bluebootle boot manager and GRUB make sure that the 4-byte disk signature is left untouched when the MBR is written.
More info is available from: http://www.windowsbbs.com/showthread.php?t=55415 [dead link]. Microsoft talks about it in a whitepaper giving some weird reasons: http://www.google.co.in/search?q=OEMBoot_Vista [dead link].
GRUB - Grand Unified Bootloader - Legacy - Version 0.97 - https://www.gnu.org/software/grub
GRUB can boot Windows, MS-DOS, FreeBSD, NetBSD, OpenBSD, GNU Mach and is included in several Linux distributions. It comes in two flavours: with a simple textual user interface or with a graphical interface.
Notes collected from test with Ubuntu 7.10 on a volume
During the installation of GRUB, the user is offered the choice to install GRUB in the MBR of the boot volume or in an Ubuntu Linux partition or in a dedicated small partition.
When installed in the MBR, GRUB competes with the Bluebottle boot manager for the space in the first volume track. When it is installed (as a side effect of installing Ubuntu) it is stored in blocks LBA=0 to 17, thus completely overwriting an existing boot manager. LBA=18 to 63 contain all zeroes. Two areas in the original MBR are preserved, the partition table and a disk signature used by Windows Vista.
GRUB stores the location of the menu file but the file proper is located in the Ubuntu partition. To boot another OS (such as Bluebottle in the above example) GRUB needs to access the Ubuntu partition first to find the chainloader command. If GRUB is damaged and fails to access it, the Bluebottle can not be started anymore. With the Bluebottle Boot Manager it can still be booted without the help of GRUB. Intrestingly, the PBR of the Ubuntu partition has no valid signature and cannot be started. The same holds true for the ancillary swap partition. Indeed, a straigthforward Ubuntu installation places GRUB in the MBR, while leaving free blocks at the beginning of the Linux and swap partition. The user has also the possibility to install GRUB in the Linux or swap partition, during the installation or at a later time. The PBR will then receive a valid signature 55aah and is recognized by the Bluebottle Boot Manager as bootable.
LILO - Linux Loader - lilo.go.dyndns.org
LILO able to boot multiple OSes, including Linux, Windows, MS-DOS, etc., is used in some Linux distributions.
Notes collected from test with Mandriva Linux Spring 2007.1 - Mandriva Linux and DSL 2.4.4
During the installation of Mandriva, the user is offered the choice to install:
▪ GRUB graphical menu (see GRUB above)
▪ GRUB text menu (see GRUB above)
▪ LILO text menu
When installed in the MBR, LILO competes with the Bluebottle boot manager for the space in the MBR and no more. The user is also offered the choice to install it in a Linux partition.
GAG - El Gestor de Arranque Grafico - https://gag.sourceforge.net/
GAG boots up to 9 OSes from either a primary or logical partition. It competes with the Bluebottle boot manager for the space in the first volume track. It is not installed in a partition. When uninstalling GRUB, ONLY the MBR is restored, the rest of the track is left untouched, that is with GRUB code. GAG cannot access USB devices (???).
OSL2000 - https://www.osloader.com
OSL2000 competes with the Bluebottle boot manager for the space in the first volume track. OSL2000 comes as a Windows install/uninstall program. During the installation no other choice is given than installing it on the boot volume in blocks LBA=0 to 57, saving whatever overwritten data on a backup diskette for re-use on the occasion of an eventual uninstall, thus restoring the previous situation.
Boot-US - https://www.boot-us.de/
Boot-US, which comes as a Win32 program, can be installed in the MBR (only on the boot volume), in a dedicated small primary partition or on a legacy floppy diskette. When installed in the MBR, it competes with the Bluebottle boot manager for the space in the first volume track. Boot-US replaces the existing MBR by its own and places a copy of it in block with LBA=1. In this manner Boot-US can be removed when necessary. It then behaves just like the Bluebottle boot manager with which it cannot coexist. As from version 2.0.0 it can boot Windows NT/2000/XP/2003 but not Vista.
BootIt NG - Next Generation - https://www.terabyteunlimited.com/bootit-bare-metal.htm
BootIt NG installs itself at the beginning of a volume, that is, replaces the MBR by its own and occupies a number of blocks on the first track on the boot volume. It thus behaves just like the Bluebottle boot manager with which it cannot coexist. It may also be installed in a dedicated primary partition, which could become an issue with a maximum of 4.
How to start AOS with a different boot manager
editWhen a primary or logical partition is created and formatted to host an AOS file system - AosFS, it contains, by construction, at the beginning, a bootloader in charge of locating and loading a kernel and further on the rest of the OS. The presence of the "magic value" 55aah at offset 1feh in the PBR signals that the partition is formatted. Hence, AOS can be started by accessing the PBR and passing control to it. That is precisely the technique used by boot managers to start AOS when instructed as documented below. In Linux jargon, one speaks of chain loading.
Exceptionally, an AOS partition destined to serve exclusively as data repository may be formatted without kernel and programs. Such a partition is not bootable, in spite of the presence of a valid signature 55aah, just by lack of kernel (see Volume hosting Bluebottle). It can only be mounted/unmounted in AOS. A good example is that of a small capacity USB-HDD, say 62MB, or even that of a floppy diskette. In both cases a functional AOS would not fit but either would come handy as data store.
When any of the boot managers cited below is installed on the occasion of installing an OS, one can expect that Windows or Linux partitions will be recognized and that these OSes will be included in a boot menu to be bootable. But none will take action in the presence of AOS and that justifies the details given below for preparing a boot manager to start AOS.
1. GRUB installed on the occasion of installing Ubuntu 7.10 or Google's gOS
▪ Option to start AOS permanently recorded in the GRUB menu
In Ubuntu, navigate to Applications > Accessories > Terminal to open a terminal, then sign in as supervisor with: sudo -s (at the prompt enter the supervisor password)
Note: In the Ubuntu-based gOS, navigate to Applications > System Tools > UXTerm.
Now enter the command:
vi /boot/menu.lst
Place the cursor where to insert new text in the menu, enter 'i' to start inserting these lines in menu.lst
# This is for booting AOS residing in hd0,2 = IDE0#3 for example title AOS on hd0,2 chainloader (hd0,2)+1
Enter ':x' to save the updated menu and to quit editing.
In Debian Wheezy append a line such as
menuentry "Native Oberon" { chainloader (hd0,msdos7)+1 }
to /etc/grub.d/40_custom. Then execute "sudo update-grub" to revise /boot/grub/grub.cfg. "msdos" identifies the partition scheme and "7" is the partition number. The Grub manual has further details.
▪ On-the-fly command controlled start of AOS from a GRUB menu
When the GRUB menu appears at start up, enter 'c' for commands. The enter the following commands in succession:
chainloader (hd0,2)+1 boot
The boot command is required here but implied when the menu.lst is interpreted.
2. Windows Vista Boot Manager
Give the preference to NeoSmart Technologies's [https://neosmart.net] software EasyBCD - current version 1.7.1 - free download. The tool is of easy use: add an OS entry, name it, specify in which partition AOS resides and save the so modified binary file BCD (Boot Configuration Data).
While in Windows XP and earlier versions, it was simple enough to edit boot.ini to instruct the built-in boot manager to start another OS, Vista requires much more from a user to persuade its boot manager to cooperate with other OSes. boot.ini was replaced by the BCD binary file which, in Vista pure, must be edited using a console application named bcdedit.exe. This might reveal itself as a tedious task better performed with a tool such as EasyBCD. More such tools may be around of course.
3. GAG
Start GAG from a GAG boot volume, or from a bootable GAG CD-ROM, and follow the GUI instructions:
1. Press 's' to Set up GAG
2. Press 'a' to add an AOS
3. Press the letter associated with the target AOS among the listed OSes (using the GRUB example 'c' for AOS) or press a digit ('1' .. '8') associated with the target volume where the AOS resides
4. Type a description (up to 15 characters)
5. Type a password or none
6. Press the letter associated with the icon to represent AOS
7. Press 'h' to save in hard disk or 'r' to return to main menu for testing this sequence
External links
Boot From Flash Drive - [http://www.usb-flash-drives-now.com/cheaper/Boot-From-Flash-Drive.html]
[dead link]
Boot from USB - even when the BIOS does not support it: [https://www.plop.at/en/bootmanager/index.html]
- ↑ BootManager.Bin has been revised since this document was written by André Fischer. Consequently BootManager.Bin in the SVN archive is somewhat larger than 6656 bytes.