jaclaz

Yep , the last screenshot is "perfect" jaclaz

Maybe it's better if you use the GUI version, use 4096: http://www.ridgecrop.demon.co.uk/index.htm?guiformat.htm I don't think so, it sounds "strange" to me. From what you say, it seems like your MacOSx (or the way you have set it or use it) uses GPT partitions ONLY. If this is the case, it's outside my area of knowledge/experience, but you will need some dedicated tool and possibly a hybrid setup, start from here: http://reboot.pro/11600/page__st__32 BTW, this partitioning problem has slowly but steadily been diverted from Original Topic. I will move all related posts to a new thread, as to "unclog" this already very long thread, as soon as you acknowledge this. JFYI, while you were playing with your hard disk , someone has been working : http://www.911cd.net/forums//index.php?showtopic=24392&st=10 Once solved this other problem, the USB_Part_Flip.exe should be able to easen the implementation of the partition entry exchanging. jaclaz

This is "strange". I mean, let's take the case when you ALREADY have an installed 2K or XP on the internal hard disk and you want to install (from a "normal" CD) an "additional" instance. The BOOT.INI already on root of "C:\" is not overwritten, the entry to the "additional" instrance is added to it. (actually the existing BOOT.INI is first modified to add the temporary entry for the install (after reboot) and then this temporary addition is removed. Maybe this happens because when you boot the CD the BOOT.INI is ALREADY there? Or maybe some checks (just like the ones for the CATCH22 trick) are performed to verify that another instance of windows is present? I dont' think the latter applies, I mean, if I do a dual boot install of DOS (7.1/8.0) and XP (on a FAT32 C:\ drive) then I decide to delete the whole Windos stuff, the "Bootsect.dos" file and the entry pointing to it should not be deleted when I re-install XP. But yes, the binifix batch was at the time created to solve this issue AFAICR (a lot of time has passed, and my memory is not as good as it used to be ), relevant links should be these: You will need some time to go through the various steps taken, I cannot even remember if this has been added/coorected jaclaz

Maybe there is some incompatibility, but cannot really say which . Do another thing. Create the 6Gb and the 200 Gb in Windows disk Management. DO NOT format them. Create the third partition in Windows disk Management. DO NOT format it. Format the third partition with MacOs. <-this is the step that seemingly messes the previous two partitions data, though I am not familiar with MAC, it sounds to me "queer" that you cannot create a partition in it or that it messes the partition table Delete first and second partition with Disk Management. Re-create the first partition 6 Gb and format it in disk management as NTFS. Re-create the second partition in Disk Management and DO NOT format it. At this point first, second and third partition shoudl have the "right" addresses/data as seen in the DTIdata tool. Leave the Tokiwa FAT32formatter alone and use INSTEAD the Ridgecrop FAT32format for the second partition: http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm jaclaz

Good, now re-write the previous values for the first two partitions, leaving the third untouched. What happens= (the only thing that CANNOT happen is that you lose the "third partition"). OR, delete the first two partitions and recreate them as you did before (still leaving untouched the third partition) jaclaz

Well, NO. What you report makes no sense. You probably (please read as definitely) did a mistake in inputting the values. (or maybe th etool is not working as expected) Try again, create the 6Gb and the FAT32 partition. DO NOT exchange their entries. Create the MacOSx partition. Report what happens. jaclaz

That's actually good/correct. First partition (second partition entry) is ENTIRELY inside the CHS limit of around 8 Gb. If it still reads 0/32/33-740/41/5 is OK (with the mentioned caveat of alignment to boundaries) Second partition (first partition entry) BEGINS below the said limit BUT ENDS after it (1023/254/63) If it still reads 740/41/6-1023/254/63 is OK (with the mentioned caveat of alignment to boundaries) Third and fourth partition are ENTIRELY OUTSIDE the limit, so they have rightfully BOTH begin and end set to 1023/254/63 The screenshot you posted on post #1417 showed how ALL the partitions (including the first two) were set to 1023/254/63, which is/was WRONG. jaclaz

