67 replies to this topic

[saddlejib]

Thought this was worth a mention in reboot.pro it may be of interest to some here

 

info here,

http://softwarebakery.com/

 

and also here

http://forum.xda-dev....php?p=39293985

 

Edit (add description)

 

Description

DriveDroid allows you to boot your PC from ISO/IMG files stored on your phone. This is ideal for trying Linux distributions or always having a rescue-system on the go... without the need to burn different CDs or USB pendrives. The paid version of DriveDroid does not include ads and helps the developer.

DriveDroid also includes a convenient download menu where you can download USB-images of a number of operating systems from your phone.

You can also create USB-images which allows you to have a blank USB-drive where you can store files in. Another possibility is to use tools on your PC to make a bootable USB-drive out of the blank image that DriveDroid created.

How do you make this work?
* Connect your phone to your PC using an USB cable
* Download an image file (.iso or .img) or create one
* Select the image file in DriveDroid to let your phone 'host' the file over USB
* (Re)start your PC and make sure the correct boot priority is set in the bios
* The image should now be booted on your PC

Note that not all ISO files will work. Most phones emulate a USB-drive and not a CD-drive, you need to use ISOs that are compatible with USB-drives. Most modern Linux-ISOs are supported as well as all distributions from DriveDroids downloadlist. True CD emulation requires changes in your rom.

Recommendations:
To quickly try DriveDroid download SliTaz from the download menu. It is an operating system of only 35MB, so it should be easily downloaded.
You can also create a 100MB FAT image through the 'Create blank image...'-menu. It should show up as a normal empty USB-drive on your PC.

[Zoso]

thats kinda cool! I don't have a mobile/portable gadget (except phone only) because I have been holding out until I find one that can dual boot to custom windows XP or POS2009.

do you know if this is possible yet and if so which hardware? not booting the .img on PC from gadget but actually booting it on the gadget.

thanks

[saddlejib]

Basically were on the cusp of a revolution in computing the phone in your pocket could easily put men on Mars but its how we use and control this tecnology that's the question.

 Google has got a game plan, it's called 'big data' colloquially, yes of course this software could be run on your phone it's not complicated but not implimented, intentionally.

Imagine Googles SBeam, NFC devices talking directly to a server or computers startup bios revamped of course.

 Or ask yourself do you need gps, magnetometer,humidity,temperature and air pressure dont forget gyroscope.

 

For changes we need a new Lineas

Linux

Not os but visionary

 

Try Ubuntu for smartphone if you can.

 

http://www.ubuntu.co...ntu-for-android

[steve6375]

You can install Easy2Boot to the SD card of a smartphone without rooting it or using DriveDroid - ensure that it is FAT32 and then install grub4dos, then copy over the E2B files. Then add ISOs, etc. and you are good to go.

[Zoso]

You can install Easy2Boot to the SD card of a smartphone without rooting it or using DriveDroid - ensure that it is FAT32 and then install grub4dos, then copy over the E2B files. Then add ISOs, etc. and you are good to go.

interesting.. but is it also possible to boot an XP on one of these newer gadgets?

it seems the hardware is up to the task. I am interested in a pocket sized gadget that a fullsize monitor, keyboard can be plugged into and also has a USB port.

my idea that Im sure others have had too is portable computing (pocket size device) where you can plug into your existing equipment in home, office, car, airplane, wherever and have the same OS to handle whatever tasks that the hardware it is plugged into is capable of.

its so simple that it has to exist already, no? it would cut profits for hardware manufacturers and maybe give the average nerd more power than they want them to have and those are reason enough for the big manufacturers to not produce.

what is currently the smallest device that can run a full windows?

[saddlejib]

