67 replies to this topic

[Wonko the Sane]

 

...loose 'focus' (diskpart reference) on the drive its loading ?

Where test.img is a g4d, active,  bootable, fat32 LiveXP image being loaded off a exFat SDCard, all three load

and all boot LiveXP and without the update kb955704 for exFat on an exFat formatted SDCard but loose the pseudo drive midway.

It would be appreciated if you could provide a more detailed (possibly using the same type of basic English and common definitions we normally use on the board) description of what happens.

I really cannot understand what happens. (let alone your setup and intended result).

Which kind of LiveXP it is?

Why you are going through the MBR?

Why are you using pre-made menu.lst entries? (that IMHO should NEVER be used when testing) instead of command line (thus getting correspondent feedback by grub4dos) 

Is any ramdisk or filedisk driver involved?

Can you take the Drive Droid thingy "out of the equation" and try that same SD card "directly" on the PC?

From the very little I can understand from your post the issue is "outside" the use of "Drive Droid" and connected to the exFAT natre of the stick, see this, you may find some ideas/info of use there:

http://reboot.pro/to...ated-usb-drive/

 

Wonko 

[saddlejib]

            Why DriveDroid ? Galaxy S4.

 

Without DriveDroid phone as mass storage It appears that the S4 wants to see this or its fat32 counterpart at the start of the SDCard when card is dismounted or the phone restarted  it then reports a damaged SDCard if this has been changed, i.e installs of g4d.




Offset             0  1   2   3   4    5   6   7    8   9  10 11 12 13 14 15

000000000   EB 76 90 45 58 46 41 54  20 20 20 00 00 00 00 00   ëv EXFAT        
000000016   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
000000032   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
000000048   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
000000064   00 00 00 00 00 00 00 00  00 48 6F 07 00 00 00 00            Ho     
000000080   00 08 00 00 00 10 00 00  00 18 00 00 30 6F 07 00               0o  
000000096   04 00 00 00 C6 F2 A6 13  00 01 00 00 09 08 01 80       Æò¦        €
000000112   1C 00 00 00 00 00 00 00  F4 F4 F4 F4 F4 F4 F4 F4           ôôôôôôôô
000000128   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000144   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000160   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000176   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000192   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000208   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000224   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000240   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000256   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000272   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000288   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000304   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000320   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000336   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000352   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000368   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000384   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000400   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000416   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000432   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000448   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000464   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000480   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 F4 F4   ôôôôôôôôôôôôôôôô
000000496   F4 F4 F4 F4 F4 F4 F4 F4  F4 F4 F4 F4 F4 F4 55 AA   ôôôôôôôôôôôôôôUª

Is there a way past this?

 

With DriveDroid,

@Steve6375
 G4B works superbly with DriveDroid and as always you're documentation is excellent even down to the # commented myE2B.cfg file.

[saddlejib]

It would be nice if RMPrepUsb could see Virtual Drives created by ImDisk.

[Wonko the Sane]

Saddlejb
As always, you fail to provide ANY meaningful detail, NEEDED to try and help you with your issue.
Grub4dos installed HOW?
And more than that WHERE?
IF the device is partitioned, and it is installed to the MBR, grub4dos needs to overwrite the MBR and some of the hidden sectors.
It is possible that *something* in your setup needs that hiddens sectors are 00's.
IF the device is super-floppy and it is installed to the PBR, grub4dos will most probably need a FAT32 (and be not compatible with exFAT) to be installed.
Post the FAT32 (and not the exFAT) PBR, a copy of when it works and a copy when it doesn't.
It is possible that the only way out is to use a setup like the one makebootfat (cited earler) can make, with a double use MBR/PBR.
 

It would be nice if RMPrepUsb could see Virtual Drives created by ImDisk.

Use *something* else to mount the Virtual Drive, like Total Mounter.
IMDISK is not "low level" enough to interact with all the Windows architecture, i.e. it hooks at a "logical drive" level just above mount manager, whilst another lower level driver will hook in such a way that it is indistiguishable from a real hardware device.
 

Wonko

[solnyshok]

Ok, I think my example might explain why Android phone complains about damaged sdcard after bootloader installation. But not just any bootloader. It actively dislikes any bootloader on ext3/4 partions. It complains and refuses to mount sdcard. If you force mount in terminal/ADB - it will mount, but bootloader will be corrupted (do not know exactly why, but has to do something with security and signing of Android system bootloader). My card is multi-partition, and while I mount PRT1 (FAT32), Android corrupts MBR PRT4 (EXT4). To avoid this problem I zeroed out MBR on PRT4 (where Linux resides) and Android immediately stopped compaining about the card. Mounts it, scans it, uses for camera/gallery storage, etc.

