Jump to content

Windows 7 Setup folder to USB method in 1.2?


naithkk

Recommended Posts

Hehe yes for me sound was too like an ad for this model, this was the first thought i had :D anyway iam researching always when buyin things and after some research i found many good reviews, like he already said

but i will not buy this next week, i bought already today :D

thats cool, one big problem now has gone

thanks for answers, i will continue work tomorrow and will see how i go on

 

about my question about grub4dos or grub 2.00, bootice does have this option

 

PS. maybe you two remember, i had already messed up this usb stick 2yrs ago with the manufacturing tool :)

 

EDIT: i cant boot with vmware the usb stick, i have connected the usb stick in vmware and on the boot device menu i choose "removable device" to boot from but it boots only from hdd, with qemu it works

also Vmware BIOS dont display the stick... :/

Edited by Weed
Link to comment
Share on other sites


Aah right, i forgot the Plop Bootmanager which i need, Thanks!

i just made a small test and have just added acronis disk director.iso but with no luck

vmware does say when i choose acronis: "cannot continue if Plop is active, please start this entry without loading plop first"

and qemu says: WARNING: PARTITION TABLE 4 IN BIOS DEVICE 128 IS ALREADY IN USE!

To prevent possible data loss will not continue further

 

here the entry in menu.lst:

title addh from partition 0map --unmap=0:0xffmap --unhook && map --rehookcat --hex --locate=PoLPu@ (md)0x3D0+0x130 > nul && echo Cannot continue if PLoP is active, please start this entry without loading PLoP first && echo && pause Press any key to return to the main menu && configfile /menu.lstset /a dev=*0x8280&0xffroot (%dev%,0)set ISO=/ISO/addh.isols %ISO% > nul || find --set-root --devices=hf /usbdrive.tag|| echo Error! Could not find usbdrive.tag && echo  && pause Press any key to return to the main menu && configfile /menu.lstls %ISO% > nul || find --set-root --devices=hf %ISO% || echo Error! Could not find %ISO% && echo  && pause Press any key to return to the main menu && configfile /menu.lstmap %ISO% (0xff) || map --heads=0 --sectors-per-track=0 %ISO% (0xff) || echo FATAL ERROR mapping %ISO%, please check if file is present and defragmented && pause Press any key to return to main menu && configfile /menu.lst#http://reboot.pro/topic/9916-grub4dos-isohybrided/page-2#entry88531#http://www.rmprepusb.com/tutorials/tailsset /a dev=*0x82a0&0xffdebug 1parttype (%dev%,3) | set check=debug offset check=%check:~-5,4%if "%check%"=="0x00" partnew (%dev%,3) 0 0 0 && partnew (%dev%,3) 0x00 %ISO%if not "%check%"=="0x00" echo WARNING: PARTITION TABLE 4 IN BIOS DEVICE %dev% IS ALREADY IN USE! && echo  && echo To prevent possible data loss will not continue further && pause && configfile /menu.lstmap --rehookroot (0xff)chainloader (0xff)

whats wrong?

Link to comment
Share on other sites

To boot all Linux and similar non Windows ISO files program uses a trick hinted by cdob and extended by Steve, check the comments in this menu entry:

http://reboot.pro/topic/9916-grub4dos-isohybrided/page-2#entry88531

 

In short, ISOHYBRID ISO images are mapped as a partition, thus requiring an available partition entry in the partition table. This is written by grub4dos when the selected menu is launched.

PLoP has read-only USB driver, meaning this modification cannot be made, hence the message you are seeing.

 

Simple images like Acronis, which have only kernel and initrd files and nothing outside to be needed by OS later on, do not actually need to be mapped as partitions, but programatically it's hard to find out if that's the case.

For such images you could manually create a menu like:

title Boot XXXXX.ISOmap /ISO/my.iso (0xff) || map --mem /ISO/my.iso (0xff)map --hookchainloader (0xff)

Or simply use QEMU (slower) as the included option in WinSetupFromUSB or VirtualBox (faster) from above to test, both allow write operations and there will be no need of PLoP. In addition, make sure 4th partition entry is unused, and the 3rd if using persistent space:

 

