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

#1 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 05 April 2020 - 09:59 PM

Here I am again with a really weird issue. I believe the issue stems from the fact that the HDD that I have is native 4K Sectors with zero emulation layer for 512 byte sector.

Not using the 4Kn drive as a boot drive, I have another that is my boot drive and that is MBR.

I can read and write to 4Kn drive without issue from within Windows.

I'm wondering if there is a way to get Grub4Dos to completely ignore or prevent it from even seeing the 4Kn drive? It is throwing up this error "Try (fd0):extended or non-MS:Skip error". What is weird is that it doesn't say (hd0,0), but instead (fb0). My guess is that the native 4K is tripping up the bootloader.

I have tried this

map --mem (md)+8 (hdX)
map --hook 

Wear X is the HDD number corresponding to the drive in question and it didn't work. It immediately throws up the aforementioned error.

I take out the drive and Grub4Dos then boots up without any issue.



#2 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 06 April 2020 - 09:00 AM

Which specific, EXACT, grub4dos version is it?

 

Generally speaking, the issue could lie in the embedded menu.lst in grldr, which is auto-executed at boot time.

 

For a "fixed" install of grub4dos that can be simplified, removing a number of commands, among them the "explorative ones" that likely trigger the error.

Example of embedded menu.lst (from grub4dos 4.6a 2019-08-01):



pxe detect
configfile
default 0
timeout 1

title find /menu.lst, /boot/grub/menu.lst, /grub/menu.lst
	errorcheck off
	configfile /boot/grub/menu.lst
	configfile /grub/menu.lst
	if "%@root%"=="(ud)" && calc *0x82A0=*0x82b9&0xff
	if "%@root:~1,1%"=="f" && find --set-root --devices=f /menu.lst && configfile /menu.lst
	find --set-root --ignore-floppies --ignore-cd /menu.lst && configfile /menu.lst
	find --set-root --ignore-floppies --ignore-cd /boot/grub/menu.lst && configfile /boot/grub/menu.lst
	find --set-root --ignore-floppies --ignore-cd /grub/menu.lst && configfile /grub/menu.lst
	configfile http://b.chenall.net/menu.lst
	errorcheck on
	commandline

title commandline
	commandline

title reboot
	reboot

title halt
	halt

I mean, if you know that your menu.lst is actually in (say) /menu.lst the first title could become:



title hardcoded menu.lst
configfile /menu.lst
commandline

BUT - before that - if you have your menu.lst in root, try making a copy of it and placing it in either:

/boot/grub/menu.lst

or

/grub/menu.lst

 

:duff:

Wonko



#3 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 06 April 2020 - 08:17 PM

Interesting, I don't even have a configfile, maybe it is actually located inside the Grub4DOS downloaded archive? I should check and see if it is, The version I am using is the chenall version grub4dos 0.4.6a 2020-02-29. I'm going to have to try copying the menu.lst file to the location that you have mentioned, as I got it on the root of the boot drive.

I notice this piece "--devices=f" and upon researching this command I find it uses u,p,n,h,f,c. Do you happen to know what letter these devices represent? I assume "f" is probably means fixed disk?



#4 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 06 April 2020 - 10:51 PM

For some reason I cannot edit my post, by embedded, does that mean that the menu.lst is also inside of the grldr file?



#5 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 April 2020 - 07:50 AM

For some reason I cannot edit my post, by embedded, does that mean that the menu.lst is also inside of the grldr file?

Yep, sorry if I wasn't explicit, as it is a theme that has been recurring, so I gave it for reknown.

The last few bytes of both grldr and grub.exe are an appended menu.lst that is executed automatically.

If you open grldr or grub.exe with - say - Wordpad and go to the very last few lines you can see it.

This menu can be edited (with a little care) with *any* hex editor, seee also:

http://reboot.pro/to...grldr/?p=175523

, or - easier - Bootice has a dedicated provision for this:

http://reboot.pro/fi...-bootice-v1332/

 

f is floppy as in (fdn)

h is hard disk  as in (hdn)

c is cd or dvd as in (cdn)

 

https://www.rmprepus...commands-primer

 

 

find --set-root --devices=upnhcf /ntldr

