why grub4dos reports 2 blocks at the blocklist /whatever.vhd command
while wincontig or defraggler see just 1 block ?
on hard disk partition, no usb stick
dynamic 10g vhd, only some 5g on disk
grub4dos 0.4.6a
win10 x64
Posted 10 June 2016 - 09:07 AM
why grub4dos reports 2 blocks at the blocklist /whatever.vhd command
while wincontig or defraggler see just 1 block ?
on hard disk partition, no usb stick
dynamic 10g vhd, only some 5g on disk
grub4dos 0.4.6a
win10 x64
Posted 10 June 2016 - 11:04 AM
What you report is EXTREMELY "queer".
Try running the blocklist command in grub4dos and post the result.
Then try running getfileextents:
http://www.msfn.org/...comment=1011369
and/or myfragmenter:
http://www.msfn.org/...comment=1017553
and post results.
The real issue you are facing is probably that you cannot mount/access the VHD from grub4dos, this is "normal", namely the reason is connected with the "dynamic" nature of the vhd.
I.e. it is likely that what grub4dos "sees" is incorrect because of the (not suitable) image format.
Are you getting an error 60 in grub4dos when mapping?
Or an error 17 when accessing the mounted image?
Though it is written all over the place, I will re-state how grub4dos DOES NOT "understand" the VHD format, it does understand ONLY RAW images and coincidentally a FIXED SIZE VHD image is a RAW image with a single sectors appended to the end of it (which grub4dos ignores).
JFYI, "0.4.6" in itself does not represent a vaild grub4dos verson, you need to state also the date.
Latest grub4dos versions (of the 0.4.6a "branch") do support RAW images (or FIXED VHD's) that are fragmented, though it is anyway advised to have them in a single chunk:
http://reboot.pro/to...ntiguous-files/
Wonko
Posted 10 June 2016 - 01:35 PM
grub> blocklist /(hd1,1)/14352.vhd
40239152+10908464
map /14352.vhd
error 61
too many fragments
getfileextents redirects to some advertisement
and www.mydefrag.com seems down but i found it at filehippo
MyFragmenter.exe -i h:\14352.vhd
I am aware that grub4dos can't boot vhd images apart from mapping to them to ram
so it's true i used to get back an error 17
but that changed with this latest grub4dos-0.4.6a-2016-06-03.7z in to this error 61
so i thought something has changed hoping that it might boot it also now.
(btw dymanic vhd is booting just fine through --mem, only the loading to ram progress is not shown at all)
Posted 10 June 2016 - 03:18 PM
The non-contiguous file error should be 60, if you don't have that, the file is contiguous (as the blocklist command output shows), the first number is the beginning of the file, the one after the + is the number of sectors in the file.
grub4dos:
40239152 <- offset (in sectors) of the extent -> 40239152*512=20602445824 <- offset (relative to volume)
10908464*512=5585133568 <- size of the single extent
Myfragmenter (assuming a "normal" 4096 bytes cluster):
5029894*4096=20602445824
1363558*4096=5585133568
It is possible that the error 61 is caused by *something* else.
As a side note, usually there is no reason to use a "dynamic" VHD file in a booting environment, what is the actual reason why you are using that?
I mean, you have to choose:
a. the images is 10 Gb, it's actual contents need only 5 Gb and it is NOT subject to increase noticeably in size -> use a 5 Gb static image
b. the image is 10 Gb, its actual contents need only 5 Gb and it is subject to a limited increase in size (let's say 20%) -> use a 6 Gb static image
c. the image is 10 Gb, its actual contents eed only 5 Gb and it is subject to increase in size up to 10 Gb -> use a 10 Gb static image
Mapping to mem a dynamic image will anyway be slower than direct mapping a much bigger static image (besides the need of large amounts of RAM).
Wonko
Posted 10 June 2016 - 05:41 PM
So it reports a "too many fragments" error 61 while itself finds 1 block.
I also checked on a fixed vhd and it seems as it's going to boot but now windows come up with a "inaccessible boot device".
Anyhow, i was just hoping, nothing else, i wanted to avoid having to deal with all this bcdboot/bcdedit terror every time.
What happens is that Win10 supports Lzx compression which gives us the opportunity to have tiny windows installations
and Grub4dos loads say an 1.87g vhd to ram in about 6 seconds.
Dynamic is preferred cause of the creation of temp files during the normal operation of a windows system
and i didn't notice any difference in loading times from a fixed one, is all about very small vhds anyway.
Thank you for the replies, they were revealing.
Edited by Camiel, 10 June 2016 - 05:42 PM.
Posted 10 June 2016 - 05:58 PM
Dynamic is preferred cause of the creation of temp files during the normal operation of a windows system
and i didn't notice any difference in loading times from a fixed one, is all about very small vhds anyway.
Well, you will have to explain that (the reasoning) to me .
Dynamic VHD's (AFAIK) can only grow in size, so - before or later - they will grow up to the "max actually needed" or "allowed"...
Mind you, de gustibus not disputandum est :
https://en.wikipedia...est_disputandum
but really I am failing to see the advantage, it would make (to me) much more sense to have a ramdisk to hold the temp files and thus need a smaller fixed vhd, or actually having a very small "OS image" and have all the non boot critical parts mounted to the flesystem from another image.
Wonko
Posted 11 June 2016 - 04:03 AM
It's true, before i realize that g4d could load dynamic vhds
i was actually using Imdisk to mount a ram drive at startup and using that as temp.
It's more or less the same thing, i'm still experimenting.
0 members, 0 guests, 0 anonymous users