Am 5/17/20 um 10:10 AM schrieb Arnout Engelen:
On Sun, May 17, 2020 at 7:16 AM Dietmar Maurer <diet...@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
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
