5 replies to this topic

[dunhill]

Hi all,

 

I am using Grub4dos for UEFI (release 2023-10-16) to boot ISO files in partition named "STORING". The type of HDD is GPT as bellow picture

 

 

The file MENU.LST is

color light-green/black light-red/black white/black white/black
timeout 30
default /default

title Windows 98 Command Prompt
	map (hd0,5)/BACKUP/INSTALL/WIN98.ISO (0xff)
	root (0xff)
	chainloader (0xff)

title Windows 10 Mini (64bit)
	map (hd0,5)/BACKUP/INSTALL/LIVE1064.ISO (0xff)
	root (0xff)
	chainloader (0xff)

title Ubuntu 22 (64bit)
	map (hd0,5)/BACKUP/INSTALL/UBT2204.ISO (0xff) || map --heads=0 --sectors-per-track=0 (hd0,5)/BACKUP/INSTALL/UBT2204.ISO (0xff)
	root (0xff)
	kernel /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity iso-scan/filename=(hd0,5)/BACKUP/INSTALL/UBT2204.ISO quiet splash ---
	initrd /casper/initrd

title Reboot System
reboot

title Halt System
halt

Grub4dos for UEFI can not boot into ISO files. The message is "CANNOT MOUNT SELECTED PARTITION" as bellow picture

 

 

Please help me to change "MENU.LST" get boot properly

 

Sorry for my English

 

Thanks in advanced.

 

 

 

 

[Wonko the Sane]

Press C to get to command line

 

Then issue:

root (hd0,5)

[ENTER]

What happens?

 

Then:

ls

 

[ENTER]

 

Can you see those .iso files?

 

Are you sure that paths and file names are CAPITAL LETTERS (grub4dos is CaSe SeNsItIvE on NTFS)?

 

Can you see all the partitions running:

geometry (hd0)

[ENTER]

 

Can you try:

root

[ENTER]

right after boot it should probably give you (hd0,0)

 

Then:

 

find --set-root /BACKUP/INSTALL/LIVE1064.ISO

[ENTER]

root

[ENTER]

if the file is found, the result should be (hd0,5) (or whatever other volume where the file is found)

 

The common issue when there is an error with grub4dos and menu.lst is that the error you see might not be the "original" one, but rather the "last" error generated by the multi-command menu.lst entry.

 

You can also try typing one by one the contents of the entry on command line.

 

Wonko

[dunhill]

Thanks Wonko

 

I follow your instructions and get the results as

 

 

The partition contains ISO file is NTFS and my HDD type is GPT. The path and file name are correct with upper case

 

I do not understand why GRUB4DOS UEFI can detect file system of the partition (hd0,3) but cannot detect file system of the partition (hd0,5)

 

Then I try to move file LIVE1064.ISO into partition (hd0,3), the results as 

 

 

For the version GRUB4DOS legacy, I did not get bad results as GRUB4DOS UEFI. GRUB4DOS legacy boot successfully ISO in USB drive (NTFS file system) with same MENU.LST

Edited by dunhill, 15 January 2024 - 04:20 AM.

[Wonko the Sane]

I don't know.

 

It seems like your GPT disk is *somehow* not seen properly by the grub4dos you are using.

 

It is not an "absolute" issue as (hd0,2) and (hd0,3) have their filesystem identified correctly by the geometry command.

Could it be that it is a "re-worked" hard disk and that you have "holes" in the GPT partition table?

Or maybe a partition out of index?

 

The error when you try the .iso on (hd0,3) seems more to be connected with a reading error.

 

Since the whole hard disk is smaller than 2.2 Tb, you could try making it MBR instead of GPT.

 

Before any other test try latest-latest (2023-11-29).

 

Wonko

[dunhill]

Thanks Wonko

 

It is very strange for me when hearing from you that the GPT partition table may have "holes" and it may be "re-work"

 

