Re: Unable to build cdrom: failed to setup loop device

[Robin Roevens <robin.roevens@disroot.org>]

[-- Attachment #1: Type: text/plain, Size: 9236 bytes --]

Hi Michael

~# 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

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,
> 
> 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 :)
> 
> It seems that on Grml the kernel addresses the loop devices in a
> different way:
> 
>   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
>   ...
> 
> On Debian it looks like this:
> 
>   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
>   …
> 
> Note the column with the minor number.
> 
> 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.
> 
> I pushed a change where we simply bind-mount all loop devices of the
> host:
> 
>  
> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=7ad12edfb0d233498410f2afc09753e70de50f80
> 
> That way, we are always compatible.
> 
> Please let me know if this works for you as well.
> 
> -Michael
> 
> > On 10 Sep 2024, at 18:59, Robin Roevens <robin.roevens(a)disroot.org>
> > wrote:
> > 
> > Hi Michael, Adolf, all
> > 
> > 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..
> > 
> > Anyway, problem solved. Thanks for the help!
> > 
> > 
> > Regars
> > Robin
> > 
> > Michael Tremer schreef op wo 04-09-2024 om 23:33 [+0200]:
> > > 
> > > 
> > > > On 4 Sep 2024, at 22:47, Robin Roevens
> > > > <robin.roevens(a)disroot.org>
> > > > wrote:
> > > > 
> > > > Hi Adolf
> > > > 
> > > > Adolf Belka schreef op wo 04-09-2024 om 21:04 [+0200]:
> > > > > Hi Robin,
> > > > > 
> > > > > On 04/09/2024 20:53, Robin Roevens 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 ]
> > > > > > ---
> > > > > > 
> > > > > > 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.
> > > > > > 
> > > > > > ---
> > > > > > $ 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?
> > > > > > 
> > > > > > 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?
> > > > > 
> > > > > 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.
> > > > > 
> > > > > I didn't see any problems but I am running everything on Arch
> > > > > Linux
> > > > > so it always has the latest kernel version.
> > > > > 
> > > > > What OS are you running for your build system and what is the
> > > > > kernel
> > > > > version in it?
> > > > 
> > > > I'm running openSUSE Tumbleweed currently with kernel 6.10.5.
> > > 
> > > Anything in dmesg? Is selinux still a thing?
> > > 
> > > > Regards
> > > > Robin
> > > > 
> > > > 
> > > > > 
> > > > > Those things may help @Michael to figure out what the issue
> > > > > is.
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Adolf.
> > > > > 
> > > > > > Robin
> > > 
> > > 
>