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