From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4fpYp515cWz339x for ; Sun, 05 Apr 2026 13:53:33 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4fpYp151Mvz2yBG for ; Sun, 05 Apr 2026 13:53:29 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4fpYp02Plsz1LC; Sun, 05 Apr 2026 13:53:28 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1775397208; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sd0A/YVz0E3FcWdXhS8xXP1/g9yPcc958Q7ie18xy+o=; b=5BWa6xL2gMpkydAR25svdilkYB8sx7ejsV0ahgI4N7VpLKYPdKrJeXDM5DIaA1NdtjM/kz T79Jiy0R6TDKrUAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1775397208; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sd0A/YVz0E3FcWdXhS8xXP1/g9yPcc958Q7ie18xy+o=; b=Gn1gyHa2ddm9inc2lInrswadeLgnICmXxUs76/7bSEP7tx/n7mJ2x6pgkWreeRXtsMRpuN PcVvXk9asRJeKa/Or4InpwQFCmz7fAY0iRB1OYnNjyvTb9lc4lf/j2HPpVVXDRouRAwIT7 BiJobSpf+EIKOOt4zfJUZWQrHxA+SgPjGsaKGRExUZV/6numsqvTCDWdhbtnOo0rSA3vAg 8/w8cobXpJBPQmzsO1/j/Y4LSD/yJ30V2emZWVovXsbjeAQMKuXfq5ssLNcfTR2QKpLHBN DLuGV0cYaBUK5yxjwKodZarnwwRsVpa2cdK2Esw1GEGtbMBHq7PuiGGlv/cJsQ== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: Building IPFire without using loop devices From: Michael Tremer In-Reply-To: <09eeb243-0768-4e16-aba9-66020087605a@ipfire.org> Date: Sun, 5 Apr 2026 14:53:27 +0100 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: References: <910F5D38-B456-4C23-9795-8F0DE003EAE8@ipfire.org> <09eeb243-0768-4e16-aba9-66020087605a@ipfire.org> To: Adolf Belka Hello, I found the problem. It wasn=E2=80=99t in the image itself, but /tmp = where we put the image and the root tree. That partition was mounted as = a tmpfs with a 4 GiB limit which we simply exceeded. The fix is to = create the image on disk: = https://git.ipfire.org/?p=3Dpeople/ms/ipfire-2.x.git;a=3Dcommitdiff;h=3D74= a4ec8bc11a43dbda0fbf806914ca3d5c88c7fe Could you please pull, rebuild and report? All the best, -Michael > On 3 Apr 2026, at 19:56, Adolf Belka wrote: >=20 > Hi Michael, >=20 > Sorry for slow reply, I have been a bit busy. >=20 > On 24/03/2026 18:16, Michael Tremer wrote: >> Hello everyone, >> On the last call, some people raised that the distribution no longer = builds properly when running a recent version of GNOME or a similar = desktop environment. We identified that the problem is udisk2 trying to = figure out what the new device is that has just been mounted, not = understanding that it is inside a container and that there should be no = access. >=20 > That was me but not from the last call but from the following mail = thread. >=20 > = https://lists.ipfire.org/development/34f64d4b-4008-418b-83b0-e621bee9f999@= ipfire.org/T/#t >=20 >> Since loop devices are not namespaces in Linux, there is no way to = get around this. However, I have put some code together that generates = the image without using any loop devices whatsoever: >> = https://git.ipfire.org/?p=3Dpeople/ms/ipfire-2.x.git;a=3Dshortlog;h=3Drefs= /heads/no-loop >> Could the people who have been affected by this and check if this = branch builds without any problems and if the generated image is also = bootable in either EFI, non-EFI or both modes, please? >=20 > I first tried running thew existing build process but with a usb disk = drive mounted and accessed via a File Manager window. However the old = build worked without any problems so I was not able to reproduce the = previous problem I had. >=20 > So then I thought, okay then I will just try building the new branch = and see how it goes. Unfortunately it failed. The failure message was:- >=20 > # Check if any files have been deleted > [ -s "/tmp/cleanup.log" ] > # Create the EFI partition > mformat \ > -F \ > -i /tmp/image.img@@536870912 \ > -N "341A5693" \ > -v "EFI" \ > -h 32 \ > -n 1 \ > -t $(( 65536 / 32 )) \ > :: > # Copy all files to the partition > mcopy -s -i /tmp/image.img@@536870912 /tmp/root/boot/efi/* :: > # Show what has been copied > mdir -i /tmp/image.img@@536870912 :: > Volume in drive : is EFI > Volume Serial Number is 341A-5693 > Directory for ::/ >=20 > EFI 2026-04-03 14:11 > 1 file 0 bytes > 2 841 190 400 bytes free >=20 > # Remove any copied content > rm -rf /tmp/root/boot/efi/* > # Print how much space we need > du -csh /tmp/root/boot/* > 7.0M /tmp/root/boot/System.map-6.18.7-ipfire > 200K /tmp/root/boot/config-6.18.7-ipfire > 0 /tmp/root/boot/efi > 25M /tmp/root/boot/grub > 73M /tmp/root/boot/initramfs-6.18.7-ipfire.img > 8.9M /tmp/root/boot/vmlinuz-6.18.7-ipfire > 114M total > # Format them > mkfs.ext2 \ > -F \ > -E offset=3D4194304 \ > -U "88ce295a-436b-4bad-9509-07ec3a630029" \ > -d /tmp/root/boot \ > /tmp/image.img \ > 520192 > mke2fs 1.47.3 (8-Jul-2025) > Discarding device blocks: 0/520192=08=08=08=08=08=08=08=08=08=08=08= =08=08 =08=08=08=08=08=08=08=08=08=08=08=08=08done > Creating filesystem with 520192 1k blocks and 130048 inodes > Filesystem UUID: 88ce295a-436b-4bad-9509-07ec3a630029 > Superblock backups stored on blocks: > 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 >=20 > Allocating group tables: 0/64=08=08=08=08=08 =08=08=08=08=08done > Writing inode tables: 0/64=08=08=08=08=08 =08=08=08=08=08done > Copying files into the device: done > Writing superblocks and filesystem accounting information: 0/64=08=08=08= =08=08 =08=08=08=08=08done >=20 > # Remove any copied content > rm -rf /tmp/root/boot/* > # Print how much space we need > du -csh /tmp/root/* > 9.8M /tmp/root/bin > 0 /tmp/root/boot > 0 /tmp/root/dev > 18M /tmp/root/etc > 0 /tmp/root/home > 1.2G /tmp/root/lib > 0 /tmp/root/lib64 > 0 /tmp/root/media > 0 /tmp/root/mnt > 68K /tmp/root/opt > 0 /tmp/root/proc > 12K /tmp/root/root > 0 /tmp/root/run > 12M /tmp/root/sbin > 4.3M /tmp/root/srv > 0 /tmp/root/sys > 0 /tmp/root/tmp > 750M /tmp/root/usr > 73M /tmp/root/var > 2.0G total > # Create the root filesystem and input files > mkfs.ext4 \ > -F \ > -E offset=3D570425344 \ > -U "e041f3cc-df7e-4a3c-a2f7-8a2457b1a741" \ > -d /tmp/root \ > /tmp/image.img \ > 2621440 > mke2fs 1.47.3 (8-Jul-2025) > Discarding device blocks: 0/655360=08=08=08=08=08=08=08=08=08=08=08= =08=08 =08=08=08=08=08=08=08=08=08=08=08=08=08done > Creating filesystem with 655360 4k blocks and 163840 inodes > Filesystem UUID: e041f3cc-df7e-4a3c-a2f7-8a2457b1a741 > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376, 294912 >=20 > Allocating group tables: 0/20=08=08=08=08=08 =08=08=08=08=08done > Writing inode tables: 0/20=08=08=08=08=08 =08=08=08=08=08done > Creating journal (16384 blocks): done > Copying files into the device: libhs.so.5.4.12: No space left on = device while looking up "libhs.so.5.4.12" > mkfs.ext4: No space left on device while populating file system > make: *** [flash-images:172: /usr/src/log/flash-image] Error 1 >=20 > Regards, >=20 > Adolf. >=20 >> Feel free to hit me up with any problems or questions. >> Best, >> -Michael >=20