I have a little problem (for this kind of forum). I made an ISO image file and boot it from a Win 7 hard drive via Grub4DOS menu. The hard drive has a mix of WinXP, 7 and Linux formatted partitions. The menu entry looks like this:

The problem is, when the ISO file is placed on a Primary NTFS formatted volume of any drive, the ISO boots every time. However, when the same ISO is placed on a Logical Volume's NTFS formatted Partition of the same drive, it never boots at all. The error message is: "Can't access the disk". It always occurs after the ISO is fully read into RAM (meaning, it is found and read by Grub4DOS). Using the same entry without "mem" doesn't change the outcome. Using "Find --set root" results in successful boot. The menu entry:

Sorry, it just a typo. I use grub4dos-0.4.5b, since stable version several times made 1-st partitions on my HD disappear (they were restored each time with Paragon). But each of the HDs had several system partitions, so Grub4DOS was probably amused enough to cut the count down.

If a partitioning is done by a non-standard way (with Acronis), it still doesn't mean Grub4DOS should be allowed to permanently delete any partition without asking, standard or not. I view its purpose a bit differently. What's interesting, it can be restored only with Paragon after that (from what packages I tried). What's the best package you can suggest to find & restore a deleted partition (not files recovery)?

The HD is 500Gb, and its Extended partition starts at 400Gb, with its volume size 100Gb.

It happens after the image is fully loaded into RAM and the next step starts (whatever it is). I noticed that some images like FreeDOS FDD will boot from a logical partition, while others like Acronis (Linux based) or Paragon CD (Win7 PE) won't. Even an ISO with the same FreeDOS floppy image in its boot sector won't boot. More interesting, these images can be found with Find --Set Root command. And they're loaded into RAM when mapped directly via (hd0,5), but they don't boot from RAM. Yet FreeDOS FDD images boot every time when mapped directly to, despite they also can't be found with "find --set root". This only happens on volumes on a Logical partition, but not on Primary partitions.

It may be, some partitioning soft deviates from "standards" - don't know, but all partitions are properly mounted in Windows, so if Windows see them all, why Grub4DOS has a problem? And the problem shows up when the image is already loaded into RAM, so it no longer relevant what partition it was loaded from. Hence, there seems to be two separate issues here:

- can't boot some image files (whether loaded into RAM or not) from a volume on a logical partition
- I placed a Linux partition on the same Logical one, and it boots without issues

It is probably because of BIOS limitation.
Make a small text file in that logical partition. Can you read it with cat command in GRUB4DOS commandline.

My PC BIOS can only read 137.4GB from USB connected hard disk. Read further and it will return junk data. The buggy BIOS does not return error, so GRUB4DOS cannot know it does not receive the correct data.

I'll try, but don't see much relevance for now. Once the image is loaded into RAM, it no longer belongs to a particular HD or partition. Yet it doesn't boot. If it were a BIOS limitation (and I've the latest BIOS with a new ASUS Mobo and 4Gb RAM), none of images would boot, but as I said, small FreeDOS FDD images boot from the same volume on a logical partition.

I just wanted to point to an evident problem with Grub4DOS. As to Plop, its ability to my knowledge is severely restricted to booting only from the first drive in BIOS drive order. I found it useful only for booting USB devices in virtual machines. Hope, I'm wrong on that.

Maybe your BIOS limit is in the middle of partition and some of the images are below BIOS limit and some are above the limit.

Please provide more detail about your system, configuration that the problem occur. What motherboard, chipset are you using ? What interface your drive is connected to ? List of partitions with type (primary, extended, logical), filesystem type, exact starting address (LBA,CHS) and size.

How do you know GRUB4DOS deleted your missing partition ? Is it possible that your partition was deleted by other program ?Windows 7 create logical partition on 1MiB boundary with no respect to disk geometry or cylinder boundary. Windows XP Disk Management does not see and automatically delete logical partition that does not end on cylinder boundary when ever you made any change to partition table (such as marking a primary partition as active). Other disk partitioning software running on Windows XP may also have similar problem.

The ISO and IMA images are placed onto Archive volume. Not sure how to get exact partition starting addresses - with what soft? But how its all remain relevant, once the image is loaded into RAM? As I said, the error occurs AFTER an image was completely loaded, and the next step started in boot sequence.

Its possible that partitions were deleted by a combination of soft, i.e. using EasyBCD to re-assign the bootable drive (not partition), and then using G4DOS and new Plop version to boot an image or partition. But I've a recollection of it being dissapearing after using Grub (or its EasyBCD adaptation). At times the 1-st Win7 active partition on another drive periodically dissapeared, at times the 1-st logical volume on the above drive.

