Jump to content

Boot Grub4Dos From HDD To Any Bootable Image File On Another HDD


Recommended Posts

Normally I can boot from USB that has all the Grub4Dos files and Images on it. Also it is able to boot from PC HDD C: partition using Boot.ini menu. I am trying now to setup using the boot.ini method to Bare Metal Boot images files Boot.ini > Grub4Dos > Image Files. Reason as have no need to use USB when at PC also get away from USB write Block wearing, also no more USB Needed.

I am trying to do this first using Vmware to test if this is doable then later transfer to physical PC

Vmware
Both drives new - growable - Mounted to IDE 0:0 and IDE 0:1

Virtual vmdk drives (made with Partition Master CD in Vmware all other partition tools I tried failed to boot a new vmdk drive).

Partition Details
(hd0,0) Primary NTFS 4k Active
(hd1,4) Logical NTFS 4k

unknown why (hd1,4) always is seen as (hd1,4)

(hd0,0) boots to boot.ini when select Grub4Dos then passes over to (hd1,4) menu.lst and lists that.

Drive Contents
(hd0,0)
ntldr (copied from physical PC XP3 OS)
ntdetect.com (copied from physical PC XP3 OS)
boot.ini (copied from physical PC XP3 OS)
grldr
menu.lst

boot.ini #Contents
[boot loader]
timeout=480
default=c:\grldr
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
c:\grldr="Grub4Dos"


Menu.lst #Contents
find --set-root /Name.tag
configfile /menu.lst
chainloader +1
commadline


(hd1,4) #Contents
all files from the Grub4Dos 0.4.6a-2022-01-18.7z archive , except grldr which is on (hd0,0) does this file also need to be on (hd1,4)
name.tag
minixp.vmdk or .img (image type decision needed)

With testing MiniXP-Flat.vmdk converted with Starwind V2V image conveter to minixp.vmdk and also to minixp.img both growable are bootable with Qemu
Also minixp.vmdk in a new Vmware project

Would the image file for XP3 OS that works in Virtual OS (which has been no snapshots that is normally run in Vmware as an Independant NonPersistant Drive). Of course when run with in Grub4Dos would be read-write and if need can either make read-only from the image or read-only from Grub4Dos if when needed.

What is the best image file for long term use and most stable a Vmware single growable vmdk image file without descriptor (the descriptor inside with growable drives). Or Vmware -FLAT non-growable drive. Or would converting with Starwind V2V Image Converter to raw img or bin file be better.

I would like to boot to the Virtual XP3 OS and be seen and be used same as would physical PC XP3 OS on drive C. But also to totally ignore physical PC XP3 Drive Partition C while in use. No software or other able to communicate with it. If it is needed I can always reboot and go to it that way.

Physical PC Basic Disks - All (PATA) (IDE) (NTFS 4k)

Disk 0 Location 0 (0)
Volumes C and E

Disk 1 Location 0 (0)
Volume D

Disk 2 Bus Number 0, Target ID 0, LUN 0 (IDE Controller)
Volume F

Disk 3 Location 0 USB Removable Flash Drive (NTFS 4k)
Volume J

Disk 4 Location 0 USB Removable Flash Drive (Usually NTFS 4k - ATM it is FAT32)
Volume G

Other USB Volumes Take H and I possibly or are DVD drives internal and external which are not installed at the moment.


Drives in Vmware are just two for testing.I can if needed make more virtual drives so emulate the above physical pc if needed.


#1 Virtual image type would best for Grub4Dos Virtual OS XP3 use

#2 Commands the the menu.lst needed to do this.

#3 Commands in the menu.lst would be better if instead of [ find --set-root=/filename ] actually target exact hdd drive and image in case of files with the same name on any other drives.
Link to comment
Share on other sites


Maybe it is a typo, but Name.tag is NOT the same as name.tag (grub4dos is CaSe SeNsItIvE on NTFS).

(hd1,4) is correct, hd1 is second disk (as first disk is hd0) primary partitions are partitions #0,1,2,3, #4 means "first logical volume inside extended".

If you don't want to use the .tag file, you can use UUID, see:

http://reboot.pro/topic/14640-how-to-use-uuid-in-this-code/

This makes apparently little sense :unsure::

Menu.lst #Contents
find --set-root /Name.tag
configfile /menu.lst
chainloader +1
commadline

The moment the configfile /menu.lst is executed control passes to the loaded /menu.lst so it is unlikely that it will ever return to the chainloader +1 command (that won't anyway work as this is an uncorrected PBR of a logical volume inside extended, you would need to correct the sectors before).

The best image format is  the NON-growable (i.e. static) RAW image + vmdk descriptor or a (still static) VHD (which is a RAW image with an appended Conectix sector that will be ignored by grub4dos). 

I am not sure to understand the "final goal", whatever you boot in the VM is inside the VM, the "real" disk is not visible/usable from inside the VM normally :dubbio::

jaclaz

Link to comment
Share on other sites

9 hours ago, jaclaz said:

Maybe it is a typo, but Name.tag is NOT the same as name.tag (grub4dos is CaSe SeNsItIvE on NTFS).

Yes the name.tag will have a different name for the moment I'm using name.tag all lower case (case sensitive for NTFS that is information worth knowing.)

9 hours ago, jaclaz said:

(hd1,4) is correct, hd1 is second disk (as first disk is hd0) primary partitions are partitions #0,1,2,3, #4 means "first logical volume inside extended".

Thanks for explaining the reason why it is shown as (hd1,4)

9 hours ago, jaclaz said:

If you don't want to use the .tag file, you can use UUID, see:

http://reboot.pro/topic/14640-how-to-use-uuid-in-this-code/

Yes I was thinking of and did try UUID but didn't work so used the name.tag for now. UUID would get and root (hd1,4) . Will try further with UUID while testing getting it to work and figuring this out.

9 hours ago, jaclaz said:

This makes apparently little sense :unsure::

Menu.lst #Contents
find --set-root /Name.tag
configfile /menu.lst
chainloader +1
commadline

The moment the configfile /menu.lst is executed control passes to the loaded /menu.lst so it is unlikely that it will ever return to the chainloader +1 command (that won't anyway work as this is an uncorrected PBR of a logical volume inside extended, you would need to correct the sectors before).

unknowing guessing would this do it ?

chainloader +1 /menu.lst

or this

chainloader (menu.lst)

9 hours ago, jaclaz said:

The best image format is  the NON-growable (i.e. static) RAW image + vmdk descriptor or a (still static) VHD (which is a RAW image with an appended Conectix sector that will be ignored by grub4dos). 

OK -FLAT non-growable also would be better for pagefile.sys when using OS that is located also on the same image.

VHD I think are seen as SCSI HDD in Vmware. But it would be only one file which I like as is better than having two files for the same virtual image.

 

9 hours ago, jaclaz said:

I am not sure to understand the "final goal", whatever you boot in the VM is inside the VM, the "real" disk is not visible/usable from inside the VM normally :dubbio::

jaclaz

Information of Goal:

To Test using VMware with vitual HDDs to same layout of a physical PC and mounted HDDs. Physical HDDs mounted in PC layout as written above.

When it works with Vmware then. I will copy what I did in Vmware and the same for real on a Physical PC.

Goal:

Bare Metal Boot with physical PC hardware without any virtual Vmware or other Virtual. The same as Boot from USB but instead same physical PC but using only Physical HDD's

Bare Metal Boot is booting from a physical motherboard to an OS on HDD. Or to boot from disc to OS. Or from USB and so on. Without using a Virtual machine.

Detail of a Boot:

Using a currently in use Primary Active Windows XP3 OS HDD C: partition that has Grub4Dos boot files on it (grldr and menu.lst) and windows edited boot.ini. When boot the PC it goes to XP Boot menu using Boot.ini where is a Grub4Dos choice to select. When Grub4Dos is chosen it will look to the menu.lst on that same partition to know what to do next. Which is to search (find --set-root /name.tag) and set root where the name tag is found. There Grub4Dos will find a configfile menu.lst and invoke that and then on screen is shown contents of that menu.lst. When choose select a choice on the menu. The menu will load that image whatever it maybe. Also it can as a normal OS interact with other drives and read-write same as would be able when booted to an OS.

My Grub4Dos knowledge isn't great at more a learning stage. So is the reason I have posted asking for help to do this. As I am stuck more at second menu.lst as what to put there. Such as run image of XP3 OS but for it not to interfere or know about the current XP3 OS that is on the initial boot drive the one I can select on the boot.ini with Grub4Dos boot files (grldr and menu.lst). Though by looks of it I may have more to learn along the way as you have found some things that don't make sense.

Link to comment
Share on other sites

Ok, let's start from the beginning.

Grub4dos (both grub.exe and grldr) have an embedded menu.lst that amounts (in recent versions) to:

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

Basically this is a mechanism to look for a /menu.lst file in a number of default paths from current root and if it is not found start looking for it in all available/accessible volumes.

The menu.lst entries consist of THREE parts:

1) a title (which is what you will see when the menu.lst is loaded, i.e. the entry text you can select and choose to boot
2) one or more commands that will be executed sequentially
3) an implied boot command (this is issued after the last command in an entry and before the next title or before the EOF marker)

