qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qemu broke booting of old RedHat floppies


From: John Snow
Subject: Re: qemu broke booting of old RedHat floppies
Date: Fri, 12 Mar 2021 01:23:04 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0

On 1/20/21 10:41 AM, Thomas Huth wrote:
On 20/01/2021 16.11, Michael Tokarev wrote:
As someone noticed on IRC, old (2.x) RedHat floppies does not boot
in current qemu.  When qemu is booted from floppy image at
  https://archive.org/details/RedHatLinuxBootDisk521998
(download the "ISO image" link there, it really is an 1.44 floppy),
seabios says Boot failed and that's it.

I run git bisect with it, knowing that qemu 2.1 works fine, and
it pointed out to this commit which is oldish qemu-2.5+:
[...]
Now, I don't even know where to put that "type=144/288/auto" thing,
I tried this:

  -drive file=RedHatLinuxBootDisk521998.disk1of1.img,if=floppy,format=raw,type=144

but it says that format=raw does not support "type=144" option.

Try:

 qemu-system-x86_64 -drive if=none,file=RedHatLinuxBootDisk521998.disk1of1.img,format=raw,id=dr1 -device floppy,drive-type=144,drive=dr1

And it's even more: I don't remember which size should be an 1.44Mb floppy :)) The file size of that image is 1492992 bytes which does not look like it is of
standard size, but I can't find which size it should be.

As mentioned on IRC already, it's likely a disk with 81 tracks instead of 80 tracks, so it's bigger than the usual 1.44 MB floppy disk images and thus QEMU likely misdetects it by default.

  Thomas



Whoops, yes, the auto-detection doesn't really seem to understand what's going on here.

./i386-softmmu/qemu-system-i386 -drive if=none,format=raw,file=../../../../Downloads/RedHatLinuxBootDisk521998.disk1of1.img,id=dr1 -device floppy,drive-type=auto,drive=dr1

this fails, as does drive-type=288.
drive-type=144 works, though.

Digging a tiny bit:

- auto chooses a (36, 80, 1) geometry (It assumes the 288 type.)
- 288 chooses the same geometry.
- 144 chooses (18, 80, 1) => 2880 sectors

None of these choices actually get the geometry right, because the fd_formats[] table just ... doesn't have that geometry in the table. It only works under the 144 type because when it just gives up and picks a geometry, it picks the first geometry under the 1.44MB section.

When it defaults to 2.88 instead, it picks the first geometry under the 2.88MB section.

Adding an explicit (18, 81, 1) choice improves our mileage:

- auto -> (18, 81, 1)
- 144 -> (18, 81, 1)
- 288 -> (18, 81, 1)

and fixes the boot.


diff --git a/hw/block/fdc.c b/hw/block/fdc.c
index 198940e737..4269c0c754 100644
--- a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ -122,6 +122,7 @@ static const FDFormat fd_formats[] = {
     /* First entry is default format */
     /* 1.44 MB 3"1/2 floppy disks */
{ FLOPPY_DRIVE_TYPE_144, 18, 80, 1, FDRIVE_RATE_500K, }, /* 3.5" 2880 */
+    { FLOPPY_DRIVE_TYPE_144, 18, 81, 1, FDRIVE_RATE_500K, },
{ FLOPPY_DRIVE_TYPE_144, 20, 80, 1, FDRIVE_RATE_500K, }, /* 3.5" 3200 */
     { FLOPPY_DRIVE_TYPE_144, 21, 80, 1, FDRIVE_RATE_500K, },
     { FLOPPY_DRIVE_TYPE_144, 21, 82, 1, FDRIVE_RATE_500K, },



Do you have the name of the person who reported this on IRC so I can add a credit?

--js




reply via email to

[Prev in Thread] Current Thread [Next in Thread]