embedded build for armv7 broken in stable/13

Hi, I am running the following build against the stable/13 source branch:
cd /usr/src
git clone -b stable/12 --depth 1 https://git.freebsd.org/src.git /usr/src
cd release
sh release.sh -c $HOME/BBB.conf


The error I get looks as follows on the command line

Code:
--------------------------------------------------------------
>>> stage 4.4: building everything
--------------------------------------------------------------
===> etc (all)
===> etc/sendmail (all)

...

===> etc (installconfig)
===> etc/sendmail (installconfig)
*** Saving mtree database for future upgrades
a .
a ./libexec
a ./boot

...

a usr/lib/debug/lib/casper/libcap_net.so.1.debug
a usr/lib/debug/lib/casper/libcap_syslog.so.1.debug
mdconfig: failed to load geom_md module: No such file or directory
gpart: Invalid number of arguments.

When I run the exact same build for stable/12 (see SRCBRANCH= in BBB.conf) everything runs fine.

My BBB.conf file looks as follows:

Bash:
#!/bin/sh
#
# $FreeBSD$
#

SRCBRANCH="stable/13"
PORTBRANCH="2021Q4"

EMBEDDED_TARGET_ARCH="armv7"
EMBEDDED_TARGET="arm"
EMBEDDEDBUILD=1
EMBEDDEDPORTS="sysutils/u-boot-beaglebone"
FAT_SIZE="50m -b 1m"
FAT_TYPE="16"
IMAGE_SIZE="3072M"
KERNEL="GENERIC"
MD_ARGS="-x 63 -y 255"
BBB_UBOOT_DIR="/usr/local/share/u-boot/u-boot-beaglebone"
PART_SCHEME="MBR"
export BOARDNAME="GENERICSD"

arm_install_uboot_bbb() {
    FATMOUNT="${DESTDIR%${KERNEL}}/fat"
    chroot ${CHROOTDIR} mkdir -p "${FATMOUNT}"
    chroot ${CHROOTDIR} mount_msdosfs /dev/${mddev}s1 ${FATMOUNT}
    chroot ${CHROOTDIR} cp -p ${BBB_UBOOT_DIR}/MLO ${FATMOUNT}/MLO
    chroot ${CHROOTDIR} cp -p ${BBB_UBOOT_DIR}/u-boot.img ${FATMOUNT}/u-boot.img
    sync
    umount_loop ${CHROOTDIR}/${FATMOUNT}
    chroot ${CHROOTDIR} rmdir ${FATMOUNT}

    return 0
}

arm_install_uboot() {
    arm_install_uboot_bbb
}

What am I missing? ...I am pretty sure that I ran a successful build against stable/13 back in July 2021.
 
Sorry for the noise. It looks like that is a valid setting.
 
let me provide a little bit more information on my system:
Code:
root@bsdbuild:~/ttt # uname -a
FreeBSD bsdbuild 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr  9 04:24:09 UTC 2021     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

root@bsdbuild:~/ttt # ls -lah /boot/kernel/ | grep geom_md
-r-xr-xr-x   1 root  wheel    71K Apr  9  2021 geom_md.ko

root@bsdbuild:~/ttt # kldload geom_md
kldload: can't load geom_md: module already loaded or in kernel

root@bsdbuild:~/ttt # kldload geom_md.ko
kldload: can't load geom_md.ko: module already loaded or in kernel

root@bsdbuild:~/ttt # kldstat
Id Refs Address                Size Name
 1   37 0xffffffff80200000  1f11ef8 kernel
 2    1 0xffffffff82112000   67feb0 zfs.ko
 3    1 0xffffffff82793000     ae38 cryptodev.ko
 4    1 0xffffffff82918000     3218 intpm.ko
 5    1 0xffffffff8291c000     2180 smbus.ko
 6    1 0xffffffff8291f000     2340 uhid.ko
 7    1 0xffffffff82922000     3380 usbhid.ko
 8    1 0xffffffff82926000     31f8 hidbus.ko
 9    1 0xffffffff8292a000     3320 wmt.ko
10    1 0xffffffff8292e000     2a08 mac_ntpd.ko

Eventually, when I try to use mdconfig in the same way as in release.sh, but manually I see no problem:

Code:
root@bsdbuild:~/ttt # truncate -s 3072M abc.img
root@bsdbuild:~/ttt # mdconfig -lv
root@bsdbuild:~/ttt # mdconfig -f abc.img -x 63 -y 255
md0
root@bsdbuild:~/ttt # mdconfig -lv
md0    vnode     3072M    /root/ttt/abc.img    
root@bsdbuild:~/ttt # mdconfig -d -u md0
root@bsdbuild:~/ttt # mdconfig -lv
root@bsdbuild:~/ttt #

...so, can anybody build an arm image with stable/13 right now?
 
geom_md should be statically linked into the kernel
i don't know why mdconfig fails
can you mdconfig -t vnode /some/random/file ?
also build this
Code:
#include <libutil.h>
#include <stdio.h>
int main()
{
printf("%d\n",kld_isloaded("g_md"));
return 0;
}
cc x.c -o x -lutil
./x
 
I saw that too and was wondering.
Is he building 12-stable on 13. I dunno. I spoke too early above so i dummy up.

But we can all see the mdconfig error.

So what about investigating the chroot after it fails.
Also check /dev/md* to see if there are indeed memory disks started.
 
