strange problem booting

[bilsch01]

I have a simple OS on partition #2 of the HD (sda2) and I have GRUB set
up to display a menu option to boot sda2. It boots and runs fine. Note
also, I have MSDOS 6.22 on sda1, which also boots and runs fine. The
boot flag in the partition table is set for sda1, but GRUB overrides
that, as it should, and boots the partition selected with the GRUB menu.
I made an image of the first 3 partitions, which is in a file named
qemu4dell.img, which I want to use for booting with QEMU. The first
sector of the image (MBR) had a non-standard booting program, which is
used by GRUB, and I replaced that with a known, standard booting program
which I have used successfully in the past. (I refer to this program as
the IPL). The command I use with QEMU is of the form:

qemu-system-i386 -drive file=qemu4dell.img

which I have been using successfully for other situations.

OK. The boot flag in the partition table is set on partition #1 (sda1)
and when I enter the QEMU command above the MSDOS partition boots in
QEMU. Great! Next, using a hex editor I un-set the boot flag for sda1
and set it for sda2 and try the QEMU command again - expecting the OS on
sda2 to boot in QEMU. Instead an error message is displayed:

missing operating system.

I know for a fact that message is displayed by the IPL program if the
first sector (volume boot sector, vbs) of the partition to be booted
does not have the signature AA55 in the last 2 bytes of the sector.
Note: partition #2 (sda2) on the HD gets booted by GRUB when selected in
the GRUB menu, so I would expect it to boot in QEMU if the boot flag is
set. Also note MSDOS on sda1 boots in QEMU when the boot flag is set.
Here's what I did to troubleshoot this problem:

1) checked the first sector of qemu4dell.img to verify that the 32-bit
sector number indicated for the start of sda2 matches the sector number
reported by fdisk -l. Note: the sector number is the location of vbs#2.

2) checked the location of vbs#2 in file qemu4dell.img and verified the
vbs is there and the AA55 signature is present.

3) just in case I'm having an "off by one error" OBOE in my brain I made
a copy of vbs#2 and wrote the copy both before and after the location of
the existing vbs#2 in qemu4dell.img. So if I'm off by one the IPL
program will find one of the copies of vbs#2 and the error won't be
reported. That didn't fix the problem.

Does anybody know what might be wrong?

TIA. Bill S.

[bilsch01]

I should have been more explicit in the last line of the post. I mean to
ask:

Does anyone know why I get the error
"missing operating system"
when trying to boot partition#2 (sda2) on QEMU?

Thanks.

[Rod Pemberton]

On Thu, 25 Mar 2021 11:20:22 -0700

Post by bilsch01
I have a simple OS on partition #2 of the HD (sda2) and I have GRUB
set up to display a menu option to boot sda2. It boots and runs fine.
Note also, I have MSDOS 6.22 on sda1, which also boots and runs fine.
The boot flag in the partition table is set for sda1, but GRUB
overrides that, as it should, and boots the partition selected with
the GRUB menu. I made an image of the first 3 partitions, which is in
a file named qemu4dell.img, which I want to use for booting with
QEMU. The first sector of the image (MBR) had a non-standard booting
program, which is used by GRUB, and I replaced that with a known,
standard booting program which I have used successfully in the past.
(I refer to this program as the IPL). The command I use with QEMU is

Used successfully in the past ... with GRUB?

Why did you replace the GRUB non-standard booting program with IPL?

sda2 boots and runs fine ... with IPL?

Post by bilsch01
qemu-system-i386 -drive file=qemu4dell.img
which I have been using successfully for other situations.
OK. The boot flag in the partition table is set on partition #1
(sda1) and when I enter the QEMU command above the MSDOS partition
boots in QEMU. Great! Next, using a hex editor I un-set the boot flag
for sda1 and set it for sda2 and try the QEMU command again -
expecting the OS on sda2 to boot in QEMU. Instead an error message is
missing operating system.

...

Post by bilsch01
I know for a fact that message is displayed by the IPL program if the
first sector (volume boot sector, vbs) of the partition to be booted
does not have the signature AA55 in the last 2 bytes of the sector.

The first sector of my Linux file system partition has an 0xAA55 at the
end, and it appears to have been installed by GRUB as it contains
the text "GRUB Geom Hard Disk Read Error" near the end of the 512
bytes. I haven't disassembled it, but it appears to be boot code,
e.g., jmp short EB63 followed by nop 90.

fdisk -l

Take the Start value for sda2 and convert it into hex.
Replace the ... in the command below with the hex value.

cd /
dd if=/dev/sda of=/bils.bin skip=0x...b count=1
hexdump -C bils.bin

Note that is sda not sda2.

Post by bilsch01
Note: partition #2 (sda2) on the HD gets booted by GRUB when selected
in the GRUB menu, so I would expect it to boot in QEMU if the boot
flag is set.

My Linux partitions don't have the Boot flag set.

I.e., I'm not sure if the Boot flag is recognized or used by Linux.

Post by bilsch01
Also note MSDOS on sda1 boots in QEMU when the boot flag
is set.

My DOS partitions have the Boot flag set.

Post by bilsch01
1) checked the first sector of qemu4dell.img to verify that the
32-bit sector number indicated for the start of sda2 matches the
sector number reported by fdisk -l. Note: the sector number is the
location of vbs#2.
2) checked the location of vbs#2 in file qemu4dell.img and verified
the vbs is there and the AA55 signature is present.
3) just in case I'm having an "off by one error" OBOE in my brain I
made a copy of vbs#2 and wrote the copy both before and after the
location of the existing vbs#2 in qemu4dell.img. So if I'm off by one
the IPL program will find one of the copies of vbs#2 and the error
won't be reported. That didn't fix the problem.
Does anybody know what might be wrong?

As QEMU is involved here and not real hardware, I can't say anything
with conclusiveness about the source of the issue. I.e., could be the
image, could be QEMU emulation, could be Linux GRUB, ...

I don't have my Linux and MS-DOS partitions on the same drive.

Linux usually likes two partitions, a swap (type 82h) and a file system
(type 83h). I have my swap first, and in the first partition slot.

Where is your Linux swap partition? Did Linux boot without it? sda3?

[bilsch01]

Post by Rod Pemberton
On Thu, 25 Mar 2021 11:20:22 -0700

Post by bilsch01
I have a simple OS on partition #2 of the HD (sda2) and I have GRUB
set up to display a menu option to boot sda2. It boots and runs fine.
Note also, I have MSDOS 6.22 on sda1, which also boots and runs fine.
The boot flag in the partition table is set for sda1, but GRUB
overrides that, as it should, and boots the partition selected with
the GRUB menu. I made an image of the first 3 partitions, which is in
a file named qemu4dell.img, which I want to use for booting with
QEMU. The first sector of the image (MBR) had a non-standard booting
program, which is used by GRUB, and I replaced that with a known,
standard booting program which I have used successfully in the past.
(I refer to this program as the IPL). The command I use with QEMU is

Used successfully in the past ... with GRUB?

parted looks like this:
Number Start End Size Type File system Flags
1 63s 3903794s 3903732s primary fat16 boot
2 3903795s 4032314s 128520s primary fat16 lba
3 4032315s 4082714s 50400s primary fat16 lba
4 7262206s 976771071s 969508866s extended
5 7262208s 8312831s 1050624s logical fat32
6 8314880s 976771071s 968456192s logical ext4

fdisk looks like this:
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 63 3903794 3903732 1.9G 6 FAT16
/dev/sda2 3903795 4032314 128520 62.8M e W95 FAT16 (LBA)
/dev/sda3 4032315 4082714 50400 24.6M e W95 FAT16 (LBA)
/dev/sda4 7262206 976771071 969508866 462.3G 5 Extended
/dev/sda5 7262208 8312831 1050624 513M b W95 FAT32
/dev/sda6 8314880 976771071 968456192 461.8G 83 Linux

One of the objectives for the time being is to boot sda2 in QEMU, which
runs on Ubuntu 20.04. sda3 will be readable/writable from sda2. The
other partitions are not part of the experiment. I do all the 'work'
from Ubuntu on sda6. There is no swap partition, and sda5 is empty space.

Originally I only booted & ran the sda2/3 system on a thumb drive. I
quit that and went to QEMU. Now I want to run from HD, and for the
purpose of the present post, also in QEMU.

Note: In the partition table in the first sector of image file for QEMU
(qemu4dell.img) I zeroed out the entry for partition #4 because I don't
have partition #4 in the image file.

Post by Rod Pemberton
Why did you replace the GRUB non-standard booting program with IPL?

I don't want QEMU booting GRUB. I mentioned GRUB and MSDOS only for
supporting information. While that might be useful for illustration,
mentioning them tends to make my post confusing.

Post by Rod Pemberton
sda2 boots and runs fine ... with IPL?

Yes, boots & runs fine with IPL.
sda2 doesn't do all of what it used to do, but that problem precedes
this set up. That problem is part of the learning experience I'm aiming for.

Post by Rod Pemberton

