docker build fails at losetup

[tedder]

I'm building with Docker on Ubuntu. I've download the Pi lite image and used modprobe. Here's the command I'm running:

time docker run -it -v `pwd`:/distro --name mydistro_builder --device /dev/loop-control guysoft/custompios:devel /CustomPiOS/nightly_build_scripts/custompios_nightly_build

It fails as follows:

Device                                Boot Start     End Sectors  Size Id Type
2018-11-13-raspbian-stretch-lite.img1       8192   98045   89854 43.9M  c W95 FAT32 (LBA)
2018-11-13-raspbian-stretch-lite.img2      98304 4464639 4366336  2.1G 83 Linux

Command (m for help): The partition table has been altered.
Syncing disks.

++++ losetup -f --show -o 50331648 2018-11-13-raspbian-stretch-lite.img
losetup: 2018-11-13-raspbian-stretch-lite.img: failed to set up loop device: No such file or directory
+++ LODEV=
+ exit 1

Looking at common.sh around line 250, the code looks like this:

  echo "Resizing file system to $size MB..."
  start=$(sfdisk -d $image | grep "$image$partition" | awk '{print $4-0}')
  offset=$(($start*512))

  LODEV=$(losetup -f --show -o $offset $image)

For some reason $image doesn't contain the full name and it is needed for that to run. Here's the full build log. Thoughts?

[guysoft]

1. What version of ubuntu?
2. Did you try running modprobe loop
3. Can you post your docker-compose.yml?

It looks like the build fails to find the loop devices.

[tedder]

ubuntu 18.04. I'm not using a docker-compose, literally just running it on the commandline. modprobe doesn't do anything, it appears to be properly built-in:

$ grep loop /lib/modules/4.15.0-43-generic/modules.builtin
kernel/drivers/block/loop.ko

Inside the docker container I see the loop-control, is there another way to test or verify?

# ls -l /dev/loop*
crw-rw---- 1 root disk 10, 237 Feb 12 22:37 /dev/loop-control

[guysoft]

is the container privileged? Can you post the creation command?

[tedder]

that run is how I'm creating and running it- I mean, I'm not building custompios locally, just using your version from Dockerhub. I changed docker run to run bash to inspect rather than throwing it away.

But you're right. I forgot --privileged. It's running now.

[tedder]

I generated a ~350mb image for octopi. mind checking it out? If it seems sane I'll try a couple others and then figure out how to automate builds.

[guysoft]

@tedder Can you share the actual distro you are building with its build log?

Because I can't tell what needs to be there without seeing the actual configuration.

[guysoft]

1, Ok, I see you are building OctoPi from DIST_NAME=OctoPi in you previous log. 2. You can test an image using qemu_boot.sh see: https://github.com/guysoft/CustomPiOS/wiki/FAQ#can-i-run-my-distro-on-qemu-to-simulate

3. The image you linked is just plain raspbian, it was not touched by OctoPi build system. I can see because its SHA1 matches the one on Raspberrypi lite at:

86e1b50e956098ab75042898b7c36c7be8d5c5cb  ./2018-11-13-raspbian-stretch-lite.zip

https://downloads.raspberrypi.org/raspbian_lite/images/

The images are saved to the workspace folder as described here.

[tedder]

Thanks. Here's the build log and here's the actual image zip (oops!).

When running qemu_boot it's assuming I have some hardware on my server; to make it run I hacked it real quick with QEMU_AUDIO_DRV=none and -vnc :0. I'll have to do more testing elsewhere or just 'burn' it onto a Pi.

[guysoft]

Looks good, BUILD SUCCEEDED! :)

[guysoft]

Also if you want to look how CI was done take a look at: https://jenkins.gnethomelinux.com/job/OctoPi/

[guysoft]

Closing if no reply, understand the issue is resolved.

[guysoft]

Ok, i also got this issue when I had no network settings in the docker container.

The solusion came from here and was to recreate the docker network bridge.