I'm thinking about designing a system for a project using some single-board computer (RaspberryPi, CubieTruck etc) that runs Linux.
My main requirement is keeping the complexity of the booted SD card to a minimum - my vision is something like:

 settings.txt # DHCP /ifconfig data etc.
 error.log    # optional
 OS.tar.gz    # the OS Omni-file
 Kernel.img   # If it can't fit with the Omni-file

The OS doesn't have to modify its files, except possibly for some error log.
My best guess so far is booting from an actual ISO using easy2boot, but the layout isn't trivial enough (and it seems kinda backwards).
Is there any project / boot option that can help me achieve my goal?

I found out about loop devices, which look like what I need - a FS inside a file.
I managed to format and mount it, like:

losetup /dev/loop0 /tmp/disk.img
mkfs -t ext2 /dev/loop0
losetup -d /dev/loop0
mkdir /tmp/disk-mount
mount /tmp/disk.img /tmp/disk-mount -o loop
touch /tmp/disk-mount/bla
umount /tmp/disk-mount

Is there any documentation for booting from such a device?


Consider using Buildroot in order to create your target root file system. This project leverages the Linux kernel configuration and building work flow to the whole embedded system file system.

  • This looks highly relevant. Will check. Thanks!
    – Nitz
    Jan 19 '15 at 8:50

If I understood you correctly, you need a tool to build a custom root file system. One of the tools I've worked with is http://www.ptxdist.org/software/ptxdist/index_en.html however I don't know if setting the bootloader to run on the Ri would be an easy task.

Also, consider that some of the files you've defined in your example would need some form of daemon to populate them, and that deamon is a binary located somewhere in the file system hierarchy.

So when you say The OS doesn't have to modify its files, except possibly for some error log. the application modifying it is probably a userspace deamon located somewhere on the rootfs (for example /usr/bin).


Following your secondary ("update") question regarding using loop device: As much as I am familiar with the boot flow, you have to first boot into an initial ramdisk (initrd) - a minimal root FS image embedded in the kernel image which holds just enough contents to mount the main root FS as loop device. After mounting the main root FS, "chroot" from the initrd into the full (loop) mounted root image.

  • I don't really see the sense in that - why not just do the minimal image as the initramfs image and forego the switch_root altogether?
    – mikeserv
    Jan 19 '15 at 21:38
  • I have little experience in building Linux, but I think that a initramfs that is too big for the device's RAM is problematic. Am I wrong?
    – Nitz
    Jan 20 '15 at 7:21
  • The initramfs is as large as what you put in it. The typical size that you see on a PC version of Linux is a result of the generic nature of the built initramfs of PC Linux distribution - they need to provide many device drivers at early init stage to support many hardware configurations, etc. In your own initramfs you may put whatever you want and reduce its size as you wish to include only what you really need for your target device. For instance, I was able to boot with an initramfs image of a little more than 1 MB.
    – ElazarR
    Jan 21 '15 at 7:48
  • Regarding the need to switch root: The initramfs is sometimes loaded by simplified bootloader like Uboot. The bootloader may have relatively slow SD device driver (relative to the SD device driver of Linux) so one may want to minimize that initramfs even beyond the available memory space for the final (RAM) root FS and use Linux to load/mount the full root FS. This is an optimization. You can avoid it and just boot directly to your final root FS image on account of boot time.
    – ElazarR
    Jan 21 '15 at 7:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.