Now that the Partitioning support work is merged (Thanks Ed!)
we are able to generate disk images with different partitions
containing some parts of the systems, auto-generating the fstab
file to mount these partitions, etc.
With this work, I'm able to generate a disk image for the
Raspberry Pi, creating one partition for `/boot` and the rest
in the second partition. On a fast attempt of getting it working,
I created the `config.txt` file needed for u-boot to know what to
do, at build-time of one of the chunks of the BSP (this is obviously
wrong), under the `/boot` folder, so that it ends up in the `boot`
partition with everything else (u-boot, kernel, etc.).
Today I've been researching about using a `extlinux.conf` file to
configure the bootloader in the Raspberry Pi, on the same way we do
with the Jetson-tk1, and it looks like it should be possible. The
reasons to do this is to support Baserock Upgrades on the Raspberry
Pi, rollback, etc.
After investigating about all of this I found that our current
situation is far from perfect, and I'd like to point out here
what I believe needs more thinking and some rework.
Current status and problems
There is no way of specifying where to put the `extlinux.conf` file,
it will always go to the main partition. Jetson-tk1 deployment fixes
this problem on its flashing script. This script creates the partitions,
and copies files to the right place.
There is a variable `BOOT_DEVICE` that is only used for the Upgrades
scripts (system-version-manager), but you need to specify it in the
cluster morphology of the system that you want to make upgradeable.
This variable doesn't do anything else, and of course it might have
wrong values if used in combination with the partitioning support, or
if you use it when deploying a system that won't have any partition,
given that this is currently possible and doesn't trigger errors or
warnings. This variable will only be used for the system that is going
to be upgraded, when receiving an upgrade. If this variable is not
properly set, your system will fail to upgrade.
There are probably more problem, but I didn't have time to investigate
Use `BOOT_DEVICE` in combination with partitioning to install
extlinux.conf and kernel in other partitions?
Install extlinux.conf in the partition `/boot` if exists and
if not default to `/`?
Create a variable in the partitioning files to specify where
to create the bootloader configuration files and kernels?
Put extlinux.conf in `/boot` by default and create a symlink
from `/` to it to make it work when no partitions? This idea is
probably the worst one. The file should be created **before**
moving things to partitions, otherwise it won't end up in the
boot partition if created.
There are probably more possible solutions for this, although
I think that `extlinux.conf` is not the only file, and we also have
to take care about the kernels.
Developer wants to put `/boot` in another partition. `extlinux.conf`
and kernel are created there.
Developer want's to upgrade the system. system-version-manager knows
what partition to mount when writing new `extconfig.conf` file and
BOOT_DEVICE and ROOT_DEVICE are not required for this, and
partitioning should create enough metadata to get this right.
If the system is deployed without partitions, and then flashed to a
board, is up to the flashing script generating the metadata needed
to make system-version-manager work properly (the replacement of
BOOT_DEVICE and ROOT_DEVICE)
Show replies by date