Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×

Recommended Posts


34 minutes ago, jaclaz said:

Now, more than 10 (ten) years have passed (actually almost 15),  and we evolved from a very limited boot environment that could only execute a bunch of assembler, consisting ONLY of MBR code, PBR code and bootloader/bootmanagers to a powerful environment that can run *anything* BUT for which essentially only bootloaders/bootmanagers exist (and was it not for our friend PBatard - Author of Rufus among other things - we would also be limited to FAT32 ):

https://github.com/pbatard/uefi-ntfs

It creates a very small second partition FAT-32 formated at the very end of the device, where the NTFS drivers requiered to boot from NTFS on a UEFI environment are located, so anyway you HAVE a FAT-32 partition to let you boot from the boot files folders located on the NTFS first partition, this drivers make also possible to boot from files folders located on a exFAT partition.  In both cases as long as Secure Boot is disabled.

alacran

Edited by alacran
Link to post
Share on other sites
7 minutes ago, jaclaz said:

map to WHAT? :whistle:

jaclaz

My mistake, I forgot to map --mem /CD/linuxmint-19.3-cinnamon-64bit.iso (0xff)

Will fix the mistake and try again and report back.

alacran

Link to post
Share on other sites
49 minutes ago, alacran said:

It creates a very small second partition FAT-32 formated at the very end of the device, where the NTFS drivers requiered to boot from NTFS on a UEFI environment are located, so anyway you HAVE a FAT-32 partition to let you boot from the boot files folders located on the NTFS first partition, this drivers make also possible to boot from files folders located on a exFAT partition.  In both cases as long as Secure Boot is disabled.

alacran

Sure. the whole point is that the FAT32 is an artificial limitation that has no technical grounds whatoever AND that if a NTFS driver can be written that runs in EFI/UEFI, then *anything* can be written in it AND that the Secure Boot mechanism is a stupid provision, because:


1) it can be worked around nonetheless as you are well aware (see https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface/Secure_Boot )

2) the signature mechanism is mis-managed by MS (and by the sheepish manufacturers that follow them)

AND that - to be a standard - it is pretty much a failure as everyone makes changes to it:

https://wiki.archlinux.org/index.php/GRUB/EFI_examples

(possibly even in good faith as the specifications are more than 2,000 (two thousand) page long) 

jaclaz

Edited by jaclaz
Link to post
Share on other sites

Yes, the Secure Boot is good for nothing, computers get Virus with or without it. The name is a fallacy. But it has being very well sold to the masses.

It is only good to make money from the developers and OEMs as their software require to be approved and certified by MS, if not the drivers can't run if Secure Boot is enabled.

So far at home all PC's HDs are MBR formated, I usually never format any HD as GPT (an unneeded complication for HDs smaller than 2TB), and as I use to Ramboot VHDs a lot by means of SVBus + grub4dos for MBR, all UEFI PCs at home have CSM enabled and Secure Boot disabled permanently.  But for now I'm making an exception booting in UEFI just to test this new version, which seems very promising to me, especially now that almost all new machines are UEFI only.

By the way tested the corrected entry on menu.lst:

Quote

title Start /CD/linuxmint-19.3-cinnamon-64bit.iso
find --set-root /CD/linuxmint-19.3-cinnamon-64bit.iso
map --mem /CD/linuxmint-19.3-cinnamon-64bit.iso (0xff)
chainloader (0xff)

It do not work, message: (initramfs) unable to find a medium containing a live file system.

Same message we get if we try the map or map --mem commands on the grub4dos for MBR without the especial (cheat) code:

Quote

iftitle [if exist (hd1,4)/CD/linuxmint-19.3-cinnamon-64bit.iso] Boot linuxmint-19.3-cinnamon-64bit.iso from second internal HD
set iso_path=/CD/linuxmint-19.3-cinnamon-64bit.iso
map (hd1,4)%iso_path% (0xff)
map --hook
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=%iso_path% quiet splash --
initrd /casper/initrd.lz

So it seems a especial code will be nedded on UEFI environment too.

alacran

Edited by alacran
Link to post
Share on other sites

Sure, that is a so-called "cheat-code" or kernel parameters, it has nothing to do with the booting method (BIOS vs. UEFI), it simply tells the kernel where to look for the rest of the system.

Those settings could also be put inside the initrd, but of course you would have to rebuild a custom one.

Anyway, generally speaking, linux .iso's cannot normally be booted by chainloading the bootsector, which is normally bypassed by the explicit kernel and initrd commands and the cheat-codes, this is not "news" and it is not "peculiar" to the UEFI.

Sticky since 2009:

http://reboot.pro/topic/8944-boot-any-iso-image-or-boot-all-iso-images/

jaclaz

Edited by jaclaz
Link to post
Share on other sites

I had to adapt a little the usual especial (cheat code) menu entries as map --hook command is not available and/or required on UEFI version of grub4dos, also avoided the use of variables (just in case), but I think using variables will give same results too, I'll test the use of variables latter.

Tried this entries on \EFI\grub\menu.lst

Quote

title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram
find --set-root /CD/linuxmint-19.3-cinnamon-64bit.iso
map --mem /CD/linuxmint-19.3-cinnamon-64bit.iso (0xff)
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=/CD/linuxmint-19.3-cinnamon-64bit.iso quiet splash --
initrd /casper/initrd.lz

title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting as Filedisk
find --set-root /CD/linuxmint-19.3-cinnamon-64bit.iso
map /CD/linuxmint-19.3-cinnamon-64bit.iso (0xff)
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=/CD/linuxmint-19.3-cinnamon-64bit.iso quiet splash --
initrd /casper/initrd.lz

Both entries got a successful boot without any issue.

So far it seems Linux Live ISOs capables to boot on MBR and/or UEFI, can be booted on UEFI environment just making very minor adaptations to the cheat code used on MBR.

alacran

Edited by alacran
Link to post
Share on other sites

In order to test the use of variables I made following entry on \EFI\grub\menu.lst

Quote

title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram
set iso_path=/CD/linuxmint-19.3-cinnamon-64bit.iso
find --set-root %iso_path%
map --mem %iso_path% (0xff)
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=%iso_path% quiet splash --
initrd /casper/initrd.lz

The linuxmint-19.3-cinnamon-64bit.iso Live CD booted flawlessly as expected, so this confirms it is also valid to use variables on the grub4dos for UEFI menu.lst, just same as the MBR version.

alacran

Edited by alacran
  • Like 1
Link to post
Share on other sites

What you should try is to add to the menu.lst entry a:
map --hook

Two possible results:
1) the entry fails because the "unknown" command creates a blocking error
2) the unknown command creates a warning and the entry works nonetheless

If this latter, you can use (minus the iftitle :unsure: ) the same entry on both normal grub4dos and on UEFI grub4dos.

jaclaz

Link to post
Share on other sites

A new test trying to Ramboot a VHD by means of grub4dos for UEFI:

This time I created on my HD a 10x64-WB.vhd, 800 MB VHD inicialized it as MBR, first primary partition is FAT-32 0C Active 64 MB, second partition is NTFS the rest of espace.  Then installed on Wimboot mode the Mini-10x64 on NTFS partition by means of wimlib-clc and created manually boot files and folders on Fat-32 partition, and edited both BCDs as on this post to test if it was capable to boot fine, I tested it Rambooting with grub4dos for MBR, and it booted very fine.

Then by means of WinImage I made a 10x64-WB.ima file from the VHD, and added following entries on EFI\grub\menu.lst to test if it can be loaded to Ram and check if it was possible to Ramboot it on UEFI:

Quote

title 10x64-WB.ima SVBus RAMDISK for UEFI boot from HD
find --set-root /VHD/10x64-WB.ima
map --mem /VHD/10x64-WB.ima (hd)
chainloader (hd-1)

title 10x64-WB.ima SVBus  RAMDISK for UEFI boot from HD
find --set-root /VHD/10x64-WB.ima
map --mem /VHD/10x64-WB.ima (hd)
chainloader (hd-1,0)

I got same result with both, the IMA file was loaded to Ram very fine, and it started booting as I was able to see the dots moving in circle, but it wasn't able to totally boot and a few time latter I got the BSOD:  INACCESSIBLE BOOT DEVICE

alacran

 

Edited by alacran
Typo
Link to post
Share on other sites
On 12/3/2020 at 3:45 AM, jaclaz said:

What you should try is to add to the menu.lst entry a:
map --hook

Two possible results:
1) the entry fails because the "unknown" command creates a blocking error
2) the unknown command creates a warning and the entry works nonetheless

If this latter, you can use (minus the iftitle :unsure: ) the same entry on both normal grub4dos and on UEFI grub4dos.

jaclaz

I'm able to MBR or UEFI boot, from internal HDs or USB device, MBR menu.lst is on the root of the disk and my UEFI menu.lst is on EFI\grub\menu.lst, as no entry on both menu.lst is shared between MBR and UEFI versions, there is no gain in doing what you suggest, also the developer/author very clearly stated which commands are not available on UEFI version, then it is better to use the right syntax on each case, and don' start trying to twist it.

By the way as I found on my very first test, the iftitle do not work on UEFI version, but forgot to comment it.

alacran

Link to post
Share on other sites
38 minutes ago, alacran said:

I'm able to MBR or UEFI boot, from internal HDs or USB device, MBR menu.lst is on the root of the disk and my UEFI menu.lst is on EFI\grub\menu.lst, as no entry on both menu.lst is shared between MBR and UEFI versions, there is no gain in doing what you suggest, also the developer/author very clearly stated which commands are not available on UEFI version, then it is better to use the right syntax on each case, and don' start trying to twist it.

By the way as I found on my very first test, the iftitle do not work on UEFI version, but forgot to comment it.

alacran

Sure, as if copy/paste was not a thing.

Besides, one could use n .lst files and have in menu.lst each entry ponting to a specific "other" .lst.

Example (BIOS /menu.lst):
 

title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram
find --set-root /CD/linuxmint-19.3-cinnamon-64bit.lst
configfile /CD/linuxmint-19.3-cinnamon-64bit.lst

Example (UEFI EFI/grub/menu.lst):
 

title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram
find --set-root /CD/linuxmint-19.3-cinnamon-64bit.lst
configfile /CD/linuxmint-19.3-cinnamon-64bit.lst

linuxmint-19.3-cinnamon-64bit.lst
 

title linuxmint-19.3-cinnamon-64bit.iso

set iso_path=/CD/linuxmint-19.3-cinnamon-64bit.iso
map (hd1,4)%iso_path% (0xff)
map --hook
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=%iso_path% quiet splash --
initrd /casper/initrd.lz

And of course this would be useful for my personal approach (COSMIAS, which noone else uses BTW) with "embedded" batch and self-mounting (JFYI):

http://reboot.pro/topic/17807-release-cosmias-a-new-approach-to-g4d-images/

 

 

38 minutes ago, alacran said:

By the way as I found on my very first test, the iftitle do not work on UEFI version, but forgot to comment it.

Yep.

jaclaz

Link to post
Share on other sites

Just to confirm if there could be something wrong during the creation of the IMA file from the VHD file on my previous post, I decided to test it Rambooting on the grub4dos MBR version, using following commands on my vhd.lst, (just to keep more order), which is called by the menu.lst on root of the partition/drive:

Quote

