[PATCH v2 0/2] Fix rpi targets build on Bullseye

[PATCH v2 0/2] Fix rpi targets build on Bullseye

[Anton Mikanovich]

Fix mkfs.vfat related build issues reported by Vijai.

Changes since v1:
- Replace sed regexp with more easy to read cut call.

Anton Mikanovich (2):
  Revert "Revert "isar-init-build-env: Add /sbin to PATH""
  rpi-sdimg: Limit volume id value

 isar-init-build-env                 | 4 ++++
 meta-isar/classes/rpi-sdimg.bbclass | 6 +++++-
 2 files changed, 9 insertions(+), 1 deletion(-)

-- 
2.17.1

[PATCH v2 1/2] Revert "Revert "isar-init-build-env: Add /sbin to PATH""

[Anton Mikanovich]

Image prepare tools like parted and mkfs.vfat from rpi-sdimg bbclass
can't be found in bullseye chroot because /sbin is not exported into
PATH by default. Add /sbin manually to fix the issue.

This should be reverted after replaced rpi-sdimg.bbclass by WIC.

This reverts commit d0bc682ee81da11f4b939165a4d4383af7ed99de.

Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
---
 isar-init-build-env | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/isar-init-build-env b/isar-init-build-env
index 85fb82f..f3d1b6b 100755
--- a/isar-init-build-env
+++ b/isar-init-build-env
@@ -57,4 +57,8 @@ export ISARROOT
 }
 unset ISARROOT
 
+# wic executes mkdosfs
+PATH=/sbin:$PATH
+export PATH
+
 [ -z "$BUILDDIR" ] || cd "$BUILDDIR"
-- 
2.17.1

[PATCH v2 2/2] rpi-sdimg: Limit volume id value

[Anton Mikanovich]

The volume name should be up to 11 characters long.
It is longer for some rpi targets and fails with the following error:

| mkfs.vfat: Label can be no longer than 11 characters
| mkfs.fat 4.2 (2021-01-31)
| WARNING: exit code 1 from a shell command.

Limit volume name length to fix the issue.

Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
---
 meta-isar/classes/rpi-sdimg.bbclass | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta-isar/classes/rpi-sdimg.bbclass b/meta-isar/classes/rpi-sdimg.bbclass