This is a nice picture. It shows the whole screen. It also shows 4 HDDs. It doesn't show what map command was used before map --status. What commands were used to produce this mapping? It looks like you have mapped from a RAM drive to some range of sectors on another RAM drive. It doesn't look like an .ISO loaded from an extended partition, which is what you've been asking about. Am I mistaken?

In this picture we see a vritual (hd32) mapped without --mem to a range of sectors on the hard disk. What commands produced this mapping? We also see a RAM drive once again looking to be mapped to a RAM drive. What commands produced this?

This picture seems to show that your virtual (hd32) is mapped to a range of sectors beginning at 379.374 GB on the HDD. With that mapping in place, can you do ls (hd32)/ and see a list of files? Please share your commands leading up to these map --status displays. Forget about using MENU.LST (or any config-file) and type the commands manually at the GRUB4DOS CLI, examining the output of each. You can have a menu entry including commandline to get to the CLI.

What's the max size of RAM Drive created by Grub4DOS, where all these images are loaded? Can that size grow depending on how many images are loaded?

For RAM disks, I believe that GRUB4DOS will try to use memory marked as available in the BIOS E820 memory map. Your largest RAM disk image will depend on the largest contiguous range of available memory.

Btw, how one can go back from Grub4DOS prompt to its Menu List? If not possible, can such command be added?

Your GRUB4DOS download should have come with a file called README_GRUB4DOS.txt. Please use it.

Also, is it possible to return to Grub4DOS screen from WinXP or 7? Then, how to exit Grub4DOS screen to already booted WinXP or 7?

No. You can use WinKexec to get to GRUB4DOS from XP, but you will have no keyboard. XP has to believe that it's being rebooted in order to do this, so all programs must shut down like they would in an ordinary reboot. So you cannot return, but you can boot the XP all over again.

map without --mem does not produce a RAM disk. It produces a sector-mapped disk. Sector 0 on the virtual disk maps to some physical sector on the backing disk. map --mem produces a RAM disk. Sector 0 on the virtual disk maps to some block of memory where the image file was copied to.

If you read the whole thread, you'll find out that I tested a series of ISO files, located on Primary and Logical partitions. They all booted from Primary partition. When it comes to Logical, some booted without issues (like FreeDOS FDD), some booted only when find --set root command was used with or without --mem (sorry for typo in the above post), and some never booted at all.

The above pictures are related to 2 images: Acronis (Linux based) and Paragon (Win7 PE based). They both booted with find --set root, but both failed to boot with map (--mem). The 1-st and 2-nd pics show Acronis didn't boot with map --mem after being loaded to RAM (to a created by Grub4DOS RAMDrive I assume). The 3-d and 4-th pic shows Paragon added with map after Acronis (don't recall, the same or different ISO) failed to boot again after PC reboot, and it also fails to boot.

Can a long file name prevent boot from a Logical partition without affecting boot from Primary? Both ISOs are menu based - can it affect boot from a Logical volume?

With that mapping in place, if I do ls (hd32)/ , is it supposed to show the list of files on both ISOs, or only on the last mapped? What other commands may help to pinpoint the issue, if run during the same session?

map without --mem produces a sector mapped disk in RAM? How its different from a RAM disk created by G4D when using --mem?

I didn't ask for docs to Grub4DOS, we all can read somehow. I asked a specific question (how to return to menu from commandline). Answer on every question on any forum was possibly already given somewhere, so presumably anything can be found if you look hard enough. Readme file for Grub4DOS was created by someone, who IMHO has no experience in writing technical docs. Its not a big pleasure to read such docs multiple times.

I've read the whole thread multiple times, trying to make sense of your challenge, so I can try to help. It's hard for me to follow. Sorry.

you'll find out that I tested a serious of ISO files, located on Primary and Logical partitions. They all booted from Primary partition.

What were your commands to boot them from a primary partition?

When it comes to Logical, some booted without issues (like FreeDOS FDD), some booted only when find --set root command was used with or without --mem (sorry for typo in the above post), and some never booted at all.

That sure sounds a lot like what karyonix suggested. If the .ISO is before some "problem boundary" or if the .ISO is after the problem boundary, depending on where they happened to be copied to. A test you could do is try booting them from a logical partition which is entirely contained below 137.4 GB.

The above pictures are related to 2 images: Acronis (Linux based) and Paragon (Win7 PE based). They both booted with find --set root,

find --set-root doesn't boot anything. Do you mean load?

