Using bootspec with RAUC and redundant partitions

Using bootspec with RAUC and redundant partitions

[robin]

Hi All,

Can anyone help me determine where to place the bootspec data in a 
system
with redundant partitions for kernel and rootfs?

We're migrating from scripts in env/boot for 'system0' and 'system1', to
bootspec. We're using bootchooser combined with the state framework to 
determine
which target needs to be booted.

Our partition table (relevant partitions):
  mmc2.0: kernel.0
  mmc2.1: kernel.1
  ...
  mmc2.4: rootfs.0
  mmc2.5: rootfs.1

Looking into the bootspec, we could add an additional 'boot' partition 
but this
breaks redundancy, and feels trivial since we have the kernel 
partitions.

But adding the loader/entries to the kernel partitions probably requires 
us to
generate them runtime (Rauc post-install?). Since Rauc determines which 
kernel
partition will be written with the contents of 'kernel' image in a 
bundle the
bootspec can't be determined at build time.

Is there a door number 3 or am I missing something here?

Best regards,
Robin van der Gracht

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Using bootspec with RAUC and redundant partitions

[Sascha Hauer]

Hi Robin,

On Tue, Sep 29, 2020 at 03:02:15PM +0200, robin wrote:
> Hi All,
> 
> Can anyone help me determine where to place the bootspec data in a system
> with redundant partitions for kernel and rootfs?
> 
> We're migrating from scripts in env/boot for 'system0' and 'system1', to
> bootspec. We're using bootchooser combined with the state framework to
> determine
> which target needs to be booted.
> 
> Our partition table (relevant partitions):
>  mmc2.0: kernel.0
>  mmc2.1: kernel.1
>  ...
>  mmc2.4: rootfs.0
>  mmc2.5: rootfs.1
> 
> Looking into the bootspec, we could add an additional 'boot' partition but
> this breaks redundancy, and feels trivial since we have the kernel partitions.

Yes, I wouldn't add an additional boot partition.

> 
> But adding the loader/entries to the kernel partitions probably requires us
> to generate them runtime (Rauc post-install?). Since Rauc determines which
> kernel partition will be written with the contents of 'kernel' image in a bundle
> the bootspec can't be determined at build time.
> 
> 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.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Using bootspec with RAUC and redundant partitions

[Enrico Jörns]

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.

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).

Best regards, Enrico

-- 
Pengutronix e.K.                           | Enrico Jörns                |
Embedded Linux Consulting & Support        | https://www.pengutronix.de/ |
Steuerwalder Str. 21                       | Phone: +49-5121-206917-180  |
31137 Hildesheim, Germany                  | Fax:   +49-5121-206917-9    |


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Using bootspec with RAUC and redundant partitions

[robin]

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).

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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: 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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Using bootspec with RAUC and redundant partitions

[robin]

Enrico,

> On 2020-09-30 10:09, Enrico Jörns wrote:
>> Hi Robin,
..
>> 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.

Re-reading this, do you mean that the blspec files on the rootfs 
partitions
should contain a root=/dev/mmcblk* of the partition they are on? And 
thus
still contain dynamic (install time computed) configuration?

I placed my kernel and bootspec entry in the rootfs partition under 
/boot.
The rootfs partition is mmcblk2p5 (barebox: mmc2.4).

The 'boot' command doesn't work with target 'mmc2.4' (probably since I 
placed
the data in a '/boot' subdirectory.

If I use 'boot /mnt/mmc2.4/boot' barebox finds the spec, kernel and dtb 
but
my root= is not set in the kernel commandline.

Best regards,
Robin van der Gracht

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Using bootspec with RAUC and redundant partitions

[Enrico Jörns]

Hi Robin,

Am Mittwoch, den 30.09.2020, 13:26 +0200 schrieb robin:
> Enrico,
> 
> > On 2020-09-30 10:09, Enrico Jörns wrote:
> > > Hi Robin,
> ..
> > > 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.
> 
> Re-reading this, do you mean that the blspec files on the rootfs 
> partitions
> should contain a root=/dev/mmcblk* of the partition they are on? And 
> thus
> still contain dynamic (install time computed) configuration?

no, what I meant was the opposite: To exclude this information from the
blspec file.

> I placed my kernel and bootspec entry in the rootfs partition under 
> /boot.
> The rootfs partition is mmcblk2p5 (barebox: mmc2.4).
> 
> The 'boot' command doesn't work with target 'mmc2.4' (probably since I 
> placed
> the data in a '/boot' subdirectory.

The bootspec entries are expected to be in /loader/entries of your
rootfs.

> If I use 'boot /mnt/mmc2.4/boot' barebox finds the spec, kernel and dtb 
> but
> my root= is not set in the kernel commandline.

A little detail I forgot to mention is that barebox requires you to
have a line 'linux-appendroot true' in the blspec file.

More info can be found here:

https://www.barebox.org/doc/latest/user/booting-linux.html#bootloader-spec

Best regards, Enrico

> Best regards,
> Robin van der Gracht
> 
-- 
Pengutronix e.K.                           | Enrico Jörns                |
Embedded Linux Consulting & Support        | https://www.pengutronix.de/ |
Steuerwalder Str. 21                       | Phone: +49-5121-206917-180  |
31137 Hildesheim, Germany                  | Fax:   +49-5121-206917-9    |


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Using bootspec with RAUC and redundant partitions

[robin]

On 2020-09-30 13:48, Enrico Jörns wrote:
> Hi Robin,
> 
> Am Mittwoch, den 30.09.2020, 13:26 +0200 schrieb robin:
>> Enrico,
>> 
>> > On 2020-09-30 10:09, Enrico Jörns wrote:
>> > > Hi Robin,
>> ..
>> > > 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.
>> 
>> Re-reading this, do you mean that the blspec files on the rootfs
>> partitions
>> should contain a root=/dev/mmcblk* of the partition they are on? And
>> thus
>> still contain dynamic (install time computed) configuration?
> 
> no, what I meant was the opposite: To exclude this information from the
> blspec file.

ack, than we're on the same page here ;)

>> If I use 'boot /mnt/mmc2.4/boot' barebox finds the spec, kernel and 
>> dtb
>> but my root= is not set in the kernel commandline.
> 
> A little detail I forgot to mention is that barebox requires you to
> have a line 'linux-appendroot true' in the blspec file.

Thats what I missed. A custom bootspec key :P

  blspec: booting vicut1-1.05.88.2.1 from mmc2
  Adding "root=PARTUUID=f340a0f5-05" to Kernel commandline

Now works as previously discussed, thanks!

Best regards,
Robin van der Gracht

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox