Hello, Robin.
On 9/30/20 11:19 AM, robin wrote:
Hi Enrico, Sascha,
On 2020-09-30 10:09, Enrico Jörns wrote:
Hi Robin,
Am Mittwoch, den 30.09.2020, 09:39 +0200 schrieb Sascha Hauer:
> Is there a door number 3 or am I missing something here?
What's the reason for additional kernel partitions? Things would be
easier if you put the kernel images into the rootfs partitions along
with the bootspec entries.
the road to success here is to not encode any slot-/partition-specific
information in the bootspec entries.
I see.
Why this would work anyway is because barebox extends the kernel
commandline with the root= entries required to boot the kernel from
that specific partition where it did read the entry from.
This way it should work having an A+B setup with only two rootfs
partitions that include the kernel, the (generic) bootspec entry and
the rootfs itself (as Sascha already pointed out).
We've decided to separate the kernel from the OS a long time ago because,
back then, we wanted to keep the bootloader simple, minimal and solid and
including ext4 support didn't quite fit into that picture. Also, our
customer used to create their own rootfs, and we'd build them a kernel
and back then we didn't bundle releases (like rauc does now).
I don't know if it helps in your case, but we had a similar problem
(wanted rootfs and kernel separate, but couldn't predict the rootfs
partition device number in kernel). We ended up with a patch to barebox
that allows specifying the rootfs device, which barebox then converts to
"root=PARTUUID=".
The patch is currently on 'master':
d39a98718154 ("bootm: add global.bootm.root_dev env var for booting via
PARTUUID")
Maybe it helps.
Regards.
Since things changed in the meantime I'll re-open that discussion
and go from there. Thanks for pointing me in this direction.
Best regards,
Robin van der Gracht
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
