From: Adolf Belka <adolf.belka@ipfire.org>
To: Michael Tremer <michael.tremer@ipfire.org>
Cc: "IPFire: Development-List" <development@lists.ipfire.org>
Subject: Re: Building IPFire without using loop devices
Date: Sun, 12 Apr 2026 13:58:46 +0200 [thread overview]
Message-ID: <7978425a-6409-452e-b265-e2e0e454d0bd@ipfire.org> (raw)
In-Reply-To: <1C3952C4-E5F6-4F11-A142-E6E2171C4A55@ipfire.org>
Hi Michael,
On 07/04/2026 18:41, Michael Tremer wrote:
> 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.
Sorry for the delay.
I tried it with my vm system. I couldn't use the .img file directly so had to convert it from .img to a .vdi file.
When I tried to boot it I just got a grub> line entry.
I wasn't sure if that was due to the .img to .vdi conversion so I then copied the .img file to a usb stick and tested it out on my PRIME system.
I got the same grub> response.
So it is not booting for me on PRIME or my vm system.
Regards,
Adolf.
>
> Best,
> -Michael
>
>> On 7 Apr 2026, at 17:12, Adolf Belka <adolf.belka@ipfire.org> 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 <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
>>>>
>>
>>
>
>
next prev parent reply other threads:[~2026-04-12 11:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 17:16 Michael Tremer
2026-04-03 18:56 ` Adolf Belka
2026-04-05 13:53 ` Michael Tremer
2026-04-07 16:12 ` Adolf Belka
2026-04-07 16:41 ` Michael Tremer
2026-04-12 11:58 ` Adolf Belka [this message]
2026-04-13 9:00 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7978425a-6409-452e-b265-e2e0e454d0bd@ipfire.org \
--to=adolf.belka@ipfire.org \
--cc=development@lists.ipfire.org \
--cc=michael.tremer@ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox