public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Adolf Belka <adolf.belka@ipfire.org>
To: "IPFire: Development-List" <development@lists.ipfire.org>
Subject: Re: Not enough space when building flash-images with new linux-firmware in build
Date: Fri, 16 Oct 2026 14:07:08 +0200	[thread overview]
Message-ID: <e5b817a7-56e5-433d-bc2c-0d1dac927665@ipfire.org> (raw)
In-Reply-To: <77cd15b8-79be-447b-b11b-4cb126974edc@ipfire.org>

Hi All,

I have just noticed that there has been a lot of changes to the build process, including around the flash-images section.

So I am going to run a build with the latest next git status and see how the linux-firmware works with that.

No point investigating problems in a process that has been changed.

Regards,

Adolf.

On 16/10/2026 13:24, Adolf Belka wrote:
> Hi All,
> 
> I have run into a problem when running a build with a new linux-firmware version. After doing the rootfile update and modifications it successfully did the cdrom build step but then in the flash-images build it failed with not enough space and then all subsequent steps failed due to directories or files not being present due to not being able to create the directories with mkdir.
> 
> The following is the log output taken up to the first few messages about cannot mkdir - not enough space left on device.
> 
> It looks like the very large linux-firmware update is exceeding the available space in the flash-images build loop device.
> 
> 
> 
> Oct 14 18:32:07: Building flash-images make: Entering directory '/home/ahb/sandbox/ipfire-2-builder2/lfs'
> make: Nothing to be done for 'download'.
> make: Leaving directory '/home/ahb/sandbox/ipfire-2-builder2/lfs'
> make: Entering directory '/usr/src/lfs'
> make: Nothing to be done for 'b2'.
> rm -rf /tmp/image.img /tmp/harddisk && mkdir -p /tmp/harddisk
> # Allocate image on disk
> dd if=/dev/zero of=/tmp/image.img bs=512 count=0 seek=$(( 8192 + 1040384 + 65536  + 5242880 ))
> 0+0 records in
> 0+0 records out
> 0 bytes copied, 1.1752e-05 s, 0.0 kB/s
> losetup /dev/loop1 /tmp/image.img
> # Write Partition table
> echo -e "8192,1040384,L,*\n1048576,65536 ,U\n1114112,5242880,L\n" | sfdisk -uS /dev/loop1
> Checking that no-one is using this disk right now ... OK
> 
> Disk /dev/loop1: 3.03 GiB, 3254779904 bytes, 6356992 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
>>>> Created a new DOS (MBR) disklabel with disk identifier 0xf25def00.
> /dev/loop1p1: Created a new partition 1 of type 'Linux' and of size 508 MiB.
> /dev/loop1p2: Created a new partition 2 of type 'EFI (FAT-12/16/32)' and of size 32 MiB.
> /dev/loop1p3: Created a new partition 3 of type 'Linux' and of size 2.5 GiB.
> /dev/loop1p4: Done.
> 
> New situation:
> Disklabel type: dos
> Disk identifier: 0xf25def00
> 
> Device       Boot   Start     End Sectors Size Id Type
> /dev/loop1p1 *       8192 1048575 1040384 508M 83 Linux
> /dev/loop1p2      1048576 1114111   65536  32M ef EFI (FAT-12/16/32)
> /dev/loop1p3      1114112 6356991 5242880 2.5G 83 Linux
> 
> The partition table has been altered.
> Calling ioctl() to re-read partition table.
> Re-reading the partition table failed.: Invalid argument
> The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or partx(8).
> Syncing disks.
> kpartx -v -a /dev/loop1
> add map loop1p1 (252:8): 0 1040384 linear 7:1 8192
> add map loop1p2 (252:9): 0 65536 linear 7:1 1048576
> add map loop1p3 (252:10): 0 5242880 linear 7:1 1114112
> # kpartx trigger a automount on some desktop enviroments
> # this leads in failing zerofree after build and umount the image
> # with the sleep 1 prevent this because the image has no fs yet.
> sleep 1
> # Format them
> mkfs.ext2 -F /dev/mapper/loop1p1
> mke2fs 1.47.4 (6-Mar-2025)
> Discarding device blocks:      0/520192\b\b\b\b\b\b\b\b\b\b\b\b\b             \b\b\b\b\b\b\b\b\b\b\b\b\bdone
> Creating filesystem with 520192 1k blocks and 130048 inodes
> Filesystem UUID: d527d8f0-d99e-4a38-a0ea-f23e468823b1
> Superblock backups stored on blocks:
>      8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
> 
> Allocating group tables:  0/64\b\b\b\b\b     \b\b\b\b\bdone
> Writing inode tables:  0/64\b\b\b\b\b     \b\b\b\b\bdone
> Writing superblocks and filesystem accounting information:  0/64\b\b\b\b\b     \b\b\b\b\bdone
> 
> mkfs.vfat /dev/mapper/loop1p2
> mkfs.fat 4.2 (2021-01-31)
> mkfs.ext4 -F /dev/mapper/loop1p3
> mke2fs 1.47.4 (6-Mar-2025)
> Discarding device blocks:      0/655360\b\b\b\b\b\b\b\b\b\b\b\b\b             \b\b\b\b\b\b\b\b\b\b\b\b\bdone
> Creating filesystem with 655360 4k blocks and 163840 inodes
> Filesystem UUID: 472cb45d-66c9-40f6-9d37-86282522bffd
> Superblock backups stored on blocks:
>      32768, 98304, 163840, 229376, 294912
> 
> Allocating group tables:  0/20\b\b\b\b\b     \b\b\b\b\bdone
> Writing inode tables:  0/20\b\b\b\b\b     \b\b\b\b\bdone
> Creating journal (16384 blocks): done
> Writing superblocks and filesystem accounting information:  0/20\b\b\b\b\b     \b\b\b\b\bdone
> 
> # Most systems that use Flashimages has no RTC at boot
> # so the interval check should disables
> tune2fs -i0 /dev/mapper/loop1p3
> tune2fs 1.47.4 (6-Mar-2025)
> Setting interval between checks to 0 seconds
> # Mount root partition
> mount /dev/mapper/loop1p3 /tmp/harddisk
> # Mount boot partition
> mkdir -pv /tmp/harddisk/boot
> mkdir: created directory '/tmp/harddisk/boot'
> mount /dev/mapper/loop1p1 /tmp/harddisk/boot
> mkdir -pv /tmp/harddisk/boot/efi
> mkdir: created directory '/tmp/harddisk/boot/efi'
> mount /dev/mapper/loop1p2 /tmp/harddisk/boot/efi
> # Copy all files
> # Copy all files from /usr/src/config/rootfiles/common to /tmp/harddisk ()
> #  = rootfile to write out
> #  = exclude
> ROOTFILE_PLACEHOLDERS="@BUILDTARGET@=x86_64-pc-linux-gnu @RUST_PLATFORM@=x86_64-unknown-linux-gnu @KERNEL_RELEASE@=6.18.54-ipfire @ARCH@=x86_64 @ARCH_DASHED@=x86-64" /usr/src/src/scripts/archive.files x86_64 /usr/src/config/rootfiles/common  | tee  | tar --create --format=pax --acls --xattrs --xattrs-include='*' --sparse --directory=/ --exclude="dev/pts/*" --exclude="proc/*" --exclude="tmp/*" --exclude="__pycache__"  --files-from=- | tar --extract --format=pax --acls --xattrs --xattrs-include='*' --sparse --directory=/tmp/harddisk
> tar: usr/lib/pkcs11/p11-kit-client.so: Wrote only 512 of 10240 bytes
> tar: usr/lib/pkcs11/p11-kit-trust.so: Wrote only 4096 of 6656 bytes
> tar: usr/lib/pppd: Cannot mkdir: No space left on device
> tar: usr/lib/pppd: Cannot mkdir: No space left on device
> tar: usr/lib/pppd/2.5.2: Cannot mkdir: No such file or directory
> tar: usr/lib/pppd/2.5.2: Cannot mkdir: No such file or directory
> tar: usr/lib/pppd/2.5.2/radattr.so: Cannot open: No such file or directory
> tar: usr/lib/pppd/2.5.2: Cannot mkdir: No such file or directory
> 
> Regards,
> 
> Adolf.



  reply	other threads:[~2026-10-16 12:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16 11:24 Adolf Belka
2026-10-16 12:07 ` Adolf Belka [this message]
2026-10-16 15:21   ` Adolf Belka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e5b817a7-56e5-433d-bc2c-0d1dac927665@ipfire.org \
    --to=adolf.belka@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox