Jump to content











Photo
- - - - -

Booting from a volume on Logical partition with Grub4DOS


  • Please log in to reply
31 replies to this topic

#1 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 23 November 2010 - 01:59 PM

Hi everyone,

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:

title HD_Diagnostics ISO
map --mem (hd0,5)/ISO_Images/HD_Diagnostics.iso (hd32)
map --hook
root (hd32)
chainloader ()

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:

title HD_Diagnostics ISO
find --set-root /ISO_Images/HD_Diagnostics.iso
map /Service_ISO/HD_Diagnostics.iso (hd32)
map --hook
root (hd32)
chainloader ()

The ISO is bootable with its own Grub4DOS boot menu.lst. The items from that menu.lst boot normally, once the host ISO is booted. What seems to be the problem, and how to fix?

Edited by sambul61, 05 December 2010 - 04:50 PM.


#2 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 27 November 2010 - 04:52 PM

Should it be reported as Grub4DOS bugs? Is there a Bug Report area on this forum, or where to do it instead?

#3 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 27 November 2010 - 06:08 PM

Should it be reported as Grub4DOS bugs? Is there a Bug Report area on this forum, or where to do it instead?


Maybe the grub4dos Forum (as opposed to the FreeDOS and Dos one) may be a senceful choice?

http://www.boot-land...hp?showforum=66

In any case, can you post there a "proper" report, meaning the SINGLE commnand you issue and the SINGLE feedback grub4dos gives you?

Maybe a typo but this:
title HD_Diagnostics ISO

find --set-root /ISO_Images/HD_Diagnostics.iso

map /Service_ISO/HD_Diagnostics.iso (hd32)

map --hook

root (hd32)

chainloader ()
looks for /ISO_Images/HD_Diagnostics.iso and attempts to boot ANOTHER image: map /Service_ISO/HD_Diagnostics.iso (hd32)

Also WHICH EXACT version of grub4dos are you using?

:)
Wonko

#4 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 27 November 2010 - 09:06 PM

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. :)

Edited by sambul61, 27 November 2010 - 09:06 PM.


#5 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 28 November 2010 - 11:31 AM

Most probably you have drives that are partitioned in a non-standard way.

:D
Wonko

#6 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 28 November 2010 - 06:32 PM

How "far" away is the logical NTFS partition? How many gigabytes before it starts on the HDD?

#7 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 28 November 2010 - 07:15 PM

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). :D 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.

Edited by sambul61, 28 November 2010 - 07:42 PM.


#8 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 28 November 2010 - 07:28 PM

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

I could imagine trouble with anything starting later than 137.4 GB.

#9 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 28 November 2010 - 07:44 PM

Yet I have no trouble booting images with Grub4DOS from a Primary partition regardless of its size & distance.

#10 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 28 November 2010 - 08:19 PM

Yet I have no trouble booting images with Grub4DOS from a Primary partition regardless of its size & distance.

What is the exact error message? "can't find" appears twice in the source code; neither of which looks like the rest of the message you reported. Same with "can't access".

#11 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 29 November 2010 - 12:22 AM

Sorry, the exact error reads:

"Error 25. Disk read error"

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

Edited by sambul61, 05 December 2010 - 04:54 PM.


#12 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 453 posts
  •  
    Thailand

Posted 29 November 2010 - 10:57 AM

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.

#13 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 29 November 2010 - 12:01 PM

Maybe PLoP ?
http://www.plop.at/en/bootmanager.html
:cheers:

:cheers:
Wonko

#14 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 29 November 2010 - 12:03 PM

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. :cheers:

Edited by sambul61, 29 November 2010 - 12:07 PM.


#15 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 453 posts
  •  
    Thailand

Posted 29 November 2010 - 02:23 PM

If it were a BIOS limitation ... none of images would boot

:cheers: 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.

#16 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 29 November 2010 - 03:30 PM

System ASUS P5Q, chipset P45, partitions (its a spare drive connected via SATA or emulated IDE, I had to temp migrate OSs to due to another drive failure):

a) Data 150Gb Primary NTFS
c) WinXP 50Gb Bootable Primary NTFS
d) Win7 100Gb Bootable Primary Active NTFS (Bootable via EasyBCD with Grub4DOS and Plop menu entries among other)
e) Data 50Gb Primary FAT32
f) Ubuntu 50Gb Ext4 Bootable Logical on Extended
g) Archive 150Gb NTFS Logical on Extended

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.

Edited by sambul61, 29 November 2010 - 03:40 PM.


#17 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 29 November 2010 - 03:43 PM

If you insist that it's correctly loaded into RAM by map --mem, please post the output of map --status. Please and thank you. :cheers:

#18 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 29 November 2010 - 03:49 PM