Post by bilsch01
qemu-system-i386 -drive file=qemu4dell.img
which I have been using successfully for other situations.
OK. The boot flag in the partition table is set on partition #1
(sda1) and when I enter the QEMU command above the MSDOS partition
boots in QEMU. Great! Next, using a hex editor I un-set the boot flag
for sda1 and set it for sda2 and try the QEMU command again -
expecting the OS on sda2 to boot in QEMU. Instead an error message is
missing operating system.

...

Some time ago I disassembled and examined the IPL in detail.

Post by Rod Pemberton

Post by bilsch01
I know for a fact that message is displayed by the IPL program if the
first sector (volume boot sector, vbs) of the partition to be booted
does not have the signature AA55 in the last 2 bytes of the sector.

The first sector of my Linux file system partition has an 0xAA55 at the
end, and it appears to have been installed by GRUB as it contains
the text "GRUB Geom Hard Disk Read Error" near the end of the 512
bytes. I haven't disassembled it, but it appears to be boot code,
e.g., jmp short EB63 followed by nop 90.
fdisk -l
Take the Start value for sda2 and convert it into hex.
Replace the ... in the command below with the hex value.
cd /
dd if=/dev/sda of=/bils.bin skip=0x...b count=1
hexdump -C bils.bin
Note that is sda not sda2.

Yes. It shows the vbs#2

Post by Rod Pemberton

Post by bilsch01
Note: partition #2 (sda2) on the HD gets booted by GRUB when selected
in the GRUB menu, so I would expect it to boot in QEMU if the boot
flag is set.

My Linux partitions don't have the Boot flag set.
I.e., I'm not sure if the Boot flag is recognized or used by Linux.

The boot flag seems to be ignored by GRUB - GRUB uses its boot menu.

Post by Rod Pemberton

Post by bilsch01
Also note MSDOS on sda1 boots in QEMU when the boot flag
is set.

My DOS partitions have the Boot flag set.

Post by bilsch01
1) checked the first sector of qemu4dell.img to verify that the
32-bit sector number indicated for the start of sda2 matches the
sector number reported by fdisk -l. Note: the sector number is the
location of vbs#2.
2) checked the location of vbs#2 in file qemu4dell.img and verified
the vbs is there and the AA55 signature is present.
3) just in case I'm having an "off by one error" OBOE in my brain I
made a copy of vbs#2 and wrote the copy both before and after the
location of the existing vbs#2 in qemu4dell.img. So if I'm off by one
the IPL program will find one of the copies of vbs#2 and the error
won't be reported. That didn't fix the problem.
Does anybody know what might be wrong?

As QEMU is involved here and not real hardware, I can't say anything
with conclusiveness about the source of the issue. I.e., could be the
image, could be QEMU emulation, could be Linux GRUB, ...

I don't think GRUB and QEMU are interacting because I wrote over the
GRUB IPL with a standard IPL: GRUB never gets started in the QEMU run.

Post by Rod Pemberton
I don't have my Linux and MS-DOS partitions on the same drive.
Linux usually likes two partitions, a swap (type 82h) and a file system
(type 83h). I have my swap first, and in the first partition slot.
Where is your Linux swap partition? Did Linux boot without it? sda3?

I used to use a swap but I stopped. I don't think I have noticed a
difference. I'm not a power user.

Thanks for your comments.

[Rod Pemberton]

On Fri, 26 Mar 2021 09:23:43 -0700

Post by bilsch01

Post by Rod Pemberton
On Thu, 25 Mar 2021 11:20:22 -0700

