Using bootspec with RAUC and redundant partitions
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
Hi Robin,
Quoted 17 lines · 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
Quoted 2 lines
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.
Quoted 7 lines
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
Signature · 9 lines
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 [email protected] http://lists.infradead.org/mailman/listinfo/barebox
Hi Robin,
Am Mittwoch, den 30.09.2020, 09:39 +0200 schrieb Sascha Hauer:
Quoted 5 lines
Quoted 1 line
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
Signature · 10 lines
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 [email protected] http://lists.infradead.org/mailman/listinfo/barebox
Hi Enrico, Sascha,
Quoted 11 lines · Enrico Jörns
Hi Robin,
Am Mittwoch, den 30.09.2020, 09:39 +0200 schrieb Sascha Hauer:
Quoted 5 lines
Quoted 1 line
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.
Quoted 7 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
Hello, Robin.
Quoted 25 lines · robin
Hi Enrico, Sascha,
Quoted 11 lines · Enrico Jörns
Hi Robin,
Am Mittwoch, den 30.09.2020, 09:39 +0200 schrieb Sascha Hauer:
Quoted 5 lines
Quoted 1 line
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.
Quoted 7 lines
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).
Quoted 5 lines
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.
Quoted 6 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
Enrico,
Quoted 2 lines · Enrico Jörns
Quoted 1 line
Hi Robin,
..
Quoted 3 lines
Quoted 3 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
Hi Robin,
Am Mittwoch, den 30.09.2020, 13:26 +0200 schrieb robin:
Quoted 9 lines
Enrico,
Quoted 2 lines · Enrico Jörns
Quoted 1 line
Hi Robin,
..
Quoted 3 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 7 lines
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.
Quoted 3 lines
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
Quoted 3 lines
Best regards,
Robin van der Gracht
Signature · 10 lines
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 [email protected] http://lists.infradead.org/mailman/listinfo/barebox
Quoted 12 lines · Enrico Jörns
Hi Robin,
Am Mittwoch, den 30.09.2020, 13:26 +0200 schrieb robin:
Quoted 9 lines
Enrico,
Quoted 2 lines · Enrico Jörns
Quoted 1 line
Hi Robin,
..
Quoted 3 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 5 lines
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 ;)
Quoted 5 lines
Quoted 2 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox