Re: [PATCH 3/3] CI: Adjust how domU is packaged in dom0

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 28 May 2025, Andrew Cooper wrote:
> 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.

OK


> > Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> 
> Thanks, but do you have any input on the /boot vs /root question on the
> other part of the thread?

I saw it. I don't have a strong opinion either way. Technically /boot is
correct but then things gets mixed up with Dom0 kernel and ramdisk.
/root allows it to be more clearly separated so I am OK with it.