Perfect. Thank you for the feedback! > On 14 Sep 2024, at 16:01, Robin Roevens wrote: > > Hi Michael > > This change seems to work correctly. > > I made sure all loop devices where assigned so that there was no free > loop device available when I started make.sh build. > It happily built cdrom without any errors. > losetup showed me that there was now a new loop device assigned to the > ipfire image. > > Regards > Robin > > > Michael Tremer schreef op do 12-09-2024 om 13:59 [+0100]: >> 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 >>>>>> >>>>>> >>>> >>