If you prefer, generally speaking you can have the same effect of a menu.lst entry by dropping to command line and typing the commands in the entry, pressing [ENTER] at each new line, and then issuing:

boot

[ENTER]

This final boot command is "final", there is no undo, nor way back, the control is passed from grub4dos to *whatever* you specified in the previous issued command(s), usually chainloading a MBR, PBR or other bootmanager/OS loader.

In the special case of a configfile directive, you are essentially passing control to the target of the directive, and this happens immediately, there is no need of the boot (explicit or implied) directive, which plainly means that any command after the configfile one (if the target is found and it is valid) will be ignored.

There is no need for this target to be called menu.lst, and not even to have the .lst extension.

i.e. for all it matters you can have a "main" menu.lst (this MUST be called menu.lst AND MUST reside in one of the preset paths unless you edit the embedded menu.lst) with an entry *like*:

title My nice OS boot

find --set-root /myosname.tag

configfile /myosname.tag

echo you won't ever see this

as long as the /myosname.tag is found and its contents are a valid grub4dos menu, the last line will never be executed.

The /myosname.tag could contain an entry *like* (root will have been already established by the previous find --set-root directive):

title My nice OS boot - 2nd level

chainloader /ntldr

or

title My nice OS boot

chainloader +1

The first one might work, the second won't as what you are chainloading (the PBR or VBR or bootsector) has an incorrect number of sectors before (in your case of a logical volume inside extended) in the BPB (Bios Parameter Block), these data can be corrected manually.

At this point the NTLDR will be running, and it will be looking for a boot.ini (in the same current root where the NTLDR is), this boot.ini needs an entry to the current (other) XP, on 1st logical partition of 2nd disk, probably something *like*:

multi(0)disk(0)rdisk(1)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

the 2 in the above is only a guess, the actual number depends on how many primary partitions you have on this second disk (rdisk(1)), as unlike grub4dos (where 0-3 are primary and logical start from 4), the boot.ini numbering of partitions is not "fixed" but rather "dynamic", see:

https://www.terabyteunlimited.com/kb/kb-articles/how-partition-numbers-are-assigned-in-boot-ini/

then, hopefully, this second windows will be booted BUT you will likely have issues with drive lettering as they are also assigned along a set of dynamic rules (you may need to use migrate.inf or a modified setupreg.hiv to install the XP with a non-calculated drive letter):

https://msfn.org/board/topic/178185-how-to-install-windows-xp-into-2nd-partition-and-get-c-as-systemdrive/

