buildd fails to build trusty based images with `mknod: ‘/dev/loopX’: File exists` errors
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
launchpad-buildd |
Fix Released
|
Critical
|
Colin Watson |
Bug Description
While trying to build trusty docker images, we are hitting the follow type of error each time (with an apparently random loop device number). We have seen this on every trusty docker build this week. These builds had not been performed since August, when it was successful.
RUN: /usr/share/
Forking launchpad-buildd slave process...
Kernel version: Linux bos01-arm64-034 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:31:48 UTC 2017 aarch64
Buildd toolchain package versions: launchpad-
Syncing the system clock with the buildd NTP service...
12 Oct 16:16:54 ntpdate[1808]: adjust time server 10.211.37.1 offset 0.081996 sec
RUN: /usr/share/
Creating target for build LIVEFSBUILD-112474
RUN: /usr/share/
Starting target for build LIVEFSBUILD-112474
mknod: ‘/dev/loop5’: File exists
Traceback (most recent call last):
File "/usr/share/
sys.
File "/usr/share/
return args.operation.
File "/usr/lib/
self.
File "/usr/lib/
"b", "7", str(minor)])
File "/usr/lib/
subprocess.
File "/usr/lib/
raise CalledProcessEr
subprocess.
RUN: /usr/share/
Stopping target for build LIVEFSBUILD-112474
RUN: /usr/share/
Removing build LIVEFSBUILD-112474
The above log is from https:/
Here are some other examples:
https:/
https:/
Related branches
- William Grant: Approve (code)
-
Diff: 63 lines (+34/-0)3 files modifieddebian/changelog (+7/-0)
lpbuildd/target/lxd.py (+20/-0)
lpbuildd/target/tests/test_lxd.py (+7/-0)
- William Grant: Approve (code)
-
Diff: 248 lines (+122/-41)3 files modifieddebian/changelog (+8/-0)
lpbuildd/target/lxd.py (+33/-20)
lpbuildd/target/tests/test_lxd.py (+81/-21)
As of systemd 211 (i.e. >= vivid), the default udev rules arrange to not create loop devices. In older releases, udev creates those, but we can race with it on startup.
I think we need to:
* wait until the container has done more of its startup work before proceeding
* check whether /dev/loop* exist before creating them
Neither of these is sufficient on its own.