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

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

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

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