Finds equipment /ntldr file, the device is set to first find the current device. Specify search order: ud, pxe, network equipment, hard disk, CD-ROM, floppy disk. The current root is always searched first.

 

 

 

:duff:

Wonko


  • RandomUser likes this

#6 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 09 April 2020 - 08:07 PM

Cool! that is great to know and the tools that you have linked is very useful. I have learned something new and I thank you for that. Although sadly Grub4DOS is still erroring out with the same aforementioned error. I tried

title just boot
configfile (hd0,0)/menu.lst

It still error out. That menu.lst is located on the root of the MBR drive (hd0,0) and not the 4Kn drive (hd3,0). I did come across with an unmap command but that would be the crux of the situation because it first needs to be mapped AFAIK. Perhaps some further reading is necessary, and cannot find out where in grldr to commit out the prober that scans for the hdd or a way to force Grub4DOS to not attempt to read the drive in question.


Edited by RandomUser, 09 April 2020 - 08:20 PM.


#7 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 10 April 2020 - 03:10 AM

Also should have mentioned that I used the same config posted above using the tool that is linked, directly into the grldr file.


Edited by RandomUser, 10 April 2020 - 03:11 AM.


#8 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 10 April 2020 - 09:08 AM

So, even without any "if" nor "find" command executed the behaviour is the same?

What happens exactly?

I mean does it show the error AND:
1) hangs indefinitely (until you press a key)
2) pauses and then continues
3) halts and doesn't go on

Try (in the embedded menu.lst):

title just boot
root (hd0,0)
root
echo this is a pause ...
pause
configfile ()/menu.lst

Does the error message come before the pause?

:duff:

Wonko



#9 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 12 April 2020 - 10:33 PM

Nope, that didn't work either the error apparently shows up before any of the menu.lst, even the embedded one is even initiated. The error halts the Grub4DOS and cannot go on and requires the "three finger salute"

As I figured, my suspicion is semi-confirmed from this forum:

Spoiler

But this isn't the end of the world and not all bad news. I decided to try chainloading Grub4DOS from Grub2, and it worked beautifully. Grub4DOS doesn't even complain about the drive and actually sees it :).

I could use the above linked tools to make a disk bootable for Grub2 however the tool doesn't come with Grub2 and using the command line gives me more control where to install Grub2 to any given drive:

grub-install.exe --boot-directory=X:\ --target=i386-pc //./PHYSICALDRIVEY

Both install Grub2 and make the disk boots into Grub2. Replace the letter "X" to correspond to your drive letter and "Y" physical drive number.

So if I wanted it to install to a folder called Grub2, then this is the way to do it:

grub-install.exe --boot-directory=X:\Grub2\ --target=i386-pc //./PHYSICALDRIVEY

Again just replace the Letter "X" and Letter "Y" to your corresponding drive.
 

Then create a grub.cfg file and add this into it:

menuentry "Grub4Dos" {
linux16 /boot/grub/grub.exe
}

You can make changes to the actual location of the grub.exe if it isn't in the boot\grub\ folder. I didn't know what the exe version of grldr was used for.

 

Perhaps this thread could get pinned? Nah probably not really needed.
 


Edited by RandomUser, 12 April 2020 - 10:35 PM.


#10 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 April 2020 - 04:16 PM

It doesn't seem related to that post, as a matter of fact it explicitly says that DOS cannot start (not that grldr won't boot), and specifies how you can boot from another non-4k disk and then chainload a grldr on the 4K disk, while in your case you simply cannot boot from a non-4k disk if the disk is connected. 

 

However it is well possible that a combination of grub4dos+BIOS+4K disks creates the issue in your case.

 

Which above linked tools?

 

Good to know that grub.exe works via GRUB2.  :)

 

 

:duff:

Wonko



#11 steve6375

steve6375

    Platinum Member

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

Posted 13 April 2020 - 06:25 PM

So the issue with grub4dos is that it hangs whilst booting from the MBR USB drive before it even runs the embedded menu?

Did you modify the embedded menu in grldr so that you can see that?

e.g.

Use BootIce to edit embedded menu in \grldr file and add

