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?
Robin
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=1kcount=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?
Those things may help @Michael to figure out what the issue is.
Regards,
Adolf.
Robin
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.
Regards Robin
Those things may help @Michael to figure out what the issue is.
Regards,
Adolf.
Robin
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=1kcount=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
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
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.imgbs=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
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
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
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
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
Hello Robin,
On 4 Sep 2024, at 20:53, Robin Roevens robin.roevens@disroot.org 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 ]
What is the output of “losetup” after this fails?
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.
Does this also work in shell?
$ 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?
It creates new namespaces in which root is less privileged than in the first namespace.
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?
Apart from that, as Adolf requested, please provide us with some more information about your kernel and distribution.
-Michael
Robin
Hi Michael
Michael Tremer schreef op wo 04-09-2024 om 21:38 [+0200]:
Hello Robin,
On 4 Sep 2024, at 20:53, Robin Roevens robin.roevens@disroot.org 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 ]
What is the output of “losetup” after this fails?
Just a list snap files mounted by snapd. Nothing from ipfire.
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.
Does this also work in shell?
Yes, it works also in a root shell.
$ 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?
It creates new namespaces in which root is less privileged than in the first namespace.
Can it be that there is some leftover somewhere from older builds when it had more privileges? Not that I can imagine what could still be there that it now prevents mounting a freshly created file on loopback.
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?
Apart from that, as Adolf requested, please provide us with some more information about your kernel and distribution.
I'm running openSUSE Tumbleweed on kernel 6.10.5.
-Michael
Robin
Hello,
On 4 Sep 2024, at 22:58, Robin Roevens robin.roevens@disroot.org wrote:
Hi Michael
Michael Tremer schreef op wo 04-09-2024 om 21:38 [+0200]:
Hello Robin,
On 4 Sep 2024, at 20:53, Robin Roevens robin.roevens@disroot.org 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 ]
What is the output of “losetup” after this fails?
Just a list snap files mounted by snapd. Nothing from ipfire.
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.
Does this also work in shell?
Yes, it works also in a root shell.
$ 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?
It creates new namespaces in which root is less privileged than in the first namespace.
Can it be that there is some leftover somewhere from older builds when it had more privileges? Not that I can imagine what could still be there that it now prevents mounting a freshly created file on loopback.
I would have guessed that you are running out of loop devices, but you have ruled that one out already.
Did I just miss the reason why mount is complaining?
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?
Apart from that, as Adolf requested, please provide us with some more information about your kernel and distribution.
I'm running openSUSE Tumbleweed on kernel 6.10.5.
-Michael
Robin
-
Adolf Belka -
Michael Tremer -
Robin Roevens