17 replies to this topic

[Ninho]

Haven't investigated thoroughly, then, is it just me, or... ? It appears though Grub4DOS won't recognize/mount 

a FAT16 partition as soon as the third byte of the jump instruction at partition boot-record (PBR) offset zero, usually :

    Jmp short  Start
    NOP

... was changed from 0x90 to anything else, including 0x0E (which, as one knows,  some boot code variants

use as a hint to make only extended int 13 calls). 

Restoring the byte sufficed to restore Grub4DOS's ability to mount, access, and boot from, the partition !

 

Issue noticed while using G4Dos 0.4.6a-2019-10-28 (Chenall's). As said, I've not investigated further yet

w/ other FAT types, G4DOS versions, or other variations off the regular boot record. 

 

Waiting to hear from you all if this is a confirmed, even expected (?) quirk, is it version specific and of course 

hoping for a fix if this is confirmed as a bug.

Edited by Ninho, 29 November 2019 - 06:53 PM.

[steve6375]

What do you mean by boot record?  MBR or PBR ?

So grub4dos boots OK - but cannot access the partition?

So if you boot using QEMU or VBox - does the same thing happen?

[Ninho]

What do you mean by boot record?  MBR or PBR ?

So grub4dos boots OK - but cannot access the partition?

So if you boot using QEMU or VBox - does the same thing happen?

- Not MBR, yes the FAT partition boot-record (PBR). Sorry it hadn't been clear - I edited my original post just now...

- Right, Grub4DOS does not see/find/can't mount the partition unless first 3 bytes have the pattern (hex) EB xx 90. Didn't try a long jmp though.

- Have tried the real thing only, i.e. bare metal. 

Edited by Ninho, 29 November 2019 - 06:54 PM.

[steve6375]

OK - well you need to try a virtual machine or at least a completely different system\BIOS.

What is your answer to question 2?

Is grub4dos installed onto MBR or PBR or both?

What are you booting from? USB? SD? floppy? CD? IDE? SATA? what size is disk? where is partition located?

Are you using standard MBR primary partition?

 

When you report an issue  - why not give clear and accurate information?

[Wonko the Sane]

- Not MBR, yes the FAT partition boot-record (PBR). Sorry it hasn't been clear - I would edit my original post, but can't seem to be allowed to...

- Right, Grub4DOS does not see/find/can't mount the partition unless first 3 bytes have the pattern (hex) EB xx 90. Didn't try a long jmp though.

- Have tried the real thing only, i.e. bare metal. 

Not exactly what you asked, but near enough.

 

Different OS's might have different ways to recognize a valid bootsector/PBR, see starting here:

https://msfn.org/boa...&comment=987373

 

The debate there is about how many (if any) of those early bytes are part of the code or part of the BPB, and which values are valid (IF they are checked), see the results of experiment a few posts below, here:

https://msfn.org/boa...&comment=987482

 

Try with E9, which is the other "valid" value besides EB XX 90.

 

 

Wonko

[Ninho]

Grub4DOS in the MBR. 

When you report an issue  - why not give clear and accurate information?

Fair enough. I thought I'd given enough context, and in my turn asked a clear and accurate question : does your grub4dos 

also cease to be able to "see" and access a partition as FAT12/16 if you change byte 02 from 90h to another value ?

 

Would you please do that simple test for me before any more arguing ? That was the gist of my initial question. 

Clearly if it confirmed Grub4DOS (current) won't mount such a FAT partition, any further exploration is mute. 

[Ninho]

Hi Wonko !

(...)
The debate there is about how many (if any) of those early bytes are part of the code or part of the BPB, and which values are valid (IF they are checked)
 
(...)
Try with E9, which is the other "valid" value besides EB XX 90.

Wonko

I have just tried an E9 long-jump, Grub4DOS mounts the part properly and everything rocks
as well. So my question is sorted out, it is a G4DOS bug which needs to be addressed
IMNSHO. While the check for a JMP - short or long kind - at PBR offset 0 is admissible, checking for the NOP at byte 2 (in case of a short jump) was always over-zealous and it has become a definite bug as soon as it is well-known that certain variants of FAT boot-codes use this very byte as an indicator. Just ignore the byte value !

Is is too much to pray either of you (Steve, Wonko..) fill a bug with Chenall or whomever ?

Good day/night...

[steve6375]

I cant report it, since I cannot give clear and accurate details. if I am asked any Q's - how can I reply?

Why don't you report it?

https://github.com/c...grub4dos/issues

[Wonko the Sane]

I have just tried an E9 long-jump, Grub4DOS mounts the part properly and everything rocks
as well. So my question is sorted out, it is a G4DOS bug which needs to be addressed
IMNSHO.

No, it is NOT a bug, it is (evidently) a decision (which is debatable of course) made to keep the behaviour consistent with MS-DOS 7.1 (and possibly older versions of MS-DOS, you know, the thing written by more or less the same guys that actually invented the FAT filesystem) the fact that later some of the same guys changed their mind and removed the check for the third byte in later OS versions may (or may not) be a valid decision, still this behaviour is not at all a bug. 
 
I will quote what I referenced earlier (that may be hasn't been read or - if it has been read - it has not been fully understood):

• under both DOS and XP the Magic Bytes are ignored and have NO influence whatsoever with reading/accessing the BPB, so they are part of the CODE (and not of the BPB) .
• XP only checks if first byte is EB OR that first byte is E9 (the three one jump bytes are is part of the BPB)
• DOS 7.1 checks that first byte is EB and third is 90 (the three two jump bytes are part of the BPB) OR that first byte is E9 (the three one jump  bytes are is part of the BPB)
• FREEdos ignores the three jump bytes and only checks for Magic Bytes (so , Magic Bytes is part of the BPB and NOT of the CODE, and the three jump bytes are part of the CODE and NOT of the BPB ) and it also has some kind of "sticky attitude" if it accesses another properly setup floppy, somehow the Magic Bytes are "ported over".

 
So, if we call it a "feature", it would make a lot of sense (to me at least) to discuss about lifting the restriction, knowing that by doing so it might happen to have non-MS-DOS compliant bootsectors (which MS-DOS won''t mount/access).

 

It could even be an added grub4dos "environment variable", with a default of "strict" and an option to set it as "loose".

 

BTW, and as a side note, what happens with map --in-situ?
 

Wonko

[steve6375]

Sure - but since we don't know how this partition was made or what it is used for or what OS is on it, or what the scenario is, etc. it is difficult to know if there is a valid and pertinent reason to relax the limitation.

[steve6375]

[Sector 165624]  80MB
0000 E9 62 00 4D 53 44 4F 53 - 35 2E 30 00 02 01 F8 1B  éb.MSDOS 5.0...ø
0010 02 00 00 00 00 F8 00 00 - 3F 00 FF 00 F8 86 02 00  .....ø.. ?.ÿ.ø†..
0020 EA 21 01 00 04 02 00 00 - 00 00 00 00 02 00 00 00  ê!...... ........
0030 01 00 06 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ........ ........
0040 80 00 29 1D 06 84 44 4E - 4F 20 4E 41 4D 45 20 20  €.).„DN O NAME 
0050 20 20 46 41 54 33 32 20 - 20 20 42 4F 4F 54 33 20    FAT32    BOOT3
0060 20 20 20 20 20 FA 66 31 - C0 8E D0 BC F0 FF FB 8E       úf1 ÀŽÐ¼ðÿûŽ

Partition 1   SIZE=36.24MiB   Type: 0C FAT32LBA (2047GB max)  *ACTIVE*
START POS   = CYL:1023 HD:254 SEC:63       END POS = CYL:1023 HD:254 SEC:63
START (LBA) = 165,624 (000286F8) SIZE (LBA) = 74,219 (000121EB) [End=239,842]

No problem with 00 or 0E for me on FAT32 ???

Attached Thumbnails

• 
• 

[steve6375]

Standard  PBR as prepared using RMPrepUSB FAT16 uses  0E and works with grub4dos

[Sector 2048]  1MB
0000 EB 3C 0E 4D 53 44 4F 53 - 35 2E 30 00 02 80 01 00  ë<MSDOS 5.0..€..
0010 02 00 02 00 00 F8 00 01 - 3F 00 FF 00 00 08 00 00  .....ø.. ?.ÿ.....
0020 A9 9F 77 00 80 00 29 1E - 16 10 3E 4E 4F 20 4E 41  ©Ÿw.€.) >NO NA