You can see the pictures that I have checked my HDD in both Windows and Linux

 

 

For the ISO files, they worked when GRUB4DOS legacy was used to boot.

 

 

[Wonko the Sane]

As said, I don't really know.

 

The fact that some partitions are recognized in the output of geometry command and some are not is strange, I would have understood that if you had (say) 128 partitions, but 5 or 6 are quite normal.

As well, I cannot see any particular size/offset problems, your disk looks like a pretty normal disk.

 

I really cannot remember the details, but I seem to remember that when I did crazy experiments with hiding/shifting GPT partitions I did manage to make partitions that were not visible anymore in grub4dos, but that were still visible in gdisk JFYI:

http://reboot.pro/in...showtopic=22553

 

If - and I believe you on this - your partitions are "regular" in both Windows and Linux, then it is a grub4dos (for UEFI) bug, but I believe that the code used for GPT access is the same in both the "old" BIOS grub4dos and the "new" for UEFI  one, and it is many years that accessing GPT is implemented, at least since 2014, similar cases should have come out, unless it is a new regression bug.

 

You can only try to use the most recent version and one from some time ago, let's say a 2023 early one like the 2023-02-23

:

http://grub4dos.chen...ories/for-UEFI/

 

and see if anything changes.

 

Wonko

[dunhill]

Thanks Wonko

 

I have modified the file MENU.LST

color light-green/black light-red/black white/black white/black
timeout 30
default /default

title Windows 10 Mini (64bit)
	map --mem (hd0,3)/LIVE1064.ISO (0xff)
	map --hook
	chainloader (0xff)
	boot

title Ubuntu 22 (64bit)
	map --mem (hd0,3)/UBT2204.ISO (0xff) || map --heads=0 --sectors-per-track=0 (hd0,3)/UBT2204.ISO (0xff)
	map --hook
	root (0xff)
	kernel /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity iso-scan/filename=(hd0,3)/UBT2204.ISO quiet splash ---
	initrd /casper/initrd

title Reboot System
reboot

title Halt System
halt

Grub4dos UEFI can boot into both ISO files WinPE and Live UBUNTU because Grub4dos UEFI can detect (hd0,3) as NTFS file system.

 

Then I have contacted the developers of Grub4dos UEFI and wait for feedback

[Wonko the Sane]

So it must be some weird incompatibility between your partitioning (or filesystem on hd0,4 and 0,5) and grub4dos code.

 

Since the partitions are found by the geometry command but their filesystems are not recognized, it could be both a "strange" GPT ID in the partition table or a non-standard boot sector ($boot file in NTFS).

 

If you have time to experiment, I would try checking the partitioning with gdisk:

https://www.rodsbooks.com/gdisk/

or another suitable program

 

Those 2 volumes should have ID 0700 or Microsoft basic data in gdisk or, if the tool shows the actual GPT GUID, it should be

ebd0a0a2-b9e5-4433-87c0-68b6b72699c7

if it isn't, it should be set as such.

 

Then, after having backed up the contents, try to re-format one of the two volumes and see if it makes a difference.

 

Wonko

[dunhill]

Thanks Wonko,

 

I have check Partition type for 2 volumes on my HDD. Nothing special

 

[Wonko the Sane]

Yep, they both look pretty much normal.

 

The only thing that comes to my mind is that there could be in grub4dos code some remnants of MBR related code.

 

On MBR devices you can have at most 4 primary partitions, that grub4dos would name (on first disk) as (hd0,0); (hd0,1); (hd0,2); (hd0,3).

 

But you can have, instead of one of the primaries an extended partitionm in which you can have as many (within some common sense) volumes as you want, and these volumes would be called (hd0,4); (hd0,5); etc.

 

Would it be possible that grub4dos somehow thinks that those (primary, as in GPT all volumes are primary) volumes are logical volumes inside extended? (and thus fail to map/access them as it is looking for a EPBR that simply is not there)

 

Wonko