Jump to content











Photo
- - - - -

Grub4DOS & 4Kn Drive Try (fd0) Error

4kn 4k sectors 4k native sectors 4096 bytes

  • Please log in to reply
38 replies to this topic

#26 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 26 April 2020 - 04:26 AM

Using a modified bootmgr PBR and remaining grldr work :hyper:. That is genius and I did not think to even do that.

Thank you so much for your help and suggestions. Much appreciated!


Edited by RandomUser, 26 April 2020 - 04:46 AM.


#27 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 26 April 2020 - 08:25 AM

Very good :), and now the bad news. :w00t:

 

No, I am joking, nothing will happen, rest assured :), but renaming grldr to something else is not advised - generally speaking by the Authors, even if there isn't a definite explanation of the reason why it shouldn't.

 

The following is ONLY for the record and for future memory.

 

Changing the PBR calling NTLDR (bootsect /NT52) to call instead GRLDR is straightforward with a hex editor (the string is on second sector of the PBR, at offset 0x0001 or at offset 0x0201 of the $Boot file) because both NTLDR and GRLDR are 5 letters long.

 

Changing the PBR calling BOOTMGR (bootsect /60) needs to rename grldr to - say - MYGRLDR in order to have a same length (7 characters) string.

 

BUT, if you check at offset 0x0200 in the PBR (or the very beginning of the second sector) you will see :

 

07 00 42 00 4F 00 4F 00 54 00 4D 00 47 00 52 00 ..B.O.O.T.M.G.R.

i.e. before the actual BOOTMGR (Unicode) there is a 07 which is the length of the string, so you can change that to:

 

05 00 47 00 52 00 4C 00 44 00 52 00 00 00 00 00 ..G.R.L.D.R.....

without needing to change the name to the grldr file.

 

Also only for memory, there is also another trick, that I found once and that unfortunately I forgot the details :w00t: : :blush: .

 

It was some misknown boot manager (or some similar software) that managed to switch between BOOTMGR and NTLDR using the same (Vista+) PBR by changing a "pointer" in the PBR, as a matter of fact, at 0x025A there is still a call to NTLDR[1]:

 

00 00 00 00 00 00 EB 22 90 90 05 00 4E 00 54 00 ......ë".N.T.
4C 00 44 00 52 00 00 00 00 00 00 00 00 00 00 00 L.D.R.........

that software changed *somewhere* the offset to the loader string.

 

I forgot which tool did that and never found it again :(, maybe someone more familiar than myself with Assembly would be able to find that byte.[2]

 

:duff:

Wonko

 

 

 

 

 

[1] And - it depends on which pbr is at hand there may be other such strings, in the 8.0 and 8.1 PBR there are also the mysterious BOOTTGT and BOOTNXT (not in the Vista and in the 7 ones)

[2] it could be the 0x0200 address in "66 0F B7 0E 00 02" aka "MOVZX ECX,WORD PTR [0200]" that is present in all the PBR's and should behave like explained here:

https://thestarman.p...TLDR_Loader.htm


  • RandomUser likes this

#28 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 27 April 2020 - 06:44 AM

That is some interesting read. Also you had me going there for a sec, I was like :suda: , then  :rofle:. Good job :clap:.

I don't know why the author advises against renaming the grldr file either. Perhaps they don't want any issues reported due to the name changes?

I was wondering what that BOOTNXT file were for and still don't know what it is used for. It does seems to exist for Windows 8.1 OS as well as Windows Server 2012.

Anyhow my PBR is somehow setup differently: here is the hex and ASCII output for my BPR:

94 C3 42 4F 4F 54 4D 47 52 20 20 20 20 00 ..BOOTMGR    .

94 C3 47 52 4C 44 52 20 20 20 20 20 20 00 ..GRLDR      .

There is no 07 value near the above hex. Just replacing any letters with 20 works and able to boot to Grub4DOS without renaming grldr.

My guess is because it is a FAT32 PBR? I mean I know my PBR is FAT32.



#29 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 27 April 2020 - 07:49 AM

That is some interesting read. Also you had me going there for a sec, I was like :suda: , then :rofle:. Good job :clap:.
I don't know why the author advises against renaming the grldr file either. Perhaps they don't want any issues reported due to the name changes?
I was wondering what that BOOTNXT file were for and still don't know what it is used for. It does seems to exist for Windows 8.1 OS as well as Windows Server 2012.
Anyhow my PBR is somehow setup differently: here is the hex and ASCII output for my BPR:
94 C3 42 4F 4F 54 4D 47 52 20 20 20 20 00 ..BOOTMGR .
94 C3 47 52 4C 44 52 20 20 20 20 20 20 00 ..GRLDR .
There is no 07 value near the above hex. Just replacing any letters with 20 works and able to boot to Grub4DOS without renaming grldr.
My guess is because it is a FAT32 PBR? I mean I know my PBR is FAT32.

Yep :), I was referring to the NTFS PBR, in the FAT (12/16/32, no idea about exFAT) ones the format is different (easier), it is a fixed length (11, actually 8+3, dotless), SPACE (0x20) padded.

