Requirement of Loopback Device Support

[jlpoolen]

The build script requires the use of one or more loopback devices.

 ./parsers/makeimage/makeimage:119:# Use losetup to treat the image file as a block device
 ./parsers/makeimage/makeimage:120:system(f"losetup --find {image['name']}")
 ./parsers/makeimage/makeimage:121:p = subprocess.Popen(["/sbin/losetup", "-l", "-J", "-j", image['name']], stdout=subprocess.PIPE)

The makeimage script is invoked after the compilation which, in my case with an AMD Bulldozer 8210 ( year 2013?), took about 8 days and nights to compile. I then was faced with a failure because my system, as currently configured (see infra VM), does not have a loopback device:

running jobs [(<Popen: returncode: None args: ['/home/jlpoole/Build.Dist/parsers/makeimage/...>, 'makeimage')]
rm -f GenPi64OpenRC.img
truncate -s 8G GenPi64OpenRC.img
sync
parted --script GenPi64OpenRC.img mklabel msdos
sfdisk --label dos --disk-id GenPi64OpenRC.img 0xc1a58a3a
Disk identifier changed from 0x4c73bb67 to 0xc1a58a3a.

The partition table has been altered.
Syncing disks.
parted --script GenPi64OpenRC.img mkpart primary 1MiB 256MiB
sfdisk --label dos GenPi64OpenRC.img --part-type 1 c

The partition table has been altered.
Syncing disks.
sfdisk --label dos --activate GenPi64OpenRC.img 1
The bootable flag on partition 1 is enabled now.

The partition table has been altered.
Syncing disks.
parted --script GenPi64OpenRC.img mkpart primary 256MiB 100%
sfdisk --label dos GenPi64OpenRC.img --part-type 2 83

The partition table has been altered.
Syncing disks.
losetup --find GenPi64OpenRC.img
losetup: cannot find an unused loop device
FATAL: JOBFAILED  makeimage
FATAL: JOBFAILED  packgenpi
FATAL: JOBFAILED  genpi64-lite-finalize
run complete.
jlpoole@jenk ~/Build.Dist $

Support for loopback devices is determined by the kernel, specifically

  CONFIG_BLK_DEV_LOOP

I'm using a virtual machine [guest] ("VM") on the Xen hypervisor running a Gentoo based kernel.

 hermes /usr/src/linux # uname -a
 Linux hermes 5.15.11-gentoo-x86_64 #1 SMP Sun Jan 16 09:24:16 -00 2022 x86_64 AMD FX(tm)-8120 Eight-Core Processor AuthenticAMD GNU/Linux
 hermes /usr/src/linux #

The VMs share the same kernel as Dom0, yet I do not have my VMs configured to load modules nor do I expose the modules to the VMs as a matter of course. In my case, the kernel configuration was set to manual:

 hermes /usr/src/linux # cat -n .config  |grep DEV_LOOP
   2402  CONFIG_BLK_DEV_LOOP=m
   2403  CONFIG_BLK_DEV_LOOP_MIN_COUNT=0
 hermes /usr/src/linux # 

So I have a VM where loopback devices are not possible in the current configuration. I'll overcome that and will update this Issue.

I recommend that a check/test for loopback capabitility be made at the outset so if someone is on a VM and does not control the hypervisor and cannot have a loopback, they will not have ventured down the path of compiling for many days only to learn they may be out of luck re: loopback devices.

[jlpoolen]

I also found my kernel did not have btrfs built-in, though I was able to load the module modprobe btrfs. Trend seems to be not to have btrfs automatically built into a kernel.

My kernel was the standard Gentoo and required loopback and btrfs to be loaded as modules:
Linux jenk 5.15.11-gentoo-x86_64 #1 SMP Sun Jan 16 09:24:16 -00 2022 x86_64 AMD FX(tm)-8120 Eight-Core Processor AuthenticAMD GNU/Linux