Hello, Thank you for the feedback.
I was going to merge the branch into next, but I am happy to wait for a couple of extra days until you have verified that I didn’t break the image. I have tested it in a VM in EFI and BIOS mode and it was working well. Best, -Michael > On 7 Apr 2026, at 17:12, Adolf Belka <[email protected]> wrote: > > 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 >>> > >
