qemu-discuss
[Top][All Lists]
Advanced

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

Re: int 13 ah=42 in boot sector returns error 0Ch


From: Max Reitz
Subject: Re: int 13 ah=42 in boot sector returns error 0Ch
Date: Mon, 4 Nov 2019 11:20:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1

On 02.11.19 06:29, bilsch01 wrote:
> int 0x13 ah=0x42 error code 0Ch means UNSUPPORTED TRACK OR INVALID MEDIA.
> 
> I have never seen this before when I was using real hardware (flash
> drives).
> 
> my command line is: qemu-system-i386 -hda js1.bin
> 
> js1.bin is 17 sectors as follows:
> sector 1: boot sector with error reporting capability. See listing below.
> sectors 2 thru 17: my operating system, jsec2.bin
> 
> Please note: I include the format=raw in command line: qemu-system-i386
> -hda js1.bin format=raw
> but it won't run unless I remove format=raw. Then it runs and reports
> the 0Ch error. Qemu says:
> WRITE OPERATIONS ON BLOCK 0 WILL BE RESTRICTED - because format=raw was
> not specified.
> I wonder if that is what is causing the 0Ch error.

That isn’t what’s meant by “specifying the 'raw' format”.  I wonder from
where you got that you should add “format=raw”, because that’s correct
in a sense, but the same source should have had an example that does not
use -hda but -drive.

What you ought to use is “-drive if=ide-hd,file=js1.bin,format=raw”
instead of -hda.  (-hda doesn’t allow specifying any options but the
filename.)


The reason for the warning and the necessity of specifying the raw
format is that otherwise a guest might write an image format header into
a raw image and then the next time qemu is started, it would interpret
the disk image as being in a format other than raw.  Malicious guests
could abuse this to read arbitrary files on the host.

So when you do not force qemu to use the raw format (which disables
format probing), qemu checks all write operations into the first sector
of the disk image whether its format probing algorithm would recognize
them to be some image format other than raw.  If so, it disallows the
write.  That’s what the warning means and that’s probably the source of
the error you’re seeing.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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