Unable to build cdrom: failed to setup loop device

Unable to build cdrom: failed to setup loop device

[Robin Roevens]

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

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?

Robin

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

[Adolf Belka]

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

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?

Those things may help @Michael to figure out what the issue is.

Regards,

Adolf.

> Robin

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

[Robin Roevens]

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

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.

Regards
Robin


> 
> Those things may help @Michael to figure out what the issue is.
> 
> Regards,
> 
> Adolf.
> 
> > Robin

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

[Michael Tremer]

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



> 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

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

[Robin Roevens]

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

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

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

[Michael Tremer]

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

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

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

[Robin Roevens]

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

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

[Michael Tremer]

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

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

[Robin Roevens]

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

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

[Michael Tremer]

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

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

[Michael Tremer]

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

Hello Robin,

> On 4 Sep 2024, at 20:53, Robin Roevens <robin.roevens(a)disroot.org> 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 ]
> ---

What is the output of “losetup” after this fails?

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

Does this also work in shell?

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

It creates new namespaces in which root is less privileged than in the first namespace.

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

Apart from that, as Adolf requested, please provide us with some more information about your kernel and distribution.

-Michael

> Robin

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

[Robin Roevens]

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

Hi Michael

Michael Tremer schreef op wo 04-09-2024 om 21:38 [+0200]:
> Hello Robin,
> 
> > On 4 Sep 2024, at 20:53, Robin Roevens <robin.roevens(a)disroot.org>
> > 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 ]
> > ---
> 
> What is the output of “losetup” after this fails?

Just a list snap files mounted by snapd. Nothing from ipfire.


> 
> > 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.
> 
> Does this also work in shell?

Yes, it works also in a root shell.

> 
> > 
> > ---
> > $ 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?
> 
> It creates new namespaces in which root is less privileged than in
> the first namespace.

Can it be that there is some leftover somewhere from older builds when
it had more privileges? Not that I can imagine what could still be
there that it now prevents mounting a freshly created file on loopback.

> 
> > 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?
> 
> Apart from that, as Adolf requested, please provide us with some more
> information about your kernel and distribution.

I'm running openSUSE Tumbleweed on kernel 6.10.5.

> 
> -Michael
> 
> > Robin
> 

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

[Michael Tremer]

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

Hello,

> On 4 Sep 2024, at 22:58, Robin Roevens <robin.roevens(a)disroot.org> wrote:
> 
> Hi Michael
> 
> Michael Tremer schreef op wo 04-09-2024 om 21:38 [+0200]:
>> Hello Robin,
>> 
>>> On 4 Sep 2024, at 20:53, Robin Roevens <robin.roevens(a)disroot.org>
>>> 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 ]
>>> ---
>> 
>> What is the output of “losetup” after this fails?
> 
> Just a list snap files mounted by snapd. Nothing from ipfire.
> 
> 
>> 
>>> 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.
>> 
>> Does this also work in shell?
> 
> Yes, it works also in a root shell.
> 
>> 
>>> 
>>> ---
>>> $ 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?
>> 
>> It creates new namespaces in which root is less privileged than in
>> the first namespace.
> 
> Can it be that there is some leftover somewhere from older builds when
> it had more privileges? Not that I can imagine what could still be
> there that it now prevents mounting a freshly created file on loopback.

I would have guessed that you are running out of loop devices, but you have ruled that one out already.

Did I just miss the reason why mount is complaining?

>>> 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?
>> 
>> Apart from that, as Adolf requested, please provide us with some more
>> information about your kernel and distribution.
> 
> I'm running openSUSE Tumbleweed on kernel 6.10.5.
> 
>> 
>> -Michael
>> 
>>> Robin