Context ------- 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 them all. Possible solutions ------------------ 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. Ideal solution -------------- 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 kernels. 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) -- Pedro