echo Hi
pause
echo trying find
find
echo trying geometry
geometry
echo trying ls
ls (hd0,0)/
pause
(then rest of menu)

So the big question is:

How did you install grub4dos on the USB drive? What tool and command?

Was it installed to the MBR or PBR or both?



#12 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 13 April 2020 - 07:02 PM

@Wonko the Sane

I never looked at it that way, thank you for your thought, I really appreciate it.

 

I'm wondering if it because of the unique nature of my board. I think it has two BIOS, one for the onboard SAS controller (mpt2BIOS rom) and another for everything else, like the CPU, USB, SATA, etc. I do have an onboard SATA as well.

 

As for the tool that is linked above is called BootIce while the linked tool can make any disk or image bootable for Grub2 but lacks the actual grub2 files. It is still a useful tool though, and would have been handy at times. Just didn't know the existence of it LOL. Heck I didn't even know that grldr even had an embedded menu.lst and the tool made it much easier to edit it.

 

I should have linked where you can find the Grub2 bootloader with the installer.

https://ftp.gnu.org/gnu/grub/

and there should be a Windows version of Grub2 installer in there. In case if anyone is interested.

 

@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.



#13 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 April 2020 - 07:57 AM

Looong shot. :w00t:

 

And not necessarily handy/portable and surely not "easy", but worth an attempt (if you want to experiment).

 

It is possible that (since grldr.exe loaded differently works) the issue is in the gtldr.mbr code. :dubbio:

 

The UMBR (only seemingly unrelated thread):

http://reboot.pro/to...b-with-bootice/

 

The thread contains also a link to my half-@§§ed workaround for GPT disks, should the UMBR fail, that one could still work (or maybe not), both anyway by-pass the standard grldr.mbr.

 

:duff:

Wonko


  • RandomUser likes this

#14 steve6375

steve6375

    Platinum Member

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

Posted 14 April 2020 - 08:12 AM

yaya has offered a test grldr to try.

https://github.com/c...mment-613170926



#15 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 15 April 2020 - 11:03 PM

Looong shot. :w00t:

 

And not necessarily handy/portable and surely not "easy", but worth an attempt (if you want to experiment).

 

It is possible that (since grldr.exe loaded differently works) the issue is in the gtldr.mbr code. :dubbio:

 

The UMBR (only seemingly unrelated thread):

http://reboot.pro/to...b-with-bootice/

 

The thread contains also a link to my half-@§§ed workaround for GPT disks, should the UMBR fail, that one could still work (or maybe not), both anyway by-pass the standard grldr.mbr.

 

:duff:

Wonko

 

Believe it or not, it wasn't a long shot, it actually worked :hyper:. Grub4DOS was able to load even with the 4Kn drive present in the system and with any Grub4DOS version.

Using this command:

umbr -d=1 -p=0 (hd1,0)/grldr

Caveat is it isn't as easily upgradable. Cannot simply drop a new version of grldr and expect it to work. I suppose I would have to rerun the same command to install a newer version of Grub4Dos if needed? (the upgrade ability isn't much of an issue as of yet anyways).

The reason why -d=1 is because I installed UMBR to an external USB test drive.

 

yaya has offered a test grldr to try.

https://github.com/c...mment-613170926

Yep, tried it with MBR and PBR and still no dice, however with the UMBR it works great and so does the other version of Grub4DOS when using UMBR.

 

Thank you all for helping me.


Edited by RandomUser, 15 April 2020 - 11:34 PM.


#16 steve6375

steve6375

    Platinum Member

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

Posted 15 April 2020 - 11:09 PM

So grub4dos (grldr) when loaded by a stage1/1.5 boot code in the MBR or PBR still fails when a 4K drive is present in the system.

 

So the issue still exists and is not solved because that should work.

The stage 1\1.5 boot code should search all partitions for the \grldr file - it seems that it finds the 4K drive and hangs during this process.

If you directly load the file using grub and grldr.exe, or use UMBR which directly points to the disk and start sector of the grldr file, then it boots OK.


Edited by steve6375, 15 April 2020 - 11:17 PM.


#17 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 15 April 2020 - 11:41 PM

So grub4dos (grldr) when loaded by a stage1/1.5 boot code in the MBR or PBR still fails when a 4K drive is present in the system.

 