but both failed to boot with map (--mem).

map with or without --mem doesn't boot anything. Do you mean load?

The 1-st and 2-nd pics show Acronis didn't boot with map --mem after being loaded to RAM (to a created by Grub4DOS RAMDrive I assume). The 3-d and 4-th pic shows Paragon added with map after Acronis (don't recall, the same or different ISO) failed to boot again after PC reboot, and it also fails to boot.

Why are you using (0xff) for Acronis and (hd32) for Paragon? Please avoid 0xFF. If you want a virtual optical disc drive, do what you did with Paragon and use (hd32), which corresponds to BIOS drive number 0xA0. If you want two virtual optical disc drives, use 0xA0 and 0xA1.

Can a long file name prevent boot from a Logical partition without affecting boot from Primary? Both ISOs are menu based - can it affect boot from a Logical volume?

I doubt it.

With that mapping in place, if I do ls (hd32)/ , is it supposed to show the list of files on both ISOs, or only on the last mapped?

ls (hd32)/ should list the directory contents of the root directory of the filesystem available at (hd32). If you have Paragon there, it should be the Paragon disk's contents. If you have Acronis at (hd32), it should show the Acronis contents. If you have Acronis at (hd33), you'd use ls (hd33)/ to list the directory contents. One drive per drive designator.

What other commands may help to pinpoint the issue, if run during the same session?

map without --mem produces a sector mapped disk in RAM? How its different from a RAM disk created by G4D when using --mem?

And here is what I said:

map without --mem does not produce a RAM disk. It produces a sector-mapped disk. Sector 0 on the virtual disk maps to some physical sector on the backing disk. map --mem produces a RAM disk. Sector 0 on the virtual disk maps to some block of memory where the image file was copied to.

"does not produce a RAM disk." A sector-mapped disk is not a RAM disk.

I didn't ask for docs to Grub4DOS, we all can read somehow. I asked a specific question (how to return to menu from commandline). Answer on every question on any forum was possibly already given somewhere, so presumably anything can be found if you look hard enough. Readme file for Grub4DOS was created by someone, who IMHO has no experience in writing technical docs. Its not a big pleasure to read such docs multiple times.

Many thanks guys! Good points and clear answers all over the board. Sorry for some terminology mix up in my posts. May be the thread should be moved to Grub4DOS section?

Basically, I can leave without Grub4DOS booting some ISOs from a Logical partition. Generally it seems to be an outstanding boot tool. The purpose was just to help fix the bugs I faced with. Yes, more accurate feedback is always helpful (otherwise how to resolve?), but for that to occur, a specific test environment must be created, and its hardly possible to use QEMU as a real PC replacement for many reasons.

There are no tools I know of to make snapshots of a real PC boot - this creates a lot of inconvenience. If you think the info above is still not enough, will try some more. But for me personally (having 4 drives as reported ) its not critical.

The commands used were exactly the same on both Logical and Primary partitions. I tried multiple entries of the same ISOs with various suitable (recommended by Guide) command combos, some with (0xff), others with (hd32) - none worked on Logical with direct mapping for these ISOs. G4D Guide says (0xff) shown better results in mounting multiple ISOs with eltorito, hence I tried it, but it didn't make any difference for neither purpose.

If both files load into RAM normally, 137.4 GB limit is irrelevant. Will try with 2TB drive - I have a suitable partition in its backyard - and see what happen...

The commands used were exactly the same on both Logical and Primary partitions. I tried multiple entries of the same ISOs with various suitable (recommended by Guide) command combos, some with (0xff), others with (hd32) - none worked on Logical with direct mapping for these ISOs. G4D Guide says (0xff) shown better results in mounting multiple ISOs with eltorito, hence I tried it, but it didn't make any difference for neither purpose.

Again, you tried too many things together, possibly in a wrong way and DEFINITELY without reporting them properly.

If you re-read my previous post, it means in a nutshell:

Qemu is fine (ok, I'm lying I added this info now, since you raised the problem)

choose one and ONE ONLY .iso

try booting it BOTH in the way that works and in the one that doesn't

post the EXACT, COMPLETE, and FULL feedback you got by doing the above using command line AND NOT a pre-made menu.lst

Again, you have overloaded us with mixed and partially unuseful info, to such extent that we don't know right now WHAT the problem is.

If you start again (and again please do so by initiating a NEW thread in the proper Forum) with a SINGLE problem/question, providing ALL the info asked for and EXACTLY that, and NO other unless asked for, it is likely that the problem will be understood, and - hopefully - solved.