From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Roevens To: development@lists.ipfire.org Subject: Re: Unable to build cdrom: failed to setup loop device Date: Wed, 11 Sep 2024 21:21:08 +0200 Message-ID: <69aa5adfb2c63bca5212b7c39eb3830fbcd5e052.camel@roevenslambrechts.be> In-Reply-To: <639C7C0A-6F88-4662-AA2B-4E272CC2DDA6@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3869741913033830498==" List-Id: --===============3869741913033830498== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael ~#=C2=A0ll /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, >=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 > =C2=A0 root(a)grml /mnt/ipfire-2.x (git)-[next] # ll /dev/loop* > =C2=A0 brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 0 Sep 11 09:29 /dev/loop0 > =C2=A0 brw-rw---- 1 root disk=C2=A0 7,=C2=A0 16 Sep 11 09:39 /dev/loop1 > =C2=A0 brw-rw---- 1 root disk=C2=A0 7,=C2=A0 32 Sep 11 09:29 /dev/loop2 > =C2=A0 brw-rw---- 1 root disk=C2=A0 7,=C2=A0 48 Sep 11 09:29 /dev/loop3 > =C2=A0 ... >=20 > On Debian it looks like this: >=20 > =C2=A0 root(a)michael:/build/ipfire-2.x# ll /dev/loop* > =C2=A0 brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 0 Aug 22 09:20 /dev/loop0 > =C2=A0 brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 1 Sep=C2=A0 9 19:23 /dev= /loop1 > =C2=A0 brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 2 Aug 22 09:07 /dev/loop2 > =C2=A0 brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 3 Aug 22 09:07 /dev/loop3 > =C2=A0 =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 > =C2=A0 > https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D7ad12edfb0d23= 3498410f2afc09753e70de50f80 >=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 > > > > > > --- > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 # Create the EFI Eltorito image > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 dd if=3D/dev/zero > > > > > > of=3D/tmp/cdrom/boot/isolinux/efiboot.img > > > > > > bs=3D1k > > > > > > count=3D2880 > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 2880+0 records in > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 2880+0 records out > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 2949120 bytes (2.9 MB, 2.8 MiB) copied, = 0.00453183 s, > > > > > > 651 > > > > > > MB/s > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 mkdosfs -F 12 -n "IPFIRE_EFI" > > > > > > /tmp/cdrom/boot/isolinux/efiboot.img > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 mkfs.fat 4.2 (2021-01-31) > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 # Mount the EFI image > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 mkdir -pv /tmp/efiboot.img > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 mkdir: created directory '/tmp/efiboot.i= mg' > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 mount -o loop /tmp/cdrom/boot/isolinux/e= fiboot.img > > > > > > /tmp/efiboot.img > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 mount: /tmp/efiboot.img: failed to setup= loop device > > > > > > for > > > > > > /tmp/cdrom/boot/isolinux/efiboot.img. > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 make: *** [cdrom:184: /usr/src/log/cdrom= ] Error 32 > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 make: Leaving directory '/usr/src/lfs' > > > > > >=20 > > > > > > ERROR: Building cdrom > > > > > > [ FAIL ] > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 Check /home/robin/src/ipfire-sandbox/ipf= ire- > > > > > > 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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2,8M=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0 2,8M=C2=A0=C2=A0 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 --===============3869741913033830498==--