On Fri, 17 Apr 2020, 08:30 bugproxy, <[email protected]> wrote: > ------- Comment From [email protected] 2020-04-17 03:12 EDT------- > (In reply to comment #21) > > Unfortunately installer-arch/ is hardcoded portion of the prefix in the > > internal archive publishing, internal mirroring, and external mirroring, > > thus I cannot change it to legacy-installer-arch. > > > > Also these will only exist for a short period of time until June, so I > don't > > see the point of investing into redoing all of our archive publishing to > > support this. > > > > If you use an internal mirror, you can modify it with extra symlinks to > > symlink legacy-images to images to fix your internal deployment. > However, we > > should work together on moving away your virt-install deployments away > from > > d-i. > > You can install suse,redhat,fedora,debian and old ubuntu guests with > virt-install. cockpit uses virt-install under the covers. virt-manager > uses virt-install under the covers. For any system that has non-Ubuntu > guests as well saying "hey we have something better" is just not > helpful. > > I think the proper fix is to teach virt-install the new installer. We > already have lots of special handling code in virt-install for different > versions of different distros.
Sure, however virt-install currently is not the best way to experience any release of Ubuntu. That's why MAAS, Canonical Distribution of Openstack, LXD, Multipass and all public & private clouds that provide Ubuntu consume and use cloud images, providing a superior experience & configurability than all other distributions mentioned. The above products cater from Multipass "give me a quick VM", to manage a "small cloud" / "very bit cloud". And virt-install using d-i or iso, instead of qcow2 images (with or without unpacked kernel) as inputs for any release of Ubuntu, on any architecture is suboptimal. virt-install should be using cloud images for Ubuntu 12.04 LTS (precise and up). Just like Multipass, lxd-kvm, maas KVM pods, OpenStack. Many other distributions also provide cloud-init enabled images. There was GSOC project to get "cloud-init" support but that only landed on a branch, and hasn't made it into release. It seems to me that virt-install pre-dates the times of distributions providing preinstalled cloud-init enabled qcow2 images. Hence so much automation grew around the suboptimal inputs. Cloud-images is not an ubuntu-only feature. Given that the d-i paths changed, and I can't make them compatible enough, I will reopen the virt-install task to fix path detection in virt-install, at a wishlist priority. I'll open a separate feature request to support cloud-images in virt-install & forward it upstream, also at wishlist priority. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1872941 Title: [Ubuntu 20.04] virt-install fails to detect path after images folder name has changed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1872941/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
