Using bootspec with RAUC and redundant partitions

[Robert Karszniewicz]

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