You can install Easy2Boot to the SD card of a smartphone without rooting it or using DriveDroid - ensure that it is FAT32 and then install grub4dos, then copy over the E2B files. Then add ISOs, etc. and you are good to go.

 

   This is certaily true of some phone's in fact I used to use G4D on one of my earlier Blackberry's but when the Curves phone O'S was updated this was not possible for security reasons the phone was not seen as a mass storage device and not seen by the bios on enumeration.

   Also this is true of the Galaxy S4 which presents itself as a media device mtp or ptp depending on your selection.

 I believe the S3 didnt do this but as I did'nt own one I can't say.

 Furthermore the S4 uses exfat and when the card is formatted differently the phone reports the card as being corrupted.

  So problem ???

 How to boot from S4 "Smart Enough" phone!

 This program may provide the solution (unfortunately I havent had the time to test it yet) but it looks promising.

   It looks as though it has the potential to be a 64 Gb Zalman on a phone (64G being size of supported card)

 @Steve6***

 The question you asked on the developers page may be answered by reading --

Installing Hirens

 From this I think RMPrep will work ???

Like I say no time to test.

 Would be a boon if it would.

 

I think ImDisk could come into play here also>>>

[rog]

most smart phone devices are ARM CPU inside so XP won't work 

[FrozenCow]

Hi, I'm the developer of DriveDroid.

 

What DriveDroid does is setup your phone to act as an USB Mass Storage drive. It will 'host' any image you choose on that USB drive. Older Android phones could also host their SDcard over USB, which is where the functionality came from, but recent phones (for reference: Galaxy S2 and newer) only enable MTP by default, which isn't emulating a true disk drive. DriveDroid will make sure things are setup right for almost all phones.

 

That means that any image that runs on a USB drive will work through DriveDroid. You'd think that ISO files would not work, since they are made for CD drives, and you'd be right. However many Linux distributions release their ISO files in a form that works on both CD and USB drives. That makes it also possible to use these ISO files on DriveDroid.

 

DriveDroid also includes an easy way to download compatible images for various distros. Distros that are in this list will just work out-of-the-box.

 

If the ISO file does not support USB drives, there are two options:

 

I've made patches for a number of Android kernels that allows the phone to act as an CD drive. That makes it possible for DriveDroid to host images as a CD drive and allows any ISO to be hosted through DriveDroid. More information can be found on this on http://forum.xda-dev...d.php?t=2196707 under "True CD-ROM emulation".

 

Lastly it's usually possible to convert the ISO to an USB compatible image. This can be done using the usual tools to convert them. DriveDroid has the functionality to create blank images, which act as an empty USB drive when hosted. When such an image is hosted you can use tools like Rufus, Windows USB Download tool, Unetbootin or whatever other tool that writes to an USB disk. A tutorial of how to do this using Rufus can be found here: http://softwarebaker...able-usb-images .

 

Just to clarify: DriveDroid does not run/install an ISO on your phone, so you cannot run Windows XP (or whatever other x86 OS) on your phone using DriveDroid. This isn't a goal of DriveDroid. You can however use ISOs like Windows XP that are stored on your phone on your PC with just an USB cable and install Windows XP through this method.

Edited by FrozenCow, 25 July 2013 - 01:50 PM.

[Wonko the Sane]

@Frozencow

JFYI, most if not all Linux .iso's can be booted from USB (let's say stick, as your nice app makes available the phone as if it was a USB stick, right?) by mapping the .iso into the partition table (normally last partition entry is used) and then chainloading it through grub4dos, see:

http://reboot.pro/to...ge-2#entry88531

 

The Easy2 Boot thingy Steve6375 wrote is based on this principle:

https://sites.google...-maintain/e2bv1

 

 

Wonko

[saddlejib]

 @ FrozenCow

 

I'm glad your on'board' and would like to welcome you to reboot.pro the place where things really happen.

 

I would also like to wish you every success in your development of DriveDroid.

[FrozenCow]

@Frozencow

JFYI, most if not all Linux .iso's can be booted from USB (let's say stick, as your nice app makes available the phone as if it was a USB stick, right?) by mapping the .iso into the partition table (normally last partition entry is used) and then chainloading it through grub4dos, see:

http://reboot.pro/to...ge-2#entry88531

 