So the issue still exists and is not solved because that should work.

The stage 1\1.5 boot code should search all partitions for the \grldr file - it seems that it finds the 4K drive and hangs during this process.

If you directly load the file using grub and grldr.exe, or use UMBR which directly points to the disk and start sector of the grldr file, then it boots OK.

So would this be considered something that needs to be fix in the MBR code? Or the BIOS is somehow interfering with the finding process?



#18 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 16 April 2020 - 07:23 AM

Believe it or not, it wasn't a long shot, it actually worked :hyper:. Grub4DOS was able to load even with the 4Kn drive present in the system and with any Grub4DOS version.

Good, :)

 

 

 

Caveat is it isn't as easily upgradable. Cannot simply drop a new version of grldr and expect it to work. I suppose I would have to rerun the same command to install a newer version of Grub4Dos if needed? (the upgrade ability isn't much of an issue as of yet anyways).

 

Yep, that UMBR code directly chainloads an extent (LBA sectors from - to) on the disk, and the addresses are written, to the MBR, not entirely unlike a normal partition table entry, hence I said not very portable.

 

 

 

So grub4dos (grldr) when loaded by a stage1/1.5 boot code in the MBR or PBR still fails when a 4K drive is present in the system.

 

So the issue still exists and is not solved because that should work.

The stage 1\1.5 boot code should search all partitions for the \grldr file - it seems that it finds the 4K drive and hangs during this process.

If you directly load the file using grub and grldr.exe, or use UMBR which directly points to the disk and start sector of the grldr file, then it boots OK.

 

Yes and no.

I understand how the (more complex and multi-sector) grub4dos MBR code would do that, but I doubt that the PBR code does the same (actually I am pretty sure it doesn't, at least for the FAT12/16 PBR which is only one sector, hence very likely my good ol' half-a§§ed method would very likely work).

It has to be seen if the same happens for FAT32 and NTFS PBR code :dubbio:

 

@RandomUser

My method uses a floppy-like image "hidden" before the first partition (due to the use of dual booting BIOS/UEFI a GPT disk) and some "standard" (modified/re-modified Syslinux) MBR code to chainload the "hidden" floppy.

The simil-floppy has the standard (FAT12) grldr PBR.

So you can surely replicate the same approach using *any* normal MBR code (i.e. one that chainloads the active primary partition in the MBR) if you can "afford" a FAT12/16 partition.

And probably the - now deprecated - approach of changing the name of the loader in the normal MS bootsector of *any* filesystem partition would as well work.

i.e. replace in it NTLDR with GRLDR or replace in it BOOTMGR with GRLDRXX (and rename gridr to grldrxx).

 

:duff:

Wonko


  • RandomUser likes this

#19 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 19 April 2020 - 08:20 AM

My gosh, that seems more complicated LOL. I didn't know that it was possible to do that, I learned something new. I do notice when going this route, you cannot add any extra partition to the drive, or so I tried with Disk Genius and Partition Guru. That is what I assume the "affordability" comes into play. Must dedicate that drive as a floppy disk in a sense. Pardon my ignorance, how does one modify the MBR? At best I use WinImage to extract the mbr but it is only 512 bytes big.



#20 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 19 April 2020 - 09:32 AM

The MBR is the first absolute sector of the device or LBA 0 and sure it is 512 bytes in size.

What a normal BIOS does is (essentially) the following:
1 let me check that the last two bytes of first sector are 55 AA
2.a  if they are not, hang or reboot

2.b if they are, simply run the code in the MBR

 

So what changes behaviour when booting is the actual code in the MBR.

 

Let's set aside the grldr.mbr (that has code that spans beyond the first sector, and all other "complex" MBR's), a *normal* MBR code does the following:
1. Read the partiton table (i.e. the 4 entries of 16 bytes each starting at offset 446 in the MBR itself) addresses
2. find if among them there is one marked as "active", if there is, then:

3. chainload the first sector (the PBR) at the address of the entry marked as active and execute the code there (which in itself will load the loader or system file, etc.)

 

What the UMBR does:
1. Read an address in *another* structure, similar to a partition table, this address is set up to the absolute LBA extents of a grldr
2. chainload that (i.e. chainload grldr directly)

 

