[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QEMU, Windows 11, and Raspios
|
From: |
G.W. Haywood |
|
Subject: |
Re: QEMU, Windows 11, and Raspios |
|
Date: |
Sat, 19 Oct 2024 13:09:05 +0100 (BST) |
Hi there,
On Fri, 18 Oct 2024, Ignacio wrote:
I am currently using a laptop that is running Windows 11 and I have
downloaded QEMU. However, I cannot figure out how to use QEMU to emulate
Raspios. Raspios does not use a .iso, but instead a .img. I was wondering
if there is a way around this or if I am complicating this process.
There surely is a way. The two data formats you mention are different
because they are used for different purposes.
First things first. Both the .iso and the .img are supplied as files,
which you can simply store somewhere on a computer. When they're kept
as files in that way there's nothing special about them. They're just
blobs of data stored on your computer, laptop, smartphone or whatever.
...ooOoo...
The file extensions '.img' and '.iso' don't mean much to most systems
which use them. It's really only DOS and Windows which take notice of
the extensions. Even then the resulting behaviour is often unhelpful.
For example, somebody can send a file by email which has the extension
somehow obfuscated, and which behaves in ways which are not expected
when you try to use it on a Windows box. (Hence, propagation of much
malware - but I digress, if only slightly, so back to the point.)
Linux-type operating systems will usually look into the file to see
what sort of a file it is before trying to do anything with the data.
They don't necessarily care about the name of the file.
...ooOoo...
Once you have somehow obtained a copy of one of these blobs of data,
you need to do things with it in order to use it. That comes next.
First, I'd check that what I downloaded is what I think I downloaded.
(See slight digression above.) How you do that is up to you and I'll
say no more about it here except that you're responsible for your own
protection from those who deliberately publish malicious software, of
whom there are millions and millions. "Easier to steal than to work"
is the ethos, or maybe they're just morons with nothing better to do
than cause trouble for people. There are a lot of those too.
...ooOoo...
When you actually copy one of these blobs of data from the file where
you saved it to the storage medium where it will be used, essentially
the process is exactly the same in both cases. It doesn't matter if
it's a .iso file or a .img file. You just take the first byte of the
file and put it in the first byte on the storage medium, the second
byte from the file to the second byte of the storage medium, and keep
on doing that for all five hundred million or however many bytes are
in the file, then stop. For devices like flash memory (for example
USB sticks, SD cards) you can use something like the venerable 'dd',
which can do just what I described with all the bytes using just one
command. There are versions of 'dd' for Windows. It might be a slow
process so it will tell you what it's doing as it does it if you give
the right command.
For things like CDs there are tools for doing this which also handle
any cookery that might be necessary because of the storage technology
(but which is irrelevant to the actual data). You can't do that with
'dd' becaseu it doesn't know about the cookery.
Note that there's a *major* difference between writing the file to a
storage medium in this way using 'dd' or whatever and writing the same
file to your home directory (which is what you did when you downloaded
it) using the operating system facilities which make all that so easy.
The difference is that when the operating system writes the file, you
don't care where in medium the data might be and data for the file can
in actual fact be spread all over the disc (or the SSD, flash card, or
whatever). Most filesystems do that with the data, so that they can
make optimum use of the storage technology. But when you write a file
e.g. using 'dd', you want the bytes all to be in the *same* order on
the storage medium as they'd appear if you listed the contents of the
file on the screen. Yes that would be boring, and not the least bit
useful, usually - I will do that now and again using the 'hexdump' [4]
tool to see exactly what I've got if there's any doubt. The reason
for this strict requirement is that you're making a filesystem on the
target medium which will look *exactly* as if it was created by one of
these operating systems we're talking about - but, in fact, it wasn't,
it was made by the computing equivalent of what in navigation would be
called "dead reckoning". There's no room for error at all in writing
the file; there might be a little in navigation, but in either case an
error can mean that you won't like the results very much.
Note also that the operating system can cope with bad spots on discs,
but when you're writing an image file in this way there can be no bad
spots (or at least none that you'll actually want to read, later on).
...ooOoo...
The .iso format is intended to be written directly to something which
resembles a CD. There are different formats for writing CDs but this
format is now the international standard:
https://en.wikipedia.org/wiki/ISO_9660
Assuming that the .iso file contains a copy of a *suitable* bootable
filesystem, after you have written the CD you can boot from it *if*
the device is capable of booting from a CD. "Suitable" means that the
files on the CD are executable by the device which you're going to try
to boot from it. No good trying to boot a system which is intended to
boot a Mac G4 on a system which isn't a Mac G4 - unless you're playing
with QEMU for example, but I digress again.
After it boots, the CD will not *usually* form the root filesystem of
the device which boots from it, but it's possible. If it does form
the root filesystem, it's called a "live CD" and it's almost certainly
read-only. This might be suitable for some applications. But often
it's more useful if the boot process instead creates a root filesystem
in memory (a "RAMdisc") which behaves to all intents and purposes like
a real disc, except that when you switch off the device, everything on
it is lost and next time you boot it you have to start all over again.
In such a case the CD itself will probably become available as a disc
device while the system is running, but it might not automatically do
that - it's up to the software on the image what it does.
...ooOoo...
The .img format is intended to be written directly to a storage medium
(more or less any storage medium - SD car, USB stick, disc, ...) for a
device in which the medium will become the 'root' filesystem when this
device actually boots and you will *usually* then be able to write to
the storage medium after booting on it. Be aware that the technology
currently has limitations, if you use flash memory for intensive write
operations over a long period of time, eventually it will wear out.
Back to your question. The .img file for RaspiOS is intended to be
the root filesystem when it's booted and running. In fact you can use
it directly by pointing QEMU to it, just pretend it's a bootable disc.
But I'd recommend that you don't do that, I'd recommend making a copy
of it. Use the copy, because when you're experimenting, especially in
the early days, it's easy to make a mistake and thus trash the image.
If (when) you do that, you can just delete it, then make another copy
from the original.
The RaspiOS image will need to be used with a VM which is emulating an
ARM processor of course, not something like an x86 CPU.
The above is the very basics which most people who describe how to get
what you're trying to do up and running won't bother to mention. When
you feel you have a grip of the basics try something like
QEMU raspios "windows host"
in your favourite search engine.
...ooOoo...
You can inspect the contents of the .img or .iso files almost as if
they were running filesystems by 'mounting' the file.
Basically you pretend the file is a disc device and treat is that way.
So if for example I have a file called 'img.iso' in /tmp/ I can mount
it on my linux box [1] using
mount -t iso9660 /tmp/img.iso /mnt/
and then
ls -l /mnt/
to see what's in there. One difference between doing that and using a
CD drive to read the data from a CD is that when I've mounted the file
it can then be altered using whatever tools are required.
To do the same sort of thing with an .img file the 'mount' command
might be able to figure it out [2] but I *might* have to do a bit more
work [3],[5]. The first part of the .img file could contain something
like a partition table, which mount might not be able to understand.
You'd probably need to tell it where in the image the partition of
interest actually starts by giving an offset, the number of bytes from
the start of the image to the start of the part you're interested in.
Finally, to repeat, there is nothing special about the names of these
files. The fact that a file is called 'something.img' does not mean
that it must be an image of a system. It might be a picture of a dog.
It's just a convention that we tend to call the things 'something.iso'
or 'something.img'. It can help when you're listing directories full
of the things, but might possibly not help understanding what goes on.
HTH
--
73,
Ged.
8<----------------------------------------------------------------------
Examples of mounting files, all done during the writing of this message:
8<----------------------------------------------------------------------
[1] /mnt/fd/ is an empty directory. It's where the filesystem that I'm
going to mount will appear, like magic, after I 'mount' it there:
8<----------------------------------------------------------------------
# ls -l /mnt/fd
total 0
# mount -t iso9660 /home/ged/junk/Diag504fCD.iso /mnt/fd
mount: /mnt/fd: WARNING: device write-protected, mounted read-only.
# ls -lrt /mnt/fd
total 357
-r-xr-xr-x 1 root root 25636 Jul 22 2000 IBMBIO.COM
-r-xr-xr-x 1 root root 33250 Jul 22 2000 IBMDOS.COM
-r-xr-xr-x 1 root root 9003 Jan 18 2005 DLGLICE.TXT
-r-xr-xr-x 1 root root 286132 Nov 22 2005 DLGDIAG5.EXE
-r-xr-xr-x 1 root root 10426 Nov 29 2005 DLGDIAG.txt
# umount /mnt/fd
# ls -l /mnt/fd
total 0
#
8<----------------------------------------------------------------------
Note above that the 'mount' command mounted the filesystem read-only.
That's because something in the .iso file data told it to do that.
8<----------------------------------------------------------------------
[2] The next one will be mounted read-write, so no warning from 'mount'.
8<----------------------------------------------------------------------
# mount -t vfat /opt/ged/FreeDOS/FREEDOS_BOOTABLE_FLOPPY.img /mnt/fd/
# ls -lrt /mnt/fd/
total 442
-rwxr-xr-x 1 root root 17806 Jan 27 2001 jem1.exe
-rwxr-xr-x 1 root root 18038 Jan 27 2001 jem2.exe
-rwxr-xr-x 1 root root 45836 Jul 8 2001 FDISK.EXE
-rwxr-xr-x 1 root root 21217 Jul 8 2001 PART.INI
-rwxr-xr-x 1 root root 20 Jul 8 2001 INSTALL.DAT
-rwxr-xr-x 1 root root 105 Jul 18 2001 INSTALL.FUL
-rwxr-xr-x 1 root root 13741 Jul 26 2001 FORMAT.EXE
-rwxr-xr-x 1 root root 8923 Aug 13 2001 ATTRIB.COM
-r-xr-xr-x 1 root root 86561 Aug 15 2001 COMMAND.COM
-rwxr-xr-x 1 root root 11894 Aug 17 2001 xkeyb.exe
drwxr-xr-x 4 root root 512 Aug 19 2001 NLS
-rwxr-xr-x 1 root root 8634 Aug 20 2001 SYS.COM
-rwxr-xr-x 1 root root 44706 Aug 23 2001 TE.EXE
-rwxr-xr-x 1 root root 515 Aug 23 2001 TE.DOC
-rwxr-xr-x 1 root root 7819 Aug 23 2001 FDISK.INI
-r-xr-xr-x 1 root root 75663 Sep 3 2001 KERNEL.SYS
-rwxr-xr-x 1 root root 67352 Sep 7 2001 INSTALL.EXE
-rwxr-xr-x 1 root root 10516 Sep 7 2001 CAT_FILE.EXE
-rwxr-xr-x 1 root root 2244 Sep 7 2001 INST.BAT
-rwxr-xr-x 1 root root 819 Sep 7 2001 READ.ME
-rwxr-xr-x 1 root root 77 May 11 2008 config.sys
-rwxr-xr-x 1 root root 1901 May 11 2008 UK.KEY
-rwxr-xr-x 1 root root 253 May 11 2008 AUTOEXEC.BAK
-rwxr-xr-x 1 root root 278 May 11 2008 AUTOEXEC.BAT
# umount /mnt/fd
# ls -l /mnt/fd/
total 0
#
8<----------------------------------------------------------------------
[3] This one fails, 'mount' doesn't know where in the file to look:
8<----------------------------------------------------------------------
# mount /opt/ged/FreeDOS/FD13-FullUSB/FD13FULL.img /mnt/fd/
mount: /mnt/fd: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error.
#
8<----------------------------------------------------------------------
[4] He fumbles around with hexdump on the file FD13FULL.img...
8<----------------------------------------------------------------------
$ hexdump -f f64a.spec /opt/ged/FreeDOS/FD13-FullUSB/FD13FULL.img | less
000000
fafc31c08ed08ed8bd007c8d66e0fbb8e01f8ec089ee89efb90001f3a5ea227ce01f8ed88ed031c08ec08dbebe01f60580756d83c71081fffe7d72f2e8c4006e
..1.......|.f................."|......1..........um......}r....n
000040
6f2061637469766520706172746974696f6e20666f756e6400ebfee8a50072656164206572726f72207768696c652072656164696e6720647269766500ebdae8
o active partition found......read error while reading drive....
000080
8100706172746974696f6e207369676e617475726520213d203535414100ebb9e8100072b626813efe7d55aa75d1ea007c0000bbaa55b441cd13723281fb55aa
..partition signature != 55AA......r.&.>.}U.u...|....U.A..r2..U.
0000c0
752cf6c1017427eb1010000400007c000000000000000000008b4508a3d17c8b450aa3d37cb80042bec97ccd13c3b80402bb007c8b4d028a7501cd13c331dbb4
u,...t'.......|...........E...|.E...|..B..|........|.M..u....1..
000100
0ecd105eac563c0075f3c30000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
...^.V<.u.......................................................
000140
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
................................................................
000180
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008001
................................................................
0001c0
01000e0f3f103f000000c1fe0f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055aa
....?.?.......................................................U.
000200
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
................................................................
*
007e00
eb3c904652444f53352e3100021001000200020000f800013f0010003f000000c1fe0f008000291414662e464431332d46554c4c20204641543136202020fafc
.<.FRDOS5.1.............?...?.........)..f.FD13-FULL FAT16 ..
007e40
31c08ed8bd007cb8e01f8ec089ee89efb90001f3a5ea5e7ce01f000060008ed88ed08d66a0fb885624c746c01000c746c201008c5ec6c746c4a0638b761c8b7e
1.....|...............^|....`......f...V$.F....F....^..F..c.v..~
...
8<----------------------------------------------------------------------
[5] ... then mounts using the offset 007e00 hexadecimal = 32256 decimal:
8<----------------------------------------------------------------------
# mount -t vfat -o offset=32256 /..../FD13-FullUSB/FD13FULL.img /mnt/fd/
# ls -lrt /mnt/fd/
total 184
-rwxr-xr-x 1 root root 7141 Feb 20 2022 setup.bat
-rwxr-xr-x 1 root root 46256 Feb 20 2022 KERNEL.SYS
-rwxr-xr-x 1 root root 223 Feb 20 2022 fdconfig.sys
-rwxr-xr-x 1 root root 85480 Feb 20 2022 COMMAND.COM
drwxr-xr-x 5 root root 8192 Feb 20 2022 freedos
drwxr-xr-x 15 root root 8192 Feb 20 2022 packages
-rwxr-xr-x 1 root root 1347 Feb 20 2022 fdauto.bat
drwxr-xr-x 4 root root 8192 Feb 20 2022 FDOS-x86
# umount /mnt/fd
# ls -l /mnt/fd/
total 0
#
8<----------------------------------------------------------------------