Post by bilsch01
I have a simple OS on partition #2 of the HD (sda2) and I have GRUB
set up to display a menu option to boot sda2. It boots and runs
fine. Note also, I have MSDOS 6.22 on sda1, which also boots and
runs fine. The boot flag in the partition table is set for sda1,
but GRUB overrides that, as it should, and boots the partition
selected with the GRUB menu. I made an image of the first 3
partitions, which is in a file named qemu4dell.img, which I want
to use for booting with QEMU. The first sector of the image (MBR)
had a non-standard booting program, which is used by GRUB, and I
replaced that with a known, standard booting program which I have
used successfully in the past. (I refer to this program as the

Used successfully in the past ... with GRUB?

Number Start End Size Type File system Flags
1 63s 3903794s 3903732s primary fat16 boot
2 3903795s 4032314s 128520s primary fat16 lba
3 4032315s 4082714s 50400s primary fat16 lba
4 7262206s 976771071s 969508866s extended
5 7262208s 8312831s 1050624s logical fat32
6 8314880s 976771071s 968456192s logical ext4
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 63 3903794 3903732 1.9G 6 FAT16
/dev/sda2 3903795 4032314 128520 62.8M e W95 FAT16 (LBA)
/dev/sda3 4032315 4082714 50400 24.6M e W95 FAT16 (LBA)
/dev/sda4 7262206 976771071 969508866 462.3G 5 Extended
/dev/sda5 7262208 8312831 1050624 513M b W95 FAT32
/dev/sda6 8314880 976771071 968456192 461.8G 83 Linux
One of the objectives for the time being is to boot sda2 in QEMU,
which runs on Ubuntu 20.04. sda3 will be readable/writable from sda2.
The other partitions are not part of the experiment. I do all the
'work' from Ubuntu on sda6. There is no swap partition, and sda5 is
empty space.
Originally I only booted & ran the sda2/3 system on a thumb drive. I
quit that and went to QEMU. Now I want to run from HD, and for the
purpose of the present post, also in QEMU.
Note: In the partition table in the first sector of image file for
QEMU (qemu4dell.img) I zeroed out the entry for partition #4 because
I don't have partition #4 in the image file.

Good, because the fdisk space allocation numbers you posted for sda4
overlap with partitions sda5 and sda6, i.e., overwrite?

There also seems to be an unused gap from 4082715 to either 7262206 or
7262208. I suspect that's were sda4 was supposed to be.

I've got nothing more on your main problem.

[bilsch01]

Post by Rod Pemberton
On Fri, 26 Mar 2021 09:23:43 -0700

Post by bilsch01

Post by Rod Pemberton
On Thu, 25 Mar 2021 11:20:22 -0700

Post by bilsch01
I have a simple OS on partition #2 of the HD (sda2) and I have GRUB
set up to display a menu option to boot sda2. It boots and runs
fine. Note also, I have MSDOS 6.22 on sda1, which also boots and
runs fine. The boot flag in the partition table is set for sda1,
but GRUB overrides that, as it should, and boots the partition
selected with the GRUB menu. I made an image of the first 3
partitions, which is in a file named qemu4dell.img, which I want
to use for booting with QEMU. The first sector of the image (MBR)
had a non-standard booting program, which is used by GRUB, and I
replaced that with a known, standard booting program which I have
used successfully in the past. (I refer to this program as the

Used successfully in the past ... with GRUB?

Number Start End Size Type File system Flags
1 63s 3903794s 3903732s primary fat16 boot
2 3903795s 4032314s 128520s primary fat16 lba
3 4032315s 4082714s 50400s primary fat16 lba
4 7262206s 976771071s 969508866s extended
5 7262208s 8312831s 1050624s logical fat32
6 8314880s 976771071s 968456192s logical ext4
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 63 3903794 3903732 1.9G 6 FAT16
/dev/sda2 3903795 4032314 128520 62.8M e W95 FAT16 (LBA)
/dev/sda3 4032315 4082714 50400 24.6M e W95 FAT16 (LBA)
/dev/sda4 7262206 976771071 969508866 462.3G 5 Extended
/dev/sda5 7262208 8312831 1050624 513M b W95 FAT32
/dev/sda6 8314880 976771071 968456192 461.8G 83 Linux
One of the objectives for the time being is to boot sda2 in QEMU,
which runs on Ubuntu 20.04. sda3 will be readable/writable from sda2.
The other partitions are not part of the experiment. I do all the
'work' from Ubuntu on sda6. There is no swap partition, and sda5 is
empty space.
Originally I only booted & ran the sda2/3 system on a thumb drive. I
quit that and went to QEMU. Now I want to run from HD, and for the
purpose of the present post, also in QEMU.
Note: In the partition table in the first sector of image file for
QEMU (qemu4dell.img) I zeroed out the entry for partition #4 because
I don't have partition #4 in the image file.

Good, because the fdisk space allocation numbers you posted for sda4
overlap with partitions sda5 and sda6, i.e., overwrite?

sda4 is extended. sda5 & 6 are logical volumes within the extended part.

Post by Rod Pemberton
There also seems to be an unused gap from 4082715 to either 7262206 or
7262208. I suspect that's were sda4 was supposed to be.
I've got nothing more on your main problem.

[Rod Pemberton]

On Fri, 26 Mar 2021 19:58:47 -0700

Post by bilsch01
sda4 is extended. sda5 & 6 are logical volumes within the extended part.

It that how extended partitions work? I.e., container for more
partitions. Well, imagine that, I just learned something new. I never
used them. I just thought DOS used them for secondary partitions. I
guess that I should've suspected something was up with the 6 partitions
instead of 4 ...

[bilsch01]

Post by bilsch01
I have a simple OS on partition #2 of the HD (sda2) and I have GRUB set
up to display a menu option to boot sda2. It boots and runs fine. Note
also, I have MSDOS 6.22 on sda1, which also boots and runs fine. The
boot flag in the partition table is set for sda1, but GRUB overrides
that, as it should, and boots the partition selected with the GRUB menu.
I made an image of the first 3 partitions, which is in a file named
qemu4dell.img, which I want to use for booting with QEMU. The first
sector of the image (MBR) had a non-standard booting program, which is
used by GRUB, and I replaced that with a known, standard booting program
which I have used successfully in the past. (I refer to this program as
qemu-system-i386 -drive file=qemu4dell.img
which I have been using successfully for other situations.
OK. The boot flag in the partition table is set on partition #1 (sda1)
and when I enter the QEMU command above the MSDOS partition boots in
QEMU. Great! Next, using a hex editor I un-set the boot flag for sda1
and set it for sda2 and try the QEMU command again - expecting the OS on
missing operating system.
I know for a fact that message is displayed by the IPL program if the
first sector (volume boot sector, vbs) of the partition to be booted
does not have the signature AA55 in the last 2 bytes of the sector.
Note: partition #2 (sda2) on the HD gets booted by GRUB when selected in
the GRUB menu, so I would expect it to boot in QEMU if the boot flag is
set. Also note MSDOS on sda1 boots in QEMU when the boot flag is set.
1) checked the first sector of qemu4dell.img to verify that the 32-bit
sector number indicated for the start of sda2 matches the sector number
reported by fdisk -l. Note: the sector number is the location of vbs#2.
2) checked the location of vbs#2 in file qemu4dell.img and verified the
vbs is there and the AA55 signature is present.
3) just in case I'm having an "off by one error" OBOE in my brain I made
a copy of vbs#2 and wrote the copy both before and after the location of
the existing vbs#2 in qemu4dell.img. So if I'm off by one the IPL
program will find one of the copies of vbs#2 and the error won't be
reported. That didn't fix the problem.

