12 replies to this topic

[nando4]

Wondering if the syslinux could be extended to allow direct mapping a floppy image for read/write? The only other bootloaders that can do that are grub4dos and burg4dos. grub4dos can't read GPT partitions and burg4dos is a large package. I require this facility to chainload into a DOS floppy image from bootmgr, save some configuration items to the floppy image then chainload out to Win7 using grub4dos (BIOS boot) or TianoCore's UEFI-DUET (uefi-x64).

[Icecube]

What do you need to save on the floppy? Is it used by Windows 7 in a later state?

[nando4]

What do you need to save on the floppy? Is it used by Windows 7 in a later state?

I'm booting DIY eGPU Setup 1.x (a floppy image), performing some PCI fixups then chainloading to Win7. Some configuration items are saved to the user doesn't have to manually do them on every boot. I've previously used grub4dos to chainload into the image then chainload out from the image which works great with BIOS boot.

Problem is grub4dos can't locate my image if it's on a GPT partition as used on a UEFI configuration. Syslinux supposely supports GPT partitions but not direct mapping. ARRHHH!! Can we integrate the features? I can then chainload out to Win7 on a GPT partition by using TianoCore's DUET-UEFI.

[Icecube]

Direct mapping requires to run MEMDISK as a COM32 module, so it can read files from the filesystem (MEMDISK doesn't read any file atm. This is done by the bootloader that boots MEMDISK)
When Syslinux v5.xx is ready, multiple COM32 modules can run at the same time, which will make a reliable memdisk.c32 module, possible.

[nando4]

Direct mapping requires to run MEMDISK as a COM32 module, so it can read files from the filesystem (MEMDISK doesn't read any file atm. This is done by the bootloader that boots MEMDISK)
When Syslinux v5.xx is ready, multiple COM32 modules can run at the same time, which will make a reliable memdisk.c32 module, possible.

Thank you for the reply. Are you implying that syslinux' MEMDISK can do direct image read/write as a COM32 module now? If so, can you advise how I'd configure it to do so? I am familiar with chainloading grub4dos from Win7's bootmgr so would in effect be replacing the following with syslinux to give me GPT partition support and direct mapping of my floppy image:

:: Load disk image as floppy disk (fd0)

:: This file must be in root directory!!

 

# debug 0 is quiet operation

debug 0

timeout 0

 

# Set location of image file

set IMG=/eGPU/eGPU-Setup-10f.img

 

# Set root to be found location of image file

# The image can be found on *any* partition

find --set-root %IMG%

 

# Map image file as writable floppy drive (fd0)

map %IMG% (fd0)

map --hook

root (fd0)

chainloader (fd0)+1

rootnoverify

[Wonko the Sane]

Seemingly this doesn't imply much :

When Syslinux v5.xx is ready, multiple COM32 modules can run at the same time, which will make a reliable memdisk.c32 module, possible.

maybe it could be better worded as:

When Syslinux v5.xx will be ready, multiple COM32 modules will be able to run at the same time, which will make a reliable memdisk.c32 module, possible.
So, after the release of Syslinux 5 hoepefully someone will write a modified memdisk that will be able to map directly an image.

Everything is - at the moment of this writing - in the future tense.


Wonko

[Sha0]

I'm booting DIY eGPU Setup 1.x (a floppy image), performing some PCI fixups then chainloading to Win7. Some configuration items are saved to the user doesn't have to manually do them on every boot. I've previously used grub4dos to chainload into the image then chainload out from the image which works great with BIOS boot.

Problem is grub4dos can't locate my image if it's on a GPT partition as used on a UEFI configuration. Syslinux supposely supports GPT partitions but not direct mapping. ARRHHH!! Can we integrate the features? I can then chainload out to Win7 on a GPT partition by using TianoCore's DUET-UEFI.

It appears that you are wanting: ... -> BOOTMGR -> XXX -> floppy image (DIY eGPU Setup 1.x -> YYY) -> BOOTMGR -> Windows. Is that right? If so, does the floppy image need to be modified multiple times or can it remain static? If it can remain static, you can make use of MEMDISK. If you are wanting that the user should be able to save options at every boot and have them available on the next boot, then this requires something other than MEMDISK.

A work-around might be to install an INT 0x13 hook which hooks accesses to the MBR and spoofs an MBR which actually maps a single partition to the actual GPT partition.

Mapping a virtual disk to a file within a filesystem is not the simplest thing. Files in filesystems can be non-contiguous, for example. They could be unaligned relative to disk sectors, too. Files can be compressed or encrypted. In order to offer write support for such a virtual disk, not only does a hook have to be able to translate from the filesystem, but it also has to be able to translate back to the filesystem (albeit a file occupying a contiguous range of sectors is the simplest case and doesn't really require any "back to" translation).

Perhaps you could "port" your floppy image to an HDD partition (is it DOS?). Then you could have that partition as a GPT partition, but also have an MBR handy for being able to spoof a non-GPT disk, if required.

[nando4]

It appears that you are wanting: ... -> BOOTMGR -> XXX -> floppy image (DIY eGPU Setup 1.x -> YYY) -> BOOTMGR -> Windows. Is that right? If so, does the floppy image need to be modified multiple times or can it remain static? If it can remain static, you can make use of MEMDISK. If you are wanting that the user should be able to save options at every boot and have them available on the next boot, then this requires something other than MEMDISK.

That is the loading sequence I require and yes, I do need to save some data to the disk image at least during the initial install. One not so convenient option I do have is for the user to do the initial configuration using a USB stick, copy the configuration across to the disk image and then use syslinux+memdisk to boot. Though if I want to keep my installation instructions simple I'd just say "if you are running UEFI with GPT partitions then do a USB install rather than disk image".

A work-around might be to install an INT 0x13 hook which hooks accesses to the MBR and spoofs an MBR which actually maps a single partition to the actual GPT partition.

Mapping a virtual disk to a file within a filesystem is not the simplest thing. Files in filesystems can be non-contiguous, for example. They could be unaligned relative to disk sectors, too. Files can be compressed or encrypted. In order to offer write support for such a virtual disk, not only does a hook have to be able to translate from the filesystem, but it also has to be able to translate back to the filesystem (albeit a file occupying a contiguous range of sectors is the simplest case and doesn't really require any "back to" translation).

You highlight exactly what the grub4dos documentation says about direct mapping - the disk image cannot reside on a compressed disk AND must be contiguous. My target users are aware of that. grub4dos directly maps and boots the disk image perfectly with BIOS-MBR boot. Only dilemma is is grub4dos can't 'find' my disk image to boot from it if it's on a GPT partition as used by UEFI.

Perhaps you could "port" your floppy image to an HDD partition (is it DOS?). Then you could have that partition as a GPT partition, but also have an MBR handy for being able to spoof a non-GPT disk, if required.

By that I figure you mean create a GPT HDD partition rather than a image? In which case the user would need to shrink their existing partitions to make room, create the new partition, copy the files over. Yes, that would do it but it's a LOT of work. Hence the reason for wanting syslinux or grub4dos to chainload myy disk image that sits on an existing partition instead.

[Sha0]

By that I figure you mean create a GPT HDD partition rather than a image? In which case the user would need to shrink their existing partitions to make room, create the new partition, copy the files over. Yes, that would do it but it's a LOT of work. Hence the reason for wanting syslinux or grub4dos to chainload myy disk image that sits on an existing partition instead.

It can even be an image file of an HDD partition. The key is: If you can guarantee that it is contiguous, then you can produce an MBR which has a partition entry which points to the range of sectors that the image file occupies. My ntfstest.exe program will dump sector info for a file, for example. Then you can hand-craft an MBR (or a tool can produce one) which has a partition entry for this range of sectors.

Then the next hundred-thousand kilometres is to use that MBR. Perhaps you could trick GRUB4DOS into using it, or perhaps it could be a so-called "hybrid" MBR which could work in union with the GPT, supporting MBR-aware-only programs like GRUB4DOS. You might look into gdisk for producing hybrid MBRs.

A great example of a product which used the "spoof a partition in the MBR that actually points to a contiguous image file" strategy was Symantec Ghost.

[nando4]

It can even be an image file of an HDD partition. The key is: If you can guarantee that it is contiguous, then you can produce an MBR which has a partition entry which points to the range of sectors that the image file occupies. My ntfstest.exe program will dump sector info for a file, for example. Then you can hand-craft an MBR (or a tool can produce one) which has a partition entry for this range of sectors.

I like the idea about getting the MBR from the harddisk image and this is certainly a step in the right direction. It would not be difficult for me to do a HDD image install instead. However, unless the bootmgr/ntldr/grub2 bootloaders can use that MBR file then I'm back to the problem I began with.. grub4dos can be chainloaded by these bootloaders but it can't find or query GPT partitions meaning it can't read that MBR file to be able to boot from it. Can syslinux boot a modified MBR file?

Is there any utility that I can point to my HDD image and it can generate such a MBR file?

[Sha0]

Can syslinux boot a modified MBR file?

Syslinux can, but the trick is that anything that reads the MBR will find the "bad" one. An INT 0x13 hook could deal with this, as mentioned... Both MEMDISK as well as chain.c32 provide INT 0x13 hooks, so maybe one of them could be adapted for this purpose. Some kind of "GPT MBR helper" utility.

Is there any utility that I can point to my HDD image and it can generate such a MBR file?

Not that I know of, but it would be trivial to produce one. NTFSTEST.EXE will give the sector range of a file on an NTFS partition. What filesystem did you want to contain this image file, anyway?

[nando4]

Not that I know of, but it would be trivial to produce one. NTFSTEST.EXE will give the sector range of a file on an NTFS partition. What filesystem did you want to contain this image file, anyway?

Prior to encountering GPT/UEFI wall. I was storing the file image on a NTFS filesystem which worked perfectly with BIOS-MBR boot. I ran MS 'contig' over the image to ensure it was contiguous. This is what most of the users who'd need the software would be doing. A GPT MBR helper would be great. Is it something that can be requested as an enhancement to syslinux?

[Sha0]

Prior to encountering GPT/UEFI wall. I was storing the file image on a NTFS filesystem which worked perfectly with BIOS-MBR boot. I ran MS 'contig' over the image to ensure it was contiguous. This is what most of the users who'd need the software would be doing. A GPT MBR helper would be great. Is it something that can be requested as an enhancement to syslinux?

As a matter of fact, yes. It would be great if you e-mailed the mailing-list with your request and use case. If such an e-mail doesn't get through today, it might mean that unfortunately, you'd have to try again later. There might be maintenance happening right now.