Hello Robin, Could you give this one a test, please? https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=2b0ecf4df598d89694442700e5da9acbd502c923 -Michael > On 11 Sep 2024, at 20:21, Robin Roevens wrote: > > Hi Michael > > ~# ll /dev/loop* > brw-rw---- 1 root disk 7, 0 1 sep 22:54 /dev/loop0 > brw-rw---- 1 root disk 7, 1 1 sep 22:54 /dev/loop1 > brw-rw---- 1 root disk 7, 10 1 sep 22:54 /dev/loop10 > brw-rw---- 1 root disk 7, 11 1 sep 22:54 /dev/loop11 > brw-rw---- 1 root disk 7, 12 1 sep 22:54 /dev/loop12 > brw-rw---- 1 root disk 7, 13 1 sep 22:54 /dev/loop13 > brw-rw---- 1 root disk 7, 14 7 sep 23:24 /dev/loop14 > brw-rw---- 1 root disk 7, 15 3 sep 12:14 /dev/loop15 > brw-rw---- 1 root disk 7, 2 1 sep 22:54 /dev/loop2 > brw-rw---- 1 root disk 7, 3 1 sep 22:54 /dev/loop3 > brw-rw---- 1 root disk 7, 4 10 sep 21:44 /dev/loop4 > brw-rw---- 1 root disk 7, 5 1 sep 22:54 /dev/loop5 > brw-rw---- 1 root disk 7, 6 1 sep 22:54 /dev/loop6 > brw-rw---- 1 root disk 7, 7 1 sep 22:54 /dev/loop7 > brw-rw---- 1 root disk 7, 8 1 sep 22:54 /dev/loop8 > brw-rw---- 1 root disk 7, 9 1 sep 22:54 /dev/loop9 > crw-rw---- 1 root disk 10, 237 1 sep 22:54 /dev/loop-control > > So numbering seems to be same here as on your Debian. > But due to snapd there are quite a few loop devices in use here.. > Checking with losetup indicates that currently only loop4 is not in > use. All other loop-devices are in use by snap images. > > When I manually mount a few empty image files (created like they are > created in make.sh), I see that there are loop-devices added to /dev on > the fly as needed. > > So possibly indeed my loop devices where all in use, but it looks like > they are not added on the fly inside the restricted environment during > build. Not sure why loop4 currently is no longer in use, but that is > probably the reason why the build now works. > > I checked by mounting an image on the free loop4 so now no existing > loop device is currently free. When I now restart the ipfire build, I > get the error again. (on latest next, including your latest changes to > make.sh) > > So it seems that we will need to somehow create a new loop device if no > loop device is currently free. With the new fact in mind that on some > systems the minor numbering scheme is different, I'm not sure how that > can be solved easily? > Possibly "losetup --find" may be a solution ? When I execute that, it > currently returns "loop17" (0 to 16 are in use) and suddenly I have a > new /dev/loop17. Not sure if that is created by losetup itself, or by > some system default udev rule. And not sure that, if it is losetup > itself creating the new loop-device, this can help in the restricted > environment? > > Regards > Robin > > Michael Tremer schreef op wo 11-09-2024 om 10:43 [+0100]: >> 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 >>>> >>>> >>