SATA-related failure on QEMU >=7.2.6

[mintsuki]

When trying to run ./build/build-iso.sh using QEMU >=7.2.6, the following SATA-related error is produced:

[xeome]

You can try using distrobox as a temporary workaround. I've tested it with the latest Debian container, and it appears to work seamlessly. I know this isn't a solution but atleast it works for me.

[JasonBreen]

You can try using distrobox as a temporary workaround. I've tested it with the latest Debian container, and it appears to work seamlessly. I know this isn't a solution but atleast it works for me.

Just tried it, still getting the same errors as above

[Epitome-of-Abnegation]

Having the same issue. Trying to troubleshoot.

[StevenLaczko]

Just built qemu-7.2.8 and tried it on Debian and it still failed with the same error as OP. What version did it work on? Does anyone just have an ISO in the meantime?

[doodayev]

Just built qemu-7.2.8 and tried it on Debian and it still failed with the same error as OP. What version did it work on? Does anyone just have an ISO in the meantime?

I'm on Linux Mint version 21.2. That is the latest version of Linux Mint though version 21.3 will be coming soon it seems. Anyways, the Qemu version for that is version 6.2.0. Either install that or just make a virtual machine in Virtual Box and use qemu in there. On Windows I'd always be compiling through a Linux Mint or Kubuntu vm anyways (make sure to enable nested virtualization if you want to go this route).

Here is a 7Z file, not an ordinary zip file, that holds both the UEFI version of the OS and the legacy BIOS version. I had to rename it from Zeal.7Z to Zeal.zip because Github doesn't let me upload normal 7zip files but all it does is just check the extension. Zeal.zip

[StevenLaczko]

Thanks for the reply. Unfortunately trying to run that iso also shows the error "Could not find ATAPI boot drive". So downgrading qemu or running it in different software might be the way to go.

[AClon314]

Just built qemu-7.2.8 and tried it on Debian and it still failed with the same error as OP. What version did it work on? Does anyone just have an ISO in the meantime?

I'm on Linux Mint version 21.2. That is the latest version of Linux Mint though version 21.3 will be coming soon it seems. Anyways, the Qemu version for that is version 6.2.0. Either install that or just make a virtual machine in Virtual Box and use qemu in there. On Windows I'd always be compiling through a Linux Mint or Kubuntu vm anyways (make sure to enable nested virtualization if you want to go this route).

Here is a 7Z file, not an ordinary zip file, that holds both the UEFI version of the OS and the legacy BIOS version. I had to rename it from Zeal.7Z to Zeal.zip because Github doesn't let me upload normal 7zip files but all it does is just check the extension. Zeal.zip

the zip file works on VMware 17.5.0!

[retu2libc]

As far as I can tell this broke in Qemu 7.2.6 as a result of commit f86c6ff824. Unfortunately Debian currently has 7.2.7 up on their bookworm mirrors right now. This is the diff that fixes latest master:

diff --git a/hw/ide/core.c b/hw/ide/core.c
index 9c4a812902..02df98bd03 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -545,9 +545,9 @@ BlockAIOCB *ide_issue_trim(

 void ide_abort_command(IDEState *s)
 {
+    ide_transfer_stop(s);
     s->status = READY_STAT | ERR_STAT;
     s->error = ABRT_ERR;
-    ide_transfer_stop(s);
 }

 static void ide_set_retry(IDEState *s)

[mintsuki]

Thank you for finding the exact version/commit, I updated the issue name.

[CoderHobbs]

The issue occurs when AUTO.ISO, which hasn't been updated for 2 years, is trying to boot. The actual system seems to be fine, which suggests it has been fixed in the meantime. The commit message does not specify a specific procedure, but looking at the scripts, doesn't the sync script also re-fresh this image? Is this as simple as a committer running sync and then commit the new image? No. The error just isn't quite as fatal.

[GutPuncher]

The issue occurs when AUTO.ISO, which hasn't been updated for 2 years, is trying to boot. The actual system seems to be fine, which suggests it has been fixed in the meantime. The commit message does not specify a specific procedure, but looking at the scripts, doesn't the sync script also re-fresh this image? Is this as simple as a committer running sync and then commit the new image? No. The error just isn't quite as fatal.

@CoderHobbs To create a new AUTO.ISO, first clean the repository working tree. Then rebuild distro ISO + reinstall, or sync the clean workdir to a VM. The proccess to make a new AUTO.ISO is:

Cd("::/Misc/Auto");
#include "AutoDistro";;

This will build a new AUTO.ISO. Once done, power-off the VM and use the sync script to sync the repo: the script has integrated functionality to pull the AUTO.ISO out from the src/ and move it to build/. Does rebuilding and syncing a new AUTO.ISO from a newer version of Zeal resolve this issue for new versions of QEMU? If so, a PR would be very welcome. If not, and there are errors that aren't "quite as fatal" after doing so, it would be helpful to see screenshots of what errors are displayed.

Extra context: AUTO.ISO is a ZealOS bootstrap self-hosted build disc that targets QEMU's debug feature to trigger reboots or poweroffs in software, intended to be integrated with the ISO build script process. The build script is designed to create a new temporary QEMU VM, copy over the new Zeal repo source code files into a temporary directory to the VM disk, and boot the AUTO.ISO disc to boot Zeal off VM CD/DVD, after which the AUTO.ISO scripting process + debug reboot/poweroffs take care of booting, copying new kernel headers in, recompiling, rebooting, copying new kernel source in, recompiling, rebooting, copying in all operating system code in, recompiling, rebooting, and then building the Public Domain BIOS-mode Zeal ISO.