Fail at check_loop_device: device node doesn't exist and `LOOP=` in cycle 1

[JohnTheCoolingFan]

What happened?

I did confirm this problem on the main branch

~~Trying to build armbian on gentoo with docker. Targeting bigtreetech CB2 from https://github.com/bigtreetech/build/tree/CB2~~

~~The fork isn't far behind the main branch, at least in terms of the compile script.~~

The problem seems to be that the script is looking for a loop device, but there aren't any that match a pattern, yet the loop exits on the first iteration with a false positive and empty LOOP variable.

How to reproduce?

(May get updated)

1. Checkout the repo
2. Run ./compile.sh
3. Make all the selections and wait until the failing point

Branch

main (main development branch)

On which host OS are you running the build script and observing this problem?

Other (Gentoo with docker)

Are you building on Windows WSL2?

• [ ] Yes, my Ubuntu/Debian/OtherOS is running on WSL2

Relevant log URL

{message:Error adding document.}

paste.armbian.com/log returns a 500 status code, putting the log here: log-build-3ebc61fd-016c-4aa1-9a41-00194251ff89.log.ans.txt

Also, the log with docker prefix, because the script decided to use docker automatically: log-docker-3ebc61fd-016c-4aa1-9a41-00194251ff89.log.ans.txt

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[github-actions[bot]]

Jira ticket: AR-2132

[JohnTheCoolingFan]

It looks like the script needs to call sudo losetup -f at least once to make sure there is an available device existing. On my machine, there are no devices that match the pattern of /dev/loopX[Y], just /dev/loop-control. After calling the aforementioned command /dev/loop0 appeared. After doing that, I managed to build an image.

[JohnTheCoolingFan]

mknod does get called in check_loop_device, but only with a "found" device, not for creating a missing device. I am putting together a fix for this and will make a PR.

[pessimism]

It looks like the commit to fix this issue got reverted: https://github.com/armbian/build/commit/7da42c8a427fe746adddbef710638b980d7de637

FYI this issue also affects Fedora the same way, only /dev/loop-control present and an losetup -f run needed.

[JohnTheCoolingFan]

Yes, the commit got reverted until a better solution is made. And thanks for reporting that this is also the case on Fedora, it's probably much easier to test with for others than gentoo

[tjhexf]

Happening to me under Fedora, any updates?

[tdleiyao]

manjaro seems to have the same problem

[JohnTheCoolingFan]

My previous attempted solution was calling sudo losetup -f in the script always, but it's problematic because you can't always expect the user to authorize sudo use. It needs to be called on the host and not inside of docker. Sure, you can do this manually, but the script exists for automating it. So I propose this mechanism: check for /dev/loop0 to exist, if it's not there, prompt the user whether to call the sudo command from the script, proceed anyway or possibly have the user running the command manually, or abort the process.

[rpardini]

@JohnTheCoolingFan you can check if inside Docker (where it is always root) or not and adapt. What we can't have is it calling losetup in the outer host in the re-launching scenario (consider armbian/build can run the outer host on MacOS/Darwin and the relaunched in Linux on a VM, as is the case with developers using Intel and Apple Silicon Macs with Docker Desktop / Rancher Desktop / Podman Desktop etc).

[JohnTheCoolingFan]

My current local fix for this is a script in userpatches/extensions/losetup.sh:

function add_host_dependencies__losetup(){
	if [[ ! -e /dev/loop0 ]]; then
		local sudo_prefix="" && is_root_or_sudo_prefix sudo_prefix
		${sudo_prefix} losetup -f
	fi
}