action #91971
closedcrosscheck if testapi::eject_cd actually works
Description
Motivation¶
Some people have reported that eject_cd does not work. I could imagine that when richiejp rewrote the qemu backend this broke as a backing file for each cd is created as well for a reason which I also don't know
Acceptance criteria¶
- AC1: test API call
eject_cdworks as one would expect
Suggestions¶
- Reproduce a case, maybe try eject_cd directly in the os-autoinst fullstack tests
- maybe we don't even need to create a backing file for ISO files? If not, then make sure that the backend does not do that
Updated by mkittler almost 3 years ago
- Status changed from Workable to In Progress
- Assignee set to mkittler
Updated by mkittler almost 3 years ago
I tried this on a live test by sending {"cmd":"backend_eject_cd"} via the developer console. It didn't work because there's no cd0 device: {"ret":{"error":{"class":"DeviceNotFound","desc":"Device 'cd0' not found"}}}. I guess I'll have to find a scenario where we actually have The device actually exists, see further comments. However, it isn't clear with which name one needs to refer to it.cd0.
Updated by mkittler almost 3 years ago
I've tried scsi-cd, cd0-device and cd0-overlay0 instead as device but only get the same error message (just with the different device). Not sure what I would have to pass here.
The QEMU invocation is:
/usr/bin/qemu-system-x86_64 -only-migratable -chardev ringbuf,id=serial0,logfile=serial0,logappend=on -serial chardev:serial0 -audiodev none,id=snd0 -device intel-hda -device hda-output,audiodev=snd0 -global isa-fdc.fdtypeA=none -m 2048 -cpu qemu64 -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -boot once=d -device usb-ehci -device usb-tablet -smp 1 -enable-kvm -no-shutdown -vnc :91,share=force-shared -device virtio-serial -chardev pipe,id=virtio_console,path=virtio_console,logfile=virtio_console.log,logappend=on -device virtconsole,chardev=virtio_console,name=org.openqa.console.virtio_console -chardev socket,path=qmp_socket,server,nowait,id=qmp_socket,logfile=qmp_socket.log,logappend=on -qmp chardev:qmp_socket -S -device virtio-scsi-pci,id=scsi0 -blockdev driver=file,node-name=hd0-file,filename=/hdd/openqa-devel/openqa/pool/1/raid/hd0,cache.no-flush=on -blockdev driver=qcow2,node-name=hd0,file=hd0-file,cache.no-flush=on -device virtio-blk,id=hd0-device,drive=hd0,serial=hd0 -blockdev driver=file,node-name=cd0-overlay0-file,filename=/hdd/openqa-devel/openqa/pool/1/raid/cd0-overlay0,cache.no-flush=on -blockdev driver=qcow2,node-name=cd0-overlay0,file=cd0-overlay0-file,cache.no-flush=on -device scsi-cd,id=cd0-device,drive=cd0-overlay0,serial=cd0
Btw, I'm using the following change to make the device configurable: https://github.com/Martchus/os-autoinst/pull/new/eject-device
Updated by mkittler almost 3 years ago
When using the QMP command query-block I get:
{
"ret" : {
"return" : [
{
"device" : "sd0",
"locked" : false,
"removable" : true,
"type" : "unknown"
},
{
"device" : "",
"inserted" : {
"backing_file_depth" : 0,
"bps" : 0,
"bps_rd" : 0,
"bps_wr" : 0,
"cache" : {
"direct" : false,
"no-flush" : true,
"writeback" : true
},
"detect_zeroes" : "off",
"drv" : "qcow2",
"encrypted" : false,
"encryption_key_missing" : false,
"file" : "/hdd/openqa-devel/openqa/pool/1/raid/hd0",
"image" : {
"actual-size" : 200704,
"cluster-size" : 65536,
"dirty-flag" : false,
"filename" : "/hdd/openqa-devel/openqa/pool/1/raid/hd0",
"format" : "qcow2",
"format-specific" : {
"data" : {
"compat" : "1.1",
"compression-type" : "zlib",
"corrupt" : false,
"extended-l2" : false,
"lazy-refcounts" : false,
"refcount-bits" : 16
},
"type" : "qcow2"
},
"virtual-size" : 21474836480
},
"iops" : 0,
"iops_rd" : 0,
"iops_wr" : 0,
"node-name" : "hd0",
"ro" : false,
"write_threshold" : 0
},
"io-status" : "ok",
"locked" : false,
"qdev" : "/machine/peripheral/hd0-device/virtio-backend",
"removable" : false,
"type" : "unknown"
},
{
"device" : "",
"inserted" : {
"backing_file" : "/hdd/openqa-devel/openqa/share/factory/iso/openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20210428-Media.iso",
"backing_file_depth" : 1,
"bps" : 0,
"bps_rd" : 0,
"bps_wr" : 0,
"cache" : {
"direct" : false,
"no-flush" : true,
"writeback" : true
},
"detect_zeroes" : "off",
"drv" : "qcow2",
"encrypted" : false,
"encryption_key_missing" : false,
"file" : "/hdd/openqa-devel/openqa/pool/1/raid/cd0-overlay0",
"image" : {
"actual-size" : 200704,
"backing-filename" : "/hdd/openqa-devel/openqa/share/factory/iso/openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20210428-Media.iso",
"backing-image" : {
"actual-size" : 987435008,
"dirty-flag" : false,
"filename" : "/hdd/openqa-devel/openqa/share/factory/iso/openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20210428-Media.iso",
"format" : "raw",
"virtual-size" : 987430912
},
"cluster-size" : 65536,
"dirty-flag" : false,
"filename" : "/hdd/openqa-devel/openqa/pool/1/raid/cd0-overlay0",
"format" : "qcow2",
"format-specific" : {
"data" : {
"compat" : "1.1",
"compression-type" : "zlib",
"corrupt" : false,
"extended-l2" : false,
"lazy-refcounts" : false,
"refcount-bits" : 16
},
"type" : "qcow2"
},
"full-backing-filename" : "/hdd/openqa-devel/openqa/share/factory/iso/openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20210428-Media.iso",
"virtual-size" : 987430912
},
"iops" : 0,
"iops_rd" : 0,
"iops_wr" : 0,
"node-name" : "cd0-overlay0",
"ro" : false,
"write_threshold" : 0
},
"io-status" : "ok",
"locked" : true,
"qdev" : "cd0-device",
"removable" : true,
"tray_open" : false,
"type" : "unknown"
}
]
}
}
Maybe the problem is "device" : "", which shouldn't be empty.
Updated by openqa_review almost 3 years ago
- Due date set to 2021-05-15
Setting due date based on mean cycle time of SUSE QE Tools
Updated by mkittler almost 3 years ago
One needs to use the id parameter, PR: https://github.com/os-autoinst/os-autoinst/pull/1663
Updated by mkittler almost 3 years ago
- Related to action #47303: [aarch64] 'eject_cd' does not work added
Updated by mkittler almost 3 years ago
The PR has been merged. It looks like no test in production uses eject_cd at the moment. I'll try to remove the workaround in bootloader_uefi.pm (introduced in #47303).
Updated by mkittler almost 3 years ago
- Status changed from In Progress to Resolved
I couldn't find any recent scenarios which runs bootloader_uefi.pm with the relevant job settings which is not broken otherwise. I've searched on OSD and o3 with various SQL queries but found nothing. So it looks like the workaround is currently dead code. Since the function is not used in production I'm resolving the ticket anyways.
By the way, I've seen https://bugs.launchpad.net/qemu/+bug/1815445. This ticket has expired but I suppose the resolution is actually my PR so I'll tell @ggardet_arm. Maybe he's still interested in this.