From: Quirin Gylstorff <quirin.gylstorff@...> Adapt the initrd to open a dm-verity partition with a fixed root hash. The initramfs script is based on [1]. [1]:

+kernelci ML as they will appreciate the feedback. Did you not have a "details" link here? In my copy of the email (attached) it links to

From: Quirin Gylstorff <quirin.gylstorff@...> Get patch from isar mailing list[1]. [1]: https://groups.google.com/g/isar-users/c/wlanc7f7UnQ Signed-off-by: Quirin Gylstorff

From: Quirin Gylstorff <quirin.gylstorff@...> Backport the following patches to detect the correct partition to update. 388f1777 util: Add get_root source /proc/self/mountinfo 3914d2b7 util:

From: Quirin Gylstorff <quirin.gylstorff@...> As /etc is read-only and needs to be accessed by the initrd move the user defined settings to a overlay in /var/local/etc. As systemd sets the

From: Quirin Gylstorff <quirin.gylstorff@...> Add support for verity and overlay fs. Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...> ---

From: Quirin Gylstorff <quirin.gylstorff@...> Add an example how to add an writable home partition Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...> ---

From: Quirin Gylstorff <quirin.gylstorff@...> This root file system supports SWUpdate and secure boot. We need a writable /tmp and /var for a boot without error messages. The mount point

From: Quirin Gylstorff <quirin.gylstorff@...> This file system is read only and use a reduced image size. Signed-off-by: Quirin Gylstorff <quirin.gylstorff@...> ---

From: Quirin Gylstorff <quirin.gylstorff@...> As we need the output of `veritysetup` to generate the initrd. Therefore do_verity_image must be called before wic generates the final disk

*This patch series adds support for a read-only squashfs based root filesystem wit SWUpdate support and secureboot. The build is somewhat complex as we need the output of dm-verity to generate the

From: Quirin Gylstorff <quirin.gylstorff@...> Adapt the initrd to open a dm-verity partition with a fixed root hash. The initramfs script is based on [1]. [1]:

Hi! So this has enough information to tell me that we have a kernel problem there, good: 02:08:17.792502 <6>[ 18.847320] omap-mailbox 4a0f4000.mailbox: omap mailbox rev 0x400 02:08:17.800596

Hi! So... I tried to understand this report, and still could not. First problem is actually in the From: line. By placing bot there, it is not clear who is responsible for this, and if someone reads

cip/linux-4.19.y-cip baseline: 121 runs, 1 regressions (v4.19.217-cip62) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig |

cip/linux-4.19.y-cip baseline-nfs: 12 runs, 1 regressions (v4.19.217-cip62) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig |

cip/linux-4.19.y-cip build: 118 builds: 1 failed, 117 passed, 2 errors, 13 warnings (v4.19.217-cip62) Full Build Summary:

Hi ! Thank you for the patch ! Yes, applying code and works properly is different question. however, your patch is LGTM. Regards, -- Masami Ichikawa Cybertrust Japan Co., Ltd. Email

Hi! As far as I can tell, logic is quite simple there and the patch would look like this. Whether the final result works and closes the security hole is different question. Best

hello everyone, following on yesterday topic about difference from cip-cip+1 and lts-lts+1 I just made a diff of what was requested yesterday v4.19.216-cip61 vs v4.19.216 the diff can be viewed on