From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Unable to build cdrom: failed to setup loop device Date: Thu, 12 Sep 2024 13:59:01 +0100 Message-ID: <5A63D8F5-A7DA-448E-8960-2F0DAF4459D1@ipfire.org> In-Reply-To: <69aa5adfb2c63bca5212b7c39eb3830fbcd5e052.camel@roevenslambrechts.be> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7302891066202940766==" List-Id: --===============7302891066202940766== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Robin, Could you give this one a test, please? https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D2b0ecf4df598d= 89694442700e5da9acbd502c923 -Michael > On 11 Sep 2024, at 20:21, Robin Roevens wrote: >=20 > Hi Michael >=20 > ~# 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 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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) >=20 > 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? >=20 > Regards > Robin >=20 > Michael Tremer schreef op wo 11-09-2024 om 10:43 [+0100]: >> Hello, >>=20 >> 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 :) >>=20 >> It seems that on Grml the kernel addresses the loop devices in a >> different way: >>=20 >> 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 >> ... >>=20 >> On Debian it looks like this: >>=20 >> 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 >> =E2=80=A6 >>=20 >> Note the column with the minor number. >>=20 >> 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. >>=20 >> I pushed a change where we simply bind-mount all loop devices of the >> host: >>=20 >> =20 >> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D7ad12edfb0d2= 33498410f2afc09753e70de50f80 >>=20 >> That way, we are always compatible. >>=20 >> Please let me know if this works for you as well. >>=20 >> -Michael >>=20 >>> On 10 Sep 2024, at 18:59, Robin Roevens >>> wrote: >>>=20 >>> Hi Michael, Adolf, all >>>=20 >>> 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.. >>>=20 >>> Anyway, problem solved. Thanks for the help! >>>=20 >>>=20 >>> Regars >>> Robin >>>=20 >>> Michael Tremer schreef op wo 04-09-2024 om 23:33 [+0200]: >>>>=20 >>>>=20 >>>>> On 4 Sep 2024, at 22:47, Robin Roevens >>>>> >>>>> wrote: >>>>>=20 >>>>> Hi Adolf >>>>>=20 >>>>> Adolf Belka schreef op wo 04-09-2024 om 21:04 [+0200]: >>>>>> Hi Robin, >>>>>>=20 >>>>>> On 04/09/2024 20:53, Robin Roevens wrote: >>>>>>> Hi all >>>>>>>=20 >>>>>>> While trying to build ipfire, which always has worked quite >>>>>>> effortless, >>>>>>> it now fails while building cdrom: >>>>>>>=20 >>>>>>> --- >>>>>>> # Create the EFI Eltorito image >>>>>>> dd if=3D/dev/zero >>>>>>> of=3D/tmp/cdrom/boot/isolinux/efiboot.img >>>>>>> bs=3D1k >>>>>>> count=3D2880 >>>>>>> 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' >>>>>>>=20 >>>>>>> ERROR: Building cdrom >>>>>>> [ FAIL ] >>>>>>> Check /home/robin/src/ipfire-sandbox/ipfire- >>>>>>> 2.x/log_x86_64/_build.ipfire.log for errors if applicable >>>>>>> [ FAIL ] >>>>>>> --- >>>>>>>=20 >>>>>>> The logfile has no extra or new information. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> --- >>>>>>> $ sudo dd if=3D/dev/zero of=3D./efiboot.img bs=3D1k count=3D2880 >>>>>>> 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 >>>>>>> --- >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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? >>>>>>>=20 >>>>>>> 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? >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> I didn't see any problems but I am running everything on Arch >>>>>> Linux >>>>>> so it always has the latest kernel version. >>>>>>=20 >>>>>> What OS are you running for your build system and what is the >>>>>> kernel >>>>>> version in it? >>>>>=20 >>>>> I'm running openSUSE Tumbleweed currently with kernel 6.10.5. >>>>=20 >>>> Anything in dmesg? Is selinux still a thing? >>>>=20 >>>>> Regards >>>>> Robin >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Those things may help @Michael to figure out what the issue >>>>>> is. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Adolf. >>>>>>=20 >>>>>>> Robin >>>>=20 >>>>=20 >>=20 --===============7302891066202940766==--