The Easy2 Boot thingy Steve6375 wrote is based on this principle:

https://sites.google...-maintain/e2bv1

 

 

Wonko

Yes, I've been discussing the possibility of integrating isohybrid (of the syslinux project) into DriveDroid, so that syslinux-based images (almost all Linux distros) can be converted to hybrid images (if they weren't already) from within DriveDroid. Chainloading grub4dos would be pretty cool too. Do you know whether that is possible without 'big' changes to the ISO? isohybrid only changes a few bytes on the ISO, but not much. It would be ideal if things could be done without copying/rearranging files in the ISO file.

 

Then again, everything will 'just work' if the phone has support for CD-ROM emulation, which is something I (and others) have been trying to push to a number of custom Android roms. CyanogenMod now has support for this on quite a few devices, like the Samsung Galaxy S, S2, S3 and S4. Next goal would be submitting the patch for CD-ROM emulation to Linus' Linux kernel so that future phones will all have this capability. The emulation itself is already in there, but it just needs a 'switch' that applications can use to switch between USB-stick and CD-ROM emulation.

 

 @ FrozenCow

 

I'm glad your on'board' and would like to welcome you to reboot.pro the place where things really happen.

 

I would also like to wish you every success in your development of DriveDroid.

Thanks. We'll see what will happen . It's certainly quite a big community for boot-related stuff compared to other sites I've seen.

EDIT: Oh also, I see this post is in "Boot from LAN", whereas "Boot from USB" would be more appropriate. Should I just start a post there, or is it still possible to move this post over there?

Edited by FrozenCow, 26 July 2013 - 09:04 AM.

[Wonko the Sane]

No, the clever part of that trick, is that the ,iso is NOT changed in anything (i.e. there is no "special" first sector as in a "canonical" iso-hybrid image).

Simply a partition entry for the .iso is written to (usually fourth, as it is free in 99% of cases) an entry in the MBR.

The tool used to write that partition entry is (in our case) grub4dos, but *anything* may do.

The booting is initiated from grub4dos, mapping the .iso file and chainloading the .iso file, I guess that most "linux" loaders can do the same thing, or a similar one, it is the distro itself that "looks in the partition table and finds itself".

 

If you prefer, we developed that method using grub4dos because it is convenient for us, but I beleieve that the same approach can be replicated with other tools.

 

One of our "normal" USB sticks simply boots to grub4dos and from it we boot *anything* (or almost anything), and chainloading grub4dos is extremely easy.

 

There are two main executables (choose one, they provide alternate means to get to the same enfvironment):

1. grldr <- which can be chainloaded from any Windows bootmanager (NTLDR and BOOTMGR) and that can be installed to the MBR OR to a PBR
2. grub.exe <- which is BOTH a DOS executable AND a Linux kernel

 

Wonko

[saddlejib]

Quote

"EDIT: Oh also, I see this post is in "Boot from LAN", whereas "Boot from USB" would be more appropriate. Should I just start a post there, or is it still possible to move this post over there?"
 

The boot from Lan was the right forum if you read the sub-header it was the first thing I posted in the right place ever.

 

As some people will attest to.

 

You should start your own thread, Phones "Pocket Computers"  need to be included here.

 

In reboot.pro that is.

 

Move It.

[Wonko the Sane]

The boot from Lan was the right forum if you read the sub-header it was the first thing I posted in the right place ever.
 
As some people will attest to.

 
No prob, mate , here it is :

To Whom it may concern
 
Re: reboot.pro member saddlejb's posting habits
 
I, the undersigned Wonko the Sane, widely reknown as The Finder, by the powers given onto me by noone at all, and in behalf of nobody,  attest that the person using the nickname of saddlejb:

• is a LONGTIME member of this board
• NEVER started a thread in the right place
• OFTEN goes out of topic on any given thread
• in ALL this time he never managed to quote PROPERLY another member's post or more generally use the board tags
• in this specific case ATTEMPTED to post in what he considered to be the right place BUT FAILED miserably and he is NONETHELESS and in perfect good faith convinced to have done the right thing (he has not)
• NOTWITHSTANDING the above he is a really nice chap anyway.

