Call losetup -f to make sure loop device exists

[JohnTheCoolingFan]

Description

1. Added a call to losetup -f which would make sure that there is a loop device that exists and available for use. See Fail at check_loop_device: device node doesn't exist and LOOP= in cycle 1 #6568
2. Added doas support to is_root_or_sudo_prefix function. I will understand if this change would be asked to be removed, added just because I use doas.

Jira reference number AR-2132

How Has This Been Tested?

Building using the command ./compile.sh BOARD=orangepi5 BRANCH=legacy BUILD_DESKTOP=no BUILD_MINIMAL=no KERNEL_CONFIGURE=no KERNEL_GIT=shallow RELEASE=bookworm on my machine.

Checklist:

Please delete options that are not relevant.

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings

[JohnTheCoolingFan]

As outlined in the "How Has This Been Tested?", there is currently a problem with the fix, which is why I'm making this PR a draft.

[igorpecovnik]

For some reason fails on the first try, creating the device and not finding it, but the second run succeeds.

Try to keep this function in host_prepare part. But on the other hand this is only needed for compiling images.

[JohnTheCoolingFan]

Ok, I've moved the call to the command way earlier, but currently I'm not sure where its place really is.

I've fixed the issue of having to run it 2 times by moving the call to losetup to host (before docker), put it in entrypoint... But I feel like that would mess with usage of ./compile.sh with other commands, which is why I would like to move it to docker and build, with the latter having an if check for running inside of docker. Although I'm not sure whether that's necessary. And I'm unsure what the call chain is in the case of ./compile.sh <settings with no command>

[JohnTheCoolingFan]

Rebased on main properly and squashed the moving around, removed the issue from the PR root comment and I think this is ready for review.

[igorpecovnik]

looks ok, it works

[rpardini]

Complete and general breakage due to this.
@igorpecovnik Have reverted on my fork

[igorpecovnik]

I check if it breaks. It didn't ... so I merge as there was no other complains.

[igorpecovnik]

This is an attempt to enable build framework execution on Gentoo. Which I don't mind if it doesn't harm us. Where is the problem?

[rpardini]

Dunno, seems it tries to use sudo even in the docker case.

[viraniac]

Yes, it breaks build on MacOS. The ensure_loop_exists must only run when ARMBIAN_RELAUNCHED is set to yes

[viraniac]

Also I don't see a point why ensure_loop_exists needs to be added to cli-docker.sh.

[JohnTheCoolingFan]

The issue on my machine was that there were no loop devices created by default unless I try to find one using losetup -f, which also requires root privileges. And even though it can be called inside docker and would output a valid loop device, the script didn't find it (presumably because it wasn't available in the docker container). But if it's called before the docker container is launched, everything works. I am using Gentoo with a distribution kernel which is not configured to create a number of free loop devices by default, only when needed. It depends on the kernel configuration and kernel command line. Technically, it's not specific to Gentoo, it just happens to be that Gentoo's distribution kernel config has such values by default.

The PR breaking builds on MacOS is a major issue, which would justify the revert of the merge, if possible. This PR only provides a dirty quickfix to go around a problem in the part of the script that finds a free loop device. The problem is that it sets the result to an empty string and "succeeds" on the first try, breaking because of the edge case that there are no /dev/loopX loop devices at all

[JohnTheCoolingFan]

Also I don't see a point why ensure_loop_exists needs to be added to cli-docker.sh.

As I've explained, calling losetup -f inside docker will output a free loop device path, but the script fails to find it.

[viraniac]

As I've explained, calling losetup -f inside docker will output a free loop device path, but the script fails to find it.

Yes, got that from the previous post. It was just that we both commented at almost the same time. There was no need to explain it twice.

May I suggest a workaround? Create a file in userpatches/extensions with the following content

function add_host_dependencies__losetup(){
	local sudo_prefix="" && is_root_or_sudo_prefix sudo_prefix
	${sudo_prefix} losetup -f
}

If that works for you, we can probably revert this change until a better version is proposed.

[JohnTheCoolingFan]

Yes, that works, although I still need to add the doas support for it to run on my machine.

[igorpecovnik]

@JohnTheCoolingFan OK, make revert PR and once this is better tested, new one. This would be IMO best path from current situation.

[JohnTheCoolingFan]

I'll also put the doas support into a separate PR