On 28/05/2025 1:30 am, Stefano Stabellini wrote: > On Thu, 22 May 2025, Andrew Cooper wrote: >> diff --git a/automation/scripts/qubes-x86-64.sh >> b/automation/scripts/qubes-x86-64.sh >> index 1dd3f48b3d29..17a37134f46a 100755 >> --- a/automation/scripts/qubes-x86-64.sh >> +++ b/automation/scripts/qubes-x86-64.sh >> @@ -185,12 +185,24 @@ Kernel \r on an \m (\l) >> find . | cpio -H newc -o | gzip >> ../binaries/domU-rootfs.cpio.gz >> cd .. >> rm -rf rootfs >> + >> + # Package domU kernel+rootfs in /root for dom0 (uncompressed) >> + mkdir -p rootfs/root >> + cd rootfs >> + cp ../binaries/bzImage root/vmlinuz-domU >> + cp ../binaries/domU-rootfs.cpio.gz root/initrd-domU >> + find . | cpio -H newc -o > ../binaries/domU-in-dom0.cpio >> + cd .. >> + rm -rf rootfs >> fi >> >> # Dom0 rootfs. The order or concatination is important; ucode wants to come >> # first, and all uncompressed must be ahead of compressed. >> parts=( >> binaries/ucode.cpio >> +) >> +[ -n "$domU_check" ] && parts+=(binaries/domU-in-dom0.cpio) > This is a NIT but I have been trying to avoid this format in favor of > > if [ -n "$domU_check" ] > then > parts+=(binaries/domU-in-dom0.cpio) > fi > > for readibility.
This is a weird one, because the (relevant) readability is the components of parts, and it's easier to scan without the extra blank lines. Nevertheless, ... > > > I can see the patch is correct. It adds a bit of complexity in exchange > for a small improvement. I am not sure if the trade off is worth it, but > I'll ack it anyway. ... see the thread on the previous patch. This was the RFC "I'd like to find a nicer way of doing it", and Anthony has made a suggestion which I need to experiment with. > Reviewed-by: Stefano Stabellini <sstabell...@kernel.org> Thanks, but do you have any input on the /boot vs /root question on the other part of the thread? ~Andrew