https://web.archive.org/web/20160817074749/http://www.911cd.net/forums//index.php?showtopic=19663

jaclaz

 

Link to comment
Share on other sites

The above is taking me a while to understand in that where does it look and what if there are more than one menu.lst or that there can only be one menu.lst allowed on any drive. Else it may invoke that.

The above maybe looking at devices locations here if "%@root%"=="(ud)" && calc *0x82A0=*0x82b9&0xff

What is (ud) ?? user drive ??

0x82A0 saved drive (current root drive)
0x82b9 UD Partition Heads and Sector per track. Real Bios Drive
0xff The whole drive

How is this emedded invoked

To get to a menu.lst isn't hard to do many ways and probably there is many more.

find --set-root (hdx,x)
find --set-root /Name.tag
find --set-root uuid () uuidnumber
configfile /menu.lst

This is taking me away from the issue I think.


I'm wondering does booting an XP3 OS image need to be rooted and mapped to (hd0,0) for it to work correct. Or can it be rooted and mapped to say (hd3,0) and still work correctly. Does it know when it is run it isn't (hd0,0) does grub4dos hep us no matter where rooted and mapped it will always be seen to XP3 OS itself as correct so it runs correctly. If so maybe grub4dos should map itself to be at the end of a SCSI line. So it is mapped far out of the way, from real the PC use we need from it,

Do we need to have grub4dos mapped to (hd0,0) at boot we never have a need to go back to it. Except reboot but we don't any thing else there we need with Grub4dos use. It is the other second menu we need for use. And if we fall from that to commandline or go there pressing button c. Then we can get back to it with configfile /menu.lst

I have tried to get rid of (hd0,0) so XP3 OS image can be rooted and mapped to (hd0,0). Now I. thinking to try it as is where ever it maybe be mapped and who cares just to see what happens. After all it is virtual no harm can be done.

Those times it has worked I got 7B errors whether because it knows it is not at (hd0,0) or Grub4Dos. 7B from past experience Acronis TIH usually means a drive issue, controller, driver or issue relating elsewhere to HDD.

Qemu Testing images that fail with grub4dos
Raw images just sit there at some point during booting constant read-write but only a few kb to 1mb transferring.
Other types of images will boot but once get 7B then those that worked before and those that haven't all 7B for some reason unknown. Cache retain in memory or pagefile and PC needs a reboot before they will work again.

If make a new Vmware project and put any image except Raw ,img into the new machine all will boot without 7B error

Makes you wonder what the 7B error is all about.

Qemu is a slug and no 64bit OS will cure it not that I have 64bit hardware except Qemu. It's problem is HDD PIO mode is there a known command for it to have UDMA mode working with older Qemu before 64bit that work with XP mainly for testing images.

 

Qemu is just R&R between testing just to see what it does. That is with the actual Vmware original and conveterted virtual XP3OS images not yet with also Grub4Dos, as I am testing with Vmware.

Edited by exogenesis
Link to comment
Share on other sites

To hopefully clear some doubts.

The (ud) is a "special" device partitioned/formatted by fbinst:

https://rmprepusb.com/tutorials/021-guide-to-grub4dos/