The 16 byte field contains two equivalent types of 'coordinates' for the
location of the boot sector. It has both C,H,S coordinates and also the
linear sector number, which is the same thing as the LBA number. (Note:
the numbers listed below in the column labeled 'start' are the LBA
numbers of the boot sectors of the partitions.) But even though
partition #2 is called type 'e' meaning LBA, the loader (IPL) in this
particular MBR does not use the LBA number to locate the boot sector, it
uses the CHS coordinates. That is a fact, I saw it in the code. However,
note that partition #1 is about 2 Gigabytes, thus partition #2 starts
after about 2 GB. Maybe CHS coordinates aren't adequate to compute that
large number. If the computed number is wrong the error message will be
displayed and boot process will halt.

That's an interesting speculation, however it is a known fact that on
the actual hard drive partition #2 boots just fine.

Something QEMU is doing must be computing the location of the boot
sector incorrectly.

For Reference here is the fdisk output for the hard drive:

Device Boot Start End Sectors Size
Id Type
/dev/sda1 63 3903794 3903732 1.9G
6 FAT16
/dev/sda2 * 3903795 4032314 128520 62.8M e
W95 FAT16 (LBA)
/dev/sda3 4032315 4082714 50400 24.6M e
W95 FAT16 (LBA)
/dev/sda4 4083710 976771071 972687362 463.8G 5 Extended

Post by bilsch01
Does anybody know what might be wrong?
TIA.    Bill S.

[Scott Lurndal]

Post by bilsch01
Something QEMU is doing must be computing the location of the boot
sector incorrectly.

QEMU is open source. Use the source, Luke.

[wolfgang kern]

On 09.04.2021 19:09, bilsch01 wrote:
...

Post by bilsch01
Device Boot Start End Sectors Size
Id Type
/dev/sda1 63 3903794 3903732 1.9G
6 FAT16
/dev/sda2 * 3903795 4032314 128520 62.8M e
W95 FAT16 (LBA)
/dev/sda3 4032315 4082714 50400 24.6M e
W95 FAT16 (LBA)
/dev/sda4 4083710 976771071 972687362 463.8G 5 Extended

FAT16 maximum : 64 sectors per cluster × 65,524 clusters = 2,147,090,432
bytes (≈2 GB) and CHS is also limited to 2GB (even 24 bits allowed 8GB).

it may choke on the 64 sectors/cluster ?
or wrong CHS settings (if they are set to max then BIOS use the LBA).
__
wolfgang