Hello, I just stumbled into this. On a Grml live system because I wanted to build on a system with 128 CPU cores and a TB of memory that I got my hands on :) It seems that on Grml the kernel addresses the loop devices in a different way: root(a)grml /mnt/ipfire-2.x (git)-[next] # ll /dev/loop* brw-rw---- 1 root disk 7, 0 Sep 11 09:29 /dev/loop0 brw-rw---- 1 root disk 7, 16 Sep 11 09:39 /dev/loop1 brw-rw---- 1 root disk 7, 32 Sep 11 09:29 /dev/loop2 brw-rw---- 1 root disk 7, 48 Sep 11 09:29 /dev/loop3 ... On Debian it looks like this: root(a)michael:/build/ipfire-2.x# ll /dev/loop* brw-rw---- 1 root disk 7, 0 Aug 22 09:20 /dev/loop0 brw-rw---- 1 root disk 7, 1 Sep 9 19:23 /dev/loop1 brw-rw---- 1 root disk 7, 2 Aug 22 09:07 /dev/loop2 brw-rw---- 1 root disk 7, 3 Aug 22 09:07 /dev/loop3 … Note the column with the minor number. In the build environment we create them like I found them on my Debian system which fails if /dev/loop0 is busy and /dev/loop1 or any of the others has to be used. That is probably why the problem went away for you. I pushed a change where we simply bind-mount all loop devices of the host: https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=7ad12edfb0d233498410f2afc09753e70de50f80 That way, we are always compatible. Please let me know if this works for you as well. -Michael > On 10 Sep 2024, at 18:59, Robin Roevens wrote: > > Hi Michael, Adolf, all > > I wanted to come back to this (didn't have time last few days). But now > it suddenly just works.. I have no idea why.. > > Anyway, problem solved. Thanks for the help! > > > Regars > Robin > > Michael Tremer schreef op wo 04-09-2024 om 23:33 [+0200]: >> >> >>> On 4 Sep 2024, at 22:47, Robin Roevens >>> wrote: >>> >>> Hi Adolf >>> >>> Adolf Belka schreef op wo 04-09-2024 om 21:04 [+0200]: >>>> Hi Robin, >>>> >>>> On 04/09/2024 20:53, Robin Roevens wrote: >>>>> Hi all >>>>> >>>>> While trying to build ipfire, which always has worked quite >>>>> effortless, >>>>> it now fails while building cdrom: >>>>> >>>>> --- >>>>> # Create the EFI Eltorito image >>>>> dd if=/dev/zero of=/tmp/cdrom/boot/isolinux/efiboot.img >>>>> bs=1k >>>>> count=2880 >>>>> 2880+0 records in >>>>> 2880+0 records out >>>>> 2949120 bytes (2.9 MB, 2.8 MiB) copied, 0.00453183 s, 651 >>>>> MB/s >>>>> mkdosfs -F 12 -n "IPFIRE_EFI" >>>>> /tmp/cdrom/boot/isolinux/efiboot.img >>>>> mkfs.fat 4.2 (2021-01-31) >>>>> # Mount the EFI image >>>>> mkdir -pv /tmp/efiboot.img >>>>> mkdir: created directory '/tmp/efiboot.img' >>>>> mount -o loop /tmp/cdrom/boot/isolinux/efiboot.img >>>>> /tmp/efiboot.img >>>>> mount: /tmp/efiboot.img: failed to setup loop device for >>>>> /tmp/cdrom/boot/isolinux/efiboot.img. >>>>> make: *** [cdrom:184: /usr/src/log/cdrom] Error 32 >>>>> make: Leaving directory '/usr/src/lfs' >>>>> >>>>> ERROR: Building cdrom >>>>> [ FAIL ] >>>>> Check /home/robin/src/ipfire-sandbox/ipfire- >>>>> 2.x/log_x86_64/_build.ipfire.log for errors if applicable >>>>> [ FAIL ] >>>>> --- >>>>> >>>>> The logfile has no extra or new information. >>>>> >>>>> When I manually try those steps, as root (as make.sh is also >>>>> ran as >>>>> root (using sudo)), they work correctly, and I'm able to >>>>> successfully >>>>> mount the image. >>>>> >>>>> --- >>>>> $ sudo dd if=/dev/zero of=./efiboot.img bs=1k count=2880 >>>>> 2880+0 records gelezen >>>>> 2880+0 records geschreven >>>>> 2949120 bytes (2,9 MB, 2,8 MiB) gekopieerd, 0,0130511 s, 226 >>>>> MB/s >>>>> $ sudo ./build/sbin/mkdosfs -F 12 -n "IPFIRE_EFI" ./efiboot.img >>>>> mkfs.fat 4.2 (2021-01-31) >>>>> $ sudo mkdir ./efi >>>>> $ sudo mount -o loop ./efiboot.img ./efi >>>>> $ df -h ./efi >>>>> Bestandssysteem Grootte Gebruikt Besch Geb% Aangekoppeld op >>>>> /dev/loop15 2,8M 0 2,8M 0% >>>>> /home/robin/src/ipfire- >>>>> sandbox/ipfire-2.x/efi >>>>> --- >>>>> >>>>> So I'm unsure as of why the build fails setting up the loop >>>>> device. >>>>> I did a ./make.sh clean, but that didn't solve it. >>>>> >>>>> If I try to mount the loop device as unprivileged user, I get >>>>> the >>>>> exact >>>>> same error. But the build process is ran as root, so that >>>>> should >>>>> also >>>>> not be the problem? >>>>> >>>>> Has anyone an idea what could be wrong here? or give me some >>>>> guidelines >>>>> on how to debug this ? >>>>> I've read there where changes to the inner workings of the >>>>> build >>>>> system, could those be the cause ? I assume not as then I would >>>>> have >>>>> seen others complain about it here? >>>> >>>> There were a couple of users who had problems with the new build >>>> system which were due to the kernel version they were running >>>> with >>>> their OS's. >>>> >>>> I didn't see any problems but I am running everything on Arch >>>> Linux >>>> so it always has the latest kernel version. >>>> >>>> What OS are you running for your build system and what is the >>>> kernel >>>> version in it? >>> >>> I'm running openSUSE Tumbleweed currently with kernel 6.10.5. >> >> Anything in dmesg? Is selinux still a thing? >> >>> Regards >>> Robin >>> >>> >>>> >>>> Those things may help @Michael to figure out what the issue is. >>>> >>>> Regards, >>>> >>>> Adolf. >>>> >>>>> Robin >> >>