Re: Building IPFire without using loop devices

[Adolf Belka <adolf.belka@ipfire.org>]

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 <adolf.belka@ipfire.org> 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/34f64d4b-4008-418b-83b0-e621bee9f999@ipfire.org/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\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: 88ce295a-436b-4bad-9509-07ec3a630029
>> 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
>> Copying files into the device: done
>> Writing superblocks and filesystem accounting information:  0/64\b\b\b\b\b     \b\b\b\b\bdone
>>
>> # 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\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: e041f3cc-df7e-4a3c-a2f7-8a2457b1a741
>> 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
>> 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
>>
>