(it doesn't normally apply/you will probably never use it), anyway the "calc *0x82A0=*0x82b9&0xff" basically means "check that memory address 0x82A0 is the same as the (rightmost/least relevant, i.e. &0xff) byte in memory address 0x82b9, 0x82b9 is fb related, while 0x82A0 is current root drive number, now that you know about this, you can happily forget about that line/formula (it is simply too advanced and regarding a corner/edge case only that you probably will never experience).

https://rmprepusb.com/tutorials/021-guide-to-grub4dos/021b/

You can have - in theory - as many menu.lst files as you like, the embedded one looks for one of them in the order of the commands, and as soon as it finds one  it passes control to it (and any other menu.lst is ignored), the devices are scanned in a given order, the commands in the embedded menu try to find the menu.lst first on the current root, then it scans devices, the issue may be - on some BIOSes - that with (example) a USB stick the disk order may be altered so, it is possible that in these cases the menu.lst found (if not on current root or /grub or /boot/grub/ below root) is not the intended one.

The embedded menu.lst is embedded at the end of the actual code in both grldr and grub.exe, it can be viewed opening the file with Wordpad and going to the very end of the file, and can be edited with a hex editor or (much easier) with BootIce, since its scope is to find the "real" external menu.lst file, in some setups it can be changed to directly do the *whatever* you want it to do and get rid completely of the external menu.lst, it is automatically loaded and executed by grub4dos at boot time.

Windows NT (and conversely 2K, XP, etc.) was originally designed to work and run from a logical volume inside extended, no problem there, in the good ol' times DOS allowed only a primary and an extended partition, so typically you would have a FAT16 partition (primary, active) containing the DOS and the NTLDR+BOOT.INI+NTDETECT.COM (+ ntbootdd.sys) and a volume inside extended containing the actual OS, this is essentially the difference (that the good MS guys call "reversed") between "boot" and "system" partition, see:

http://www.multibooters.co.uk/system.html

The problem with this kind of setup (in a single disk setup) is that the primary would get drive letter C: whilst the logical volume would get drive letter D:, something that may (or may not) be wanted/liked.

For what it matters once you are booted to grub4dos (and there are several methods to do that) you can use a NT boot floppy image (i.e. containing NTLDR+BOOT.INI+NTDETECT.COM) just fine (without needing any extra driver), there is no end to the tricks that can be used, including (shameless plug <_<) the special MBR code and the underfloppy image in not used sectors or the UMBR.

These are ONLY for your info, to know that alternatives do exist, do not even think of using these methods (yet):

http://reboot.pro/index.php?showtopic=19516

http://reboot.pro/index.php?showtopic=22317&p=215423

http://reboot.pro/topic/19516-hack-bootmgr-to-boot-windows-in-bios-to-gpt/page-11#entry197690

http://reboot.pro/index.php?showtopic=21856

 

Yes, you are not the first one to report that Qemu on 64 bit is not (yet) working well, the 32 bit did work just fine, personally I am using now (but what do I know?) Virtualbox (32 bit) for my little experiments using RAW images+VMDK descriptors, just in case/JFYI:

https://www.forensicfocus.com/forums/general/boot-a-dd-into-a-virtual-machine-with-virtualbox/

The 7b error technically means "inaccessible boot device", typically it comes from a mismatch between what the "real" mode of the NTLDR sees (essentially BIOS) and what the "protected" mode part sees, on real hardware it is typical of a missing or misconfigured driver, but there are several reasons why it can happen, all related to accessing the boot device in the early stages of booting.

To map an image (i.e. not booting from a volume/partition on disk, but rather booting from a volume/partition inside the image) you will need a special driver, namely firadisk, winvblock or svbus.

I know I am giving you lots of info, some rather complex, you will need some time to digest these, and you should simply ignore what doesn't sound useful (yet), but feel free to ask questions if there is something you have difficulties in grasping.

jaclaz

 

 

Link to comment
Share on other sites

Before I start to reply from a user point of view about grub4dos the error messages while been straight to the point do not help. I mean for example [ file not found ] error but what file does the error refer to could be any file. I think a rethink about adding extra info for errors when we get them. Such as [ filename.ext file not found at line ## ] appreciate those with multi commands on one line it may not help those but if they split the line down to many it knowing which filename.ext would help them also. This is not a problem just with filename not found but for many errors more info is needed.

Thanks for all the information you have written above so far, you are correct that some of the information is more advanced than the project I have at hand although I will read later when project completed and running. I am saving the page for when it changes each time for later viewing.

Link to comment
Share on other sites

jaclaz> Windows NT (and conversely 2K, XP, etc.) was originally designed to work and run from a logical volume inside extended

jaclaz> To map an image (i.e. not booting from a volume/partition on disk, but rather booting from a volume/partition inside the image) you will need a special driver, namely firadisk, winvblock or svbus.

MAybe it should be Grub4Dos sees the HDD image as the physical HDD. Then it would be a physical disk volume/partition , same as a normal bios does.

Use firadisk, winvblock or svbus so it will see the HDD image as a volume/partition a Physical HDD booting from C drive for this project. This could also get rid of the 7B errors this does make sense.

Some reading to do for now Firadisk, winvblock and svbus further details for and of them and their usage in Grub4Dos for this project. Also see how a basic NTFS basic floppy disk boot will change things, I will do this first.

Embedded menu.lst I did try on boot drive without a menu.lst and yes embedded works booted to the menu.lst and shows the menu nice'n'easy

Lots to look at and lots to try :) Edited by exogenesis
Link to comment
Share on other sites

The error message is "normal" (not unlike the one you would get in DOS or in Windows command prompt).

If you want, grub4dos is very similar to those command line interfaces, intended to run commands one at the time BUT a menu.lst behaves as a sequence of commands, not unlike a batch file (which BTW are available in grub4dos as well, by convention using the .g4b extension), so you run a sequence of commands (that you cannot see) and when you get an error there is no way to know which command (and its arguments) created it, and this is exactly the reason why - generally speaking, before creating a menu.lst (particularly if complex) it is a good idea to test their contents on command line, one command at the time.

Or you need to make commands much more explicit, adding custom echo messages (always or  in case of error), setting differently the debug level, enable stepping, etc. but these are as well some more advanced topics.

About the drivers, I would try first SVBUS (as it is the newest and usually just works), winvblock and firadisk are good as well but they are more "sensitive" to the specific setup (i.e. the actual hardware, virtual in your case, but that later may become "real") and to the specific contents of the image, i.e. on some setups firadisk works a treat while winvblock has issues and viceversa on some other case.

jaclaz

Link to comment
Share on other sites

Yes I have been trying Firadisk And Winvblock yrt to try SVBus maybe that one could work. As you say the issue at hand is that the image file trying to load will always been seen to windows as an image file emulated OS. SO reason for tools to try trick the OS into thinking that the image HDD is a real OS HDD not image but physical. So it will load and map it to C drive. As you have mentioned to windows it doesn't matter if it is on a primary or extended as long as it is physical so a signature can be valid and so will allow to load.

Is it Grub4Dos at fault - Maybe I don't know further how it could be.
Is it Virtual Software - Well it can run and also install windows if need be so maybe no.

I do have another thought how to proceed install to the the image as would a real physical Storage drive HDD or Memory Drive types. My though is rough and so far is this.

Bootable CD > Run Grub4Dos Which mounts an empty .img file And XP Install CD Then Runs the disc
after first install reset
Bootable CD - Run Grub4DOs Which Mounts the .img File And Mounts XP Install CD > Run the .img > Which continues to install XP OS

It is rough but if works XP installed and running with correct partitioning of image and correct drive letter C: assigned in XP Windows
Link to comment
Share on other sites

That said I have an issue first that is I have a Silicon Image HDD controller which recently I added a drive that has been not used for a while. The controller is fine without te drive but with the drive it makes Grub4Dos work strange. The drive in question is this one as listed above and here.

Disk 2 Bus Number 0, Target ID 0, LUN 0 (IDE Controller)
Volume F

I have seen various errors and one constant error but I believe it is not the problem.

#1 When boot past the Grub4DOs (first) Boot Meu to the payload menu there is a long wait. And the error then says I need add [ geometry --lba1sector (130) ] (without [ ]) to first line in the menu.lst - I guess this would need to be on the grub4dos (first) boot side menu.lst.
I did try this geometry thing on first line but never committed to it in menu.lst or Grub4DOs the next command it would need. As I didn't believe what I read further or what happens if do commit it to disk.

#2 When I boot to the Grub4Dos (first) Boot Menu and press C button then root to (hd2,4) which is where this drive is always at in Grub4Dos. It then gives this error.
FATAL! inconsistent data read From (0x2) 0+63
FATAL! inconsistent data read From (0x2) 1+1
FATAL! inconsistent data read From (0x2) 0+63
FATAL! inconsistent data read From (0x2) 0+1


#3 If I reboot then at Grub4Dos (first) Boot Menu Press C this time I type.
map --status
at the bottom it will say Int13 is OFF or similar.


#4 If I reboot and Grub4Dos (First) Boot Menu I press C then type.
Root (hd2,4)
It will shows correct the drive as NTFS (0x7) as normal


If I do wait long enough a few minutes the geometry (130) thing will finally pass and will then be at the Payload Menu.lst and able to run menu choices. Today I did XP3 OS (C:) drive backup but the speed and time it took twice as long as usual. I didn't read or write to this drive but other drives these two.

Disk 0 Location 0 (0)
Volumes C and E Backup C


Disk 1 Location 0 (0)
Volume D Save Backup image to D


The drive That takes forever to be seen by Grub4DOs works with speed in XP3 (UDMA5) and also on live OS and other Live discs I run from CD or DVD.

I wonder if it is the controller and without the HDD connected the controller is not an issue with Grub4Dos no Geometry (130) and no long wait occurs.

Any ideas !
Link to comment
Share on other sites

It could be due to several reasons, AFAIK:

an incompatibility of some kind (between grub4dos and the controller or - more probably between grub4dos and the BIOS+specific controller)

an actual issue with the disk

*something* unbalanced in the MBR or PBR or both (or in the EMBR of the Extended partition), possibly in the BPB (some data in it may be used/checked when booting but not necessarily when accessing the disk/volume from a booted system, that usually does not rely on some lower level interface such as BIOS)

a bad cable/connector (do not underestimate this, in the years I have seen intermittent issues of this kind, sometimes temperature connected, sometimes plain voodoo) 

The #3 is "normal" as you haven't mapped nor hooked anything.

If you can avoid using this interface/disk it would be easier, as this - unless the exact cause is identified and the problem solved - represents an issue that may (or may not) affect the mapping and possibly then the functioning of Svbus/firadisk/winvblock.

jaclaz

Link to comment
Share on other sites

I have been testing the external HDD Controller Device Silicon Image 0680 ATA Cable and more. With Drives as listed above Drive 1 D and Drive 2 F swapped by cable to drive connect not cable to Device Connection. Booting Grub4Dos now doesn't hang during booting with geometry (it doesn't show or is to fast to notice) and goes on to show Grub boot menu quickly.