In that you can change directly from BOOTMGR to GRLDR[Space][Space] without problems, this is a remnant of good ol' DOS filenames.

I think that the warning about the name change may be due to some of the commands/modules needing to "call" grldr, but no idea if that is actually already happening or it is a "future" provision.

:duff:
Wonko


  • RandomUser likes this

#30 steve6375

steve6375

    Platinum Member

  • Developer
  • 7283 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 27 April 2020 - 07:58 AM

if there is a bug in grub4dos - please report it clearly and accurately.

If the grub4dos MBR boot code does not work, please report it.

If using a standard MBR which boots to the active partition plus a grub4dos PBR does not work, please report it.

Describe accurately how to reproduce the issue (e.g. what device you are booting from, what is in the MBR and PBR, what tools you used to prepare it, what you see, what other devices are connected and how they are partitioned\formatted).

Surely it is better to fix grub4dos?

https://github.com/c...4dos/issues/239



#31 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 27 April 2020 - 09:17 AM

Steve, come on :), it cannot be more clear and detailed than this, there is no bug whatever in grub4dos, there is a bug in grldr.mbr, simply it "scans" disks at boot[1] and it has an hiccup when it finds a 4kn (non-boot) disk.

 

It does work allright if the 4kn disk is not scanned, and the specific issue was already worked around (proving that the issue lies in the grldr.mbr and in the grldr.mbr ONLY) in TWO ways:

1) using the UMBR to directly chainload the grldr on the boot disk/partiton -> OK
2) using a normal MBR code chainloading the PBR and using a normal PBR with the loader name changed to GRLDR -> OK

 

 

:duff:

Wonko

 

[1] and this is "by design", as grub4dos grldr.mbr is intended to find a grldr on *any* disk


  • RandomUser likes this

#32 steve6375

steve6375

    Platinum Member

  • Developer
  • 7283 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 27 April 2020 - 09:41 AM

@steve6375

I'll have to try that entry and report back.

Yes Grub4DOS is installed on an MBR so that it can boot directly to grldr. It doesn't matter if it is a USB flash drive or an internal HDD that Grub4DOS is installed on. The error happens exactly the same, as you may already have seen the picture on the github page on the issue.

I have used wingrub and BootIce to make the disk bootable to grub4dos. The results are the same.

So basically when the 4Kn drive present, error happens. If the 4Kn is not present, Grub4DOS boots up without any issue. Grub2 elevate this issue by chainloading grub4dos even with the 4Kn drive present.

 

Sorry - was this reply therefore a lie?



#33 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 27 April 2020 - 12:03 PM

Sorry - was this reply therefore a lie?

No, it wasn't a lie, it was simply a bit "vague" between grub4dos (intended as grldr or grub.exe) and grldr.mbr.

 

But you perfectly know how grub4dos (grldr) is never installed to the MBR, grldr.mbr may.

 

And following it was confirmed that loading either grldr or grub.exe in alternate ways (grub2, UMBR, normal MBR+PBR) worked just fine, so the issue is ONLY in grldr.mbr.

 