...

My general advice would be to get the mentioned SanDisk Extreme, which is recognised as a fixed disk, make 2 partitions, first FAT32 acrtive and second NTFS, and leave the remaining 2 partition entries unused, to be able to boot Linux ISOs with persistence space if needed...

Link to comment
Share on other sites

In short, ISOHYBRID ISO images are mapped as a partition, thus requiring an available partition entry in the partition table. This is written by grub4dos when the selected menu is launched.

I hate to be picky :unsure:, but actually I am picky.

 

ISOHYBRID is not involved at all in this.

An isohybrid .iso is a particular form of (non-standard) .iso that CONTAINS a  MBR, in practice the fact that the ISO9660 standard has the provision for it's bootrecord on sector 16 leaves the first 16 sectors (of 2048 bytes) empty and unused, and one can take advantage of this to do queer things with this space.

 

As a shameless plug :w00t: see here what can be done with it (different from isohybrid) COSMIAS:

http://reboot.pro/topic/17807-release-cosmias-a-new-approach-to-g4d-images/

 

The nice trick by cdob works along a different principle.

 

Any "normal" CONTIGUOUS .iso extents can be mapped to a partition entry in the MBR.

 

If you think a bit about it, a partition entry is nothing (abstracting for one moment from the differences between CHS and LBA, let us assume that CHS is not used anymore, or that the whole extents are above the 8 Gb CHS limit) but an address table.

 

In a MBR entry for a "normal" volume/partition there are just three pieces of information:

  1. a partition ID
  2. the start address of the partition
  3. the length (or extents) of the partition

So, nothing prevents from writing to an otherwise unused partition entry some values to the effect of mapping a contiguous area of the disk as if it was a partition.

 

Windows will ignore an entry in partition table with ID 0 (0x00).

Linux will check anyway the actual addresses in the entry and, if it detects that the addresses correspond to a valid volume/filesystem (CDFS in this case) it will mount/access the .iso fine, for all it matters to Linux, it is a partition like any other one.

 

If you prefer, the partition ID is - contrary to what has been for years the beliefs of many (I would say most) people - not really a partition ID, but rather a "protective ID":

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/determining-filesystem-type.html

 

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

It's helpful you to be around and be picky, nothing bad.

 

Please correct me if I am wrong- I got the impression that if the ISO image is not isohybrid-ed, its contents, mapped as a partition, won't be used by Linux. Have you confirmed that for example, the same distro ISO image, on first case isohybrid image, and the seconds case non-isohybrid work the same way?

My conclusions were also based on attempts to boot this way *BSD ISO images, none of them worked unless no other files were required outside initrd/kernel, and all images were non-isohybrid. It could have been just the kernel/init scripts ignoring such partitions, no matter as contents of isohybrid-ed image or not.

Link to comment
Share on other sites

Sure I can confirm that a "normal", plain, Linux .iso image NOT isohybrided usually works through partition mapping (I seem to remember that there are a few that do not anyway).

 

The whole point is a specific feature of the Linux kernel/way of working (that not necessarily is common with BSD).

 

None of the several Linux .iso images that Easy2boot supports (but that you can of course map directly without using Easy2boot at all) through ISO partition mapping are modified in any way (and this is actually the big advantage of the method in general and of Easy2boot speciifcally), and AFAIK none of them are isohybrided (but I could be wrong about this latter).

 

Now that you make me think about it, I cannot confirm that an actually isohybrided image works this way, never tested that.

 

As a side note, gparted does NOT recognize an actual partition CDFS formatted as a valid one, though the method (though not with a partition ID of 0x00, but rather with a "normal" 0x83 partition ID) is used by a few particular Linux distro's, see as an example, Zeroshell:

http://www.zeroshell.org/

and:

http://gparted-forum.surf4.info/viewtopic.php?id=16632

 

The (nice) idea of that distro (which is a specialized "firewall/router" distro) is that the actual OS should be UNmodifiable and capable of working when booted from a CD/DVD, using *any* available media to save settings and logs, the hard disk or USB stick image in it is nothing but the actual CD/DVD version with a "loading" partition before and a "settings partition" after.

 

jaclaz

Link to comment
Share on other sites

My impression was that the isohybrid part actually tricks Linux to mount contents exposed such way, so they are accessible.

Just completed some tests with regular and isohybrid-ed variants of the same Linux images and they both worked the same way, thanks for the clarification, in this case compatibility is even better.

 

None of the several Linux .iso images that Easy2boot supports (but that you can of course map directly without using Easy2boot at all) through ISO partition mapping are modified in any way (and this is actually the big advantage of the method in general and of Easy2boot speciifcally), and AFAIK none of them are isohybrided (but I could be wrong about this latter).

 

Actually the most of the recent Linux distros come with isohybrid-ed ISOs, at least all of the 30-40 various popular distros checked some time ago when I was playing with this stuff. Never suspected or hinted that Easy2boot modifies them, since they already come isohybrid-ed, and I am also using this method in WinSetupFromUSB in all recent versions.

 

Anyway, thanks for the heads up.

Now since you brought me back to this subject, I am curios which part/script of the boot process actually is responsible and eventually are we all just lucky using a design flaw/bug/coincidence/just happens to work, or it's intended behaviour.

Link to comment
Share on other sites

 

Now since you brought me back to this subject, I am curios which part/script of the boot process actually is responsible and eventually are we all just lucky using a design flaw/bug/coincidence/just happens to work, or it's intended behaviour.

I think it is "intended" or "by design".

If you think a bit about it, there is some logic in the behaviour (both in the "Windows" and in the "Linux" one, though "different" logic).

Let's see what Windows does (more or less :unsure:):

  1. let's check the partition ID in each partition entry in the MBR
  2. if it is 0 ignore the entry
  3. if it is non-zero compare it against a list of known partition ID's
  4. if it is NOT among the known ID's AND the partition addresses are OK, show the partition in disk manager as "unknown"
  5. if it is among the known ID's AND the partition addresses are OK, probe the volume for the actual filesystem used AND IF this probing results in a known, valid filesystem, show the partition in disk manager with the proper volume filesystem type AND mount it (assign to it a drive letter in explorer)
  6. if it is among the known ID's AND the partition addresses are OK, probe the volume for the actual filesystem used AND IF this probing results in an unknown, OR invalid filesystem, show the partition in disk manager AND mount it (assign to it a drive letter in explorer BUT as soon as you try opening the volume you are prompted for formatting it)

Remember that if the partition type is 0x07 not necessarily it is a NTFS filesystem, as exFAT (and I believe also UDF filesystem in Vista :ph34r: and later) use also 0x07, remember also how - unlike on Linux - partitioning and formatting are "linked together", i.e. it doesn't really exists a mkfatfs (or similar) under windows, as when you format a volume, the volume resides on the device, and the format command also updates the partition ID, as better explained in the given link:

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/determining-filesystem-type.html

there is the need for "volume bootsector probing".

Now, we are used to a bunch of filesystems (FAT, NTFS, etc.) that do have the BPB in the bootsector and the bootsector is the first sector, but as an example UDF, has not (like CDFS) this, the good Linux guys are used in Ext2/3/4 to have it at a fixed offset from the beginning of the volume.

 

As a side note, try opening a isohybrid .iso with Winimage or with 7-zip, last time I tried Winimage "opted" for it being a (hard disk) volume, whilst 7-zip "opted" for it being a CD/.iso: 

http://reboot.pro/topic/9076-the-mistery-of-windows-7-install-required-cddvd/?p=172168

http://reboot.pro/topic/17715-iso-image-with-mbr-and-small-fat-partition/

http://reboot.pro/topic/9916-grub4dos-isohybrided/?p=86292

 

Let's see what Linux does (probably, please understand how while the previous ones are educated guesses about how a windows NT works, the following are more wild than educated guesses and I may well have some terms or concepts "wrong" or worse):

 

  1. let's check the partition ID in each partition entry in the MBR
  2. No matter if it is 0 or any value, link the addresses in the entry to a valid device, like /dev/sda3
  3. check the addresses in the partition entry are valid, AND IF they are valid, probe the volume for the actual filesystem used AND IF this probing results in a known, valid filesystem, proceed to mount it (if automount is enabled) and create a mount point for the extents described in the partition entry 
  4. more or less the Linux fdisk will "see" (just like device manager) *any* partition whose addresses are defined in the MBR, no matter if the eatents contain a valid (recognized) filesystem or not.

 

