Perfect. Thank you for the feedback!
On 14 Sep 2024, at 16:01, Robin Roevens robin.roevens@disroot.org 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=2b0ecf4df598d8969444...
-Michael
On 11 Sep 2024, at 20:21, Robin Roevens robin.roevens@disroot.org 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@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@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=7ad12edfb0d233498410...
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 robin.roevens@disroot.org 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 > robin.roevens@disroot.org > 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