Re: make-memstick.sh creates in 14.0-CURRENT run-away processes
- In reply to: Matthias Apitz : "make-memstick.sh creates in 14.0-CURRENT run-away processes"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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