Boot method: CD
kvm -m 2048 -drive file=/export/storage/usba.img,if=virtio -drive file=/var/tmp/debian-wheezy-DI-b2-amd64-netinst.iso,if=virtio,media=cdrom,boot=on -net nic,model=virtio -net tap -vnc :1 -usbdevice tablet -smp 2
Image version: debian-wheezy-DI-b2-amd64-netinst.iso
Date: today

Machine: kvm guest running on Unstable host
Processor:2 (amd64)
Memory:2GByte
Partitions: na

Output of lspci -knn (or lspci -nn):

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:           [O]
Detect network card:    [O]
Configure network:      [O]
Detect CD:              [E]
Load installer modules: [ ]
Detect hard drives:     [ ]
Partition hard drives:  [ ]
Install base system:    [ ]
Clock/timezone setup:   [ ]
User/password setup:    [ ]
Install tasks:          [ ]
Install boot loader:    [ ]
Overall install:        [ ]

Comments/Problems:

The CD drive wasn't found. If I omit the "if=virtio", then kvm falls
back to ide and the drive is found, of course.

Using virtio for the hard disk and the nic seems to work.

Hi Harald,

and thanks for your report.

Harald Dunkel <harri@afaics.de> (2012-10-03):
 - when booting on non-virtio cdrom, udebs are detected on the cdrom
   and/or on the network, loaded, and the virtio-modules kernel udeb is
   then loaded, and non-cdrom resources work fine (nic, hard disk).
 - when booting with virtio cdrom, the relevant module hasn't been put
   in the initramfs, so cdrom isn't detected at all, and game over.

I suspect all we need is to add virtio-modules-${kernel:Version} to
pkg-lists/cdrom/<arch>.cfg files. Quoting for example the amd64 one:
| console-setup-pc-ekmap
| fat-modules-${kernel:Version}
| cdrom-core-modules-${kernel:Version}
| input-modules-${kernel:Version}
| fb-modules-${kernel:Version}
| console-setup-udeb
| kbd-udeb
| usb-modules-${kernel:Version}
| serial-modules-${kernel:Version}
| usb-serial-modules-${kernel:Version} ?
| uinput-modules-${kernel:Version} ?
|
| # Support for firewire cdroms (and disks, I think)
| firewire-core-modules-${kernel:Version}
| # Support for usb cdroms
| usb-storage-modules-${kernel:Version}
| # USB and firewire cdroms both need this.
| scsi-core-modules-${kernel:Version}
| # Support for SCSI cdroms on common controllers.
| scsi-common-modules-${kernel:Version}
|
| # also support MMC/SD cards
| mmc-modules-${kernel:Version} ?
|
| acpi-modules-${kernel:Version}

I haven't played much with virtio myself, but I could probably provide
you with an amd64 netinst image for test purposes. Do you want to
perform some tests?

Mraw,
KiBi.

On Mon, 17 Mar 2014 03:32:41 +0100 Cyril Brulebois <kibi@debian.org> wrote:
[...]

Richard just ran into this again.

I agree.  This should be done for at least amd64 and i386.  It is
probably sensible for all architectures where virtio-modules is built.

[...]

I can test this easily.

Ben.

This bug also prevents installation of Debian in OpenBSD's native
vmm(4) hypervisor: https://man.openbsd.org/vmm

The vmm hypervisor only provides virtio devices. Installation of Debian
with a netinstall image fails in the same way as described above.

OpenBSD users who want to use Debian in vmm currently have to install
Debian in Qemu and then boot the installed system in vmm. This works
around the problem but it is very inconvenient.

people too. But I'm struggling to get my qemu to actually boot such an
image! My command line is

$ qemu-system-x86_64 -enable-kvm -m 2048 \
  -drive file=efi-hard-disk.img,if=virtio,format=raw \
  -drive file=/scratch/mirror/debian-cd-test/debian-10.0-SBHACK-amd64-NETINST-1.iso,if=virtio,media=cdrom,boot=on

