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

[Michael Tremer <michael.tremer@ipfire.org>]

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

Perfect. Thank you for the feedback!

> On 14 Sep 2024, at 16:01, Robin Roevens <robin.roevens(a)disroot.org> wrote:
> 
> 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
>>>>>> 
>>>>>> 
>>>> 
>>