Building IPFire without using loop devices

Building IPFire without using loop devices

[Michael Tremer]

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.

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?

Feel free to hit me up with any problems or questions.

Best,
-Michael

Re: Building IPFire without using loop devices

[Adolf Belka]

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