MultiBoot for the Raspberry Pi 4 and Raspberry Pi 3

[RonR]

MultiBoot maintains multiple copies of Raspberry Pi OS (RaspiOS) on a single storage device. Only one copy of RaspiOS may be active at a time, but changing the active copy requires little more than a reboot. When Master Boot Record (MBR) partitioning is used (default), a maximum of 3 copies of RaspiOS may be present. When GUID Partition Table (GPT) partitioning is used, a total of 127 copies of RaspiOS is theoretically possible, but the practical limit is around 25. MultiBoot can quickly convert an MBR storage device to GPT at any time.

Each RaspiOS instance occupies its own ROOT partition and shares a common BOOT partition. The common BOOT partition is saved to and restored from its associated ROOT partition when a different RaspiOS instance is selected. Each RaspiOS instance has a user defined name for convenient identification.

The initial starting point is an operational RaspiOS installation. Additional copies of RaspiOS are then installed by MultiBoot from normal image files. The user selects the image file to install, the partition size, and the RaspiOS instance name. RaspiOS instances may later be removed, resized, moved to the top or bottom of adjacent free space, or renamed.

A single script (mb) performs all configuration actions as well as selecting the active RaspiOS instance. Selecting the active instance of RaspiOS can be accomplished interactively by executing mb with no parameters or non-interactively by specifying the name of the RaspiOS instance to be activated. In either case, a reboot will occur and the newly selected RaspiOS instance will be active. Executing the MultiBoot script (mb) with a -i or --identify option will display the currently active RaspiOS instance.

Configuration is performed by executing the MultiBoot script (mb) with a -c or --config option. The storage device that contains the currently running RaspiOS system cannot be configured due to the partitioning operations that are involved. Simply boot from another storage device to perform configuration. MultiBoot will display a list of storage device candidates to select from for configuration. Configuration candidates are storage devices whose first partition is VFAT and second partition is EXT4. The first time MultiBoot configures a storage device, you will be asked for permission to initialize it, which consists of copying the BOOT partition contents to the ROOT partition /boot directory.

Configuration actions include:

Insert

This action inserts a new RaspiOS instance. You first select an 'Unpartitioned_Free_Space' area of sufficient size for the new RaspiOS instance to reside in. Then you specify the pathto/imagefile to be installed. Next, a partition size is requested. Partition size can be entered with a multiplier suffix of K, M, G, or T, for Kilobytes, Megabytes, Gigabytes, or Terabytes. If no multiplier suffix is given, the number is interpreted as the number of sectors. Then you must enter a name for the new RaspiOS instance. Names may contain embedded spaces which will be converted to underscores. Names may not start with a hyphen. Maximum name length is 40 characters. If WiFi is to be enabled (optional), you may specify the pathto/filename to be used for wpa_supplicant.conf. You may also enable or disable SSH logins. The final step is to confirm installation of the new RaspiOS instance.

Remove

This action removes an existing RaspiOS instance. Choose the name of the RaspiOS instance you wish to remove and confirm. The currently active RaspiOS instance cannot be removed until another RaspiOS instance is first made active.

Resize

This action resizes a partition. A partition can only be expanded into free space above it. To utilize free space below it, first use the Locate action to move the partition down. The current, minimum, and maximum partition sizes are displayed. Partition size can be entered with a multiplier suffix of K, M, G, or T, for Kilobytes, Megabytes, Gigabytes, or Terabytes. If no multiplier suffix is given, the number is interpreted as the number of sectors. The partition size may also be specified as 'minimum' or 'maximum'.

Locate

This action moves a partition to the top of free space above it or the bottom of free space below it. Depending on the speed of the media and size of the partition, this action can take a considerable amount of time to complete.

Rename

This action prompts for a new name and renames the chosen RaspiOS instance following confirmation

Select

This action selects the active RaspiOS instance. The currently active RaspiOS instance is indicated by a '=' instead of a ':' separating the RaspiOS instance name and partition size. A reboot does not occur during this configuration action.

MBRGPT

This action converts MBR partitioning to GPT partitioning.


NOTE: Do NOT use the 'Expand Filesystem' function in raspi-config! Doing so will render your storage device unusable. Always use MultiBoot to manipulate partitions.

NOTE: The ability to boot an SD card using GUID Partition Table (GPT) partitioning requires the RaspiOS 5.4.61 or later kernel.

