Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv
Date: Thu, 14 Jul 2022 16:21:00 UTC
On 2022-Jul-14, at 08:21, Glen Barber <gjb@freebsd.org> wrote:
> On Thu, Jul 14, 2022 at 08:10:12AM -0700, Mark Millard wrote:
> [... snip ...]
>
>> But it does not appear that modern /usr/src/release/ by itself
>> would produce the inefficient alignments unless the mdconfig
>> and gpart combination used did something odd overall that
>> did not happen in my example sequence.
>>
>> Here, I'm just using the mismatch to indicate that the snapshot
>> and release builds do not seem to match what /usr/src/release/
>> is set up to do. I've not managed to reproduce the alignment
>> that the snapshot and release .img files have in them by
>> following the /usr/src/release steps for the example Small
>> Board Computer that I'm using to illustrate the issue.
>>
>> It suggests something odd is going on for the official image
>> builds that makes the difference. What, I've no clue.
>>
>
> I do not know either, but I have been looking into it. All of the
> userland utilities (mkimg, makefs, etc) that are used are used *within*
> the build chroot, so I see no sign of any "leakage" from the build host
> itself creeping into the process.
mkimg (via mkisoimages.sh) does not apply to the likes of RPI.conf
or the other SBCs: disc1, dvd, and bootonly are not involved but
are what use mkisoimages.sh . A similar point goes for use via
make-memstick.sh : not involved for SBC contexts list RPI.conf .
The same goes for makefs : it is only used via mkisoimages.sh
and make-memstick.sh --which are not involved.
/usr/main-src/release/release.sh has:
/usr/main-src/release/release.sh:chroot_arm_build_release() {
that has the code:
export mddev=$(chroot ${CHROOTDIR} \
mdconfig -f ${IMGBASE##${CHROOTDIR}} ${MD_ARGS})
arm_create_disk
arm_install_base
arm_install_boot
arm_install_uboot
mdconfig -d -u ${mddev}
and /usr/main-src/release/tools/arm.subr has:
arm_create_disk() {
# Create the target raw file and temporary work directory.
chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
if [ "${PART_SCHEME}" = "GPT" ]; then
chroot ${CHROOTDIR} gpart add -t efi -l efi -a 512k -s ${FAT_SIZE} ${mddev}
chroot ${CHROOTDIR} newfs_msdos -L efi -F ${FAT_TYPE} /dev/${mddev}p1
chroot ${CHROOTDIR} gpart add -t freebsd-ufs -l rootfs -a 64k ${mddev}
chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}p2
fi
if [ "${PART_SCHEME}" = "MBR" ]; then
chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZE} ${mddev}
chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev}
chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE} /dev/${mddev}s1
chroot ${CHROOTDIR} gpart add -t freebsd ${mddev}
chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2
chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k ${mddev}s2
chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
fi
return 0
}
Out of that, only mdconfig and gpart contribute to the alignment
that I've been referencing. newfs_msdos and newfs work just
within what they are given, not changing the gpart results,
so far as I know.
Investigating the mdconfig result in the jail by adding some
output might help. Something like adding gpart show's after
the gpart create and each gpart add could confirm some of
the staging for the SBC images:
arm_create_disk() {
# Create the target raw file and temporary work directory.
chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
gpart show ${mddev}
if [ "${PART_SCHEME}" = "GPT" ]; then
chroot ${CHROOTDIR} gpart add -t efi -l efi -a 512k -s ${FAT_SIZE} ${mddev}
gpart show ${mddev}
chroot ${CHROOTDIR} newfs_msdos -L efi -F ${FAT_TYPE} /dev/${mddev}p1
chroot ${CHROOTDIR} gpart add -t freebsd-ufs -l rootfs -a 64k ${mddev}
gpart show ${mddev}
chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}p2
fi
if [ "${PART_SCHEME}" = "MBR" ]; then
chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZE} ${mddev}
gpart show ${mddev}
chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev}
chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE} /dev/${mddev}s1
chroot ${CHROOTDIR} gpart add -t freebsd ${mddev}
gpart show ${mddev}
chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2
chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k ${mddev}s2
gpart show ${mddev}
chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
fi
return 0
}
Manual execution of just the commands in question in an
interactive instance of the jail could be an alternative
(if that makes sense).
> Additionally, I double-checked (and triple-checked) the configuration
> files used for these builds, and there are no stale artifacts of
> overriding IMAGE_SIZE or any other variables - everything sources the
> in-tree ${srcdir}/release/${TARGET}/${TARGET_ARCH}.conf (i.e.,
> release/riscv/riscv64.conf, for example).
Again, for what I'm reporting, the:
${srcdir}/release/${TARGET}/${TARGET_ARCH}.conf
are not involved. The following are involved:
# ls -C1 /usr/main-src/release/[a-r]*/[A-Z]*.conf
/usr/main-src/release/arm/GENERICSD.conf
/usr/main-src/release/arm/RPI-B.conf
/usr/main-src/release/arm64/PINE64-LTS.conf
/usr/main-src/release/arm64/PINE64.conf
/usr/main-src/release/arm64/PINEBOOK.conf
/usr/main-src/release/arm64/ROCK64.conf
/usr/main-src/release/arm64/ROCKPRO64.conf
/usr/main-src/release/arm64/RPI.conf
/usr/main-src/release/riscv/GENERICSD.conf
I've been using RPI.conf's context as the example.
> That said, there have been a few updates to PR 264032 overnight that has
> lead to some head-scratching.
>
> By the way, thank you for poking into this in the depth that you had.
> It is very much appreciated.
===
Mark Millard
marklmi at yahoo.com