On 14/04/2025 5:57 pm, Anthony PERARD wrote: > On Mon, Apr 14, 2025 at 12:08:59PM +0100, Andrew Cooper wrote: >> From: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com> >> >> Use the new test-artifacts which provide rootfs.cpio.gz rather than >> initrd.tar.gz. rootfs.cpio.gz also has all the necessary top-level >> directories, and includes the rc_verbose setting, so these modifications can >> be dropped. >> >> Having that, do not repack the whole initrd, but only pack modified >> files and rely on Linux handling of concatenated archives. >> This allows packing just test-related files (which includes the whole >> toolstack), instead of the whole initrd. >> >> For xilinx-smoke-dom0-x86_64.sh, this involves instructing grub not to unzip >> the archive, as doing so corrupts it. >> >> Signed-off-by: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > This patch seems to depends on the other patch series for > "test-artifacts" repo.
Yes, there's a large interlink, although the other series is fully committed now. > > I've tried to compare the rootfs fs generated by this repo, and the one > generated in the "test-artifacts" repo, and I think there's a few > changes, at least for the arm64 rootfs as the changes have probably > already sailed for x86_64, namely: > > Those don't exist in the new rootfs: > rc-update add networking sysinit > rc-update add modloop sysinit > rc-update add modules boot > rc-update add sysctl boot > There's `echo > /etc/modules` been added. > > But I guess none of those matter, as it already works on x86_64 tests. Those changes are discussed in the other series, in the relevant patches. modules is deliberately removed; we don't build them (properly), and the scan on boot puts errors onto the console. Emptying /etc/modules is to remove af_packet and ipv6, again because we don't have those as modules (we build ipv6 in). Modloop seems to be scanning other devices for filesystems. networking depends on sysctl, but I can't see any of them being used, and the arm64 tests work fine without them > > Overall, looks good, more common code between tests! Indeed. We can always put them back in if they turn out to be needed. > Reviewed-by: Anthony PERARD <anthony.per...@vates.tech> Thanks. ~Andrew