It is possible (but it would need to be tested/confirmed and at first sight it doesn't seem likely to me) that setting in a particular way the "control bytes" for grldr.mbr  the issue can be avoided.

******************************************************************************
***               grldr.mbr - Details about the control bytes              ***
******************************************************************************

Six bytes can be used to control the boot process of GRLDR.MBR.

Offset	Length	Description
======	======	==============================================================
5ah	1	bit0=1: disable the search for GRLDR on floppy
		bit0=0: enable the search for GRLDR on floppy

		bit1=1: disable the boot of PREVIOUS MBR with invalid
			partition table(usually an OS boot sector)
		bit1=0: enable the boot of PREVIOUS MBR with invalid
			partition table(usually an OS boot sector)

		bit2=1: disable the feature of unconditional entrance to
			the command-line(See below `--duce')
		bit2=0: enable the feature of unconditional entrance to
			the command-line(See below `--duce')

		bit3=1: disable geometry tune(See below `--chs-no-tune')
		bit3=0: enable geometry tune(See below `--chs-no-tune')

		bit4 - bit6: reserved

		bit7=1: try to boot PREVIOUS MBR after the search for GRLDR
		bit7=0: try to boot PREVIOUS MBR before the search for GRLDR

5bh	1	timeout in seconds to wait for a key press. 0xff stands for
		waiting all the time(endless).

5ch	2	hot-key code. high byte is scan code, low byte is ASCII code.
		the default value is 0x3920, which stands for the space bar.
		if this key is pressed, GRUB will be started prior to the boot
		of previous MBR. See "int 16 keyboard scan codes" below.

5eh	1	preferred boot drive number, 0xff for no-drive

5fh	1	preferred partition number, 0xff for whole drive

		if the preferred boot drive number is 0xff, the order of the
		search for GRLDR will be:

			(hd0,0), (hd0,1), ..., (hd0,L),(L=max partition number) 
			(hd1,0), (hd1,1), ..., (hd1,M),(M=max partition number)
			... ... ... ... ... ... ... ... 
			(hdX,0), (hdX,1), ..., (hdX,N),(N=max partition number)
						       (X=max harddrive number)
			(fd0)

		otherwise, if the preferred boot drive number is Y(not equal to
		0xff) and the preferred partition number is K, then search for 
		GRLDR order and above.

		Note: if Y < 0x80, then (Y) is floppy, else (Y) is harddrive,
		      and (Y,K) is partition number K on harddrive (Y).

Maybe if the (Y,K) are set to 0x80 and 0, corresponding to (hd0,0) it won't scan for other disks :dubbio:, or maybe - since the 4kn disk is seen as floppy - setting 5ah bit0=0 is enough to skip over it. :unsure:

 

Maybe a workaround - should the actual issue be not solved - would be to modify the code, making use of the "reserved" bits 4-6 to mean "only look for grldr on bootdisk (bd).

 

:duff:

Wonko



#34 steve6375

steve6375

    Platinum Member

  • Developer
  • 7283 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 27 April 2020 - 03:17 PM

Sorry to be a bit obtuse. But grldr.mbr is a file isn't it? AFAIK that file is not used when booting from grub4dos using the MBR of a standard partitioned disk. It may have the same \ similar contents to sectors 0-20 of the drive but that is irrelevant.

 

The MBR code loads the following sectors (1-20 approx) and that code searches for the \grldr file. No grldr.mbr file is needed?

 

RandomUser stated 'Yes Grub4DOS is installed on an MBR so that it can boot directly to grldr' - there is no mention of a grldr.mbr file?

 

What I am trying to get confirmation of is, if you install grub4dos to the MBR of a standard legacy-partitioned drive and boot DIRECTLY to the drive via it's grub4dos MBR + sectors 1-20 - do you still see the problem when a 4K disk is attached.

 

No other file is involved - Legacy BIOS - loads MBR - MBR loads sectors 1-20 - MBR looks for \grldr on other drives.



#35 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 28 April 2020 - 04:58 AM

Please don't fight. The post wasn't intended to cause a fight.

What I meant was that Windows bootloader MBR (bootmgr) was not being use to boot the disk at all and there is not any other boot sequence. Also the boot disk is not GPT.

 

I do feel stupid though, because I decided to give the BootIce tool another try on a test drive and try booting again using the grub4dos option for MBR and PBR from the tool and to my surprise it booted up, although it seems to boot slower then using a normal Windows MBR and modified bootmgr PBR. I don't know why it didn't work before when I tried BootIce the first time :blush:. Perhaps it was the Acronis True image that interfered with the software as Acronis does have some writes protections or perhaps I merely thought I did used BootIce to install Grub4DOS as boot or most likely I have missed a step somewhere when utilizing the tool. For this I am sorry for causing a fight and wasting everyone's time.

 

I did however learned some new tricks and things and I thank you @Wonko the Sane, for that. You also have taught me that it is indeed possible to boot into a GPT disk in BIOS mode. Wingrub is the issue here for sure.

Again I apologize for wasting time.

 

Edit:

I forgot to mentioned that the only thing that I can recall doing differently was issuing a "clean" command from diskpart before using the BootIce to install Grub4DOS for the second try.

I really don't want to issue a clean command on my primary boot drive, so the workaround will work nicely and seems a little bit more speedier to boot.


Edited by RandomUser, 28 April 2020 - 05:57 AM.


#36 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 28 April 2020 - 08:16 AM

Naah, it is not a fight at all :), only some misunderstanding, Steve6375 knows about grub4dos a lot, actually much more than myself, but we have different ways to "store" and "recall" (and explain) the same or similar knowledge.

 

AFAIK the way grub4dos is installed to the MBR (by *any* tool, be it BootIce, grubinst, a grub4dos batch, whatever) is to copy the grldr.mbr file to the first few (18 last time I checked) sectors of the disk.

 

See:

http://reboot.pro/to...dows-and-linux/

 

THIS post:

http://reboot.pro/to...ux/#entry189578

including an excerpt from the grub4dos README:





******************************************************************************
 *** grldr.mbr - How to write it to Master Boot Track of the hard disk ***
 ******************************************************************************

 grldr.mbr contains code that can be used as Master Boot Record. The code is
 responsible for searching all partitions for grldr and when found, loading it.
 Currently supported partition types are: FAT12/FAT16/FAT32, NTFS, EXT2/EXT3.
 Logical partitions in the extended partition are supported, provided that the
 extended partition type is Microsoft-compatible. In fact, the Linux extended
 partition type(0x85) is not fully tested for the search mechanism.

 How to write GRLDR.MBR to the Master Boot Track of a hard disk?

 First, read the Windows disk signature and partition information bytes
 (72 bytes in total, from offset 0x01b8 to 0x01ff of the MBR sector), and put
 them on the same range from offset 0x01b8 to 0x01ff of the beginning sector of
 GRLDR.MBR.

 Optionally, if the MBR in the hard disk is a single sector MBR created by
 Microsoft FDISK, it may be copied onto the second sector of GRLDR.MBR.

 The second sector of GRLDR.MBR is called "previous MBR". When GRLDR not found,
 "previous MBR" will be started.

 No other steps needed, after all necessary changes stated above have been made,
 now simply write GRLDR.MBR on to the Master Boot Track. That's all.

Hence I say that the installed grub4dos to the MBR uses the grldr.mbr code, as what is written to the MBR and following sectors is actually grldr.mbr in the grub4dos package, because that is what it is.

 

If you prefer, the SAME CODE is written to the file grldr.mbr AND - once grub4dos is installed - it is ALSO written to the MBR and following sectors. 

 

And again, the grldr.mbr (please read as grub4dos installed to the MBR) is intended to find a grldr, so it needs to "scan" at least one drive to find it, this is usually unnoticeably slower, it is likely that - even if it now works in this particular RandomUser case (BTW is it the modified/fixed version yaya provided or is it the earlier version the one that now works?) - it is possible that if the 4kn disk is seen as (fd0) it takes some time to scan it before the (hdx) devices (and thus the delay is noticeable) :unsure:

 

:duff:

Wonko


  • RandomUser likes this

#37 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 04 May 2020 - 10:10 PM

I have to agree with DavidB that your post is fun to read. Also I'm relieved that there is no fight going on.

The error can be replicated using Wingrub tool to install the MBR however when I tried using BootIce tool, It works for the second time. I did notice that it has an option for Grub4Dos 4.5 and another option for Grub4Dos 4.6, I'm thinking I may have had selected 4.5 instead on the first attempt, but after some reading it may not even mattered?

I also think the slight delay could possibly not only the 4Kn drive, also there is a text based splash type screen when booting up, along with scanning for drives. Perhaps with the modified PBR, it points directly to grldr and thus is faster?

I tried Yaya version and the latest public released build (0.4.6a-2020-02-29), they both did errored out. Now that does not seem the case for either :wacko:.

I'm thinking wingrub was used for a very old version of grub4dos, perhaps before firadisk was even created.

I need to make a possible correction on one of my previous post, I may have said I used bootlace, and that isn't correct. I used the tool called BootIce to install grub4dos.

The provided grub install tool never did worked for me, even with running as admin.



#38 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 May 2020 - 08:38 AM

 Perhaps with the modified PBR, it points directly to grldr and thus is faster?

Yep, that is the whole point. :)

 

The grldr.mbr code is - by design - intended to look for the first grldr it finds *anywhere*.

 

This normally is (already) on the first device (hd0) and in the "active" partition on it (which usually is also the first partition, i.e. (hd0,0)) but in your particular case, the 4kn disk is *somehow* seen/mapped as (fd0) and most probably it is scanned before any other disk (and - again for *some reasons* - it errors out).

 

It is entirely possible that on n other machines with a similar setup the 4kn disk is mapped as (hd1), or (hd2), etc. and thus the grldr is found earlier and the issue is not reproducible.

 

But in any case, i.e. even when it works on the other 99.999% of machines, it is inherently a little bit (normally it is not noticeable) slower, as this initial scan is performed anyway.

 

The "direct" approach is "direct" ;) and everything remains on the same disk:

1) the MBR code only looks in the Partition table of "self" disk (and doesn't go around looking for other disks)
2) when it finds the single partition that is active it chainloads the PBR of that partition
3) the PBR code chainloads the OS loader (NTLDR or BOOTMGR or grldr in this case) on "self" partition (and doesn't go around looking for other disks or partitions) 

:duff:

Wonko


  • RandomUser likes this

#39 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 08 May 2020 - 10:26 PM

That makes sense. Thank you for your response.







Also tagged with one or more of these keywords: 4kn, 4k sectors, 4k native sectors, 4096 bytes

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users