title 10x64-WB.ima.lz4 - from HD 144 MB - SVBus RAMDISK for MBR boot
find --set-root /VHD/10x64-WB.ima.lz4
map --top --mem /VHD/10x64-WB.ima.lz4 (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

title 10x64-WB.ima - from HD 800 MB - SVBus RAMDISK for MBR boot
find --set-root /VHD/10x64-WB.ima
map --top --mem /VHD/10x64-WB.ima (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

And it Rambooted very fine on MBR version,  this confirms nothing was wrong during making an IMA file from the VHD file.

Then the BSOD:  INACCESSIBLE BOOT DEVICE got when using UEFI version is related to something else, I guess the current intent on this third version of grub4dos for UEFI to find/locate on memory the IMA the second (NTFS) partition/drive by means of translating/relocating the SVBus driver info to info that can be valid/used on UEFI environment is not working fine yet.

@jaclaz

Hi my friend. As you can see I make use of several different *.lst files called by the MBR menu.lst, just didn't mentioned it (this way) on my previous post for simplicity,

I'm also aware the internal menu.lst of grub4dos for MBR can be modiffied very easy with BootIce if required to point to find the external main menu.lst on other location or to a renamed *.lst file.

But as I have readen, to do same thing on the UEFI version it has to be done on the source code, and recompile it.

Anyway IMHO we should respect the guidances from the author/developer about what commands are valid or not on this new version.

alacran

Edited by alacran
Link to post
Share on other sites

Just for testing pourposes, (as I do not see any practical use for it), I created a 900 MB VHD, inicialized it as MBR, single partition FAT-32 0C, and extracted there the content of my Win10XPE_x64.ISO (843 MB), only excluded the CDUsb.y file to let it find on internal HDs the partition where it is contained.

Made following entrie on \EFI\grub\menu.lst:

Quote

title Win10XPE_x64.vhd SVBus RAMDISK for UEFI boot from HD
find --set-root /VHD/Win10XPE_x64.vhd
map --mem /VHD/Win10XPE_x64.vhd (hd)
chainloader (hd-1)

The VHD was loaded to Ram very fine and it booted flawlessly, this confirms the grub4dos for UEFI is working very fine. Then my statement on previous post is valid:

Quote

I guess the current intent on this third version of grub4dos for UEFI to find/locate on memory the IMA second NTFS partition by means of translating/relocating the SVBus driver info to info that can be valid/used on UEFI environment is not working fine yet.

I can say only issues pending to solve are Rambooting VHDs when using SVBus driver, and load to RAM big size VHDs (2+ GB).

In fact I don't know which it the actual size limit to load on Ram some item, so far a 2.3 GB VHD or IMA file is not loaded, it reports not enought Ram, but I was able to load and boot from Ram linuxmint-19.3-cinnamon-64bit.iso which size is 1.89 GB, based on this I assume the limit is currently about 2 GB.

alacran

Link to post
Share on other sites

New version available:

Quote

This new version is capable to UEFI Ramboot my 800MB Wimboot Mini-10x64 as VHD or as IMA:

A big thanks to yaya, a1ve, and all other developers involved on this great achievement.

Quote

title 10x64-WB.vhd SVBus RAMDISK for UEFI boot from HD -1
find --set-root /VHD/10x64-WB.vhd
map --mem /VHD/10x64-WB.vhd (hd)
chainloader (hd-1)

title 10x64-WB.ima SVBus  RAMDISK for UEFI boot from HD -2
find --set-root /VHD/10x64-WB.ima
map --mem /VHD/10x64-WB.ima (hd)
chainloader (hd-1)

But the 2.3 GB Mini-10x64 Compact mode installed did not boot as VHD or as IMA file:

Quote

title 10x64-UEFI.vhd SVBus RAMDISK for UEFI boot from HD
find --set-root /VHD/10x64-UEFI.vhd
map --mem /VHD/10x64-UEFI.vhd (hd)
chainloader (hd-1)

title 10x64-UEFI.ima SVBus RAMDISK for UEFI boot from HD
find --set-root /VHD/10x64-UEFI.ima
map --mem /VHD/10x64-UEFI.ima (hd)
chainloader (hd-1)

Message is still the same:

(hd0,1)
Out of memory
boot_image_handle not found

Press any key to continue....

NOTE: Both, the 800 MB Wimboot and the 2.3 GB Compact mode, where installed on NTFS second partition, and boot files/folders are on first 64 MB FAT-32 0C partition (active to also be MBR bootable) of the (MBR inicialized) VHD or IMA. See pictures of sample BCDs attached on this post.

From my previous post:

Quote

In fact I don't know which it the actual size limit to load on Ram some item, so far a 2.3 GB VHD or IMA file is not loaded, it reports not enought Ram, but I was able to load and boot from Ram linuxmint-19.3-cinnamon-64bit.iso which size is 1.89 GB, based on this I assume the limit is currently about 2 GB.

Then only issue remaining is:
Load to RAM VHD or IMA files bigger than 2 GB.

alacran

Edited by alacran
Link to post
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...