Hi Michael,

On 05/04/2026 15:53, Michael Tremer wrote:
Hello,

I found the problem. It wasn’t 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=people/ms/ipfire-2.x.git;a=commitdiff;h=74a4ec8bc11a43dbda0fbf806914ca3d5c88c7fe

Could you please pull, rebuild and report?

I have updated my local copy and rebuilt it and it successfully built the image.

I will now look to find some time to test out installing the image on my vm 
testbed to confirm that it installs fine.

Regards,

Adolf.


All the best,
-Michael

On 3 Apr 2026, at 19:56, Adolf Belka <[email protected]> wrote:

Hi Michael,

Sorry for slow reply, I have been a bit busy.

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.

That was me but not from the last call but from the following mail thread.

https://lists.ipfire.org/development/[email protected]/T/#t

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=people/ms/ipfire-2.x.git;a=shortlog;h=refs/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?

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.

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:-

# 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 ::/

EFI          <DIR>     2026-04-03  14:11
        1 file                    0 bytes
                      2 841 190 400 bytes free

# 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=4194304 \
-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             
done
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

Allocating group tables:  0/64     done
Writing inode tables:  0/64     done
Copying files into the device: done
Writing superblocks and filesystem accounting information:  0/64     
done

# 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=570425344 \
-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             
done
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

Allocating group tables:  0/20     done
Writing inode tables:  0/20     done
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

Regards,

Adolf.

Feel free to hit me up with any problems or questions.
Best,
-Michael




Reply via email to