index 1efc1c4..b13611b 100644
--- a/meta-isar/classes/rpi-sdimg.bbclass
+++ b/meta-isar/classes/rpi-sdimg.bbclass
@@ -46,7 +46,11 @@ do_rpi_sdimg () {
     # Create a vfat image with boot files
     BOOT_BLOCKS=$(LC_ALL=C parted -s ${SDIMG} unit b print | awk '/ 1 / { print substr($4, 1, length($4 -1)) / 512 /2 }')
     rm -f ${WORKDIR}/boot.img
-    mkfs.vfat -n "${BOOTDD_VOLUME_ID}" -S 512 -C ${WORKDIR}/boot.img $BOOT_BLOCKS
+
+    # Limit volume name length to be 11 characters long
+    VOLUME_NAME=$(echo "${BOOTDD_VOLUME_ID}" | cut -c -11)
+
+    mkfs.vfat -n "$VOLUME_NAME" -S 512 -C ${WORKDIR}/boot.img $BOOT_BLOCKS
     mcopy -i ${WORKDIR}/boot.img -s ${IMAGE_ROOTFS}/boot/* ::/
 
     # Burn Partitions
-- 
2.17.1

Re: [PATCH v2 1/2] Revert "Revert "isar-init-build-env: Add /sbin to PATH""

[Jan Kiszka]

On 15.03.22 19:40, Anton Mikanovich wrote:
> Image prepare tools like parted and mkfs.vfat from rpi-sdimg bbclass
> can't be found in bullseye chroot because /sbin is not exported into
> PATH by default. Add /sbin manually to fix the issue.
> 
> This should be reverted after replaced rpi-sdimg.bbclass by WIC.
> 

Why this ping-pong, why not fixing it directly? Raspios limitations?
With Debian, it's a no-brainer to use wic for generating Raspi images,
as done multiple times downstream by now.

Jan

> This reverts commit d0bc682ee81da11f4b939165a4d4383af7ed99de.
> 
> Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
> ---
>  isar-init-build-env | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/isar-init-build-env b/isar-init-build-env
> index 85fb82f..f3d1b6b 100755
> --- a/isar-init-build-env
> +++ b/isar-init-build-env
> @@ -57,4 +57,8 @@ export ISARROOT
>  }
>  unset ISARROOT
>  
> +# wic executes mkdosfs
> +PATH=/sbin:$PATH
> +export PATH
> +
>  [ -z "$BUILDDIR" ] || cd "$BUILDDIR"

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH v2 1/2] Revert "Revert "isar-init-build-env: Add /sbin to PATH""

[Jan Kiszka]

On 16.03.22 06:06, Jan Kiszka wrote:
> On 15.03.22 19:40, Anton Mikanovich wrote:
>> Image prepare tools like parted and mkfs.vfat from rpi-sdimg bbclass
>> can't be found in bullseye chroot because /sbin is not exported into
>> PATH by default. Add /sbin manually to fix the issue.
>>
>> This should be reverted after replaced rpi-sdimg.bbclass by WIC.
>>
> 
> Why this ping-pong, why not fixing it directly? Raspios limitations?
> With Debian, it's a no-brainer to use wic for generating Raspi images,
> as done multiple times downstream by now.
> 
> Jan
> 
>> This reverts commit d0bc682ee81da11f4b939165a4d4383af7ed99de.
>>
>> Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
>> ---
>>  isar-init-build-env | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/isar-init-build-env b/isar-init-build-env
>> index 85fb82f..f3d1b6b 100755
>> --- a/isar-init-build-env
>> +++ b/isar-init-build-env
>> @@ -57,4 +57,8 @@ export ISARROOT
>>  }
>>  unset ISARROOT
>>  
>> +# wic executes mkdosfs

And that comment is wrong: wic is not involved, and it would not run
tools from the build environment, only from the buildchroot-target.

Jan

>> +PATH=/sbin:$PATH
>> +export PATH
>> +
>>  [ -z "$BUILDDIR" ] || cd "$BUILDDIR"
> 

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH v2 1/2] Revert "Revert "isar-init-build-env: Add /sbin to PATH""

[Baurzhan Ismagulov]

On Wed, Mar 16, 2022 at 06:06:51AM +0100, Jan Kiszka wrote:
> Why this ping-pong, why not fixing it directly? Raspios limitations?
> With Debian, it's a no-brainer to use wic for generating Raspi images,
> as done multiple times downstream by now.

Yes, this is already in our pipe. I'm open to either; that said, the idea was
to unblock Vijai first, since it's an error in the current implementation with
an obvious fix, and refactor on top. Reimplementation usually requires some
stabilization phase. How do you see this?

With kind regards,
Baurzhan.

Re: [PATCH v2 1/2] Revert "Revert "isar-init-build-env: Add /sbin to PATH""

[Jan Kiszka]

[Re-adding the list that I dropped]

On 16.03.22 12:18, Jan Kiszka wrote:
> On 16.03.22 09:41, Baurzhan Ismagulov wrote:
>> On Wed, Mar 16, 2022 at 06:06:51AM +0100, Jan Kiszka wrote:
>>> Why this ping-pong, why not fixing it directly? Raspios limitations?
>>> With Debian, it's a no-brainer to use wic for generating Raspi images,
>>> as done multiple times downstream by now.
>>
>> Yes, this is already in our pipe. I'm open to either; that said, the idea was
>> to unblock Vijai first, since it's an error in the current implementation with
>> an obvious fix, and refactor on top. Reimplementation usually requires some
>> stabilization phase. How do you see this?
> 
> If we want a quick hack, that should go to the raspi image recipe which
> currently breaks, not this central script.
> 
> Jan
> 

-- 
Siemens AG, Technology
Competence Center Embedded Linux