Every day learn a new Grub4DOS command. :cheers: Will see...

#19 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 30 November 2010 - 02:35 PM

Here we go: both ISO images below can boot from a logical volume on extended partition via find --set root command. They also loaded into RAM via map --mem command, but can't boot after that.

One ISO is loaded to mem
One ISO map status
Two ISOs map status 1
Two ISOs map status 2

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?

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

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?

Edited by sambul61, 30 November 2010 - 03:15 PM.


#20 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 30 November 2010 - 04:15 PM

Here we go: both ISO images below can boot from a logical volume on extended partition via find --set root command. They also loaded into RAM via map --mem command, but can't boot after that.

Huh? "both...can boot...can't boot after that." Do they boot or don't they boot? Your earlier posts say that they can't. Do you mean "both...can load...can't boot after that"?

One ISO is loaded to mem

This picture shows the precise error message that you gave in this thread's #11. Ok. It shows you are trying to set the current filesystem to whatever is on device 0xFF (or (hd127)).

One ISO map status

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?

Two ISOs map status 1

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?

Two ISOs map status 2

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.

#21 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 30 November 2010 - 05:50 PM

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.

title Acronis
map --mem (hd0,5)/ISO/Acronis_trial_disk.iso (0xff)
map --hook
root (0xff)
chainloader ()
boot

title Paragon
map (hd0,5)/ISO/Paragon_trial_disk.iso (hd32)
map --hook
root (hd32)
chainloader ()
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.

Edited by sambul61, 05 December 2010 - 04:55 PM.


#22 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 30 November 2010 - 06:34 PM

@Sambul61

Maybe there are communication problems. :)

You are overloading us with question, examples, different .iso's, partitions vanishing, primary and logical, etc.

Often it is not easy to understand each other if the probelm is not "focused" or "narrowed" enough.

Let's try to simplify troubleshooting (only about the difference between the SAME .iso in a Primary or in a Logical Volume inside Extended)

Choose one .iso image (and one only).

Name it 8.3 (so that we remove this possibility - very remote - from the equation), as an example: mypretty.iso

Place it in the root of a Primary partition. (so that we remove the possibility - still very remote - of a directory problem) as an example: C:\mypretty.iso

Verify that it boots with a given set of commands, GIVEN ON COMMAND LINE, NOT BY USING A menu.lst ENTRY.

Post the set of commands that worked.

Post the feedback grub4dos gives after EACH command.

Copy the .iso in the root of the primary partition to the root of a Logical Volume, example K:\mypretty.iso

Now try ON COMMAND LINE, NOT BY USING A menu.lst ENTRY, the SAME commands you used successfully before.

Post the feedback grub4dos gives after EACH command.

The whole point is that in order to try understanding what happens, we need the feedback from each single command in a given sequence.

Please take note that the final boot command that you appear to be using in menu.lst entries is UNneeded, as it is implied inside a .lst entry, whilst it is necessary when using command line.

The question:

I asked a specific question (how to return to menu from commandline)


Which you asked among n others:

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?

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

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?

And thus was quite difficult to spot, has a simple answer, which had you actually read the Guide, sticky in the grub4dos Forum (this is still FreeDOS and DOS):
http://www.boot-land...hp?showforum=66
http://www.boot-land...?showtopic=5187
http://diddy.boot-la...os/Grub4dos.htm

If you boot to grub4dos AND a menu.lst file is found and loaded THEN you press "c" to get to command line and you press "esc" to get back to the loaded menu.lst.

If you boot to grub4dos AND NO menu.lst is found and loaded OR you want to use ANOTHER .lst configuration file, you issue a configfile command.

Actually this is how menu.lst is actually loaded by default:
http://diddy.boot-la...es/embedded.htm
Please note how different version of grub4dos may have different contents in the embedded menu.

Once again, it would be nice if you could post grub4dos related questions, one - or a very few at the time - in specific threads in the grub4dos Forum.

:cheers:
Wonko

#23 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 30 November 2010 - 06:38 PM

If you read the whole thread,

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.

title Acronis
map --mem (hd0,5)/ISO/Acronis_trial_disk.iso (0xff)
map --hook
root (0xff)
chainloader ()
boot

title Paragon
map (hd0,5)/ISO/Paragon_trial_disk.iso (hd32)
map --hook
root (hd32)
chainloader ()
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.

configfile

#24 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 30 November 2010 - 08:25 PM

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 :cheers:) 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. :cheers:

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

Edited by sambul61, 30 November 2010 - 08:49 PM.


#25 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 30 November 2010 - 08:59 PM

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. :cheers:


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 :cheers: 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.

At the moment there are NO chances for this to ever happen.

:)
Wonko




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users