Re: make-memstick.sh creates in 14.0-CURRENT run-away processes

From: Matthias Apitz <guru_at_unixarea.de>
Date: Mon, 04 Sep 2023 05:58:08 UTC
El día Freitag, August 18, 2023 a las 06:17:42 +0200, Matthias Apitz escribió:

> 
> I was used to use in 13.0-CURRENT the script "make-memstick.sh" to
> create memstick immages to install the system on smaller devices where
> the OS can't build from the sources, and it always worked fine for many
> years. Now I'm ready to do so with my fresh compiled system (sources
> from git August, 5:
> 
> $ uname -a
> FreeBSD jet 14.0-CURRENT FreeBSD 14.0-CURRENT amd64 1400094 #0 main-n264568-1d7ffb373c9d: Sat Aug  5 17:22:47 CEST 2023     guru@jet:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
> 
> but the image is not produces and some processes create temp
> files of 800++ GByte. Here are the details:
> 
> root@jet:/usr/src/release/amd64 # ./make-memstick.sh /home/guru/140.root ~guru/memstick.img
> Calculated size of `/home/guru/memstick.img.part': 23795073024 bytes, 263113 inodes
> Extent size set to 32768
> /home/guru/memstick.img.part: 22692.8MB (46474752 sectors) block size 32768, fragment size 4096
>         using 27 cylinder groups of 869.44MB, 27822 blks, 10240 inodes.
> super-block backups (for fsck -b #) at:
>       192,  1780800,  3561408,  5342016,  7122624,  8903232, 10683840,
>  12464448, 14245056, 16025664, 17806272, 19586880, 21367488, 23148096,
>  24928704, 26709312, 28489920, 30270528, 32051136, 33831744, 35612352,
>  37392960, 39173568, 40954176, 42734784, 44515392, 46296000
> Populating `/home/guru/memstick.img.part'
> Image `/home/guru/memstick.img.part' complete
> Creating `/tmp/efiboot.iFachZ'
> /tmp/efiboot.iFachZ: 65528 sectors in 65528 FAT32 clusters (512 bytes/cluster)
> BytesPerSec=512 SecPerClust=1 ResSectors=32 FATs=2 Media=0xf0 SecPerTrack=63 Heads=255 HiddenSecs=0 HugeSectors=66584 FATsecs=512 RootCluster=2 FSInfo=1 Backup=2
> Populating `/tmp/efiboot.iFachZ'
> Image `/tmp/efiboot.iFachZ' complete
> 
> It says 'complete' but never ends growing the file /tmp/mkimg-oGNnFb:
> 
> root@jet:/usr/home/guru # ls -ltrah /tmp | tail -6
> drwx------   2 guru wheel  512B Aug 18 15:43 tmux-1001
> -rw-------   1 root wheel   33M Aug 18 17:18 efiboot.iFachZ
> -rw-------   1 root wheel    0B Aug 18 17:18 mkimg-4eMWKW
> drwxrwxrwt  21 root wheel  1.0K Aug 18 17:18 .
> drwxr-xr-x  22 root wheel  1.0K Aug 18 17:43 ..
> -rw-------   1 root wheel  850G Aug 18 17:53 mkimg-oGNnFb
> 
> root@jet:/usr/home/guru # ls -ltrh mem*
> -rw-r--r--  1 root wheel   22G Aug 18 17:18 memstick.img.part
> -rw-r--r--  1 root wheel    0B Aug 18 17:18 memstick.img
> 
> Only a hard reset and reboot helps.
> 

(Sorry for the delay, I was out for vacation)

The last part of the script ./make-memstick.sh which should produce the final
image, but the processes mkimg never end, is:


...
# Make an ESP in a file.
espfilename=$(mktemp /tmp/efiboot.XXXXXX)
make_esp_file ${espfilename} ${fat32min} ${BASEBITSDIR}/boot/loader.efi

mkimg -s mbr \
    -b ${BASEBITSDIR}/boot/mbr \
    -p efi:=${espfilename} \
    -p freebsd:-"mkimg -s bsd -b ${BASEBITSDIR}/boot/boot -p freebsd-ufs:=${2}.part" \
    -a 2 \
    -o ${2}
...

I've split the two processes, connected my the pipe, and run them one
after the other as:


#!/bin/sh

# set -x

BASEBITSDIR=/home/guru/140.root
img=/home/guru/zdata/memstick.img

espfilename=/home/guru/zdata/efiboot.7S9yjL

mkimg -s bsd -b ${BASEBITSDIR}/boot/boot \
      -p freebsd-ufs:=${img}.part > ${img}.part.mkimg

mkimg -s mbr \
    -b ${BASEBITSDIR}/boot/mbr \
    -p efi:=${espfilename} \
    -p freebsd:=${img}.part.mkimg \
    -a 2 \
    -o ${img}

# ls -l /home/guru/zdata
# -rw-r--r--  1 root wheel 23795073024 Sep  3 17:12 memstick.img.part
# -rw-------  1 root wheel    34091008 Sep  3 17:12 efiboot.7S9yjL
# -rw-r--r--  1 root wheel 23795081216 Sep  3 18:25 memstick.img.part.mkimg
# -rw-r--r--  1 root wheel 23829172736 Sep  3 18:34 memstick.img

The resulting file 'memstick.img' (copied with dd to an USB key)
boots fine.

Now I'm clueless about why the pipe between

mkimg ... -p freebsd:-"mkimg -s bsd ..." ...

does not work as it should.

	matthias


-- 
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub