[fedora-arm] F21 disk image idea

[Patrick Noffke]

On Wednesday, January 08, 2014 02:16:55 PM Brendan Conoboy wrote:
> Hi everybody,
> 
> There are two significant issues with the disk images in F20 that I 
> would like to address in F21:
> 
> 1. Duplicate disk images with and without a VFAT partition.  This 
> doubles QA load and can confuse end users.
> 

Sorry for my ignorance, but why do you need to create images with VFAT partitions?

> 2. Unlike x86 spins, images aren't always ready to be used after they're 
> written to storage.  Instead, uboot bits need to be copied into place 
> using a specific method.  This is unintuitive and prone to user error.
> 
> In F18 and earlier we simply produced images per supported device, but 
> the matrix of supported devices and spins makes this prohibitively 
> expensive, so something else needs to be done.  The following proposal 
> is one way to handle it, but I'm open to anything that improves on 
> either or both of the aforementioned issues.
> 
> The idea: 2 images per device, a board image and an OS image.  Here's 
> how it works:
> 
> The board image: This is a very small image that contains the essential 
> bootloader bits for booting Fedora on a board.  It contains the 
> bootloader if a board doesn't have one, a partition table, and just 
> enough brains to load the proper dynamic material like extlinux.conf 
> from the OS image.
> 
> The OS image: This contains / (No separate /boot).  One per spin is all 
> we need.
> 
> The key idea is that we're trying to decouple the Fedora OS from the 
> idiosyncrasies of the hardware.  We can make lots of board images, 
> they're really small- they don't even need to be part of the Fedora 
> release cycle unless we think that is desirable.
> 
> For a hypothetical end user with a beaglebone black, the experience is 
> something like:
> 
> download f21-xfce.img
> download fedora-arm-bbb.img
> write f21-xfce.img to block device
> write fedora-arm-bbb.img to same block device
> 
> Alternately:
> 
> download f21-xfce.img
> download fedora-arm-bbb.img
> write fedora-arm-bbb.img to same block device
> partprobe
> write f21-xfce.img to partition 3 of block device
> 
> Clearly some decisions need to be made about partition vs block device 
> for the OS image, but ultimately we resolve issue #1 and simplify issue 
> #2.  Assuming we went with writing a partition instead of a complete 
> block device, end users would only need to install the per-device disk 
> image once an could move between Fedora versions by updating the / 
> partition.
> 
> Anyway, that's where my mind is on this one.  What do you all think? Can 
> you make it better?
> 

I created an embedded Linux distro at work, and I did something similar to the "Murphy" paper (the stuff about OS images):
https://www.kernel.org/doc/ols/2005/ols2005v1-pages-21-36.pdf

The OS images are just files in a big "OS image" file system (on one partition).  One of the images (the "current" one) gets loop-back mounted by a boot kernel.  If you want to run a kernel (contained within the OS image) newer than the one in the boot kernel, you can do this with kexec.  And I believe you can loop-back mount them as read/write (I do it read-only for my system, but I recall testing read/write, and I think that worked).

Then if you need a VFAT partition, or any other partitions, they can coexist with the OS image partition.

This approach allows many different images to coexist, and you can switch between images just by editing a text file (or whatever the boot kernel uses to decide which OS image to use).  One downside is you need lots of storage if you want to have multiple images.

This approach probably creates a lot of new problems that you don't want to deal with.  I mainly wanted to mention it in case it triggers any other ideas.

Patrick