Virtual UEFI doesn't recognize SCSI disks?

berndbausch · 04-01-2020, 09:29 PM

I created a KVM-based VM with UEFI and SCSI disks (connected to an emulated LSI Logic controller). After installing Debian 10, it doesn't launch Grub when started, but drops into the EFI shell.

As far as I can see from the UEFI menu and the EFI shell, the SCSI disk on which Debian was installed is not visible. In the EFI shell, there is no FS0: device.

I can boot into rescue mode from the installation DVD and launch a Bash, from where all looks nice. The Debian 10 install DVD has a reinstall Grub option, which I used although I doubt the Grub installation is the problem. And indeed, it doesn't change anything.

Is the virtual UEFI (based on the Tianocore project) unable to deal with SCSI disks? What should I try?

EDIT: From the install DVD, I can get into a Grub prompt. There, an ls displays these rather unexpected devices:

Code:

(proc) (fd0) (fd1) (cd0) (cd0,apple2) (cd0,apple1) (cd0,msdos2)

Clearly something is not right. But what?

Edit2: When I replace the SCSI controller with SATA, all works nicely. However I would really like to make my VM work with SCSI disks.

smallpond · 04-02-2020, 01:54 PM

Can you get to the uefi shell? List devices and drivers and see if your SCSI disks are shown.

Are you starting this with QEMU? Can you show the qemu parameters?

berndbausch · 04-02-2020, 09:55 PM

Yes, the EFI shell greets me with

Code:

Mapping table
      FS0: Alias(s):CD1a1:;BLK4:
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/CDROM(0x1)
     BLK0: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
     BLK1: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
     BLK2: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
     BLK5: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(2,MBR,0x7561008E,0x5CAC,0x1620)
     BLK3: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/CDROM(0x0)

From the rescue mode on the install CD, I can run lspci and get

Code:

  ...
  00:01.0 ISA bridge: Intel Corporateion 82371SB PIIX3 ISA [Natoma/Triton II]
  00:01.1 IDE interface: Intel Corporateion 82371SB PIIX3 IDE [Natoma/Triton II]
  ...
  00:05.0 SCSI storage controller: LSI Logic / Symbios Logid 53c895a

So, UEFI and/or the EFI shell only see the IDE controller in PCI slot 1, not the SCSI controller in slot 5. This is obviously the problem.

The VM:

Code:

$ virsh dumpxml deb10full
...
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='scsi' index='0' model='lsilogic'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </controller>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
...

Qemu looks like this (newlines and colour added for ease of reading):

Code:

$ ps -ef|grep deb10
qemu      2244     1 60 10:40 ?        00:41:46 /usr/bin/qemu-system-x86_64 
-machine accel=kvm -name guest=deb10full,debug-threads=on -S 
-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-deb10full/master-key.aes 
-machine pc-i440fx-2.11,accel=kvm,usb=off,dump-guest-core=off -cpu SandyBridge-IBRS,vme=on,ss=on,vmx=on,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,ssbd=on,xsaveopt=on -drive file=/usr/share/edk2/ovmf/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on 
-drive file=/var/lib/libvirt/qemu/nvram/deb10full_VARS.fd,if=pflash,format=raw,unit=1 
-m 3072 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 
-uuid 68fd4b2b-6974-4a8a-af23-25b667e8b446 -no-user-config -nodefaults 
-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-deb10full/monitor.sock,server,nowait 
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew 
-global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 
-global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 
-device lsi,id=scsi0,bus=pci.0,addr=0x5 

-drive file=/home/bbausch/lsac1/deb10full.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0 
-device scsi-hd,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0,bootindex=1 
-drive file=/home/bbausch/lsac1/disk1.qcow2,format=qcow2,if=none,id=drive-scsi0-0-1 
-device scsi-hd,bus=scsi0.0,scsi-id=1,drive=drive-scsi0-0-1,id=scsi0-0-1 
-drive file=/home/bbausch/lsac1/disk2.qcow2,format=qcow2,if=none,id=drive-scsi0-0-2 
-device scsi-hd,bus=scsi0.0,scsi-id=2,drive=drive-scsi0-0-2,id=scsi0-0-2 
-drive file=/home/bbausch/lsac1/disk3.qcow2,format=qcow2,if=none,id=drive-scsi0-0-3 
-device scsi-hd,bus=scsi0.0,scsi-id=3,drive=drive-scsi0-0-3,id=scsi0-0-3 
-drive file=/home/bbausch/lsac1/disk4.qcow2,format=qcow2,if=none,id=drive-scsi0-0-4 
-device scsi-hd,bus=scsi0.0,scsi-id=4,drive=drive-scsi0-0-4,id=scsi0-0-4 
-drive file=/home/bbausch/lsac1/disk5.qcow2,format=qcow2,if=none,id=drive-scsi0-0-5 
-device scsi-hd,bus=scsi0.0,scsi-id=5,drive=drive-scsi0-0-5,id=scsi0-0-5 
-drive file=/home/bbausch/lsac1/dvd.iso,format=raw,if=none,id=drive-ide0-0-0,readonly=on 
-device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 

-netdev tap,fd=27,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:fa:57:99,bus=pci.0,addr=0x3 
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-vnc 0.0.0.0:1 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on

smallpond · 04-03-2020, 10:30 AM

I took a look at my old notes. We never booted from SCSI in qemu. Although we worked on SCSI, FC and iSCSI, we only accessed them at runtime. Pretty sure there were support issues and ATA boot was just better supported. For example '-hda foo.img' instantiates both IDE controller and drive. Recall that SCSI boot has never been natively supported on a PC, it requires a boot ROM on the controller to scan for drives.