[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Unidentified subject!



On 11/17/19 8:44 AM, Johannes Schauer wrote:
> 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.

> 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.

> 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.

> 3. How can I connect via ssh? Is there a public key hosted somewhere?

On which environment are you booting the images? 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.

> 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.

Cheers,

Thomas Goirand (zigo)


Reply to: