Closed garzdin-schwarz closed 8 months ago
This is not a bug, it's a problem on the way you run Image Factory, which is not described in the issue.
Image Factory does need to access loop devices at the moment, so if you don't give it access to it, it won't work.
Running modprobe
from a container makes zero sense, run it on the host.
Make sure losetup
works for you on the host first, then move towards ensuring that the container is privileged and has access to /dev
.
In Kubernetes this would be:
securityContext:
privileged: true
volumes:
- name: host-dev
hostPath:
path: /dev
@smira That's fine, but it's not documented anywhere. Also it doesn't work at https://factory.talos.dev :)
Image Factory works, there's no .qcow2.tar.gz
, and qcow2 is not directly available for metal
(but that's not in the Image Factory).
So is it the imager
then? Not sure I understand, because after looking at the code qcow2 images are available and I've successfully converted a raw
metal image from the image-factory to qcow2
with qemu-img
, which the imager
also uses under the hood. And it works when booted from.
And as far as I understand the .tar.gz
extension is supported as that only compresses the output image. But even without it this should work.
metal
in fact is a standard imager
profile which is in Talos, but this doesn't configure QCOW2 settings, so it won't generate QCOW2 image. You can still download raw
and convert, but if that needs to be supported, the support should start with Talos.
So we should rather collect what we're looking for - e.g. we want qcow2
on the fly, and create a feature request for it.
Or you don't know how to deploy - create a request for it, start by sharing your steps, helm charts, etc.
That would be more helpful.
metal
in fact is a standardimager
profile which is in Talos, but this doesn't configure QCOW2 settings, so it won't generate QCOW2 image. You can still downloadraw
and convert, but if that needs to be supported, the support should start with Talos.
What do you mean that the support should start with Talos? There's already QCOW2-formatted images for Exoscale and Oracle. For the Metal platform it'd be dependant on what hypervisor you run it on. In my case I'm running it on QEMU, so QCOW2 images are fully supported.
To me it seems like this is only an artificial limition of the imager. I tried supplying a custom profile to it:
arch: amd64
platform: metal
secureboot: false
version: v1.6.1
input:
kernel:
path: /usr/install/amd64/vmlinuz
initramfs:
path: /usr/install/amd64/initramfs.xz
baseInstaller:
imageRef: ghcr.io/siderolabs/installer:v1.6.1
output:
kind: image
imageOptions:
diskSize: 1306525696
diskFormat: qcow2
outFormat: .tar.gz
But that didn't output a valid QCOW2 image.
You're moving in the right direction, qcow2 requires more option, look for qcow profiles. Either way, if you see something missing, please open a feature request, we will look into that.
The image-factory builds ISOs fine. But when requesting a different type of image like a RAW image or QCOW2 it fails with the following error:
failed to setup loopback device: exit status 1: losetup: cannot find an unused loop device\n
When looking at the logs of the image-factory I see:
Executing
modprobe loop
inside of the running image-factory container errors out with: