Jump to content











Photo
- - - - -

Linux from VHD How To?

linux windows boot vhd image-file howto

  • Please log in to reply
67 replies to this topic

#51 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted A week ago

 

This is similar to what is in the hubiC download...

And actually IDENTICAL to the one ALREADY posted by tritant and re-posted here:
http://reboot.pro/to...e-2#entry201566

with explanation of the commands in RED.

 

BUT later there is seemingly an issue with NTFS 3G (as tritant posted).

 

And AGAIN, there is not one need in the world to use the UUID syntax (if it is actually making things more complex), since there is seemingly no issue with using a "plain" root= volume (and this can be derived in Linux syntax from the grub4dos one by the given oneliner):
http://reboot.pro/to...b4dos/?p=200832



calc *0x82a0-31 | call Fn.2 | set LXVOLID=sd &;  calc *0x829e&255+1 > nul &; set LXVOLID=%LXVOLID%%@retval%

:duff:

Wonko



#52 steve6375

steve6375

    Platinum Member

  • Developer
  • 6351 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted A week ago

Doesn't that code assume that grub4dos (the BIOS) detects the same devices that are detected by linux and in the same order?

What about special SATA/RAID controllers that are attached to disks that are not enumerated by the BIOS? Other \dev\sd devices?

The BIOS could be set up to boot from SATA disk #3 as the HDD boot device (BIOS hd1 when you boot to grub4dos) but is this enumerated by linux as sda or sdd?

Using UUID overcomes these issues and so should be safer if it is in the correct format?



#53 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted A week ago

Doesn't that code assume that grub4dos (the BIOS) detects the same devices that are detected by linux and in the same order?

What about special SATA/RAID controllers that are attached to disks that are not enumerated by the BIOS? Other \dev\sd devices?

The BIOS could be set up to boot from SATA disk #3 as the HDD boot device (BIOS hd1 when you boot to grub4dos) but is this enumerated by linux as sda or sdd?

Using UUID overcomes these issues and so should be safer if it is in the correct format?

Sure :).

 

But if it works it works.

 

Hint: right now the "plain" root= works fine with "plain" devices.

Viceversa the UUID syntax reportedly creates (later) an issue.

 

It's years that grub (and grub4dos and GRUB2) use BIOS to have device/volume names that can be passed to the linux kernel, besides the different way the devices are numbered they tend to follow the same BIOS order, of course there may be cases when this doesn't happen, but they don't represent but a restricted number of situations. 

 

 

We have a new user (virgus) that is trying to reproduce some experiments and that needs to learn the basics about grub4dos (and probably about Linux also).

 

When (if) he will be more familiar with grub4dos (and Linux) and when he will succeed with the "plain" syntax on "plain" devices and when (if) he will fail with the "plain" syntax on "non-plain" devices, then the UUID syntax will be *needed*, while until then it is only some overengineering that will IMHO only confuse the poor guy.

 

Step by step:

1) provide manually the appropriate /dev/sdxy, manually translating the grub4dos (hdm,n) naming

2) automate the above

3) if this works, it works

4) if this doesn't work, it doesn't work and more sophisticated methods can be used [1]

 

:duff:

Wonko

 

[1] BTW if you re-read the thread, the UUID syntax does already work fine, but most probably, judging from tritant's report, there is the need to change something in the init (or *whatever*) the Linux runs at boot that mounts the "external" NTFS volume via NTFS3G (and this will depend on the specific Linux distro, etc. , etc.) 

User wean_irdeh already reported success with it (but using another distro), after I (already) suggested how the UUID syntax would be more "universal":

http://reboot.pro/to...e-2#entry200256



#54 steve6375

steve6375

    Platinum Member

  • Developer
  • 6351 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted A week ago

It seems we have to use /dev/sdxy format!

title UBT-small.vhd
find --set-root --ignore-floppies --ignore-cd  /ubuntu/UBT-small.vhd
# debug must not be off for the LXVOLID code to work
debug 1
calc *0x82a0-31 | call Fn.2 | set LXVOLID=sd &;  calc *0x829e&255+1 > nul &; set LXVOLID=%LXVOLID%%@retval%
echo
echo LXVOLID=%LXVOLID%
echo
pause --wait=3
kernel /ubuntu/vmlinuz  root=/dev/%LXVOLID% kloop=/ubuntu/UBT-small.vhd  kroot=/dev/mapper/loop0p1 vga=792
initrd /ubuntu/initrd.img

Edit: Note that LXVOLID does not return the correct value in this example!


Edited by steve6375, A week ago.


#55 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted A week ago

 

It seems we have to use /dev/sdxy format!



title UBT-small.vhd
find --set-root --ignore-floppies --ignore-cd  /ubuntu/UBT-small.vhd
# debug must not be off for the LXVOLID code to work
debug 1
calc *0x82a0-31 | call Fn.2 | set LXVOLID=sd &;  calc *0x829e&255+1 > nul &; set LXVOLID=%LXVOLID%%@retval%
echo
echo LXVOLID=%LXVOLID%
echo
pause --wait=3
kernel /ubuntu/vmlinuz  root=/dev/%LXVOLID% kloop=/ubuntu/UBT-small.vhd  kroot=/dev/mapper/loop0p1 vga=792
initrd /ubuntu/initrd.img

... and you just made virgus' homework. :whistling:

 

:duff:

Wonko



#56 steve6375

steve6375

    Platinum Member

  • Developer
  • 6351 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted A week ago

Except the LXVOLID code does not seem to work...

It works in my VBOX VM and returns sda1 which is correct, however on a single disk laptop it returns sda1 also which is incorrect as the USB drive should be sdb1?



#57 steve6375

steve6375

    Platinum Member

  • Developer
  • 6351 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted A week ago

What we need is the number of disks in the system and then the USB drive will be the last one (assuming no other USB drive is connected).

e.g.  if 2 internal disks + USB drive = 3 drives - so under linux the USB drive will be sdc.



#58 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted A week ago

Except the LXVOLID code does not seem to work...

It works in my VBOX VM and returns sda1 which is correct, however on a single disk laptop it returns sda1 also which is incorrect as the USB drive should be sdb1?

It simply translates the grub4dos device, so - unless there is an issue with the single line translation - it might be a case of GIGO.

 

In any case discussion about it (working not working, betterings, etc;) should be taken to here:
http://reboot.pro/to...ts-in-grub4dos/

 

Would you mind doing that (and stopping hijacking this thread)?

 

Of course feel free to continue here :).

 

:duff:

Wonko



#59 steve6375

steve6375

    Platinum Member

  • Developer
  • 6351 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted A week ago

OK, but the OP should bear in mind that the code you recommended as a solution does not work (which I thought was relevant to this thread?).



#60 virgus

virgus

    Newbie

  • Members
  • 11 posts
  •  
    Italy

Posted A week ago

Wonko, Steve, thanks to both of you so much!

 

Just one thing about repositories:

I couldn't download anything bigger than 20Mb from Baidu (...but not because of my 100Mbit connection), so I managed to create an account (god bless google translator from chinese!) and then assigned to my account the contents of the repositories of the smart and nice chinese guys that shared the UBT-small.vhd on Baidu cloud. I did this despite of the fact that the download was almost impossible from my internet provider.

 

The reason was simply that I found an online service tool (which I greatly recommend to all of you) which makes possible to sync Baidu and hubic, and most of the others cloud services around: www.multcloud.com

It took two nights to get all the data onto hubic storage because I had to do it in two steps (baidu free space is 5GB).

 

Yesterday I moved from hubic to Mega mostly because hubic allows sharing for 30 days max; so on Mega I won't have the need to change the shared links every month in my previous post ;-)

 

 

... and you just made virgus' homework. :whistling:

 

LOL! Yes, somehow you both cleared many things at once, but I feel in the next few days I'll still have a lot to learn from your replies (time for bed now...) :-) Hope to have some time to test your entries by the end of the week.

 

Talk to you soon and have a great day!

V.


Edited by virgus, A week ago.


#61 steve6375

steve6375

    Platinum Member

  • Developer
  • 6351 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted A week ago

This .mnu file seems to work for E2B.

Note that it assumes that linux will list the E2B USB drive as the last sd device.

If there is more than one USB drive or SD card reader or other storage device connected, linux may not list the E2B drive as the last sd device

 

e.g. linux drives

sda = SATA 0

sdb = SATA 1

sdc = USB port 0 -  if E2B USB drive is in this port, the code below will not work (it will use sdd)!

sdd = USB port 1

# http://reboot.pro/topic/20603-linux-from-vhd-how-to/
# https://hubic.com/home/pub/?ruid=aHR0cHM6Ly9sYjEwNDAuaHViaWMub3ZoLm5ldC92MS9BVVRIXzdlNGMzOGI0YmNmMjgyMDc2OGM3NDlhYTcyODFkODM1L2RlZmF1bHQvLm92aFB1Yi8xNDgyNDIzOTk4XzE0ODUwMTU5OTg/dGVtcF91cmxfc2lnPWYzOTdkZWRlMTJhOTQ3ZjQwOGU3ZWFkZGM0ZmJjMWRhYWYwMWJkNjQmdGVtcF91cmxfZXhwaXJlcz0xNDg1MDE1OTk4#/UBT-small
# make \ubuntu folder on E2B drive
# copy initrd.img, UBT-small.vhd and vmlinuz to \ubuntu folder
# copy this file to \_ISO\LINUX\MNU folder
title UBT-small.vhd\n Boot to linux VHD
set ISO=/ubuntu/UBT-small.vhd
set LXVOLID=
debug 1 ;; rootnoverify (hd-1) > nul ;; calc *0x82a0-31 | call Fn.2 | set LXVOLID=sd
find --set-root %ISO% > nul ;; calc *0x829e&255+1 > nul &; set LXVOLID=%LXVOLID%%@retval%
echo
echo Please check - E2B USB drive is detected as %LXVOLID%
echo Press ENTER if OK...
pause --wait=30
kernel /ubuntu/vmlinuz  root=/dev/%LXVOLID% kloop=%ISO%  kroot=/dev/mapper/loop0p1 vga=792
# add vga=792 for 1024 x 768 display if needed or use vga=ask
initrd /ubuntu/initrd.img


#62 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted A week ago

OK, but the OP should bear in mind that the code you recommended as a solution does not work (which I thought was relevant to this thread?).

That's not exact.

The code "I recommended" does work fine on "standard" hard disks (and again its scope is only to "translate" the device name), you introduced the booting from USB variant, and that one needs to "shift" disks, not really news in itself, hence the:

rootnoverify (hd-1)

to get last disk.

 

(which is however only a partial solution)

 

When virgus will be up-to-date with the thread, we will get back to the UUID approach.

 

As said before, each Linux distro may have a slightly different approach to manage the accessing/mounting of the NTFS volume hosting the .vhd (provided that it is a NTFS volume) and thus each and every Linux distro image may need a modified init (or *whatever*) to accept the UUID parameter and/or some other modification and/or even installing the whole stuff as wean_irdeh demonstrated.

 

:duff:
Wonko



#63 steve6375

steve6375

    Platinum Member

  • Developer
  • 6351 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted A week ago

For this particular version, it runs ntfs-3g and passes whatever the root= parameter value is straight to it.

 

ntfs-3g only seems to accept \dev\xxx format (???). If you use root=UUID=abcd then 'ntfs-3g UUID=abcd' is called which it does not understand as a valid device.

 

So the script would need to be changed so that if the user specifies  UUID or LABEL then it converts it to /dev/xxx before calling ntfs-3g.

 

Because of the difference in linux and BIOS device enumeration, most (all?) of my E2B menus use UUID where possible.

 

E2B sets debug 0 (to reduce messages) before running any .mnu file, and the OP said he was using E2B so debug 1 is required for him.



#64 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted A week ago

For this particular version, it runs ntfs-3g and passes whatever the root= parameter value is straight to it.

 

ntfs-3g only seems to accept \dev\xxx format (???). If you use root=UUID=abcd then 'ntfs-3g UUID=abcd' is called which it does not understand as a valid device.

 

So the script would need to be changed so that if the user specifies  UUID or LABEL then it converts it to /dev/xxx before calling ntfs-3g.

Sure :), this is EXACTLY what tritant reported and that started it all:

http://reboot.pro/to...ow-to/?p=201219

 

The base 10 points remain:

1) knowledgeable Linux users most probably know how to use kloop, losetup, etc. AND they also know for the distro they use how to modify the init (or *whatever*) if needed

2) wean_irdeh provided an example on how to modify initial loading files so that UUID works fine, but those apply to Arch Linux (and not necessarily to any other distro)

3) a different distro might (will) require different changes

4) to avoid these changes (at least on some distro's) a Linux /dev/ ID needs to be passed to the kernel root= parameter

5) for a specific "install" or "instance" it doesn't take more than what? two minutes to boot a Linux (*any* Linux) and check which /dev/ Linux sees (and edit the menu.lst entry with such a "hardcoded" device ID)

6) otherwise (for a non-USB setup) an "automatic" grub4dos device ID to Linux device ID "translator" has been presented that may work

7) now there is also a modified translator (valid for USB booting only) that may work

8) Both #6 and #7 are far from being "foolproof" or "universal"

9) the "right" way is to use a UUID (Universal Unique ID)

10) in order to use a UUID some changes may (or may not) be needed inside the actual Linux distro (depending on the specific distro). Loop to #1

 

:duff:

Wonko


  • ZEE likes this

#65 wean_irdeh

wean_irdeh

    Newbie

  • Members
  • 16 posts
  •  
    Vietnam

Posted A week ago

 

Sure :), this is EXACTLY what tritant reported and that started it all:
http://reboot.pro/to...ow-to/?p=201219
 
The base 10 points remain:
1) knowledgeable Linux users most probably know how to use kloop, losetup, etc. AND they also know for the distro they use how to modify the init (or *whatever*) if needed
2) wean_irdeh provided an example on how to modify initial loading files so that UUID works fine, but those apply to Arch Linux (and not necessarily to any other distro)
3) a different distro might (will) require different changes
4) to avoid these changes (at least on some distro's) a Linux /dev/ ID needs to be passed to the kernel root= parameter
5) for a specific "install" or "instance" it doesn't take more than what? two minutes to boot a Linux (*any* Linux) and check which /dev/ Linux sees (and edit the menu.lst entry with such a "hardcoded" device ID)
6) otherwise (for a non-USB setup) an "automatic" grub4dos device ID to Linux device ID "translator" has been presented that may work
7) now there is also a modified translator (valid for USB booting only) that may work
8) Both #6 and #7 are far from being "foolproof" or "universal"
9) the "right" way is to use a UUID (Universal Unique ID)
10) in order to use a UUID some changes may (or may not) be needed inside the actual Linux distro (depending on the specific distro). Loop to #1
 
:duff:
Wonko

 

Hey, i actually have moved from arch linux a long ago due to issues in the arch linux devs when it comes to security issues, you can read more in igurublog.wordpress.com, or if you are too lazy, the main point is the developer don't take the absence of package signing as an issue, also they stated arch linux distro is not meant as everyday distro (and the AUR is a wildwest repo)

So I moved into debian testing, but my setup is more complicated.
I'm using UEFI, grub2, and an encrypted partition (not boot) inside a vhd. I never encounter any issues when using losetup and ntfs-3g with the setup and arch linux, but for whatever reason systemd act strangely on debian compared to arch linux so that I have to use qemu-nbd instead of losetup to mount vhd for the setup.

Right now I just bundled these binary (qemu-nbd, blkid, ntfs-3g) whenever I want to boot to debian testing, but it shouldn't be too hard if I write the script so everything can be automated, I'll try when I have spare time. The script should be compatible to initramfs-tools user, specifically debian and debian derivatives (including ubuntu and linux mint)

#66 alanyih

alanyih
  • Members
  • 1 posts
  •  
    Taiwan

Posted 12 hours ago


9) the "right" way is to use a UUID (Universal Unique ID)

10) in order to use a UUID some changes may (or may not) be needed inside the actual Linux distro (depending on the specific distro). Loop to #1

 

 

Ref:

http://bbs.wuyou.net...079&pid=3330148

 

    menuentry " UBT-small.vhd " --class  ubuntu {
            insmod gzio
            insmod part_msdos
            insmod part_gpt
            insmod ext2
            insmod ntfs
            insmod probe
            set vhdfile="/ubt/UBT-small.vhd"
            set root=(hd0,1)
            search --no-floppy -f --set=aabbcc  $vhdfile
            set root=${aabbcc}
            probe -u --set=ddeeff ${aabbcc}
            loopback loop0 $vhdfile
            linux        (loop0,1)/vmlinuz root=UUID=${ddeeff} rw  kloop=$vhdfile  kroot=/dev/mapper/loop0p1
            initrd        (loop0,1)/initrd.img
    }

 

 



#67 ndog37

ndog37

    Member

  • Members
  • 64 posts
  •  
    New Zealand

Posted 6 hours ago

 

Didn't work for me under grub2, uefi, gpt disk

 

ntfs-3g: Failed to access volume 'UUID=DA18F33818F3126D' : No such file or directory

 

cat /proc/cmdline

BOOT_IMAGE=(loop0,1)/vmlinuz root=UUID=DA18F33818F3126D rw kloop=/ubt/UBT-small.vhd kroot=/dev/mapper/loop0p1

 

What is the ntfs-3g command it is trying to run? I would like to try it manually.


Edited by ndog37, 6 hours ago.


#68 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 hours ago

The issue is with the command line of ntfs-3g.

 

As ALREADY said, the ntfs.3g seemingly accepts only a "/dev/sd*something*", user tritant here:
http://reboot.pro/to...ow-to/?p=201237

 

cleverly replaced that with '`blkid -U <uuid>`

sudo mount -t ntfs-3g `blkid -U 6054DA9E54DA766E` /host

 

 

:duff:

Wonko







Also tagged with one or more of these keywords: linux, windows, boot, vhd, image-file, howto

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users