"""
Booting from DVD/CD...
Boot failed: Could not read from CDROM (code 0003)
Booting from Floppy...
Boot failed: could not read the boot disk

Booting from Hard Disk...
...

and then things hang. What am I missing? If I remove the "if=virtio"
from both drive stanzas, I at least get to the isolinux menu.

Can you try 'mini.iso' from this location?
http://ftp.nl.debian.org/debian/dists/stretch/main/installer-amd64/current/images/netboot/

At OpenBSD we have determined that this image allows us to do
a netinstall of latest Debian in the vmm hypervisor.

Dear Maintainer,

I encountered the same issue.

The kernel and initrd on the installer CD (unofficial one for Alpha
architecture), does detect attached drive (/dev/vda, and I did read it
using dd without issues, and it has correct content, dd | sha256sum is
same as of the iso file). It shows in dmesg too.

blkid in the shell shows the drive.

The issue is probably how the installer is scanning for drives.

If installer asks me to select a driver and device, and I use 'cdrom' or 'none',
then point it to '/dev/vda', the installer works perfectly.

Creating a symbolic link from /dev/sda or /dev/cdrom to point to /dev/vda
did not help tho.  (If I go via manual driver and device then just
confirm /dev/cdrom , it then accepts and reads it fine).

Cheers,
Witold

Dear Maintainer,

any progress on this, I still have this issue.

I think the culprit might be in the `list-devices cd`, but the git /
salsa organization of debian-installer is very convoluted, and I can't
track it down where it is.


Regards,
Witold

Hi,

this is still broken with recent debian installer daily snapshots.

The device is there and supported by kernel, I can mount things manually
(i.e. mount -t iso9660 /dev/vda /media), but installer simply ignores
this device, even if I create symlink (ln -s vda cdrom).

The workaround to selecting driver none, and pointing to /dev/vda seems
still to work and only option.

Can we get some fix in the debian installer for this?

This reminds me of a similar bug we fixed in the kernel on sparc64 which
turned out to be two missing functions in the kernel for the vio driver
on sparc64 [1][2].

So it's probably a good idea to verify first that the virtio block device
driver behaves correctly in that sense and creates the proper mod aliases.

Then debian-installer should be able to detect the CD-ROM block device automatically.

Adrian

FYI. This happens on both alpha and arm64 from my tests. So possibly
more architectures are affected if it is arch specific.

On Mon, 21 Dec 2020 at 21:52, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

The virtio driver isn't arch-specific.

Adrian

22.01.2020 09:18, Witold Baryluk wrote:

Out of curiosity, _why_ this is necessary?
For the install time, isn't it trivial to use regular ide/sata cdrom
drive or an usb flash instead of more exotic ways? Most of the time
cdrom is only needed for the installation, later on you can either
remove it entirely or switch it to virtio if needed.

We did lots of installations of various systems out there in qemu/kvm,
and we always use most common devices during this time.

Thanks,

/mjt

trivial? I don't know how to do that, and it does
feel like a workaround.

What about QA infrastructure that might want to do installs
of various iso images, and do testing, or boot live CDs,
for testing. Would scripts require extra special cases for
every architecture?

What does that mean? virtio is very much common.

How is the user of qemu supposed to know which is the
"most common device"? Are we going to maintain the
proper flags for every architecture in the installation guide?

It is an honest question.

Please note that If one uses the most obvious way of supplying
iso image, that is `-cdrom debian-testing-arm64-netinst.iso`,
it also doesn't work:

qemu-system-aarch64 -M virt -cpu max -smp 2 -m 8192 -device
qemu-xhci,id=usb -usb -device usb-kbd -device usb-tablet -device
virtio-gpu-pci -cdrom debian-testing-arm64-netinst.iso -bios
/usr/share/qemu-efi-aarch64/QEMU_EFI.fd

I don't find this exotic at all, and rather straightforward,
and probably the first thing user will try.



Thanks,
Witold

Dear Maintainer,

I just tested daily snapshot installed for amd64 for trixie, and it
appears that some parts of this issue are fixed (I do not know when,
probably years ago).

For example

qemu-system-x86_64 -enable-kvm -cpu host -smp 4 -m 8G -drive file=${HOME}/debian-testing-amd64-netinst.iso,if=virtio,media=cdrom

works.

But a bit strange thing (not the end of the world tho), is that partman
also shows this read-only cdrom-class vda device in a selection menu
(and saying it is 816.8MB with no partitions, but this device does in
fact have 2 partitions. Size is correct, same as reported in dmesg, and
matching iso file size).


I still do have issue with other way: