From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4ftpwk3sWWz2yDM for ; Sun, 12 Apr 2026 11:59:02 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4ftpwg0sCwz2xMP for ; Sun, 12 Apr 2026 11:58:59 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4ftpwc1kq0z5K3; Sun, 12 Apr 2026 11:58:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1775995136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LFksYPpn2AR09/EjuIhGKJ/ArsOsOV/ZzYv31uML1UQ=; b=rTlRznElXJOlyadg482j4yvNimUrKEBOwfHQbgmFiaV9YLEKq7M9zxE/HIdoh/GUBSxePX q1deAIyJPd9kSMJJTFowKgUqlkEHn/VjkrY7trvXljn8/5V/b6M03HFjjDaNZWH5+ZnhYj 10VDSF08IW7Tixq83NrvY2L7J3VY5wVGLYHL6XQ908ih3QSKqolDwfOuzDjKNwxIJ+s+oW FDyCW6ck0perxG0vRtATbbC1ewoevTS0NphGapIPS8Joht0fd5HTT/cXiY2TG6d1EbszfG g4nS1uZBJGhylqPNDejOyS9vjQWEbiem9s5VG/Y5XCx0ztpVEiXfrhrtUfQiCw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1775995136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LFksYPpn2AR09/EjuIhGKJ/ArsOsOV/ZzYv31uML1UQ=; b=KpLakckCl8O94kV1Ml86EEOYDUSkgM7KpepatprZ8Zgsqsiuwrc26Fv93VaX6YjAKc/buH Wge0ymIpYdMDq4BQ== Message-ID: <7978425a-6409-452e-b265-e2e0e454d0bd@ipfire.org> Date: Sun, 12 Apr 2026 13:58:46 +0200 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Subject: Re: Building IPFire without using loop devices To: Michael Tremer References: <910F5D38-B456-4C23-9795-8F0DE003EAE8@ipfire.org> <09eeb243-0768-4e16-aba9-66020087605a@ipfire.org> <1C3952C4-E5F6-4F11-A142-E6E2171C4A55@ipfire.org> Content-Language: en-GB Cc: "IPFire: Development-List" From: Adolf Belka In-Reply-To: <1C3952C4-E5F6-4F11-A142-E6E2171C4A55@ipfire.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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 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 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 >>>> >> >> > >