But now doesn't go to the payload menu. If when at Grub Boot Menu I type uuid instead of 5 partitons listed I see 6 and also 3 invalid partitions. Which I assume could be RMPrepUSB on the USB. So I deleted USB back to no Partition and created a new one Basic Logical Extended NTFS 4k and viewed with RMPrepUSB Drive info and it shows 4 partitions still but on the first has any numbers data. Boot to Grub4Dos boot menu again > type C .> uuid and the same is showing with 4 invalid partitions.

 

MAybe MBRs or other so I have attached here in an archive of all the drives MBRs and all Drive Infos from RMPrepUSB Drive Info and UI pictures of Disk Manager, Partition Master, and Check Disk GUI showing all the drives as they are now.

The archive is password which I will send to your PM inbox. As I am not sure or informed enough to know if posting MBRs contains any drive information that could be used now or in the future to target a drive with Virus or otherwise.

 

The archive contents may give you a better insight in to the system drive layout, all drives MBR and Infos and if they are correct or any have any problems.

 

 

Drives CDEF and USB G.rar

Link to comment
Share on other sites

First thing rest assured that MBR's and PBR's do not contain any "meaningful" (from a privacy/virus/malware point of view) info, they contain "common" code + a few specific data (geometry/addresses/etc.) that are not of interest to anyone and the Disk Signature (in the MBR) and the Volume Serial (in the PBR) that - while "unique" - are anyway random generated at partitioning and formatting times, so as well not particularly interesting.

