Score:0

qemu+kvm, unhelpful virt-install --location error

pr flag

I have fought with qemu and virt-install to no avail, and I am completely stuck with an unhelpful error message that gets me absolutely nowhere.

FIRST, some necessary system configuration:

Base metal operating system is Ubuntu Server 20.04 LTS. No desktop environment. VM operating system will be Ubuntu Server 18.04 LTS. No desktop environment.

I have a 60GB LVM at /dragonode that I intend to use as the primary storage volume for this virtual machine:

calyodelphi@dragonweyr:~$ lsblk
NAME                           MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
[loop partitions omitted]
nvme0n1                        259:0    0   477G  0 disk 
├─nvme0n1p1                    259:1    0   512M  0 part /boot/efi
├─nvme0n1p2                    259:2    0     1G  0 part /boot
└─nvme0n1p3                    259:3    0 475.4G  0 part 
  ├─ubuntu--vg-ubuntu--lv      253:0    0    50G  0 lvm  /
  ├─ubuntu--vg-dragonode--lv   253:1    0    60G  0 lvm  /dragonode
  └─ubuntu--vg-dragonhoard--lv 253:2    0 365.4G  0 lvm  /dragonhoard

I have successfully configured a bridge with netplan to serve as the metal interface for the system:

calyodelphi@dragonweyr:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP mode DEFAULT group default qlen 1000
    link/ether f8:75:a4:b5:ca:ba brd ff:ff:ff:ff:ff:ff
3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 94:e6:f7:36:91:d8 brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether f8:75:a4:b5:ca:ba brd ff:ff:ff:ff:ff:ff

And now the command I cobbled together, and the problem:

calyodelphi@dragonweyr:~$ virt-install --name dragonode --ram=2048 --disk path=/dragonode/dragonode.qcow2,size=50,format=qcow2 --vcpus 1 --os-type linux --os-variant ubuntu18.04 --graphics none --network bridge:br0 --location 'http://archive.ubuntu.com/ubuntu/dists/bionic/main/binary-amd64/' --extra-args "console=tty0 console=ttyS0,115200n8 ip=192.168.1.144::192.168.1.1:255.255.255.0:dragonode.home:eth0:none"
ERROR    Error validating install location: Could not find an installable distribution at 'http://archive.ubuntu.com/ubuntu/dists/bionic/main/binary-amd64/'

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

Most of this command I assembled mostly using this guide with a little bit of additional referencing from this collection of examples (specifically the linked section) and this helpful RedHat documentation, and also exchanged messages directly with the author of the first article.

However, upon running the above command, you can see the unhelpfully generic error.

The frustrating part of this, is that that URL comes directly from the manpage for virt-install in the --location argument definition:

-l, --location OPTIONS
   Distribution tree installation source. virt-install can recognize certain distribution trees and fetches a bootable kernel/initrd pair to
   launch the install.

   --location allows things like --extra-args for kernel arguments, and using --initrd-inject. If you want to use those options with CDROM media,
   you can pass the ISO to --location as well which works for some, but not all, CDROM media.

   The "LOCATION" can take one of the following forms:

   https://host/path
       An HTTP server location containing an installable distribution image.

   ftp://host/path
       An FTP server location containing an installable distribution image.

   ISO Probe the ISO and extract files using 'isoinfo'

   DIRECTORY
       Path to a local directory containing an installable distribution image. Note that the directory will not be accessible by the guest after
       initial boot, so the OS installer will need another way to access the rest of the install media.

   Some distro specific url samples:

   Fedora/Red Hat Based
       https://download.fedoraproject.org/pub/fedora/linux/releases/29/Server/x86_64/os

   Debian
       https://ftp.us.debian.org/debian/dists/stable/main/installer-amd64/

   Ubuntu
       https://us.archive.ubuntu.com/ubuntu/dists/wily/main/installer-amd64/

   Suse
       https://download.opensuse.org/pub/opensuse/distribution/leap/42.3/repo/oss/

   Additionally, --location can take 'kernel' and 'initrd' sub options. These paths relative to the specified location URL/ISO that allow
   selecting specific files for kernel/initrd within the install tree. This can be useful if virt-install/ libosinfo doesn't know where to find
   the kernel in the specified --location.

   For example, if you have an ISO that libosinfo doesn't know about called my-unknown.iso, with a kernel at 'kernel/fookernel' and initrd at
   'kernel/fooinitrd', you can make this work with:

     --location my-unknown.iso,kernel=kernel/fookernel,initrd=kernel/fooinitrd

I have tried multiple variations of the problem command:

All suggestions by a friend who has encountered this same error before and couldn't remember how he solved it.

The ISO attempt resulted in these last few lines after what seemed like initial success:

mount: mounting /root/cdrom/casper/extras/modules.squashfs-generic on /root/lib/modules failed: No such file or directory
mount: mounting /dev on /root/dev failed: No such file or directory
[a few more of these]
run-init: current directory on the same filesystem as the root: error 0
Target filesystem doesn't have requested /sbin/init.
[more run-init errors]
No init found. Try passing init= bootarg.


BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

I am so far beyond my own ability to solve this and desperately need help to get a VM running.

The VM setup that I intend to accomplish:

  • VM at path /dragonode/dragonode.qcow2
  • VM OS: Ubuntu 18.04 LTS, without graphics
  • Bind the VM's virtual network interface to br0
  • Provision with the IP address 192.168.1.144 so I can immediately ssh to it
  • The rest should be self-explanatory in the original command
Score:1
gn flag

I only use the Ubuntu Serverguide section on virt-install as a reference. Also, graphics is needed to perform the actual installation, which can be via VNC. Using the ISO method, with the iso already downloaded and in the current directory, here is a suggested command (assumes it can get an IP address from the host network DHCP):

virt-install --name dragonode --ram 2048 \
--disk path=/dragonode/dragonode.img,bus=virtio,size=50 \
-c ubuntu-18.04.6-live-server-amd64.iso \
--network bridge=br0,model=virtio \
--video=vmvga --graphics vnc,listen=0.0.0.0 --noautoconsole -v --vcpus=1
Calyo Delphi avatar
pr flag
I forgot to add one more important caveat to all of this: I'm on a home network with an ISP-provided router with a half-lobotomized user interface. There is no DHCP reservations table. Nothing I can use network-admin side to set the client IP. It must be set client-side to get anything resemblant of a static DHCP reservation. So this will leave the VM with a random IP address I can't readily guess on provision. I also don't have graphics available because this is a mostly headless unit.
Doug Smythies avatar
gn flag
@CalyoDelphi : Graphics: Yes, there are none, directly. You use VNC from a computer with graphics to implement a display on the VM and complete the installation. I'll try to figure out how to do a static IP address, but you could always change it to static after the installation.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.