It is possible that the CD laser (or it's circuit) has failed. DVD writers have TWO laser diodes. It is perfectly possible that one of the two has died while the other is still perfectly operational. See: http://www.die4laser.com/dvd-rec/DissectionofaDVDwriter.htm jaclaz

Our Mac friends seem like not too happy about them: http://www.xlr8yourmac.com/feedback/express34_card_reports.html but the reports are quite controversial. jaclaz

Won't setting it to manual IP addresses solve the problem as well? jaclaz

Just for the record, and OT 7-zip may be enough http://reboot.pro/6492/page__st__18 jaclaz

Add the MacOSx partiion (or whatever). Verify that the first two partitions have not changed (as seen in the DTIdata tool). Re-run WinsetupfromUSBwithGUI. Re-test. jaclaz

If it's a hard link, instead of guessing the location , one could use hlscan.exe .... This is the 2K version, it should work on later OS versions too (at least it does on XP): http://www.microsoft.com/downloads/en/details.aspx?FamilyID=289adee4-abb3-4e18-ab07-c77db8654979&displaylang=en If it's a junction (symbolic directory link) , one can use junction.exe ... http://technet.microsoft.com/en-us/sysinternals/bb896768 jaclaz

Why don't you simply try doing it? Quick selection guide : if it works, no problem if it doesn't work, we will find a way to fix it. I have NO idea whether MacOSx respects cylinder/heads boundary "old" standard or just like Vista :ph34r:/7 allows for fractional end heads/cylinders. In the worst case you can re-partition creating the two first partitions (the NTFS and the FAT32 one) on boundaries. jaclaz

There is something that is "just not right". From the last screenshot you posted seems like you have "removed" all CHS data ("leveling" it to 1023/254/63). This way CHS data is not anymore balanced with LBA data. Besides, this, you seem like running a "standard" Windows 7, which does not anymore respect cylinder and head boundaries. This is not normally a problem IF you ONLY use "newish" (post Vista ) partitioning tools and NEVER use DOS, Windows 9x/Me, Windows 2K/XP or Linux partitioning tools. Basically Microsoft "changed the rules" they themselves established (starting with Vista ) so older tools/apps may decide to "correct" these non-standard (or better said maybe non-orthodox settings) and this can cause data loss. A recent example is here: and a few more dated ones here: http://reboot.pro/9897/ As said, they do not represent a problem, if you know that the problem exists and take steps to avoid it. With a setup like the one proposed, the grub4dos MBR will be able to only access/read the 6 GB partition (located BELOW the 48 bit LBA limit BUT second entry in the Partition Table) and since the " the "usb divx reader" seemingly works with the 200 Gb partition, no matter where it is located, as long as it is first partition in the Partition Table, you should be fine and dandy. Still the proposed "solution" is actually a "workaround", as the "real solution" would be to change BIOS code, see here for a quick reference: http://reboot.pro/13387/ The problem remains only that of fixing the source on second partition for the XP install, I tend to think that this will be trivial for ilko_t as soon as he happens to "pass by" and notice the issue. jaclaz

No prob whatever, take all the time you need (and more) this is FUN, remember About fixing a drive letter, the reference is "migrate.inf": http://www.911cd.net/forums//index.php?showtopic=19663 that can be used for other tweaks too. Sure , I would say excellent instead of "not too bad" I am thinking about it, but without *ANY* third party tools (and no batches) I think it is hard. And anyway there may a difference between "running Vista or 7 and installing XP" and "running XP and installing XP". jaclaz

This is very nice. Yes, but you see, under XP diskpart or disk management won't allow the partitioning, and you need a third party tool anyway, be it a "RMPREPUSB like" utility or the Cfadisk/dummydisk driver or anyay something "designed" to have the stoopid stick properly partitioned and bootable. I don't remember having noticed any problem with "drive number" in the BPB, but as said it is perfectly possible that it does create problems. That's why I said : I mean, we do know that in order to set the stoopid variables, the RC needs to access ONLY some very limited parts of the Registry: it is very possible that bootcfg looks for "something else". For testing purposes, try copying a "whole" Registry to the "\whatever\System32\config" directory (but probably also some keys in it needs to be changed) Sure , not at all a problem for this use/purpose of this project, which is anyhow reserved to people that know where their towel is.

It doesn't work this way. If I ask you to do something, there are REASONS why I ask you to do that particular thing (and NOT another thing) and I would appreciate if you could: do what I ask you to do do NOTHING else report EXACTLY what you did and the result you had My crystal ball is (again) out of tune and I cannot know what is your current setup unless you describe it EXACTLY, COMPLETELY and FULLY. The DTIDATA tool screenshot you posted lately shows an incorrect partitioning, that may cause DATA LOSS in some cases/when some tools are used. Of course you are perfectly free to use the disk "as is" . WHICH version of WinsetupfromUSB withGUI are you using? The Beta 1.0-7 has a rather complex mechanism of booting through different .lst files. The settings you need to modify (if possible to solve this issue with a simple Edit) are AFAICR either in winsetup.lst or the various 1.lst, 2.lst, etc. jaclaz

Forget about it (for the moment), we will find and fix that when we will have solved the "other" problem. Any difficult part in: In first line you have: No/32/33/NTFS/41/5/740/2048/11888640 and in second line: No/41/6/740/FAT 32/254/63/1023/11890688/419471360 Change first line to: No/41/6/740/FAT 32/254/63/1023/11890688/419471360 Change second line to: No/32/33/NTFS/41/5/740/2048/11888640 Is the above difficult? ANYWAY, DO NOT DO IT, your current partition data is also invalid. Redo from start: Use ONLY Windows 7 Disk Management. Delete EACH and ALL partitions. Create a new partition, around 6 GB in size, partition it as NTFS, make it ACTIVE. Create a new partition, around 200 Gb in size Exit Disk Management. Use either of the mentioned FAT32 formatting apps to format the 200 Gb partition (drive). Verify that you can write and read files on both partitions. Use the partition tool to EXCHANGE the data in first two lines. Reboot and check that you can still write and read on both partitions. Copy a movie or whatever to the FAT32 partition and test if "usb divx reader" works with the disk. jaclaz

You are perfectly right about the bizzarreness of having the docs only in the stable and as well about the fact that the info is not much highlighted (please read as NOT highlited at all). As often happens the Beta should have led quickly to a "new stable", but we are still at Beta 7. About the .exe I am not so sure. I mean the idea of having a stable and an experimental beta should be that people should ONLY use stable at first attempt(s) and only later try the beta. The MS system sweeper is nothing but a (dumbed down) WinPE 3.x, so, yes, it will "conflict" with *anything* BOOTMGR/BCD based. See here: http://reboot.pro/14487/ If you want multiple Vista or 7 based thigies, you may want to take another "path", see the above and: https://sites.google.com/site/rmprepusb/sweeper https://sites.google.com/site/rmprepusb/tutorials/multiisoimdiskautounattend (and there are more similar on the RMPREPUSB site) You need to take the whole thing in a "historical" view, the "Install Windows from USB" was once named "Install Windows XP from USB", that was (is) the tricky part. Installing Windows 7 from USB is relatively easy, though finding a way to manage it through a .iso wasn't actually straightforward : http://reboot.pro/9076/ but if you only use/have 7 and one or more PE's the pointed to approach is probably more suited to your needs. BTW, another NOT highlighted piece of info on first post of the thread reads: that also brings you to the RMPREPUSB site, though to an older approach. Things are ever-changing and it is difficult to keep things together and in a "tidy and ordered state" .... jaclaz

Happy you made it. jaclaz

Are you familiar with a hex/disk editor? Or can you use this thingy here: http://www.dtidata.com/ntfs_partition_repair.htm or a similar app. The idea is to try and see if we can "trick" the "usb divx reader" into accepting the partition even if it is not "first" on disk. Most of the times these kind of thingies look for the partition that is in first entry of the partition table (no matter if it is actually first partition on disk). So you can try the following: create a 6 Gb partition NTFS crete a 200 Gb partition FAT32 run the tool and jolt down partitions data edit the partition table, copying 2nd entry contents over 1st one and 1st entry contents over 2nd one see if the "usb divx reader" sees the FAT32 partition now. jaclaz

Verified. Debug has no direct disk access under any of NT/2K/XP and latrer OS. I start to think that there is nothing capable of accessing a disk sector in "default" MS OS install so, it's a dead end. jaclaz

On WHICH environment? Maybe you are trying to use a WinPE 3.0 instead ofa WinPE 2.x? (read just a few posts above yours) jaclaz

Yes, but you are missing the point. For some reasons (that we are trying to understand) grub4dos DOES NOT recognize *ANY* partition but the first one as validly formatted (or if you prefer as containing a valid filesystem). This means that there is no sense in forcing grub4dos to search in second partition, since right now it CANNOT ACCESS it. The 200 Gb size is HUGE. You can try (as an experiment) to reduce the size of first partition FAT32, so that it is around 120 Gb. It is possible that grub4dos (or your BIOS) does not, for any reason, provide correctly 48 bit LBA addressing, so anything above the 48 bit LBA limit: http://www.48bitlba.com/overview.htm becomes "a suffusion of yellow". You can use (again WHICH WIndows are you running?) any of: http://tokiwa.qee.jp/EN/Fat32Formatter/ http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm to format the partition under Windows (definuitely 2K/XP, cannot say Vista or 7). jaclaz