What you posted are the MBR's which - in a case such as yours with use of logical volumes inside extended are only a small part of the story.

To check a primary partition/volume one needs:
1) the MBR (first absolute sector of disk)
2) the PBR/VBR (first sector of the partition/volume)

To check a logical volume one needs:

1) the MBR
2) the chain of EMBR/EPBR's (first sector of the extended partition AND in case of more than one logical volume the "next" EMBR until all logical volumes are mapped)
3) the VBR

Most of the common tools used in "booting matters" are very useful for primaries but not so much for logical volumes inside extended.

About the 4 MBR's you included, they are seemingly just fine BUT DISK0.MBR has a few issues, the Extended Partition is marked as being type 0x05 (which is "CHS mapped") but its extents exceed the CHS mapping limit AND it doesn't fall on a cylinder boundary, then the CHS start data 1023/0/4 doesn't correspond to the LBA value, and there is a "queer"  66 sectors gap between the primary and the extended.

 Such wrong/unbalanced situation may well be an issue in grub4dos.

The other ones look fine, the Extended Partition is marked as 0x0F ("LBA mapped") the CHS and LBA addresses are balanced, they are only unusual as they don't start "normally" at LBA 63 but rather at LBA 16065 (and in CHS at 1/0/1 rather than on 0/0/1).

