Ivan Nikolaenko <ivan.nikolaenko@unikie.com> writes:
These changes can be used in an external configuration layer as follows: overlays = [ (self: super: { gptOffset = 9437184; }) ];
Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko@unikie.com> ---
This patch is not a solution but just a proposal about how things can be done. There is at least one another way of doing this (having our own make-gpt.sh script), but I thought that editing of the current one is better way.
Also I don't know should we also consider other images and rootfs be fixed this way.
img/live/Makefile | 3 ++- img/live/default.nix | 1 + scripts/make-gpt.sh | 22 ++++++++++++++++++++-- 3 files changed, 23 insertions(+), 3 deletions(-)
Hi Ivan, thanks for the proposal. I still think this is a cross-distribution problem looking for a cross-distribution solution, not something specific to Spectrum. Other distributions providing vendor-neutral ARM images (e.g. Fedora, NixOS) have exactly the same problem. Solving it as part of Spectrum doesn't help them solve the same problem, and I think it's critically important for the long term maintainability of Spectrum that we be wary of implementing custom solutions for cross-distro problems, even when they start out pretty small like this one. So I think the best way forward here would be to have a small program that lives outside of Spectrum. It would take a firmware image, a generic ARM OS GPT image, and a configurable offset (or, if more board-specific knowledge ends up being required, some sort of board configuration file). It would then create a new GPT image, install the firmware appropriately, and then copy the partitions from the generic image, offset appropriately. [[ To be honest, I'm surprised this program doesn't exist already considering its limited scope, but I haven't seen anything like it. I suspect part of the reason is that most distros have still not caught up with the idea of installing an image, rather than doing a bespoke imperative installation, but that's definitely the direction things are moving in — e.g. systemd is doing lots of work to support image-based installs. [1] ]] This approach would avoid introducing additional complexity into Spectrum, _and_ would work for other operating systems too. It could be _the_ way to produce firmware+OS images for people who need to do that, reducing the amount of effort required to be spent on this problem across the ecosystem by users, integrators, and distributors. And the program should be pretty small and easy to write. It wouldn't be duplicating Spectrum's make-gpt.sh particularly, because the two would be focused on different tasks. make-gpt.sh takes some filesystem images and produces a GPT image from them, whereas this program would take an existing GPT and add in the platform-specific firmware. And it wouldn't need to be duplicated for every board somebody wanted to build images for, because the same program should be flexible enough to work for all boards that work this way. Some background here that's important to remember is that this is not something most end users would be expected to need to do. The ideal way of installing Spectrum on ARM, for an end user, would be to install a firmware distribution on separate storage (or if their board comes with firmware pre-installed that supports standards-based boot, they don't even have to do that!), and then install Spectrum on main storage. The firmware and OS could be updated and maintained independently*, and so Spectrum doesn't have to also be an ARM firmware distribution — we can leave that to other capable projects. Combined firmware+OS images are therefore mainly useful to two groups: end users using boards that don't have separate storage for firmware (or for which there is no firmware available that supports booting from main storage), or organisations who want to roll a system out across lots of devices, for whom it's more convenient to only have a single image on a single type of storage to worry about. If there's some reason this wouldn't work, and we absolutely *need* changes in Spectrum to accomodate firmware in the images we build, I'm willing to reconsider, but with my current knowledge, it looks to me like it could be solved distribution-independently, outside of Spectrum, and that doing so would make things better for everybody trying to create vendor-neutral ARM OSes. Previous discussion on this topic: - https://spectrum-os.org/lists/archives/spectrum-devel/20220828164957.p3743hv... - https://spectrum-os.org/lists/archives/spectrum-devel/0ead7a33-4c9b-6eab-26d... [[ As a side note, EBBR recommends using a protective partition rather than just offseting the GPT, to make the firmware area of the image more visible. [1] ]] * I'd really like fwupd support in Spectrum. [1]: https://arm-software.github.io/ebbr/index.html#gpt-partitioning