NOTICE AGAIN: ZERO OUT EXT3/4 PARTITION BOOTSECTOR to allow mounting of FAT32 partition in Android. Strange, I know. I think Android is crazy cautious about EXT3/4 bootloaders, to prevent booting unsigned ROMs from any EXT3/4 filesystem, no matter if it is on internal or external sdcard.

========================================

Here the same in more detail, hopefully it saves time to other people trying to read bootable FAT32/EXT4 card in Android
(keywords: USB multi-boot, Micro SDHC, Android, SD Card is Damaged, bootloader, grub, mbr)

========================================

I use Sandisk Ultra Micro SDHC 64 GB card in my phone (LG Optimus 3D, ICS 4.0.4) and in compact Lexar USB3.0 card reader on a keychain.
Card http://tinyurl.com/m3crhhu
Reader http://tinyurl.com/pyyuhwu

I expose some IMGs through DriveDroid (THANK YOU FROZENCOW!!! EXCELLENT PROGRAM!!!) - mostly Windows Defender Offline x32/x64, and Install/Recovery. But I also boot from USB reader into multiple ISOs, Porteus Linux and a real installation of Linux Mint on EXT4. It is fast enough. Boots in a minute. Reads are upto 30MB/s sequential, Writes 10, Random 4K Reads 5, Random 4K Writes 3 MB/s. Feels like a slow laptop HDD of 5 years ago.

Card is partitioned into:
MBR  with BOOTMGR (here and in other cases, installed with BOOTICE)
PRT1: FAT32 -50GB with BOOTMGR (NT6) - Largest partition for data - compatibile with most devices
PRT2: NTFS - 1GB NTLOADER*
PRT3: NTFS - 1GB NTLOADER*
PRT4: EXT4 - 12GB - used to be GRUB2, now empty

*PARTITIONS 2 and 3 are small stubs between FAT32 (max space) and EXT4 (limited space at the end of  card). I figured that one day I might want to reduce FAT32 and experiment with another or two partitions, without having to move EXT4. I guess PRT2 and PRT3 are not relevant further to this topic.

I played quite a lot with the PRT1, it boots Windows 8 BootMgr, and from there I have added syslinux and grub4dos and can go between them, chainloading each other in circles. What is interesting, is that I can put any bootloader on FAT32 (PRT1) and it will not affect my card when I put it into Android phone.

THE PROBLEM BEGAN AFTER INSTALLATION OF LINUX ON PRT4(EXT4). Android refuses to mount the card. I forced it through terminal with
su
mount -t vfat /dev/block/mmcblk1p1 /mnt/sdcard/_ExternalSD

File explorers then can see the card but message about Damaged SD Card still hangs there in notifications. When I unmount the card and try booting Linux, it freezes silently. Turns out bootloader of GRUB2 in PRT4 is corrupted.

In order to solve this problem, I booted Mint's vmlinuz/initrd directly from GRUB4DOS on PRT1 and reinstalled GRUB2 on PRT4, then used BOOTICE (windows tool) to copy MBR from EXT4 partition (512 bytes) and save it into file on FAT32. Now I can boot it from BOOTMGR directly into GRUB2.mbr file and use Linux. Then, I used BOOTICE's sector editor functionality, to fill first sector (512 bytes) of PRT4 with zeroes. After doing, this, Android stopped compaining about the card and happily mounts FAT32 partition.

[Wonko the Sane]

@solnyshok
There is something "queer" about your definitions/terminology.
The MBR is one (and one only) on the disk and it is first sector of the device.
The PBR's or VBR's are the Partition Boot Records (or Volume Boot Records) and there is one for each partition/volume (again first sector - or first few sectors of each volume or partition depending on the filesystem used).

BTW, if you have already grub4dos available, there is no reason to also have GRUB2 (grub4dos can boot a Linux directly alright).


Wonko

[solnyshok]

Yeah, thanks for pointing out. "MBR on PRT4" is wrong, but hopefully understandable. Technically it is PBR on Partition 4. But I do not see any option to edit my previous post. Regarding GRUB2 use: I prefer to to launch GRUB2 because its menu is automatically updated after kernel upgrades. Using GRUB4DOS to launch Linux directly, I would need to manually edit menu.lst after each kernel upgrade.

[solnyshok]

@FrozenCow - how different are formats of IMG and VHD files? From what I found in the web (I might be wrong with this), vhdtool used to convert RAW to VHD does this

Converts an existing RAW disk image file to a fixed-format VHD. 
The existing file length, rounded up, will contain block data
A VHD footer is appended to the current end of file.

Looks like VHD = RAW  + FOOTER, and maybe you could allow DriveDroid to mount vhd files as images (by intelligently exposing only raw data part of it)?

Edited by solnyshok, 02 September 2013 - 06:42 PM.

[Wonko the Sane]

@FrozenCow - how different are formats of IMG and VHD files? From what I found in the web (I might be wrong with this), vhdtool used to convert RAW to VHD does this

Converts an existing RAW disk image file to a fixed-format VHD. 
The existing file length, rounded up, will contain block data
A VHD footer is appended to the current end of file.

Looks like VHD = RAW  + FOOTER, and maybe you could allow DriveDroid to mount vhd files as images (by intelligently exposing only raw data part of it)?

100% exact!

 

The issue is ONLY with "dynamic" or "multi-part" or "differencing" images.

"Fixed size" or "static" .vhd files are EXACTLY  RAW disk images with a "Connectix" footer appended (512 bytes or one sector).

There are a few programs developed here on reboot.pro that can create automatically a footer to convert a RAW image to .vhd or remove the footer to convert a static .vhd to a RAW image (though this can be done with *any* hex disk editor, of course).

 

This is the actual reason why grub4dos can map .vhd images (though it will throw a warning about the image been bigger than the size derived from the partition table), see also:

http://reboot.pro/to...hd-in-grub4dos/

 

I have not clear if you "pass" through grub4dos anyway, if yes, instead of the PBR/VBR you can chainload the core.img "directly".

 

 

Wonko

[FrozenCow]

Hmm, if VHD images are indeed RAW+FOOTER, then I'd guess the bootsector/mbr actually starts on the first byte of the file? If that's the case then I would think it should just work. The only 'weirdness' would be that footer, making the disk bigger when used through DriveDroid compared to when used in a VM/whatever. That shouldn't be a problem though.

@wonko, is that footer needed? Isn't it just a .img with a footer appended?

[Wonko the Sane]

Hmm, if VHD images are indeed RAW+FOOTER, then I'd guess the bootsector/mbr actually starts on the first byte of the file? If that's the case then I would think it should just work. The only 'weirdness' would be that footer, making the disk bigger when used through DriveDroid compared to when used in a VM/whatever. That shouldn't be a problem though.

@wonko, is that footer needed? Isn't it just a .img with a footer appended?

Sure it is (please read as not really )

A tool/driver intended to use .vhd images will *need* it, a tool intended to use RAW images will *need* it not.

 

Basically an info that is missing in a .img (or RAW image of a disk) is the geometry besides a few more parameters useful in a VM..

Normally (and with the "old" partitioning scheme of respecitng cylinder boundary) it would be easy to get it from an existing partition table CHS values, but a number of things cannot be done (as an example "partition" a blank image).

In practice, until you are within the 8 GB CHS boundary, geometry may change, particularly for smallish images, and have n/16/63, n/64/32, etc, but as soon as you go over this limit, and exit the CHS realm to go into the LBA only one, any machine/OS will use a n/255/63 geometry, so it is not really an issue.

At the time there were three solutions devised by the good guys making VM's:

1. a separate "descriptor file like VMware .pln and .vmdk
2. a "footer" like the "Connectix" one (remember that the "static" .vhd format was made by Connectix and only much later MS bought the company and "Virtual PC"
3. a "header" like other forms of VMware .vmdk and - later - Virtualbox  .vdi

 

Here is some related info:

http://reboot.pro/to...ge-file-offset/

 

At the time the *only* available and reliable/working Virtual Disk Driver was Ken Kato's VDK which was hardcoded to use n/64/32 geometry (being originally developed for NT 4.0) and that made necessary the use of a .pln (or .vmdk) descriptor file to manage correctly most RAW images, see:

http://www.forensicf...asc/highlight=/

http://reboot.pro/to...tual-disk-boot/

http://sanbarrow.com...#calcgeoexample

 

 

Later all available drivers would use the LBA only data or default to the 255/63 geometry. like modern Windows does.

VDK and the possibility to "tune" manually geometry still has some needs/merits, though, that is essentially the reason/way I used to put together MBRBATCH:

http://reboot.pro/to...atch-001-alpha/

http://reboot.pro/to...ease-001-alpha/

 

The "Connectix approach" is as a matter of fact the most "intelligent" one as you can have it while keeping - to most effects - the RAW image accessible with anything.

Grub4dos throws the warning just as it would do for a "real" RAW image taken from a hard disk partitioned with the "old" convention of respecting Cylinder/Head boundaries (i.e. with "excess sectors" at the end), it calculates the number of sectors actually belonging to partitioned space and issues the warning, but that's all.

 

Generally speaking a .vhd image is a Hard Disk like image (i.e. a partitioned image) and it's first sector will be the MBR, not a PBR/VBR.

 

Wonko

[intrax]

I have extensively tested drivedroid during the last couple of days because I was planning to use my phone as a boot device to restore problem pc's for which I normally use usb sticks formatted using grub4dos and containing multiple recue iso's started through an grub4dos menu.

 

Few glitches have come to light:

 

I created a custom image file with size of 1Gb and drivedroid goes off to create the file, but this takes a considerable amount of time and only the message bar indicates it is still working. Somehow I ended up with an image file of 1Gb on android which came up as only 200Mb usb disk in windows.

 

I choose foolisly the filename 'drivedroid.img' for my image, cause it turns out this filename is used by the program itself and it happily overwrites your custom image file with its own stuff if you happen to switch usb modes... NO warning given !

 

Installing grub4dos to the disk image is not working. You have to delete and recreate the partition in windows to be able to install grub4dos.

If you have created a superfloppy image (without mbr) grub4dos is NOT booting so there must be something flacky about the image file format.

 

After using drivedroid 1 time the usb state is not correctly reset and you have to reboot the phone to be able to return to 'normal' usb connections.

 

I think drivedroid is a good app with great potential but more attention and work is needed to get rid og these annoying bugs...

 

cheers all

[saddlejib]

I also have and am still testing drivedroid with no problems except for the occasional phone reboot but only because i'm also using 'SG USB Mass Storage Enabler' at the same time and I forget to eject and unplug and replug cable, my bad. (s4 galaxy with 64gb exfat card)

To explain briefly

I create a removeable disk image with imdisk in windows, (16gb), then save it,

Then mount the newly created image with TotalMounter (thanks for the heads up Wonko) then prep it in accordance with tutorial 72a RmPrepUSB. (Easy2Boot). To see the image you have to use 'list all hard drives' in RMPrep. Then save the prepped image.

Then I copy the image to my ExtSDcard/Drives/  folder on phone using 'SG USB Mass Storage Enabler' once thats done I eject usb UNPLUG stress and return to MTP.

Then I open DriveDroid load the G4B (EasyBoot) image as read /write reconnect to computer and populate the relevant folders on G4B with my .iso's, imgs,  etc.

So this means I've got a fat32 usb on an exfat card which runs pe7 and livexp's and of course boots from grub4dos.

 

(did'nt know about 'drivedroid.img' tho)

 

Edit:

It does'nt have to be E2B you can just use RMPrepusb or whatever you want to change the image you've created after all, to all intents and purposes the image once mounted is seen as a usb drive thanks to DriveDroid (FrozenCow),

[intrax]

@saddlejib

interesting !

What device type are you using for the Imdisk device file ?

As in my case a 'superfloppy' device created by drivedroid is not booted by grub4dos...

[saddlejib]

Imdisk control panel, give file name for image file, drive letter as is,

 

Size ? mine was 16gb (remember filetypes stuff) smaller = constrictions on filetypes,mine ntfs.)

 

device type,Auto

 

but more importantly,

 Virtual disk drive access image file directly.

 last but not least.

Tick Removeable Media

 

This route is full of pitfalls but DriveDroid is a Zalman without a hard drive.

[intrax]

Would be nice to have an answer to my question.

You can use a partition manager in windows to see if the image is mbr or superfloppy...

[Wonko the Sane]

Would be nice to have an answer to my question.

You can use a partition manager in windows to see if the image is mbr or superfloppy...

Since the image was mounted in Total Mounter and "prepped" along mentioned RMPREPUSB tutorial it is a hard disk like (partitioned and with MBR) kind of image.

Of course there is no need to use IMDISK to create a (superfloppy) image to later mount it in Total Mounter to partition and format it in RMPREPUSB.

The RMPEPUSB 72a tutorial could do with better explaining that while the verb "format" is used, when you choose the "+Boot as HDD" option what actually happens is that the target is partitioned (besides being formatted).

 

Wonko

[saddlejib]

Sorry had gone to bed but as Wonko says above,

Using the TotalMounter method your image in DriveDroid is recognized by windows (Explorer and Disk Management) as a hard drive.

If you require it to be recognized as a removeable drive use the method for Imdisk outlined above but then copy your image to the phone using 'SG USB Mass Storage Enabler' , Eject drive after etc etc

Then load it (the file you've just created)

with DriveDroid reconnect phone and if you require RMPrepUSB or wish to do anything else you can,  as its now seen as a removeable usb device. The image file of course can be of any size or type you require.

 

Edit:

 In essence I'm just creating any size  blank .img files with ImDisk to be transfered to your Drives folder after that it's your choice open it with whatever o's you want and do what you want with it.