[Bug 1822407] Re: Installing 18.04 to a virtio device produces an unbootable system on armhf

[Robert Merrill]

To reproduce (use a machine with fast CPU...), on xenial as your host:

qemu-system-arm built from source:
  rmerrill at ubuntu-1404:~/qemu$ git remote get-url origin
  git://git.qemu-project.org/qemu.git
  rmerrill at ubuntu-1404:~/qemu$ git rev-parse --abbrev-ref HEAD  
  stable-2.9
  rmerrill at ubuntu-1404:~/qemu$ 

Follow the instructions here:
https://gist.github.com/takeshixx/686a4b5e057deff7892913bf69bcb85a

With the following changes:
- Download the bionic vmlinuz and initrd instead of xenial
- I ran into some trouble getting the network set up right on the host. Note that you will have to install isc-dhcp-server (NOT udhcpd as apt will helpfully suggest). You will also have to tweak apparmor to allow dhcpd to read conf files outside of its usual place.
- On the invocation of qemu-system-arm, change `-serial stdio` to `-serial mon:stdio` -- this is what you actually want anyway.
- Add `-smp 4` (or however many CPUs your host has, maybe minus one) to make the install go a little faster.

-- 
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/1822407

Title:
  Installing 18.04 to a virtio device produces an unbootable system on
  armhf

Status in debian-installer package in Ubuntu:
  New

Bug description:
  Using the netboot vmlinuz and initrd found here:
  http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main
  /installer-armhf/current/images/generic-lpae/netboot/

  Running in a QEMU "virt" machine, the install goes fine but the result
  can't boot because virtio_blk is not compiled into the kernel and
  update-initramfs is stubbed out (appears to be a copy/hardlink of
  /bin/true). I should note that the install produces /boot/initrd.img
  as a broken/dangling symlink which may or may not be desirable.

  I am currently attempting to produce a bootable system by:
  - Running the installer again on the same virtual disk
  - Getting to the point where it asks how to partition the install
  - Backing out until I can drop to a shell
  - chrooting into the install (involves mounting /, /boot, and bind-mounting /dev /sys and /proc)
  - adding virtio_blk to /etc/initramfs-tools/modules
  - running mkinitramfs manually

  This is very painful even if it works because the installer is *slow*
  inside QEMU and there's no clear way to get to the state where I can
  mount /dev/vda more quickly.

  From what I gather people did not have this problem on xenial, and I'm
  not the only one who tripped on this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1822407/+subscriptions