From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer <michael.tremer@ipfire.org> To: development@lists.ipfire.org Subject: Re: Unable to build cdrom: failed to setup loop device Date: Mon, 16 Sep 2024 18:17:40 +0100 Message-ID: <204F51B6-C547-427E-A8D3-AA7004F2394E@ipfire.org> In-Reply-To: <040970b49222b1fa0ac1b6dbf3ae201a7d450e32.camel@roevenslambrechts.be> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5881646283616049628==" List-Id: <development.lists.ipfire.org> --===============5881646283616049628== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Perfect. Thank you for the feedback! > On 14 Sep 2024, at 16:01, Robin Roevens <robin.roevens(a)disroot.org> wrote: >=20 > Hi Michael >=20 > This change seems to work correctly.=20 >=20 > 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.=20 >=20 > Regards > Robin >=20 >=20 > Michael Tremer schreef op do 12-09-2024 om 13:59 [+0100]: >> Hello Robin, >>=20 >> Could you give this one a test, please? >>=20 >> =20 >> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D2b0ecf4df598= d89694442700e5da9acbd502c923 >>=20 >> -Michael >>=20 >>> On 11 Sep 2024, at 20:21, Robin Roevens <robin.roevens(a)disroot.org> >>> 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=3D7ad12edfb0= d233498410f2afc09753e70de50f80 >>>>=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 >>>>> <robin.roevens(a)disroot.org> >>>>> 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 >>>>>>> <robin.roevens(a)disroot.org> >>>>>>> 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 >>=20 --===============5881646283616049628==--