[Bug 1872941] Comment bridged from LTC Bugzilla

Dimitri John Ledkov launchpad at surgut.co.uk
Fri Apr 17 09:49:17 UTC 2020


On Fri, 17 Apr 2020, 08:30 bugproxy, <bugproxy at us.ibm.com> wrote:

> ------- Comment From cborntra at de.ibm.com 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
Foundations Bugs, which is subscribed to debian-installer in Ubuntu.
https://bugs.launchpad.net/bugs/1872941

Title:
  [Ubuntu 20.04] virt-install fails to detect path after images folder
  name has changed

Status in Ubuntu CD Images:
  Opinion
Status in Ubuntu on IBM z Systems:
  Won't Fix
Status in debian-installer package in Ubuntu:
  Won't Fix
Status in virt-manager package in Ubuntu:
  Invalid

Bug description:
  Installer version: Latest
  https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x

  Description/Reproduction:
  Start virt-install with the following options:

  virt-install \
  --name ubuntu20-guest1 \
  --memory 4096 \
  --vcpus 4 \
  --disk "size=4" \
  --location http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x \
  --network "network=default" 

  Error:
  ERROR    Error validating install location: Could not find an installable distribution at 'http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x'

  The location must be the root directory of an install tree.
  See virt-install man page for various distro examples.

  
  Looking at previous releases I would guess it expects an "images" directory instead of the new "classic-images" directory. I'm aware of the workaround to specify kernel/initramfs directly but that shouldn't be a solution.

  == Comment: #2 - Andre Wild1 <Andre.Wild1 at ibm.com> - 2020-04-15 03:51:21 ==
  (In reply to comment #0)
  > Installer version: Latest
  > https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x
  > 

  Sorry I've copied the wrong link. This is the link I've used successfully in the past:
  http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1872941/+subscriptions



More information about the foundations-bugs mailing list