In making this attestation I have exercised care and diligence that would reasonably be expected of someone granted the title of The Finder in these circumstances, having thoroughly researched the matter, all previous posts by the afore mentioned member and also my Tarots and I-Ching (crystal ball is in the shop for tuning, again).
 
I furhter certify that the above statements represent, to the best of my knowledge, an accurate description of the past member behaviours on the board.
 
Dated at Florence, Italy this  July 27, 2013
 
Signed:
Wonko the Sane (The Finder)

 
 

Wonko

[saddlejib]

@ Wonko

A BIG Thank You,

 Once more your clarity in this and many other matters has brightened my day.

[FrozenCow]

No, the clever part of that trick, is that the ,iso is NOT changed in anything (i.e. there is no "special" first sector as in a "canonical" iso-hybrid image).

Simply a partition entry for the .iso is written to (usually fourth, as it is free in 99% of cases) an entry in the MBR.

The tool used to write that partition entry is (in our case) grub4dos, but *anything* may do.

The booting is initiated from grub4dos, mapping the .iso file and chainloading the .iso file, I guess that most "linux" loaders can do the same thing, or a similar one, it is the distro itself that "looks in the partition table and finds itself".

 

If you prefer, we developed that method using grub4dos because it is convenient for us, but I beleieve that the same approach can be replicated with other tools.

 

One of our "normal" USB sticks simply boots to grub4dos and from it we boot *anything* (or almost anything), and chainloading grub4dos is extremely easy.

 

There are two main executables (choose one, they provide alternate means to get to the same enfvironment):

1. grldr <- which can be chainloaded from any Windows bootmanager (NTLDR and BOOTMGR) and that can be installed to the MBR OR to a PBR
2. grub.exe <- which is BOTH a DOS executable AND a Linux kernel

 

Wonko

Ah, right. What I was getting at was that phones have slow write I/O on their SDcards. So changing a lot of bytes will take quite a long time. Next to that is the space constraints on their SDcards which we want to minimize. DriveDroid needs one file that will act as an USB stick.

If someone downloaded an ISO (like Windows) onto their phone they will want to use this file in DriveDroid.

 

If I understand correctly with the method you're describing you'd have to create an image, put an partition table in there, put a FAT-partition in it and place the ISO into that FAT-partition. I guess some bootsector will be written into the image to allow chainloading the ISO. Then through DriveDroid the image would act as an USB stick and could be accessed from Windows to place ISO files onto.

 

This could work pretty well, however the image that needs to be created can only be 4GB on most phones (most of them have FAT32 on the SDcard). So, you could only have a total of 4GB of ISO files in this file, instead of multiple ISO files of 4GB.

 

I think it should also be possible to use the whole SDcard as a bootable device, since the SDcard usually is also formatted using FAT32. It 'only' needs a bootsector written on it and a file that directs the bootloader to the appropriate filepaths where the ISO files can be found to chainload. The downside of this is that the SDcard needs to be unmounted from Android in order to not corrupt things. I'm not sure whether this is still possible with new-ish phones, since those often have their SDcard builtin and usually are not able to unmount it safely.

 

Last possibility would be to have a small image with the bootloader and chainloading functionality on it. You boot off of that, load its chainloading-code into memory and then just wait. In DriveDroid you then select the appropriate ISO file you want to boot, so that ISO file will get hosted instead of the small image. Then you press a button on the PC for it to continue and the chainloading code will chainload the ISO that is now hosted as the USB stick.

I think this possibility is the most compatible, but it does require you to switch between the small image and the ISO each time you want to boot from an non-hybrid ISO.

 

I'm still not 100% sure how chainloading an ISO works in detail (will it setup CD-rom functions that map to a USB disk?) and whether that works for all nonhybrid ISO files. I guess I just have to try fiddling with it. What would be a good starting point?

 