In the case of a "normal" .iso, most probably the Linux *whatever* checks sector 16 (which will be sector 48 because the device will have a 512 bytes sector size) and finds the CD001 and in the case of a isohybrid .iso checks first sector, understands that it is a MBR and not a volume bootsector and proceeds to check for the EXT2/3/4 superblock, doesn't find it, then goes on and checks sector 16 (please read as 48), and decides it represents a valid CDFS filesystem/volume.

 

What would be very interesting at this point would be IMHO to experiment on Windows with the UDF filesystem (on Vista :ph34r: or later) as the UDF can be used both as a hard disk volume and as a CD/DVD filesystem.

It is possible that "directly" or with a trick or two, we could manage to have under Windows a working entry in a partition table for a UDF volume which is actually a UDF .iso ....

 

jaclaz

Link to comment
Share on other sites

I was more interested about the init scripts which mount the fake partition, because that's where booting in such way may fail, and because Linux is way more flexible and doesn't really care much if mounting block device, a file or contiguous space as marked in the partition table. Mount utility seems to do fine its job as long as it recognises valid FS and kernel/udev scripts list the fake partition as a valid device in /proc/partitions for example to be in the list.

From what I found so far, the various Linux distros handle searching for and mounting the needed CD-ROM in different ways in their init scripts.
Debian netinst for example makes use of two binaries cdrom-detect, cdrom-checker, and a shell script list-devices to handle all that. Once candidate devices are discovered according to certain criteria, they are passed to mount to be checked for the tag files, and mount does not care if the device is a whole disk, partition or a file, just attempts to mount it using all known file systems, or cdfs if explicitly passed as argument.
ISO mounted as a fake partition is not found and used for example if using USB hard disk. In case of USB flash drive, no matter removable or fixed type everything is fine. Apparently somewhere along the lines devices which are (on) USB hard disks are excluded.
 

devices="$(list-devices cd; list-devices maybe-usb-floppy)"    for device in $devices; do        if try_mount $device $CDFS; then            break 2        fi    done        devices="$(list-devices usb-partition)"    for device in $devices; do        if try_mount $device $CDFS; then            db_set cdrom-detect/hybrid true            break 2        fi        if try_mount $device $FATFS; then            db_set cdrom-detect/usb-hdd true            break 2        fi    done	....	try_mount() {		# TO REMOVE, there is a bug somewhere in the kernel, the first		# mount command fail when changing floppy disk		# so we have to launch mount twice		mount $1 -tauto $MNT || true		umount $MNT || true		mount $1 -tauto $MNT		media_mounted && checkcontents $MNT		}	...	

Puppi Linux Slacko 5.6, uses probepart_init in the init script, which when listing all partitions uses /proc/partitions to make the list. The regex returns our /dev/sda4 too, which later on will be passed to mount and mounted eventually as CDFS.

 

Slackware (14.0) uses hardcoded device list - /dev/srN, /dev/hdX, /dev/pcdN etc, mounting the fake partition fails, it does not expect CDFS on a partition.

 

Trinity Rescue Kit searches in /proc/partitions for the given volume label using mlabel, which fails since it seem to expect partition with vfat file system.

 

Luckily, most other distros search in partitions for their files and when passing each possible partition to mount it succeeds mounting it as CDFS.

Link to comment
Share on other sites

Well, IMHO something that should be tested (on those not working) would be to try with a "valid" partition ID, let's say 0x83, i.e. it is possible that some of those not working don't "like" the 0x00 partition ID. :unsure:

 

jaclaz

Link to comment
Share on other sites

The partition is already listed by the kernel and available, it's the init scripts ignoring it because it doesn't match certain pattern, and partition ID is not part of it.

 

For the record, discovering and listing disks and their partitions in the kernel seems to happen in /block/genhd.c.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...