image-backup may be used to create backup images of individual partitions which can be later installed by MultiBoot. The -n or --noexpand option should be used when creating a backup for use with MultiBoot.

MultiBoot is also suitable for use with a Raspberry Pi 2 (SD card only).

[RonR]

It's now been 3 months but there's still not an official RaspiOS image file available for download that can be loaded directly onto a USB device and booted on a Raspberry Pi 4.

The attached script will update the firmware files on older RaspiOS images making them capable of being loaded directly onto a USB device and booted without going through the steps of first creating an SD card, updating it, and creating an image file from it or copying it to a USB device.

Usage is:

sudo ./upd-image-fw <pathto/imagefile>

For example:

Code: Select all

sudo ./upd-image-fw 2020-05-27-raspios-buster-armhf.img

[RonR]

New RaspiOS images have been made available (2020-08-20-raspios-buster-armhf) containing updated firmware. These images are now compatible with direct booting on a Raspberry Pi 4. See Raspberry Pi EEPROM Manager for a simplified and convenient method of updating the Raspberry Pi 4 bootloader EEPROM.

The 2020-08-20-raspios-buster-armhf images have been tested with and operate properly with MultiBoot (attached to the first post of this topic).

[RonR]

I made a small enhancement to MultiBoot:

Executing the MultiBoot script (mb) with a -i or --identify option will display the currently active RaspiOS instance.

[pasman1]

hello.

Scripty mb not works with non-en locale.

[RonR]

Scripty mb not works with non-en locale.

Can you give more details please.

There's no localization logic in the script.

[pasman1]

in the script is used

printf

function (for example lines 258,260,262,264),
which need localised float numbers:

Code: Select all

pi@raspberrypi:~ $ printf "%.1f\n" 2,6
2,6
pi@raspberrypi:~ $ printf "%.1f\n" 2.6
bash: printf: 2.6: nieprawidłowa liczba
2,0

it generate errors, because

bc

returns not localised numbers.

regards.

[RonR]

it generate errors, because

bc

returns not localised numbers.

I've never dealt with localization, but isn't this a localization problem in bc, not the script?

Doesn't leaving the default "en_GB.UTF-8 UTF-8" locale installed allow proper operation?

[pasman1]

No.
There is other error:

Code: Select all

$ sudo ./mb -c
Scanning /dev/sdb

Saving BOOT partition
e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 103388/210080 files (0.3% non-contiguous), 708780/839680 blocks
resize2fs 1.44.5 (15-Dec-2018)
The filesystem is already 839680 (4k) blocks long.  Nothing to do!

e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 103388/210080 files (0.3% non-contiguous), 708780/839680 blocks
losetup: /home/pi/2020-05-27-raspios-buster-arm64.zip: Warning: file does not fit into a 512-byte sector; the end of the file will be ignored.
sfdisk: /dev/loop0: does not contain a recognized partition table
./mb: line 431: [: 134217728: unary operator expected

./mb: line 475: * 512: syntax error: operand expected (error token is "* 512")

[RonR]

No.
There is other error:

With no example as to how to reproduce the error, I'm at a loss as to how to proceed. I'm not seeing this problem here.

[fbe]

No.
There is other error:

Code: Select all

...
losetup: /home/pi/2020-05-27-raspios-buster-arm64.zip: Warning: file does not fit into a 512-byte sector; the end of the file will be ignored.
...

You should unzip 2020-05-27-raspios-buster-arm64.zip first. losetup doesn't work with zip-files.

[RonR]

You should unzip 2020-05-27-raspios-buster-arm64.zip first. losetup doesn't work with zip-files.

Good catch, thanks!

[pasman1]

After unpacking, and with en_GB locale script works

Good job!!

[RonR]

After unpacking, and with en_GB locale script works

Good job!!

Thanks for the feedback. I'm very pleased to hear your problems are resolved.

[RonR]

MultiBoot.zip (in the first post of this topic) has been updated.

MultiBoot now supports installing multiple copies of RaspiOS on SD cards in addition to USB storage devices.

[epoch1970]

Does multiboot use an hybrid GPT MBR partition table?
If so, what happens if a raspios user runs something else than pdisk to edit their partitions? Raspios doesn’t come with pdisk AFAIK, fdisk is certainly top of mind.

[RonR]

Does multiboot use an hybrid GPT MBR partition table?
If so, what happens if a raspios user runs something else than pdisk to edit their partitions? Raspios doesn’t come with pdisk AFAIK, fdisk is certainly top of mind.

As described in the first post, MultiBoot works with either MBR (default) or GPT. MultiBoot uses sfdisk (which handles both MBR and GPT disks) for most operations but uses gdisk to convert MBR to GPT if desired. MultiBoot handles all partitioning (creating, deleting, resizing, moving, and converting), on both MBR and GPT. No other tools are needed.

When GPT is used, a Hybrid MBR is created by gdisk for the BOOT partition only (partition 1). Since the BOOT partition is never altered, it never needs re syncing. The Hybrid MBR is needed for GPT booting on boards other than the Raspberry Pi 4.

Current versions of fdisk are also GPT and Hybrid MBR aware.

[epoch1970]

Current versions of fdisk are also GPT and Hybrid MBR aware.

Good to know. Thanks.

[emma1997]

Is there any way to convert GPT to MBR? All the new portable drives come that way and it would be great if I didn't have to fire up the W10 machine every time just to convert.

[RonR]

Is there any way to convert GPT to MBR? All the new portable drives come that way and it would be great if I didn't have to fire up the W10 machine every time just to convert.

Why don't you like GPT?

The 'g' option of gdisk says (I've never tried it):

Convert GPT into MBR and exit. This option converts as many partitions as possible into MBR form, destroys the GPT data structures, saves the new MBR, and exits. Use this option if you've tried GPT and find that MBR works better for you. Note that this function generates up to four primary MBR partitions or three primary partitions and as many logical partitions as can be generated. Each logical partition requires at least one unallocated block immediately before its first block. Therefore, it may be possible to convert a maximum of four partitions on disks with tightly-packed partitions; however, if free space was inserted between partitions when they were created, and if the disk is under 2 TiB in size, it should be possible to convert all the partitions to MBR form.

[emma1997]

Thank you for that detailed description. As usual you are one of the most responsive and helpful members.

So maybe as easy as?

Code: Select all

gdisk -g /dev/sdx

I thought I tried it but don't recall why it failed before. I know hybrid is not an option.

There is no choice, my OS only works with MBR. New drives come with one single GPT partition and it would be nice to convert on the Pi instead of having to use the Wintel box just for that. I will probably pick up another WD 2tb Elements from Newegg to give that a try. Thanks again.

PS I see now it's interactive and maybe not so easy but will give it a go when a new drive arrives.

[RonR]

So maybe as easy as?

Code: Select all

gdisk -g /dev/sdx

Not quite.

I think you'd run 'gdisk /dev/sdX' followed by entering 'r' then 'g'.

[emma1997]

Yup... I figured that out in man. As a last resort read the manual. Only as a last resort though. lol

[bonzer2u]

Hi Ron,

Downloaded your programs and reading the docs before I give it a go. Thx for your guidance, I'm definitely not an advanced user.......

[RonR]

I have a couple large retropie distros (64 and 128gb) and a significantly tweeked twister 1.7 (32gb), all sd cards that I have been swapping in and outa my Pi4-4gb that I would like to consolidate on a just arrived 1 TB usb-ssd.

The following instructions will not alter your original SD cards. I'm going to assume you are consolidating all SD cards to the new 1TB SSD as the destination. If you have a large USB flash drive to use instead, that's fine.

1. Boot each of the SD cards and create an image file of it using image-backup. First mount a USB flash drive to save the backup image file to and run:

Code: Select all

sudo ./image-backup --noexpand

After specifying the image file to create, you can simply hit RETURN to accept the defaults for "Initial image file ROOT filesystem size (MB)" and "Added space for incremental updates after shrinking (MB)".

You want a separate backup image file for each of your SD cards.

2. Choose one of the backup image files and write it to the SSD drive using Etcher.

3. Boot any SD card and run MultiBoot in configuration mode:

Code: Select all

sudo ./mb --config

4. Choose the SSD drive. The only action initially available is "initialize". Choose it, and give a name to the first OS you wrote to the SSD with Etcher.

5. Select "Resize" and resize the first OS to the desired size.

6. Exit MultiBoot and you should be able to boot the first OS from the SSD.

7. To add the remaining OS image files, boot the SD card again, run MutiBoot in configuration mode, and use the "Insert" action.

8. After all OS image files have been added, boot the SSD.

9 To boot a different OS, simply run MultiBoot with no options (sudo ./mb), select the desired OS, and the system will reboot to the selected OS.