Which exact first 3 bytes do not work for you?

[steve6375]

fat16 

E9 62 0E

works OK.

also 2019-10-28 grldr works OK

Attached Thumbnails

• 

Edited by steve6375, 29 November 2019 - 09:03 PM.

[Ninho]

fat16
E9 62 0E
works OK.
also 2019-10-28 grldr works OK

OK, thanks very much for the testing/checking/gathered evidence, this is exactly the sort of help I needed/hoped from you Guys !
It follows, the mounting problems I encountered (only when the byte in question is not 90h !)
are not, or not only, caused by Grub4DOS itself but somehow related to by some complex interaction of "things" I'm trying to build.

Evidently I'll have to investigate in details, I'll need more time - don't we all want we had more spare time ?

[steve6375]

Which is why I asked all those Q's which you still haven't answered!

I found it difficult to believe that after all these years, you had discovered such a basic new issue with grub4dos.

It was much more likely that you had a BIOS issue, but since you have not tested it on a different system or QEMU (e.g. RMPrepUSB - F11) or a VM such as VBOX+VMUB and have not provided any details, we can't really help.

If you can provide the ALL the answers to the Q's and check using QEMU or another system, we could probably easily tell you where to look for the cause.

[Wonko the Sane]

Which is why I asked all those Q's which you still haven't answered!

I found it difficult to believe that after all these years, you had discovered such a basic new issue with grub4dos.

It was much more likely that you had a BIOS issue, but since you have not tested it on a different system or QEMU (e.g. RMPrepUSB - F11) or a VM such as VBOX+VMUB and have not provided any details, we can't really help.

If you can provide the ALL the answers to the Q's and check using QEMU or another system, we could probably easily tell you where to look for the cause.

 ... and we are back to the need for the Standard Litany ... 

https://jdebp.eu/FGA...ard-litany.html

 

 

 

OK, thanks very much for the testing/checking/gathered evidence, this is exactly the sort of help I needed/hoped from you Guys !
It follows, the mounting problems I encountered (only when the byte in question is not 90h !)
are not, or not only, caused by Grub4DOS itself but somehow related to by some complex interaction of "things" I'm trying to build.

Evidently I'll have to investigate in details, I'll need more time - don't we all want we had more spare time ?

Sure  , and that is exactly the reason why our little spare time is precious and should be dedicated to troubleshoot (and hopefully solve) properly documented issues.  

 

Wonko

[Ninho]

Sure and that is exactly the reason why our little spare time is precious and should be dedicated to troubleshoot (and hopefully solve) properly documented issues.

Ha ha! I have difficulty believing that our irreplaceable Wonko does not love spending an inordinate amount of that precious spare time of his just for the sake of polishing up his own ego. But not to argue... I only asked for somebody to verify a IMO clearly stated assumption relative to Grub4DOS, never asked or expected you to "troubleshoot" my system.

[Wonko the Sane]

Ha ha! I have difficulty believing that our irreplaceable Wonko does not love spending an inordinate amount of that precious spare time of his just for the sake of polishing up his own ego. But not to argue... I only asked for somebody to verify a IMO clearly stated assumption relative to Grub4DOS, never asked or expected you to "troubleshoot" my system.

Yep , the issue is that it is so hard to find nowadays a suitable paste and appropriate (woolen) clothes to make it as shining as it deserves to.  (and so a lot of time and  effort being dedicated to that leaves less spare-spare time)

 

Wonko