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 > > > > > > > > > > > > > >