What my modified MBR code does (in the specific case of a "hidden partition on GPT disk):

1. Read an address in *another* structure, similar to a partition table, this address is set up to the absolute LBA extents of a small volume residing bewtween the GPT reserved sectors and the first "real" volume, i.e. normally unused and blank area

2. chainload the first sector (the PBR) of that minimal volume, that is the "normal" grub4dos floppy PBR, i.e. that chainloads grldr directly.

Now, this small partition needs to be "hidden" in the specific case of a GPT disk modified to boot on a BIOS machine in a way that doesn't alter *anything" when on UEFI, but in a "normal" BIOS only MBR disk you can have its address duplicated in the "real" partition table and so make it visible (and no need to have it active), but again we are back to the good ol'advice by Gilles Vollant (the Author of Winimage), which paraphrased says, no matter what, always have a small FAT partition active, if you can "afford" to "waste" one of the 4 partition entries for a small FAT volume, that is the most flexible approach. 

 

Back to the grldr.mbr, it is a far more complex piece of code.

When it is started by the BIOS it looks for all disks connected to find the grldr (and this scan is likely what makes it hang in your case) as - by design - it is not intended to boot from a grldr on a given partition.

 

Finally the UMBR is "good" BUT when/if you update the grldr or even - in some cases - you defragment the volume where grldr resides (let alone if you expand/shrink/move partitions) you need to re-install the UMBR.

 

My half-@§§ed approach has the advantages that:
1. the minimal volume resides in an area at the beginning of a disk, that won't be affected by expand/shrink/move of partitions

2. there are no issues when you want/need to update the grldr since the address/size changes are taken care of by the FAT(12) filesystem

BUT (at least in the specific version with the minimal volume "hidden") you need to mount the extent to update the grldr (or to edit the menu.lst there[1])

 

To answer your questions, there are many tools that allow to change parts (let's call these parts "data" of the MBR). i.e. the Disk Signature and the Partition table (basically all partitioning tools do this), the rest is "code" and can be modified by any hex editor, but of course the code needs to make sense (it is "pure" assembly).

 

If you want to play a bit with the MBR (the data part) manually (to see what is inside it) I can recommend Tiny Hexer with my (shameless plug) MBRview and PTNview structure viewer scripts:

http://reboot.pro/to...-hexer-scripts/

 

:duff:

Wonko

 

[1] this latter is not really an issue, as the menu.lst in the minimal volume can be written so that it chainloads another menu.lst in a "more accessible" volume.



#21 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 21 April 2020 - 05:59 AM

Thank you for your response. It is an interesting read. Sadly I do not know ASM very well and probably going to be over my head.

Currently it looks like I have two options, use your method of booting or use GRUB2.

Are there any pros and con between the two?

They both seems to be upgradable for grldr, but it seems that GRUB2 provides the easiest to upgrade path. GRUB2 shouldn't be affected by resizing and moving of partition either AFAIK.

Right now my primary boot drive is currently only booting Grub4DOS the traditional way, meaning the error will occur with the 4Kn drive, as I am trying to determine the best course of action. Your way is interesting, because I didn't think of that idea, let alone knowing that it is possible, but for some reason I'm leaning towards GRUB2. Please don't take offense in this. Having options is a good thing. With GRUB2 is like booting into Grub4DOS with extra step, and your method seems to get right to the booting process which is really neat.

An external drive was used to test these boot options to find out if it works or not.



#22 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 21 April 2020 - 08:33 AM

After re-reading your post, I did find one advantage of your method of boot compared to GRUB2, that is booting directly into a GPT disk from BIOS and GRUB2 cannot do that. In my case I am booting directly from MBR so I still have both option open to me.

I do have another question. Could you chainload another Grub4DOS automatically to an accessible volume, thus making the upgrade much easier?



#23 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 21 April 2020 - 09:54 AM

No offence taken, rest assured.

 

The scope of the original thread:

http://reboot.pro/to...in-bios-to-gpt/

was expressly that of finding a way (workaround) to boot on BIOS a GPT disk AND WITHOUT altering it in any way detectable by UEFI when the disk was connected (back) to a UEFI machine, hence it is (seemingly) "complex" and "hidden", but you need not to know any Assembly to actually use or modify it to better suit your needs.

 

 

But again, in your specific case - apart GRUB2 - the easiest would be

EITHER

having a "normal" MBR code and a modified PBR loading grub4dos

OR

using grub4dos as secondary bootmanager, loaded by a "normal" bootmanager (NTLDR), the "inconvenience" in the former is that the PBR is not the "standard" one (i.e. tools *like* bootsect.exe may overwrite it with code invoking the NTLDR or BOOTMGR) in the latter you might need to press one or two keys more when booting.

 

This way everything would be "normal", you would have grldr in a normal volume, normally visible and thus easily updatable.

 

If you detail what you have booting now (i.e. what is your actual boot setup) there could be even simpler solutions, as said earlier, the easiest if you can "afford" to "waste" a partition entry would be a small FAT partition.

 

Or more complex :w00t: ones:

Just an example, assuming you normally boot to a BOOTMGR (i.e. Vista,7, 8 or later) AND you use not an NTLDR (i,e, you don't normally boot to NT/2K/XP):
1) have a "normal" MS MBR
2) have a "normal" MS PBR invoking NTLDR (/NT52 in bootsect.exe)

3) have a NTLDR in root
4) have a BOOT.INI with only one entry in it to C:\grldr with low timeout

