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: Sat, 14 Sep 2024 17:01:24 +0200 Message-ID: <040970b49222b1fa0ac1b6dbf3ae201a7d450e32.camel@roevenslambrechts.be> In-Reply-To: <5A63D8F5-A7DA-448E-8960-2F0DAF4459D1@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7243515901337338395==" List-Id: --===============7243515901337338395== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael This change seems to work correctly.=C2=A0 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 Regards Robin Michael Tremer schreef op do 12-09-2024 om 13:59 [+0100]: > Hello Robin, >=20 > Could you give this one a test, please? >=20 > =C2=A0 > https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D2b0ecf4df598d= 89694442700e5da9acbd502c923 >=20 > -Michael >=20 > > On 11 Sep 2024, at 20:21, Robin Roevens > > wrote: > >=20 > > Hi Michael > >=20 > > ~# ll /dev/loop* > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 0=C2=A0 1 sep 22:54 /dev/loop0 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 1=C2=A0 1 sep 22:54 /dev/loop1 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0 10=C2=A0 1 sep 22:54 /dev/loop10 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0 11=C2=A0 1 sep 22:54 /dev/loop11 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0 12=C2=A0 1 sep 22:54 /dev/loop12 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0 13=C2=A0 1 sep 22:54 /dev/loop13 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0 14=C2=A0 7 sep 23:24 /dev/loop14 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0 15=C2=A0 3 sep 12:14 /dev/loop15 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 2=C2=A0 1 sep 22:54 /dev/loop2 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 3=C2=A0 1 sep 22:54 /dev/loop3 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 4 10 sep 21:44 /dev/loop4 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 5=C2=A0 1 sep 22:54 /dev/loop5 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 6=C2=A0 1 sep 22:54 /dev/loop6 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 7=C2=A0 1 sep 22:54 /dev/loop7 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 8=C2=A0 1 sep 22:54 /dev/loop8 > > brw-rw---- 1 root disk=C2=A0 7,=C2=A0=C2=A0 9=C2=A0 1 sep 22:54 /dev/loop9 > > crw-rw---- 1 root disk 10, 237=C2=A0 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 > > > =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=3D7ad12edfb= 0d233498410f2afc09753e70de50f80 > > >=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) copi= ed, 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/efibo= ot.img' > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 mount -o loop /tmp/cdrom/boot/isolin= ux/efiboot.img > > > > > > > > /tmp/efiboot.img > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 mount: /tmp/efiboot.img: failed to s= etup loop > > > > > > > > device > > > > > > > > for > > > > > > > > /tmp/cdrom/boot/isolinux/efiboot.img. > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 make: *** [cdrom:184: /usr/src/log/c= drom] Error 32 > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 make: Leaving directory '/usr/src/lf= s' > > > > > > > >=20 > > > > > > > > ERROR: Building cdrom > > > > > > > > [ FAIL ] > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 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=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 >=20 --===============7243515901337338395==--