* Building IPFire without using loop devices @ 2026-03-24 17:16 Michael Tremer 2026-04-03 18:56 ` Adolf Belka 0 siblings, 1 reply; 5+ messages in thread From: Michael Tremer @ 2026-03-24 17:16 UTC (permalink / raw) To: IPFire: Development-List 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Building IPFire without using loop devices 2026-03-24 17:16 Building IPFire without using loop devices Michael Tremer @ 2026-04-03 18:56 ` Adolf Belka 2026-04-05 13:53 ` Michael Tremer 0 siblings, 1 reply; 5+ messages in thread From: Adolf Belka @ 2026-04-03 18:56 UTC (permalink / raw) To: Michael Tremer; +Cc: IPFire: Development-List 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Building IPFire without using loop devices 2026-04-03 18:56 ` Adolf Belka @ 2026-04-05 13:53 ` Michael Tremer 2026-04-07 16:12 ` Adolf Belka 0 siblings, 1 reply; 5+ messages in thread From: Michael Tremer @ 2026-04-05 13:53 UTC (permalink / raw) To: Adolf Belka; +Cc: IPFire: Development-List 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? 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Building IPFire without using loop devices 2026-04-05 13:53 ` Michael Tremer @ 2026-04-07 16:12 ` Adolf Belka 2026-04-07 16:41 ` Michael Tremer 0 siblings, 1 reply; 5+ messages in thread From: Adolf Belka @ 2026-04-07 16:12 UTC (permalink / raw) To: Michael Tremer; +Cc: IPFire: Development-List 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 >> > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Building IPFire without using loop devices 2026-04-07 16:12 ` Adolf Belka @ 2026-04-07 16:41 ` Michael Tremer 0 siblings, 0 replies; 5+ messages in thread From: Michael Tremer @ 2026-04-07 16:41 UTC (permalink / raw) To: Adolf Belka; +Cc: IPFire: Development-List 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 <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 >>> > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-04-07 16:41 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-03-24 17:16 Building IPFire without using loop devices 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox