Hi, sorry, I forgot to set a subject in my initial email. Fixing this now. Please CC me, because I'm not subscribed to debian-cloud@l.d.o. >Quoting Johannes Schauer (2019-11-17 08:44:32) >> due to limitations of salsa CI and maybe bugs it is currently not possible >> to create a virtual machine image that can be booted with qemu on the salsa >> CI runners. Maybe it's possible to download a disk image from [1] to >> circumvent that limitation? >> >> So first a feature request: Would it be possible to provide a stable URL to >> download the latest Debian sid and buster images? Currently, the last directory >> on [1] is named by date with an index on it and it would be an additional step >> to parse the HTML to figure out which directory is the latest. Maybe a symlink >> could be placed which always points to the latest image directory? >> >> Second feature request: the qcow2 images seem to have a virtual size of 2G. >> This is a bit small to do anything useful in them. Could this size be bumped to >> something larger? Because of how the qcow2 format works, this would not require >> more disk space for the image itself. > Basically, it's useless to make the disk bigger, because it is resized > on-demand at boot time by cloud-init. I assume then, that if I run a "qemu-img resize" before booting the image, then cloud-init will take care of adjusting the partition inside the image to the new disk size? Unfortunately I cannot test this myself because I'm still at a loss as how to log into the system. >> Then I have a few questions about the stuff that you host on [1] and it would >> probably be best if you don't write your answer as an email reply to me but >> enhance the docs at [1]. Thanks! >> >> 1. From what is written in the docs at the root it's obvious what the azure, >> ec2 and gce files are. But what is the difference between generic, >> genericcloud and nocloud files? > Basically, generic and genericcloud are images suitable for OpenStack, > and probably others (like Digital Ocean). The cloud one is using the cloud > kernel, while the other, the standard kernel, so it would work for something > like OpenStack baremetal (aka Ironic). Yes, they are different from the > OpenStack ones, and you can choose between one or the other. My take is that > we still don't have full feature parity (like generating the image only when > needed), so probably the OpenStack image is currently best. We're looking > into fixing the situation for Debian Bullseye. And what are the "nocloud" images? >> 2. What is the root password for the qcow2 images? > There's no root password. In the cloud, you're supposed to have cloud-init > fill-up /home/debian/.ssh/authorized_keys with the key provided by the > metadata server. As I explained in the first paragraph of my initial email, I'm trying to find an alternative to creating a bootable disk image myself that I can then use on salsa CI runners (for example inside autopkgtests). So there is no metadata server. >> 3. How can I connect via ssh? Is there a public key hosted somewhere? > On which environment are you booting the images? As I said in the beginning, I'm trying to find images that I can boot inside salsa CI runners. So just with qemu I guess. > Unfortunately, the EC2 image have a non-standard username. In OpenStack, it's > normally "debian" as username, which is what cloud-init does. Each time, this > can be overridden by metadata. I guess that is more "cloud" stuff that I don't actually want. I'm just looking for already prepared disk images I can boot into. >> 4. What do the *-backports directories contain? Is it just stable releases >> with the backports repository enabled? Or have packages inside been >> upgraded to their backports versions? > Even in the normal version, backports are activated (just like with a > standard Debian system), but no packages from backports has been added. I'm > not sure what Waldi did in the backports folder, but looking into it (ie: in > the .json), it looks like only the kernel has been taken from > buster-backports. >> 5. In [1] it says that there are SHA1SUMS and SHA256SUMS files and *.sign >> files. But I don't see any for sid/daily. Where are those? > It's still a missing feature compared to what I did over the last 3 Debian > releases for the OpenStack images. Hopefully, we'll get this fixed. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature