Hi.

On an ARM device, i wonder if it's possible to boot the whole / installed on a RAID 1 array.
And if it is, please explain how.

I'm not sure if you mean loading a different Linux system than normal, or loading the normal Linux system from RAID 1. The issues are similar in any case.

I'm no expert on this, but I do work with embedded systems (mainly with a non-Linux OS). The answer is generally, no. Embedded devices use simple boot-loaders that are not able to "load" files from a RAID 1 array, or an external disk. In some cases the loaders may not support loading an "initrd", only a binary file containing the kernel. The kernel is not necessarily located on disk, it may be loaded from a fixed position in flash. The same may be true of the "initrd" image.

The boot-loader for the ARM device is probably in flash or ROM and may only understand a few (or one) filesystems located at the beginning of the disk or storage.

In order to load the kernel and initrd from a RAID 1 array, the boot-loader has to understand the RAID metadata format. That is accomplished on an Intel PC by having a BIOS ROM on the RAID controller. The boot-loader (GRUB for example) uses the BIOS to do the actual "loading" of the kernel and initrd. It is the BIOS that understands the mirror or stripe format and metadata. You will probably not be able to modify or extend the boot-loader on an ARM device to understand the metadata.

The kernel and initrd have to be loaded from a file-system that the boot-loader understands, so they have to be located outside the RAID 1 array. The implication is that those two files cannot be stored or loaded redundantly. However, those should be the only two files that cannot be in the RAID array.

Depending on the boot-loader it may be possible to tell it the starting block offset (or patch it) for locating the kernel and initrd. That would allow loading the two files from a RAID 1 array (but not RAID 0) but still would provide no redundancy for those files. Additionally, that is only practical when the location of those two files does not change. Since there is no advantage gained, it is a bit pointless.

To provide redundancy, the boot-loader (or software it uses) has to understand the concept of mirroring and be able to try loading those two files (or at least kernel with no initrd) from the two different sets of disk blocks.

From what I can tell, there is an ARM version of GRUB. Assuming that you wanted to use it, then the GRUB files could not be located inside the RAID 1 array. For GRUB to support loading the kernel or initrd from RAID 1, GRUB would have to provide support for the RAID 1 metadata and filesystem used. GRUB 2 may satisfy that requirement. You are still left with the problem of how to make the ARM loader load GRUB. GRUB is not just a single file.

A lot of embedded devices have a kernel in a section of flash, and a filesystem in another section of flash. Those devices don't use the concept of partitions and don't support using RAID1 for the file storage containing the root filesystem. If initrd loading is not supported you can't move the system files to a RAID array. Even with an initrd, you would have to keep the kernel and initrd where they are and just put the remaining files in the RAID 1 array. That would require the device containing the RAID 1 array to be connected and working in order to boot the system.

How could you boot from the whole "/" on a RAID 1 array? You could possibly use one of these two methods.

1. Install GRUB 2 to the existing root file storage. This assumes GRUB 2 supports the block device and the RAID 1 containing the target Linux system. The ARM boot loader has to be able to load GRUB 2 somehow. Those are fairly large assumptions. I don't think that ARM systems have a standard like a BIOS for GRUB to use services of the ARM loader.
2. Write a "root" privileged loader that loads the target kernel and initrd into memory. Run the loader on the default Linux system that boots. Have the loader take over the CPU and transfer execution to the target kernel and initrd. You may also have to write some copying code to move the binary images to the correct physical memory locations. This is all very messy and requires assembly language to change the CPU to the correct execution mode. The kernel is going to expect certain things, and I don't know enough about Linux to tell you what. For example, a flat memory model in 32-bit protected mode with virtual paging disabled. A running kernel has already changed a lot of the hardware settings from what a kernel expects at start-up.

I've only used the second method on a DOS system to boot a non-Linux operating system. I essentially tacked some copying and start-up code to the front of an existing OS image. I knew what the OS expected, so I wrote the code to copy it to the expected memory location and change the CPU mode. Since the resulting file was a ".COM" file I was limited to a small 64K operating system.

If you find out more details about the ARM system you can answer your question more definitely. How does it boot the existing Linux system? Is there any information about the boot-loader or firmware used on the ARM system? What are the capabilities of GRUB for the ARM architecture?

As is often that case, booting from RAID 1 may be possible but not worth the effort required.

I did a bit of investigation into ARM booting.

It seems there are two common boot-loader standards for ARM

• U-Boot
• UEFI

U-Boot understands Flash and USB with a partition table and FAT filesystem support. UEFI is a complicated standard that includes loading operating systems, pre-boot applications and other features. Neither of them directly supports the Linux RAID format on ARM.

So far as I can tell there is no working GRUB 2 for ARM. It looks like it may eventually support U-Boot and UEFI. That may someday include the RAID module for GRUB 2 that understands Linux RAID.

At the moment, the answer to booting Linux directly from RAID on ARM architectures, is no. The kernel and initrd must be located in a non-RAID partition or device. U-Boot requires those files to be in a FAT filesystem and supports flash or USB devices. The rest of the files can be anywhere that is accessible from the Linux system you are booting. The root filesystem does not have to be the same as the one containing the kernel and initrd. In fact, other than for updating the kernel and initrd, the Linux system being booted does not need access to those files. For example, you can put the kernel and initrd files in flash and then the booted Linux kernel does not require flash support. Without flash support you would have to use some other OS or program to update the kernel and initrd in flash.

How you select the OS to boot is another interesting question. U-Boot provides for scripts, and some ARM devices support remote serial consoles. With U-Boot you can enter a command to boot from USB. The USB boot device has to use the legacy partition format (not GUID) and the file-system containing the kernel and initrd must be FAT. Still, it makes the most sense to put those files on the same device with the rest of the files. USB storage is removable. You can investigate the U-Boot software if that's what your ARM device uses. It may be possible to write a script to check for a removable USB device to boot, and then boot from flash if a USB boot device is not found.

I'm assuming that you aren't putting a RAID1 array in flash. That seems unnecessary. However, it should be possible if the Linux system being booted supports the flash device and partitioning of flash.

In summary, you can put all the "/" files except for the kernel and initrd in a Linux RAID1 array.

It's U-Boot.

Thanks for all these explanations. It's much clear for me.

For now, my autoboot.txt, which can be compared to lilo.conf or grub-1's menu.lst, contains the parameters for the /, which is root=/dev/mmcblk0p1, and the location of the kernel, which is /boot/uImage.

I did a blind try some days ago, but i failed.
I need to better understand U-Boot before wasting my time again .

Thanks again.