this might slow your booting of maybe one second or two (you won't notice it)

 

Then, even if you sometimes boot to NT/2K/XP you can use one of the n tricks available in grub4dos to obtain that, like (IMHO very simple/easy, create it once and be done with it) a mapped floppy image with NTLDR and a BOOT.INI pointing to your NT system.

 

 As a side-side note, as a matter of fact you don't even need an image as you can build it (either floppy ot hd-like) on-the-fly when booting, see as a reference this seemingly unrelated thread:

https://msfn.org/boa...e-on-usb-drive/

starting from around here:

https://msfn.org/boa...comment=1176709

 

With the "fat" utility you can then  copy the NTLDR and BOOT.INI to the image, modify the contents of BOOT.INI and chainload the image.

 

:duff:

Wonko


  • RandomUser likes this

#24 RandomUser

RandomUser

    Member

  • Members
  • 49 posts
  •  
    United States

Posted 23 April 2020 - 01:48 AM

Thank you for more info.

My setup is relatively simple. While I have multiple drives, one of them is a dedicated non GPT formatted boot drive. Grub4DOS is/was the only bootloader that is/was installed on the drive. I mainly use it for Grub4DOS to load the OS in RAM, booting full Windows completely in RAM, I guess I got spoiled on it. Another drives for data storage. The thing is RAM booting have saved me a few time, especially when I think I have had contracted the 0 byte free space virus. The free space keeps getting depleted, almost as quick as you delete a file or more. It's like no amount of deletion would free up space, and the nice thing about RAM booting is that you can essentially reboot your problem away. The virus is gone LOL. I think the virus side loaded through a website or an ad or something. Some ad makes it's way around the adblock plus. Funny thing the Anti-virus didn't pick it up, so maybe there was something else going on, but hay reboot and problem solved!

The 0 byte free space thing happens only on the RAM drive where Windows sits and happens sparingly.

Correction, As of yet, I do have Clover on the same drive as grub4DOS, but Clover is dormant, as it does not have any boot code installed on said drive at (MBR and/or PBR), because it was able to be chainloaded from Grub4DOS.


Edited by RandomUser, 23 April 2020 - 02:05 AM.


#25 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 23 April 2020 - 09:34 AM

So you do not have issues in:

1) use a normal MBR

and EITHER:

2) try changing the name of the loader in the PBR (if your PBR loads NTLDR you can try changing it to load GRLDR, if your PBR loads BOOTMGR you can try changing it to - say -GRLDRXX and of course rename grldr to grldrxx or first change it so that it loads NTLDR and then edit it to load GRLDR)

OR (if not simpler more "standard"):

3) have the PBR load NTLDR and add a NTLDR and a BOOT.INI invoking grldr

 

Both methods are simple and straightforward.

 

:duff:

Wonko


  • RandomUser likes this





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