@saddlejib: I see "Boot from LAN" is 'everything else' Sorry I missed that. "Pocket Computers" would indeed be a nice subforum for DriveDroid as well as Zalman VE200 or anything related.

[Wonko the Sane]

If I understand correctly with the method you're describing you'd have to create an image, put an partition table in there, put a FAT-partition in it and place the ISO into that FAT-partition. I guess some bootsector will be written into the image to allow chainloading the ISO. Then through DriveDroid the image would act as an USB stick and could be accessed from Windows to place ISO files onto.

NO.

Let's start again form scratch (I am not familiar with the way DriveDroid works, nor with Android, so I will just try and explain how the methoid works on a "normal" USB stick, SD card or anyway *any*device that is seen by BIOS and that is - or can be - partitoned).

 

A "partitioned" device (or "hard-disk-like") means that it's first (512 bytes) sector is a MBR (Master Boot Record)

No matter if the MBR contains booting CODE or not it will ALWAYS contain at least TWO sets of DATA:

• the partition table, i.e. 4 (four) 16 byte each entries at offset 446, that are commonly numbered (using grub4dos and many other tools 0 based numbering convention) as #0, #1, #2 and #3
• the "Magic bytes" 0x55AA at offset 510

Most "small" partitioned devices will have only one partition entry filled with actual partition addresses, at the most two.

If you prefer 99.99% devices will have either of:

1. one single Primary partition spanning over the whole device size, and whose addresses will occupy entry #0
2. two Primary partitions, the first spanning over almost the whole device size and the second - often called "fake" partition - spanning over the last cylinder (this is created by some tools to increase the chances that a BIOS will recognize the device as "hard disk-like") that will occupy entries #0 and #1
3. one Primary partition and one single Extended partition (that can contain more than one volume) and that will also occupy entries #0 and #2 

Even if there is a third partition in use, it will occupy entry #2, so in 99.999999999% of cases the entry #3 - addressed in grub4dos as (hdn,3)  will be empty (all 00's).

 

Any Dos and Windows will check the partition ID in all partition entries and if one has an ID of 0x00 the entry will be considered "empty/not valid").

Any Linux will check the partition entries and NO matter the ID will check if there is *anything* it can mount/recognize at a given address (provided that the address itself is not all 00's).

 

So, you copy the .iso file to the filesystem on the pre-esisting parittion (no matter if FAT, FAT32 NTFS or Ext2/3/4 as grub4dos can access all of them, with a small caveat that will talk about later), let's say that your .iso file is called Mylinux.iso (and that you can access it as a file from DOS/Windows as - say - F:\Mylinux.iso or from Linux as /mnt/sda1/Mylinux.iso.

 

Using the partnew command in grub4dos (but as said you can do the same with any hex/disk editor) you simply write to the MBR, in entry #3 the "blocklist" that belong to the file Mylinux.iso (in the form of both CHS and LBA address i.e. along the "syntax" that the MBR entry requires).

Then you use the grub4dos (but as said you can probably use another loader) to map (temporarily) the /Mylinux.iso to a "virtual CD" drive and chainload this Virtual CD drive "as is".

Typically a Linux CD (or .iso) will attempt (and succeed) to load in "real mode" two things:

1. a kernel
2. a intird (initial Ram Disk)

as soon as those are loaded it will switch to "protected mode" (and the grub4dos virtual CD" will "cease to exist").

A number of Linux Distro's already have provisions built-in to find and load the actual .iso file (if you prefer to create a new Virtual CD with the contents of the .iso), but all of them, even those that do not have that provision, will scan the MBR of the "hard-disk-like" device and will find the entry written earlier and treat the disk sectors addressed there as if they were an actual partition (or volume).

If you prefer we are providing the Linux kernel a way to access the SAME area with two different methords, as "file" or as "volume".

 

The little caveat I hinted about before with Ext2/3/4 is that the actual Mylinux.iso file NEEDS to be contiguous to allow being mapped as a partition/volume in the MBR and this is not always the case on these filesystem (and since the good Linux guys after all these years are still in full denial mode abnot the possibility that a large file may be fragmented on ext2/3/4 filesystem there is not AFAIK a remedy for this -when it happens).

 

Now, what I don't know is if your nice app exposes the actual "whole device" or only the "partition" (or "volume" or the *whatever* that gets a drive letter in Dos/Windows) i.e. if the first sector of the *whatever* it exposes is a MBR or a PBR.

If the latter, it is still possible (at least for FAT16/32, proved, but I believe for NTFS also) to modify the PBR in such a way that is at the same time a PBR and a "fake" MBR (thus allowing the needed four partition entries). 

 

This is BTW the approach traditionally used by makebootfat:

http://advancemame.s...oot-readme.html

 

The 4 Gb is a limit of the FAT32 filesystem, but it relates to a single file, so you can have as many up-to-4-Gb-in-size .iso images as they fit in the actual SDcard available space, as each time you boot you can select WHICH image you map in the partition table.

 

I hope this clears the matter.

 

If you explain in more details what your nice app "exposes", I am sure we can help you to find a suitable solution, be it involving grub4dos or not. 

 

Wonko 

[FrozenCow]

Thanks for the explanation of grub4dos. I know about MBR, bootsector, etc, since I've implemented generation of this in DriveDroid when one wants to create a blank image.

 

 

One thing that isn't totally clear for me is:

you use the grub4dos to map (temporarily) the /Mylinux.iso to a "virtual CD" drive and chainload this Virtual CD drive "as is".

How will it map the iso as a virtual CD? Will Windows and any other OS just see a CD-drive when it's probing for ATA/SATA/SCSI devices?

 

I have no idea how it does that, but I'd just presume that to be the case, so let's get to what DriveDroid does:

 

DriveDroid makes use of Gadget USB functionality in the Linux kernel and more specifically the Mass Storage functionality. You can find more about the actual implementation here: https://github.com/t..._mass_storage.c

The Mass Storage functionality emulates an USB Mass Storage device, which can be a removable disk (like an USB stick), a USB disk or an CD-rom device (I will come back to this). Let's just say Android only supports removable disks. Linux will handle all calls that are made on the USB connection directly to a user-specified block device or file. DriveDroid specifies that file to the kernel, so that the phone 'hosts' the file like a USB stick. The PC will then see a removable disk with the exact contents of the file.

 

That way the device you see on your PC (like /dev/sdb) will be exactly the same as the file that is specified (byte for byte). That means that the file should contain a bootsector, partition table and whatever else you'd want/need.

 

Now, I said Android only supports removable disks, but this is not entirely true for custom roms/kernels, since those can be patches to have CD-rom support. CD-rom support also works the same in that the file is mapped directly as a CD-rom device and with that, ISOs will just work like normal CDs. For users/phones that cannot or do not want to change their kernel, we're stuck with removable USB disks, so that's what I'm focusing on here.

 

Keep in mind that an image file needs to contain the whole content of a disk, including bootsector+partition table. In my previous post I was talking about creating an image and putting grub4dos on it with a FAT/NTFS/EXT/whatever partition to put the ISO files on. I think this is necessary, since we want a bootsector on it where grub4dos can be started from and we need grub4dos to access the ISOs somewhere. The simplest way to do this is placing grub4dos and the ISOs in the same image.

 

Am I right on this so far?

[Wonko the Sane]

FrozenCow, on 27 Jul 2013 - 5:02 PM, said:
Am I right on this so far?

Yes and no.
There are still seemingly some issues with definitions.

I asked a (I believe) simple question.

You have to make up your mind.

The first absolute sector of the *whatever* DriveDroid "exposes" can be EITHER:

• a MBR Master boot record, part of the disk, device or \\.\PhysicalDrive

OR

• a PBR Partition Boot Record or "boottsector", part of the "drive", "partition" or "volume" or \\.\LogicalDrive

WHICH of the two is the first sector of the *whatever* DriveDroid exposes?

To make it more clear (if needed) a disk (whole disk) partitioned will have in sequence:

• MBR
• hidden sectors (traditionally 62)
• PBR of first partition/volume on it

The MBR belongs to the disk and is NOT part of the partition or volume (the whatever gets a "drive letter" in windows).

The PBR is NOT part of the disk, it is part of the partition or volume (the whatever gets a "drive letter" in windows).


Wonko

P.S.: Wait a minute, maybe I am starting to understand how I completely failed at understanding what DriveDroid does , it exposes a FILE residing on the phone's sd-card, NOT the "whole" SD card itself?

[FrozenCow]

Like I said, DriveDroid exposes the whole disk, every byte that is in the image file will be exposed as a disk: the first byte of the disk is the first byte of the file, the last byte on the disk is the last byte of the file. It's a 1-to-1 mapping. For me a disk is just a bunch of bytes, just like a file.

 

I don't know what a hidden sector, PBR, \\.\PhysicalDrive or \\.\LogicalDrive is, but I know the MBR is located in the first 512 bytes of the disk and thus in the first 512 bytes of the image. Maybe that's different for non-hybrid ISO files. Hopefully that makes sense?

 

Maybe the use of 'bootsector' was confusing. I should've said bootstrap code: the first 446 bytes of the MBR and thus the first 446 bytes of a disk.

[TheHive]

Tried it on a Nexus 7 with slitaz.iso. nothing happens when booting pc.

 

 

Had a seperate question.

How will the person who uses the 'Create a blank image' , regain that space back to android parition.

[Wonko the Sane]

Like I said, DriveDroid exposes the whole disk, every byte that is in the image file will be exposed as a disk: the first byte of the disk is the first byte of the file, the last byte on the disk is the last byte of the file. It's a 1-to-1 mapping. For me a disk is just a bunch of bytes, just like a file.
 
I don't know what a hidden sector, PBR, \\.\PhysicalDrive or \\.\LogicalDrive is, but I know the MBR is located in the first 512 bytes of the disk and thus in the first 512 bytes of the image. Maybe that's different for non-hybrid ISO files. Hopefully that makes sense?
 
Maybe the use of 'bootsector' was confusing. I should've said bootstrap code: the first 446 bytes of the MBR and thus the first 446 bytes of a disk.

No, the misunderstanding (my fault actually ) is seemingly before that.

Let's see if I have now understood how it works :
DriveDroid exposes as if it was a device a FILE that resides on the SD-Casrd of the phone.
I.e. If the FILE that is on the Sd-Card is a (whole) hard disk image then the first sector "exposed" to the booting PC is the MBR (of the FILE which is an image of the disk).

What I thought was that Drive Droid could (and maybe it can/it is possible) expose to the booting PC the whole SD-Card and all the files the SD Card contains.

But, apart what it does currently, since as you nicely put it you deal with "bunches of bytes" maybbe it is still possible to have Drive Droid do that (expose to the booting PC the bunch of bytes constituting the whole SD-card).

Otherwise i.e. if only a file can be exposed, then you are right, in the case of the .iso, the .iso needs to be modified into a iso-hybrid one.

But since you have the right approach that file=disk=bunch of bytes maybe it is possible that you can expose to the booting PC a "buch of bytes composed of a "header" + the actual UNmodified .iso file.
The header would be a very minimal hard disk image, with a MBR, and a small (FAT12 would do),active partition containing grub4dos.
This way we can use the partnew method alright.


Wonko

[FrozenCow]

Tried it on a Nexus 7 with slitaz.iso. nothing happens when booting pc.

 

 

Had a seperate question.

How will the person who uses the 'Create a blank image' , regain that space back to android parition.

Have you followed the setup (Preferences -> Setup USB Settings) and did that work? Have you tried the different USB systems that are listed there?

'Create blank image' will just create a file on your SDcard. Deleting the file will regain the space back.

 

No, the misunderstanding (my fault actually ) is seemingly before that.

Let's see if I have now understood how it works :
DriveDroid exposes as if it was a device a FILE that resides on the SD-Casrd of the phone.
I.e. If the FILE that is on the Sd-Card is a (whole) hard disk image then the first sector "exposed" to the booting PC is the MBR (of the FILE which is an image of the disk).

What I thought was that Drive Droid could (and maybe it can/it is possible) expose to the booting PC the whole SD-Card and all the files the SD Card contains.

But, apart what it does currently, since as you nicely put it you deal with "bunches of bytes" maybbe it is still possible to have Drive Droid do that (expose to the booting PC the bunch of bytes constituting the whole SD-card).

Otherwise i.e. if only a file can be exposed, then you are right, in the case of the .iso, the .iso needs to be modified into a iso-hybrid one.

But since you have the right approach that file=disk=bunch of bytes maybe it is possible that you can expose to the booting PC a "buch of bytes composed of a "header" + the actual UNmodified .iso file.
The header would be a very minimal hard disk image, with a MBR, and a small (FAT12 would do),active partition containing grub4dos.
This way we can use the partnew method alright.


Wonko

Yes, exactly. It can host any 'file' or 'block device', that is a bunch of bytes, as a USB disk.

 

You're right that the whole SD-card can be exposed as a USB disk, this is certainly a possibility. There are however 2 problems with this approach.

First, Android has a partition of the SDcard mounted where applications or the user can still write stuff. When exposing the SDcard I'd need to unmount its partitions, which isn't always possible (files locked by apps). This is however what older Android devices have done to let the PC access files of the phone, but modern devices use MTP for that (which works on a higher level and does not expose the disk as a bunch of bytes).

Second problem is that some modern have a 'fake' SD-card, in the sense that the data is on the same disk as the rest of the OS. Exposing this disk would require unmounting root, which isn't possible.

 

You're also right about prepending some data to the ISO. This could very well be a good option. I'm not 100% sure whether it is actually possible to prepend a bunch of bytes to a file without copying all data to a larger file. Another option is creating a loopback device that contains the heading bytes + the ISO itself. I've done some searching on this and found http://serverfault.c...l-file-on-linux . The tool they use there (dmsetup) does not seem to be available on my phone. I do see /dev/mapper/, which dmsetup uses, it might be possible to copy an ARM version of dmsetup to the phone, but I'll have to try that later (need to do some fixes in DriveDroid).

[Wonko the Sane]

Can you access the "file" only as "file" within the filesystem of the device or as a (arbitrary) number of contiguous sectors?

So, let's say that we have:

1. a "header", it could be something like 300 Kbytes, containing a MBR and a grub4dos
2. the actual .iso file

Can you have them one after the another in the filesystem?
Can you "expose" them as a single "bunch of bytes"?

 

Much better if you could get the header "by itself" and the ".iso" by itself and "expose" them as a single bunch of bytes, but even if this is not possible, if the above can be done, an "overhead" of 300Kbytes for *each* .iso seems to me like (while being not "elegant" to have a series of almost 100% duplicated headers) not entirely a bad idea.

 

Wonko

[FrozenCow]

Hmm, not 100% sure I understand what you mean. The SDcard is FAT32. Is the question: can I just allocate a file (of 300KB) that is placed right before the ISO and expose the combined bytes (not on FAT32-level, but on disk-byte level)? If that's what you mean, I don't think this can be done reliably, since there could be a file allocated before the ISO file.

 

Yes making them one file is the purpose of http://serverfault.c...l-file-on-linux, but I'm not entirely sure whether that would work on Android.

 

Another approach is to have the grub4dos part in a separate file.

• Expose the grub4dos image as a USB disk
• Boot from the disk
• Let grub4dos wait before chainloading
• Expose the ISO file
• Let grub4dos chainload the USB disk

This approach should always work, but requires some work by the user (switching from grub4dos to ISO).

Edited by FrozenCow, 28 July 2013 - 10:41 AM.