On Sun, May 17, 2020 at 10:44 PM Thomas Lamprecht <tho...@lamprecht.org> wrote: > Am 5/17/20 um 10:10 AM schrieb Arnout Engelen: > > It would make the scenario of starting an unmanaged image without explicit > > parameters work. > > 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".
Requiring an explicit "unmanaged" in `/etc/os-release` means proxmox will only auto-detect CTs that were explicitly written for proxmox... only falling back to 'unmanaged' when /etc/os-release does not exist sounds fine to me, though. I'll create an updated version of this patch that implements these 2 paths. > 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. Right, I was less sure about that part. > > When using the 'create CT' button in the web UI, PVE/LXC/Setup.pm will > > auto-detect the ostype. > > > > (...) > > > > 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? AFAICT the 'create CT' web UI does not currently allow setting the ostype. This of course could be changed/fixed, but the auto-detection that is already there seems nice. I haven't used the API yet, and wanted to avoid using the CLI (which requires root) where possible (though it looks like I'll have to compromise there to get access to some features anyway ;) ). Kind regards, Arnout _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
