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

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

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

Hi Michael

This change seems to work correctly. 

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. 

Regards
Robin


Michael Tremer schreef op do 12-09-2024 om 13:59 [+0100]:
> Hello Robin,
> 
> Could you give this one a test, please?
> 
>  
> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=2b0ecf4df598d89694442700e5da9acbd502c923
> 
> -Michael
> 
> > On 11 Sep 2024, at 20:21, Robin Roevens <robin.roevens(a)disroot.org>
> > wrote:
> > 
> > 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
> > > > > 
> > > > > 
> > > 
>