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