[pve-devel] [PATCH container] lxc: fall back to 'unmanaged' on unknown ostype

Thomas Lamprecht thomas at lamprecht.org
Sun May 17 22:44:38 CEST 2020


Am 5/17/20 um 10:10 AM schrieb Arnout Engelen:
> On Sun, May 17, 2020 at 7:16 AM Dietmar Maurer <dietmar at proxmox.com> wrote:
>>> Rather than failing, it would be nice to fall back to 'unmanaged' when
>>> the ostype cannot be determined/found.
>> Why exactly would that be nice? FWICT it would start the container
>> with wrong and unexpected setup.
> It would make the scenario of starting an unmanaged image without explicit
> parameters work.
>
> When using the 'create CT' button in the web UI, PVE/LXC/Setup.pm will
> auto-detect the ostype. When it fails to detect the ostype, like will be the
> case for a 'raw' image that should be run unmanaged, it dies. When
> instead of dying it would assume 'unmanaged', this would work for such
> 'raw' images. Indeed if it was an image that needs to be run 'managed'
> this change would make it fail later rather than earlier.

First, thanks for sending out a contribution.

I'd rather add recognizing an explicit "unmanaged" type from the CTs
`/etc/os-release` or if really only return this on setup if there's no 
os-release
and no other releasefile, which then at least ensures that modern 
distros (which
most ship /etc/os-release)are wrongly mapped to "unmanaged".

Fallback in update_pct_config for when no ostype is set in the config 
for existing
CT is not OK, it must be recognizable on setup..

> While I agree failing early is generally good practice, here running the
> image 'unmanaged' when no OS was detected seems like a more
> optimistic choice, as it fixes the 'raw unmanaged image' scenario.


This is something most user won't ever need.. Why is it a problem to set the
unmanaged OS type through CLI/API?

cheers,
Thomas




More information about the pve-devel mailing list