# embedded build for armv7 broken in stable/13



## Andreas Strauch (Jan 20, 2022)

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


```
--------------------------------------------------------------
>>> 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:


```
#!/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.


----------



## Phishfry (Jan 20, 2022)

Andreas Strauch said:


> mdconfig: failed to load geom_md module: No such file or directory


Have you tried to manually load the module for testing?
aka test mdconfig on an image or something to make sure it is working.


Andreas Strauch said:


> MD_ARGS="-x 63 -y 255"


What is this???


----------



## Phishfry (Jan 20, 2022)

Sorry for the noise. It looks like that is a valid setting.








						Release build fails to install devel/swig
					

I'm trying to build an image using the release building infrastructure as a reference guide. I understand that the process is slightly different for 13.0, so I make adjustments where needed.  Specifically I'm wanting to build a 13.0-RELENG image for the Pine book Pro with...




					forums.freebsd.org


----------



## Andreas Strauch (Jan 21, 2022)

let me provide a little bit more information on my system:

```
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:


```
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?


----------



## covacat (Jan 21, 2022)

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 

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


----------



## Jose (Jan 21, 2022)

Does not compute.


Andreas Strauch said:


> Hi, I am running the following build against the stable/13 source branch:
> `git clone -b stable/12...`


----------



## Phishfry (Jan 21, 2022)

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.


----------



## Andreas Strauch (Jan 21, 2022)

covacat said:


> 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...


```
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...



covacat said:


> also build this
> 
> ```
> #include <libutil.h>
> ...



Here we go...


```
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:


```
#!/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:

```
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:


```
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?


----------



## covacat (Jan 21, 2022)

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

```
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


----------



## Andreas Strauch (Jan 30, 2022)

Success! Thanks!

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


```
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)


----------



## Andreas Strauch (Jan 30, 2022)

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?


----------



## covacat (Jan 30, 2022)

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


----------