can you mdconfig -t vnode /some/random/file ?

I think I already did that in my last post, but let me do it again, just to be sure...

Code:
root@bsdbuild:~/ttt # truncate -s 3072M xyz.img

root@bsdbuild:~/ttt # mdconfig -t vnode -f xyz.img
md0

root@bsdbuild:~/ttt # mdconfig -lv
md0    vnode     3072M    /root/ttt/xyz.img

Next, let me build the little program...

also build this
Code:
#include <libutil.h>
#include <stdio.h>
int main()
{
printf("%d\n",kld_isloaded("g_md"));
return 0;
}
cc x.c -o x -lutil
./x

Here we go...

Code:
root@bsdbuild:~/ttt # cat x.c
#include <libutil.h>
#include <stdio.h>
int main()
{
printf("%d\n",kld_isloaded("g_md"));
return 0;
}

root@bsdbuild:~/ttt # cc x.c -o x -lutil

root@bsdbuild:~/ttt # ./x
1

Last but not least, let me try to resolve the confusion about stable/12 vs. stable/13... I clone stable/12 into /usr/src but then in $HOME/BBB.conf I specify to check out stable/13 via SRCBRANCH:

Bash:
#!/bin/sh
#
# $FreeBSD$
#

SRCBRANCH="stable/13"
PORTBRANCH="2021Q4"

EMBEDDED_TARGET_ARCH="armv7"
...

The actual build happens in /scratch, which is totally empty when I start my build. As soon as I start my build that will change and I get:
Code:
root@bsdbuild:/scratch/usr/src # git status
On branch stable/13
Your branch is up to date with 'origin/stable/13'.

nothing to commit, working tree clean

Anyway, to make 100% sure there is no mixup, I completely cleaned out /usr/src and checked out stable/13:

Code:
root@bsdbuild:/usr/src # git status
Refresh index: 100% (86921/86921), done.
On branch stable/13
Your branch is up to date with 'origin/stable/13'.

nothing to commit, working tree clean

I also completely cleaned out /scratch and restarted the complete build from /usr/scr/release via the release.sh command as advertised before. The result does not change. I still get the exact same error as before.

...so I am wondering: can anybody reproduce my problem?
 
ok, here is the problem
mdconfig is actually executed by release.sh in chroot /scratch which is a 13-STABLE install
so you run a 13-STABLE mdconfig on 13-RELEASE kernel which might fail because probably this
Diff:
sys/sys/module.h
- #define       MAXMODNAME      32
+ #define       MAXMODNAMEV1V2  32
+ #define       MAXMODNAMEV3    MAXPATHLEN
+ #define       MAXMODNAME      MAXMODNAMEV3

you can hack release.sh to use a static mdconfig (from /rescue on host) which you need to copy under the chroot tree before it is used
 
Success! Thanks!

As suggested by covacat, I made the following tweak to release.sh

Diff:
diff --git a/release/release.sh b/release/release.sh
index 75278a12d..da2ea8adc 100755
--- a/release/release.sh
+++ b/release/release.sh
@@ -385,6 +385,7 @@ chroot_arm_build_release() {
        export MAKE_FLAGS="${MAKE_FLAGS} TARGET_ARCH=${EMBEDDED_TARGET_ARCH}"
        export MAKE_FLAGS="${MAKE_FLAGS} ${CONF_FILES}"
        eval chroot ${CHROOTDIR} env WITH_UNIFIED_OBJDIR=1 make ${MAKE_FLAGS} -C /usr/src/release obj
+       eval chroot ${CHROOTDIR} env WITH_UNIFIED_OBJDIR=1 make ${MAKE_FLAGS} -C /usr/src/release base.txz
        export WORLDDIR="$(eval chroot ${CHROOTDIR} make ${MAKE_FLAGS} -C /usr/src/release -V WORLDDIR)"
        export OBJDIR="$(eval chroot ${CHROOTDIR} env WITH_UNIFIED_OBJDIR=1 make ${MAKE_FLAGS} -C /usr/src/release -V .OBJDIR)"
        export DESTDIR="${OBJDIR}/${KERNEL}"
@@ -394,6 +395,9 @@ chroot_arm_build_release() {
                -V OSRELEASE)"
        chroot ${CHROOTDIR} mkdir -p ${DESTDIR}
        chroot ${CHROOTDIR} truncate -s ${IMAGE_SIZE} ${IMGBASE##${CHROOTDIR}}
+
+       cp /rescue/mdconfig ${CHROOTDIR}/sbin/mdconfig
+
        export mddev=$(chroot ${CHROOTDIR} \
                mdconfig -f ${IMGBASE##${CHROOTDIR}} ${MD_ARGS})
        arm_create_disk

(nevermind the first change because of base.txz - that is something I need for a different purpose)
 
oh... BTW: I'd like to submit a bug ticket for the issue, but I am not sure about what against to issue that bug ticket? The change in sys/sys/module.h doesn't seem wrong. Still it breaks something in a different place.


Anybody, any suggestions?
 
well if there is a 'bug' it's in release.sh
it's not ok-ish to run user-land binaries with a mismatched kernel especially those that rely on kernel structures

so release.sh should warn or use as many running kernel binaries as possible or error out if it's not possible
in your case the existence of a prebuilt static version of mdconfig simplified the workaround
 
Back
Top