Hi Jan,
>> Your dump is missing the verityroot container. Does lsblk no longer list it by default, or were/are there inconsistencies what was >>configured vs.
>>what was run?
>I also noticed this missing verityroot container in the image. I confirmed the secure boot is enabled from the boot as well as dmesg logs. >However, the "lsblk" command does not show the verityroot by default.
>Probably we may have to install "systemd-cryptsetup" for non-security image as well, see the fix for security image here[1].
>This package is available from trixie onwards.
>[1] https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commit/36b11192674082aaa1228c60e8c0239fa7c94111
Any comments on this update?
Thanks & Regards
Shivanand K
-----Original Message-----
From: kunijadar shivanand(ＴＳＩＰ DITC_DIT-OST)
Sent: 22 June 2026 11:46
To: 'Jan Kiszka' <[email protected]>; [email protected]
Cc: balakumar adithya(ＴＳＩＰ ＤＩＴＣ＿ＤＩＴ-ＯＳＴ) <[email protected]>; dinesh kumar(ＴＳＩＰ DITC_DIT-OST) <[email protected]>; hayashi kazuhiro(林 和宏 □ＤＩＴＣ○ＣＰＴ) <[email protected]>
Subject: RE: [isar-cip-core][PATCH] Revise README files to reflect the latest changes
Hi Jan,
Thanks for the comments,
> Do we really want to hard-code the release here and below? We are always testing the default one, and that is trixie right now.
I understand it is not mandatory. I just kept to sync the build and run commands as in run command we specifically mention DISTRO_RELEASE=trixie. I will remove this in v2 patch.
Regarding the inconsistence format for run command, will update to make it consistent in v2.
> Your dump is missing the verityroot container. Does lsblk no longer list it by default, or were/are there inconsistencies what was >configured vs.
>what was run?
I also noticed this missing verityroot container in the image. I confirmed the secure boot is enabled from the boot as well as dmesg logs. However, the "lsblk" command does not show the verityroot by default.
Probably we may have to install "systemd-cryptsetup" for non-security image as well, see the fix for security image here[1].
This package is available from trixie onwards.
[1] https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commit/36b11192674082aaa1228c60e8c0239fa7c94111
Thanks & Regards
Shivanand K
-----Original Message-----
From: Jan Kiszka <[email protected]>
Sent: 21 June 2026 14:17
To: kunijadar shivanand(ＴＳＩＰ DITC_DIT-OST) <[email protected]>; [email protected]
Cc: balakumar adithya(ＴＳＩＰ ＤＩＴＣ＿ＤＩＴ-ＯＳＴ) <[email protected]>; dinesh kumar(ＴＳＩＰ DITC_DIT-OST) <[email protected]>; hayashi kazuhiro(林 和宏 □ＤＩＴＣ○ＣＰＴ) <[email protected]>
Subject: Re: [isar-cip-core][PATCH] Revise README files to reflect the latest changes
On 19.06.26 12:56, Shivanand Kunijadar wrote:
> The SWUpdate & Secure boot readme files are outdated, adjust these
> files to reflect the current changes and debian version based on the
> master branch.
>
> Signed-off-by: Shivanand Kunijadar
> <[email protected]>
> ---
> doc/README.secureboot.md | 63 +++++++++++++--------------
> doc/README.swupdate.md | 92 ++++++++++++++++++++--------------------
> 2 files changed, 75 insertions(+), 80 deletions(-)
>
> diff --git a/doc/README.secureboot.md b/doc/README.secureboot.md index
> 8ab67a8..5ac8611 100644
> --- a/doc/README.secureboot.md
> +++ b/doc/README.secureboot.md
> @@ -48,7 +48,7 @@ Supply the script name and path to wic by adding
> #### secure-boot-snakeoil
>
> This package uses the snakeoil key and certificate from the ovmf
> package from -Debian bullseye or later for signing the image.
> +Debian trixie or later for signing the image.
>
> #### secure-boot-key
>
> @@ -66,10 +66,10 @@ Set up a secure boot test environment with
> [QEMU](https://www.qemu.org/)
>
> ### Prerequisites
>
> -- OVMF from edk2 release edk2-stable201911 or newer
> - - This documentation was tested under Debian 11 with OVMF
> (2020.11-2+deb11u1) from Debian bullseye
> +- OVMF from edk2 release 2025.02-8+deb13u1 or newer
> + - This documentation was tested under Debian 13 with OVMF
> +(2025.02-8+deb13u1) from Debian trixie
> - efitools for KeyTool.efi
> - - This documentation was tested under Debian 11 with efitools
> (1.9.2-2~deb11u1) from Debian bullseye
> + - This documentation was tested under Debian 13 with efitools
> + (1.9.2-3.5) from Debian trixie
> - libnss3-tools
>
> ### Debian Snakeoil keys
> @@ -144,7 +144,7 @@ Build the image with a signed EFI Boot Guard and
> unified kernel image with the snakeoil keys by executing:
>
> ```bash
> -kas-container build
> kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/ebg-secure-boot-snakeoil.
> yml
> +./kas-container build
> +kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/trixie.yml:kas/opt/ebg-s
> +ecure-boot-snakeoil.yml
> ```
Do we really want to hard-code the release here and below? We are always testing the default one, and that is trixie right now.
>
> For user-generated keys, create a new option file in the repository. This option file could look like this:
> @@ -186,7 +186,7 @@ need to stored in the folder `recipes-devtools/secure-boot-secrets/files`.
> Build the image with user-generated keys by executing the command:
>
> ```bash
> -kas-container build kas-cip.yml:kas/board/qemu-amd64.yml:<path to the
> new option>.yml
> +./kas-container build
> +kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/trixie.yml:<path to the
> +new option>.yml
> ```
>
> ### Start the image
> @@ -196,7 +196,7 @@ kas-container build
> kas-cip.yml:kas/board/qemu-amd64.yml:<path to the new option Start the image with the following command:
>
> ```bash
> -SECURE_BOOT=y \
> +DISTRO_RELEASE=trixie SECURE_BOOT=y \
Ok, in the absence of a .config.yaml, we do need these explicit assignments. But you use an inconsistent format, here vs. below.
> ./start-qemu.sh amd64
> ```
>
> @@ -211,6 +211,7 @@ and the following command is sufficient:
> Start the image with the following command:
>
> ```bash
> +DISTRO_RELEASE=trixie \
> SECURE_BOOT=y \
>
> OVMF_CODE=./build/tmp/deploy/images/qemu-amd64/OVMF/OVMF_CODE_4M.secbo
> ot.fd \ OVMF_VARS=<path to the modified OVMF_VARS.fd> \ @@ -233,45 +234,43 @@ EFI stub: UEFI Secure Boot is enabled.
>
> For updating the image, the following steps are necessary:
> - [Build the image with snakeoil keys](#build-image)
> -- save the generated swu
> `build/tmp/deploy/images/qemu-amd64/cip-core-image-cip-core-bullseye-q
> emu-amd64.swu` to /tmp
> +- save the generated swu
> +`build/tmp/deploy/images/qemu-amd64/cip-core-image-cip-core-trixie-qe
> +mu-amd64.swu` to /tmp
> - modify the image for example, switch to the RT kernel as modification:
>
> ```bash
> -kas-container build
> kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/ebg-secure-boot-snakeoil.
> yml:kas/opt/rt.yml
> +./kas-container build
> +kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/trixie.yml:kas/opt/ebg-s
> +ecure-boot-snakeoil.yml:kas/opt/rt.yml
> ```
>
> - start the new target
>
> ```bash
> -SECURE_BOOT=y ./start-qemu.sh amd64
> +DISTRO_RELEASE=trixie SECURE_BOOT=y ./start-qemu.sh amd64
Yet another way of formatting this line.
> ```
>
> -Copy the swu cip-core-image-cip-core-bullseye-qemu-amd64.swu to the
> running system
> +Copy the swu cip-core-image-cip-core-trixie-qemu-amd64.swu to the
> +running system
>
> ```bash
> -scp -P 22222 /tmp/cip-core-image-cip-core-bullseye-qemu-amd64.swu
> [email protected]:/home/
> +scp -P 22222 /tmp/cip-core-image-cip-core-trixie-qemu-amd64.swu
> [email protected]:/
> ```
>
> - check which partition is booted, e.g. with `lsblk`:
>
> ```bash
> root@demo:~# lsblk
> -NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> -sda 8:0 0 6G 0 disk
> -├─sda1 8:1 0 16.1M 0 part
> -├─sda2 8:2 0 32M 0 part
> -├─sda3 8:3 0 32M 0 part
> -├─sda4 8:4 0 1G 0 part
> -│ └─verityroot 252:0 0 110.9M 1 crypt /
> -├─sda5 8:5 0 1G 0 part
> -├─sda6 8:6 0 1.3G 0 part /home
> -└─sda7 8:7 0 2.6G 0 part /var
> +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> +sda 8:0 0 2.8G 0 disk
> +├─sda1 8:1 0 20.8M 0 part /boot
> +├─sda2 8:2 0 128M 0 part
> +├─sda3 8:3 0 128M 0 part
> +├─sda4 8:4 0 1G 0 part
> +├─sda5 8:5 0 1G 0 part
> +└─sda6 8:6 0 512M 0 part /var
> ```
Your dump is missing the verityroot container. Does lsblk no longer list it by default, or were/are there inconsistencies what was configured vs.
what was run?
>
> - install the swupdate and reboot the image
>
> ```bash
> -root@demo:~# swupdate -i
> /home/cip-core-image-cip-core-bullseye-qemu-amd64.swu`
> +root@demo:~# swupdate -i
> +cip-core-image-cip-core-trixie-qemu-amd64.swu
> root@demo:~# reboot
> ```
>
> @@ -279,16 +278,14 @@ root@demo:~# reboot
>
> ```bash
> root@demo:~# lsblk
> -NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> -sda 8:0 0 6G 0 disk
> -├─sda1 8:1 0 16.1M 0 part
> -├─sda2 8:2 0 32M 0 part
> -├─sda3 8:3 0 32M 0 part
> -├─sda4 8:4 0 1G 0 part
> -├─sda5 8:5 0 1G 0 part
> -│ └─verityroot 252:0 0 110.9M 1 crypt /
> -├─sda6 8:6 0 1.3G 0 part /home
> -└─sda7 8:7 0 2.6G 0 part /var
> +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> +sda 8:0 0 2.8G 0 disk
> +├─sda1 8:1 0 20.8M 0 part /boot
> +├─sda2 8:2 0 128M 0 part
> +├─sda3 8:3 0 128M 0 part
> +├─sda4 8:4 0 1G 0 part
> +├─sda5 8:5 0 1G 0 part
> +└─sda6 8:6 0 512M 0 part /var
> ```
>
> ## Secure boot on Generic UEFI x86
> diff --git a/doc/README.swupdate.md b/doc/README.swupdate.md index
> affb85b..10ce1cc 100644
> --- a/doc/README.swupdate.md
> +++ b/doc/README.swupdate.md
> @@ -190,23 +190,23 @@ write it to `/etc/hwrevision`.
> Set up `kas-container` as described in the [top-level README](../README.md).
> Then build the image which will later serve as update package:
> ```
> -host$ ./kas-container build
> kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/ebg-swu.yml
> +host$ ./kas-container build
> +kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/trixie.yml:kas/opt/ebg-s
> +wu.yml
> ```
> -Save the generated swu `build/tmp/deploy/images/qemu-amd64/cip-core-image-cip-core-bullseye-qemu-amd64.swu` into a separate folder (ex: /tmp).
> +Save the generated swu `build/tmp/deploy/images/qemu-amd64/cip-core-image-cip-core-trixie-qemu-amd64.swu` into a separate folder (ex: /tmp).
>
> Next, rebuild the image, switching to the RT kernel as modification:
> ```
> -host$ ./kas-container build
> kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/ebg-swu.yml:kas/opt/rt.ym
> l
> +host$ ./kas-container build
> +kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/trixie.yml:kas/opt/ebg-s
> +wu.yml:kas/opt/rt.yml
> ```
>
> Now start the image which will contain the RT kernel:
> ```
> -host$ SWUPDATE_BOOT=y ./start-qemu.sh amd64
> +host$ DISTRO_RELEASE=trixie SWUPDATE_BOOT=true ./start-qemu.sh amd64
> ```
>
> -Copy `cip-core-image-cip-core-bullseye-qemu-amd64.swu` file from `tmp` folder into the running system:
> +Copy `cip-core-image-cip-core-trixie-qemu-amd64.swu` file from `tmp` folder into the running system:
> ```
> -host$ scp -P 22222 /tmp/cip-core-image-cip-core-bullseye-qemu-amd64.swu root@localhost:
> +host$ scp -P 22222 /tmp/cip-core-image-cip-core-trixie-qemu-amd64.swu root@localhost:
> ```
>
> ## SWUpdate verification
> @@ -214,28 +214,27 @@ host$ scp -P 22222
> /tmp/cip-core-image-cip-core-bullseye-qemu-amd64.swu root@loc Check which partition is booted, e.g. with lsblk:
> ```
> root@demo:~# lsblk
> -NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> -sda 8:0 0 6G 0 disk
> -├─sda1 8:1 0 16.1M 0 part
> -├─sda2 8:2 0 32M 0 part
> -├─sda3 8:3 0 32M 0 part
> +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> +sda 8:0 0 2.8G 0 disk
> +├─sda1 8:1 0 16M 0 part /boot
> +├─sda2 8:2 0 128M 0 part
> +├─sda3 8:3 0 128M 0 part
> ├─sda4 8:4 0 1G 0 part /
> ├─sda5 8:5 0 1G 0 part
> -├─sda6 8:6 0 1.3G 0 part /home
> -└─sda7 8:7 0 2.6G 0 part /var
> +└─sda6 8:6 0 512M 0 part /var
> ```
>
> -Also check that you are running the RT kernel:
> +Also check that you are running the RT kernel (i.e PREEMPT_RT):
> ```
> root@demo:~# uname -a
> -Linux demo 4.19.233-cip69-rt24 #1 SMP PREEMPT RT Tue Apr 12 09:23:51
> UTC 2022 x86_64 GNU/Linux
> +Linux demo 6.12.85-cip22 #1 SMP PREEMPT_RT Thu, 01 Jan 1970 06:30:00
> ++0530 x86_64 GNU/Linux
> root@demo:~# ls /lib/modules
> -4.19.233-cip69-rt24
> +6.12.85-cip22
> ```
>
> Now apply swupdate and reboot
> ```
> -root@demo:~# swupdate -i
> cip-core-image-cip-core-bullseye-qemu-amd64.swu
> +root@demo:~# swupdate -i
> +cip-core-image-cip-core-trixie-qemu-amd64.swu
> root@demo:~# reboot
> ```
> Use the `-v` flag when running swupdate for verbose logs of any errors.
> @@ -243,23 +242,22 @@ Use the `-v` flag when running swupdate for verbose logs of any errors.
> Check which partition is booted, e.g. with lsblk and the rootfs
> should have changed ``` root@demo:~# lsblk
> -NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> -sda 8:0 0 6G 0 disk
> -├─sda1 8:1 0 16.1M 0 part
> -├─sda2 8:2 0 32M 0 part
> -├─sda3 8:3 0 32M 0 part
> +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> +sda 8:0 0 2.8G 0 disk
> +├─sda1 8:1 0 16M 0 part /boot
> +├─sda2 8:2 0 128M 0 part
> +├─sda3 8:3 0 128M 0 part
> ├─sda4 8:4 0 1G 0 part
> ├─sda5 8:5 0 1G 0 part /
> -├─sda6 8:6 0 1.3G 0 part /home
> -└─sda7 8:7 0 2.6G 0 part /var
> +└─sda6 8:6 0 512M 0 part /var
> ```
>
> Check the active kernel:
> ```
> root@demo:~# uname -a
> -Linux demo 4.19.235-cip70 #1 SMP Tue Apr 12 09:08:39 UTC 2022 x86_64
> GNU/Linux
> +Linux demo 6.12.85-cip22 #1 SMP PREEMPT_DYNAMIC Thu, 01 Jan 1970
> +06:30:00 +0530 x86_64 GNU/Linux
> root@demo:~# ls /lib/modules
> -4.19.235-cip70
> +6.12.85-cip22
> ```
>
> Check bootloader ustate after swupdate
> @@ -272,7 +270,7 @@ in_progress: no
> revision: 2
> kernel: C:BOOT0:linux.efi
> kernelargs:
> -watchdog timeout: 60 seconds
> +watchdog timeout: 120 seconds
> ustate: 0 (OK)
>
> user variables:
> @@ -285,7 +283,7 @@ in_progress: no
> revision: 3
> kernel: C:BOOT1:linux.efi
> kernelargs:
> -watchdog timeout: 60 seconds
> +watchdog timeout: 120 seconds
> ustate: 2 (TESTING)
>
> user variables:
> @@ -303,27 +301,27 @@ root@demo:~# bg_setenv -c Build the image for
> swupdate with a service which causes kernel panic during system boot using below command:
>
> ```
> -host$ ./kas-container build
> kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/ebg-swu.yml:kas/opt/kerne
> l-panic.yml
> +host$ ./kas-container build
> +kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/trixie.yml:kas/opt/ebg-s
> +wu.yml:kas/opt/kernel-panic.yml
> ```
> -Save the generated swu `build/tmp/deploy/images/qemu-amd64/cip-core-image-cip-core-bullseye-qemu-amd64.swu` in a separate folder.
> +Save the generated swu `build/tmp/deploy/images/qemu-amd64/cip-core-image-cip-core-trixie-qemu-amd64.swu` in a separate folder.
> Then build the image without `kernel-panic.yml` recipe using below command:
> ```
> -host$ ./kas-container build
> kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/ebg-swu.yml
> +host$ ./kas-container build
> +kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/trixie.yml:kas/opt/ebg-s
> +wu.yml
> ```
>
> Start the target on QEMU:
> ```
> -host$ SWUPDATE_BOOT=y ./start-qemu.sh amd64
> +host$ DISTRO_RELEASE=trixie SWUPDATE_BOOT=y ./start-qemu.sh amd64
> ```
>
> -Copy `cip-core-image-cip-core-bullseye-qemu-amd64.swu` file from `tmp` folder into the running system:
> +Copy `cip-core-image-cip-core-trixie-qemu-amd64.swu` file from `tmp` folder into the running system:
> ```
> -host$ scp -P 22222 /tmp/cip-core-image-cip-core-bullseye-qemu-amd64.swu root@localhost:
> +host$ scp -P 22222 /tmp/cip-core-image-cip-core-trixie-qemu-amd64.swu root@localhost:
> ```
>
> Apply swupdate as below:
> ```
> -root@demo:~# swupdate -i
> cip-core-image-cip-core-bullseye-qemu-amd64.swu
> +root@demo:~# swupdate -i
> +cip-core-image-cip-core-trixie-qemu-amd64.swu
> ```
>
> Check bootloader ustate after swupdate. If the swupdate is successful then **revision number** should be **3** and status should be changed to **INSTALLED** for Partition #1.
> @@ -336,7 +334,7 @@ in_progress: no
> revision: 2
> kernel: C:BOOT0:linux.efi
> kernelargs:
> -watchdog timeout: 60 seconds
> +watchdog timeout: 120 seconds
> ustate: 0 (OK)
>
> user variables:
> @@ -349,7 +347,7 @@ in_progress: no
> revision: 3
> kernel: C:BOOT1:linux.efi
> kernelargs:
> -watchdog timeout: 60 seconds
> +watchdog timeout: 120 seconds
> ustate: 1 (INSTALLED)
>
> user variables:
> @@ -377,7 +375,7 @@ in_progress: no
> revision: 2
> kernel: C:BOOT0:linux.efi
> kernelargs:
> -watchdog timeout: 60 seconds
> +watchdog timeout: 120 seconds
> ustate: 0 (OK)
>
> user variables:
> @@ -390,7 +388,7 @@ in_progress: no
> revision: 0
> kernel: C:BOOT1:linux.efi
> kernelargs:
> -watchdog timeout: 60 seconds
> +watchdog timeout: 120 seconds
> ustate: 3 (FAILED)
>
> user variables:
> @@ -419,21 +417,21 @@ The build system looks for the reference
> artifact in a directory named `previous Copy the reference artifacts to the mentioned directory with the following commands:
> ```
> mkdir -p build-v2/previous-image
> -cp
> build/tmp/deploy/images/qemu-amd64/cip-core-image-cip-core-bookworm-qe
> mu-amd64.squashfs build-v2/previous-image
> +cp
> +build/tmp/deploy/images/qemu-amd64/cip-core-image-cip-core-trixie-qem
> +u-amd64.squashfs build-v2/previous-image
> cp build/tmp/deploy/images/qemu-amd64/linux.efi
> build-v2/previous-image ``` Build the second image with `build-v2`
> as the build directory with the following command:
> ```
> -KAS_BUILD_DIR=build-v2 ./kas-container build
> kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/ebg-swu.yml:kas/opt/delta
> -update.yml
> +KAS_BUILD_DIR=build-v2 ./kas-container build
> +kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/trixie.yml:kas/opt/ebg-s
> +wu.yml:kas/opt/delta-update.yml
> ```
> Now start the first image. Run the following commands:
> ```
> -host$ DISTRO_RELEASE=bookworm SWUPDATE_BOOT=y ./start-qemu.sh amd64
> +host$ DISTRO_RELEASE=trixie SWUPDATE_BOOT=y ./start-qemu.sh amd64
> ```
> -Copy `cip-core-image-cip-core-bookworm-qemu-amd64.swu` file from `build-v2/tmp/deploy/images/qemu-amd64/` folder into the running system:
> +Copy `cip-core-image-cip-core-trixie-qemu-amd64.swu` file from `build-v2/tmp/deploy/images/qemu-amd64/` folder into the running system:
> ```
> host$ cd build-v2/tmp/deploy/images/qemu-amd64/
> -host$ scp -P 22222 ./cip-core-image-cip-core-bookworm-qemu-amd64.swu root@localhost:
> +host$ scp -P 22222 ./cip-core-image-cip-core-trixie-qemu-amd64.swu root@localhost:
> ```
>
> ## Delta Software Update using zchunk handler @@ -520,7 +518,7 @@
> Next, rebuild the image using the Kconfig menu, switching to the RT
> kernel as mo
>
> Now start the image which will contain the RT kernel:
> ```
> -host$ SWUPDATE_BOOT=y ./start-qemu.sh amd64
> +host$ DISTRO_RELEASE=trixie SWUPDATE_BOOT=y ./start-qemu.sh amd64
> ```
>
> By default, SWUpdate uses the machine-id from `/etc/machine-id` as the `client-id` (configurable via `WFX_DEVICE_ID` in the `swupdate-config-wfx` recipe). This `client-id` is later used to create `wfx` job for the client:
> @@ -604,14 +602,14 @@ Follow the steps mentioned in the section
> [Building and testing the CIP Core ima
>
> Flash the BeagleBone Black RT kernel image into SDcard ``` -host$ dd
> if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-bullseye-bbb.wi
> c \
> +host$ dd
> +if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-trixie-bbb.wic
> +\
> of=/dev/<medium-device> bs=1M status=progress ```
>
> After flashing the BBB RT kernel image into SD card, mount the SD card on host PC and copy .swu file from `tmp` folder to root partition like below.
>
> ```
> -host$ sudo cp tmp/cip-core-image-cip-core-bullseye-bbb.swu
> /<mnt>/home/root/
> +host$ sudo cp tmp/cip-core-image-cip-core-trixie-bbb.swu /<mnt>/root/
> ```
>
> Connect a serial port cable between host PC and BBB.
Thanks for taking care of this "minor" but then highly confusing details!
Jan
--
Siemens AG, Foundational Technologies
Linux Expert Center
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.