Grub4dos mapped disk (vhd) isn't detected by Debian based distro (antiX 15)

Suppose there are two hard drives

/dev/sda (hd0)
/dev/sdb (hd1)

(hd0) is where my vhd resides (hd0,0)/ada.vhd

 

(hd1) is where the linux iso resides (hd1,0)/linux.iso

 

Here is the grub4dos script:

#### Map the vhd as the first harddrive
find --set-root /linux.iso
map --heads=0 --sectors-per-track=0 /linux.iso (0xFF)
map --hook
root (0xFF)
kernel /antiX/vmlinuz vga=791 from=hd,usb,cd fromiso=/linux.iso en xres=800x600
initrd /antiX/initrd.gz
map (hd0,0)/ada.vhd (hd0)
map --rehook
boot

#### Map the vhd as the last harddrive
find --set-root /linux.iso
map --heads=0 --sectors-per-track=0 /linux.iso (0xFF)
map --hook
root (0xFF)
kernel /antiX/vmlinuz vga=791 from=hd,usb,cd fromiso=/linux.iso en xres=800x600
initrd /antiX/initrd.gz
map (hd0,0)/ada.vhd (hd-1)
map --rehook
boot

I have successfully boot to the linux iso, but the vhd is remain undetected.

 

Does anyone know the solution?

 

 

homepage: http://antix.mepis.org/

I don't know why I can't edit the post, so I post here

 

antiX 15 is based from Debian Jessie (stable)

Well, it's normal.

 

The grub4dos mapping lasts until the "real mode" (or BIOS if you prefer) pases control to "protected mode" (or to the OS if you prefer).

When you map the .iso you are passing to the Linux kernel a number of parameters, among which :
fromiso=/linux.iso

which is telling it to mount the .iso calle linux.iso in root.

 

Nothing is passed to the Linux about the ada.vhd.

 

Start again from here:
http://reboot.pro/to...rom-vhd-how-to/

you need to modify the Linux initrd adding commands to mount the image automatically or mount it manually once the Linux has booted.

 

Each distro may have (or may not have) some different method/tool suitable, like kpartx, losetup or mdadm, essentially you want to have at boot time a loopback device mapping the image (actually the partition(s) inside it) to a /dev/mapper/loopx device, a couple of examples (Debian based distro):
http://www.opopop.ne...op_file_system/

https://felixc.at/ArchLinux-loopback

BUT each distro and even each version of a same distro may have different ways/tools to (hopefully) achive that.

 

Remember that the .vhd must be of the "fixed" type (which is nothing but a RAW image with a single sector appended to it) unless you use some particular tool to interpret it, which could be libvhdio, or virtualbox-fuse, etc.

 

Grub4dos ONLY supports "fixed" type .vhd's though recent version allow "dynamic" ones BUT ONLY if --mem mapped (loaded in RAM), in your case - however - you are booting from the .iso so you don't need any mapping in grub4dos.

 

Wonko

Well, it's normal.

 

The grub4dos mapping lasts until the "real mode" (or BIOS if you prefer) pases control to "protected mode" (or to the OS if you prefer).

When you map the .iso you are passing to the Linux kernel a number of parameters, among which :
fromiso=/linux.iso

which is telling it to mount the .iso calle linux.iso in root.

 

Nothing is passed to the Linux about the ada.vhd.

 

Start again from here:
http://reboot.pro/to...rom-vhd-how-to/

you need to modify the Linux initrd adding commands to mount the image automatically or mount it manually once the Linux has booted.

 

Each distro may have (or may not have) some different method/tool suitable, like kpartx, losetup or mdadm, essentially you want to have at boot time a loopback device mapping the image (actually the partition(s) inside it) to a /dev/mapper/loopx device, a couple of examples (Debian based distro):
http://www.opopop.ne...op_file_system/

https://felixc.at/ArchLinux-loopback

BUT each distro and even each version of a same distro may have different ways/tools to (hopefully) achive that.

 

Remember that the .vhd must be of the "fixed" type (which is nothing but a RAW image with a single sector appended to it) unless you use some particular tool to interpret it, which could be libvhdio, or virtualbox-fuse, etc.

 

Grub4dos ONLY supports "fixed" type .vhd's though recent version allow "dynamic" ones BUT ONLY if --mem mapped (loaded in RAM), in your case - however - you are booting from the .iso so you don't need any mapping in grub4dos.

 

Wonko

 

Wonko, do you have any idea how we can mount a G4D mem mapped drive? kinda like how winvblock does? Concept::

-G4D Alloc an empty mem map drive of a specific size

-Boot linux

-mkfs.ntfs

-kexec back into G4D, or bootmgr

-Load up windows and use NTFS mem mapped disk.

Wonko, do you have any idea how we can mount a G4D mem mapped drive? kinda like how winvblock does? Concept::
-G4D Alloc an empty mem map drive of a specific size
-Boot linux
-mkfs.ntfs
-kexec back into G4D, or bootmgr
-Load up windows and use NTFS mem mapped disk.

There is a thread dedicated to this, where the OP (and some other good Linux guys) have made available a couple solutions to mount a RAW image (or "fixed" VHD) in Linux at boot that should be a good base for what you want to do:
http://reboot.pro/to...rom-vhd-how-to/
I don't think that under Linux it will be "impossible" to map a given extent in memory to a disk or volume, but no real idea, the switch back to grub4dos would mean to re-map in grub4dos the same extent to a mem disk and then use anyway Winvblock or similar in order to boot windows.


Wonko

Well my thought on the matter was to for example:

-Boot to G4D

-load up a small linux image

-Extract a 7z of an entire PE

-kexec into that PE

Edited by Biatu, 06 March 2017 - 08:39 AM.

Hmmm.
Isn't (or cannot be) a .wim file "compact enough"?
I mean how much space (please read as time, as you need to boot to the Linux and uncompress it) do you save by using a 7z archive?
And if it is a "huge" PE, you can still have a tiny boot.wim and them mount contents from another image.
Maybe you have some valid reasons to make this but I am completely failing to see an advantage.
Can you detail what "more" would you expect from such a setup?


Wonko

Well, as a good example LZMA and LZMA are much better than LZX, trying to squeeze every byte I can into an image. and having a stripped down linux kernel to do some preprocessing would open up a lot of possibilities imo. For example, you could use a linux kernel with an embedded initrd that contains some scripts to do a load of things before going into the PE, or even a stripped down non-PE windows. select features/drivers you wish to load prior to OS bootup, modify registry, etc.

I still don't see all these advantages, but surely you have your reasons to follow this route.

It somehow reminds me of the good ol' gnome plan :
http://knowyourmeme.com/memes/profit
1) make a linux based pre-boot environment
2) modify on the fly a Windows based pre-installation environment and switch to it
3) ????
4) profit!


Wonko