About DISK0, first thing one must understand is if the EMBR is on LBA sector 29,543,538 (the LBA address in the entry) or on sector 16,434,498 (the LBA address corresponding to the CHS entry 1023/0/4).

Are you familiar (generally speaking) with hex/disk editors and their operation?

You could get Tiny Hexer and my templates for it from here:
http://reboot.pro/index.php?showtopic=21999

The MBR backup program by Wimb in the above should be capable of saving also the EMBR's and PBR's.

Otherwise there is a little program by Terabyte that should be able to:

https://www.terabyteunlimited.com/kb/kb-articles/explanation-of-the-partinfo-utility/

https://www.terabyteunlimited.com/downloads-free-software/#partinfo

If you have Excel or a compatible spreadsheet program, you could also find of use my spreadsheet CHS_LBA to check the values :

http://reboot.pro/index.php?showtopic=2959

http://reboot.pro/index.php?showtopic=2959&p=74116

Again, I know I am throwing at you a number of "advanced" tools/concepts, don't worry the whole stuff seems more difficult than it really is, but you will need some patience, the TLDR; is:

I don't like (and I presume grub4dos also doesn't :unsure:) the way your DISK0 is partitioned, the issues - once understood - can be corrected but if you can (i.e. you are experimenting and the disk/volumes do not contain important data or you already have these data backed up)  it would be easier to start from scratch re-partitioning the disk and recreating the volumes.

jaclaz

 

Link to comment
Share on other sites

My level of understanding MBRs and PBRs is not at a level that you are at, for understanding them.

 

5 hours ago, jaclaz said:

Such wrong/unbalanced situation may well be an issue in grub4dos.

The other ones look fine, the Extended Partition is marked as 0x0F ("LBA mapped") the CHS and LBA addresses are balanced, they are only unusual as they don't start "normally" at LBA 63 but rather at LBA 16065 (and in CHS at 1/0/1 rather than on 0/0/1).

Is this also referring to Disk0 or other MBRs of disks

 

Easier for now I think for me to start with a (near factory) fresh Drive0.

 

1. Secure Erase Disk0 using the G.Hughes secure disk erase tool

2. Partition the Disk0 using a Partition tool to as previous Partitions C and E

3. I have ATIH standalone backups for each partition. I will also make separate RAW images of both partitions in case ATIH fails.

Restoring the Disk with ATIH little use as the partition structure would also be copied. So need to use copy files mode this may mean no disk signature is then regenerated which also would be needed. Unsure if partition tools do this or command to use for a disk signature if the XP Microsoft Install Disk has to do it.

Would then Disk0 system Disk partition C be able to boot or something I have missed.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...