jaclaz

From the large "top" photo the "internal" connector seems smaller than the "external one" (which is a "normal" SATA one), BUT the position of the notches in the large "front" photo seems like it is NOT a micro sata. jaclaz

Agreeed. So why is in this particular image the 'no emulation' 'image' 'BootImage.img' in fact a FAT file system ? This strikes me as odd ? Aha. Aha! http://www.imdb.com/title/tt0094898/crazycredits?item=cz0003114 Let's wait until you can have a look at one of these Acronis images. A number of answers to your questions will become self-evident. Please do have a look at BOTH the little batch provided in the referenced thread: http://reboot.pro/topic/12406-editing-iso-files/ and to the one (latest temporary version) on post # 26 http://www.msfn.org/board/topic/172610-acronis-iso-boot-on-uefi-pc/page-2#entry1085084 They are both rather simple, and it is easier if you read their contents to understand the procedures I used. The "main" issue is not connected to Isobuster, it is a combination of a "lack" of info in the El-Torito specifications, with the way Isobuster (mis)represents the field. With reference to the mentioned specs: http://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf Figure 3 and Figure 5 the value on bytes 6-7 is NOT (as it appears in Isobuster) the SIZE of the image, but the: (this is the value that is "traditionally" set to 4 sectors). So, there is no real way, based on the entries in boot catalog to know the size of the image. Windows up to server 2003 and PE 1.x: With "Microsoft Corporation.img/ArnesBootRecord" there are no issues, as the loader file is actually 2048 bytes in size (and the Sector Count Field is also set to 4 sectors), if you right click on "Microsoft Corporation.img" and Extract, the result is correct Windows Vista and later (and PE >1.x): With "etfsboot.com" there are no issues, as the loader file is actually 4,096 bytes in size (and the Sector Count Field is set to 8 sectors), if you right click on "Microsoft Corporation.img" and Extract, the result is correct (the only issue, more philosophical than anything else is that the "fake" "Microsoft Corporation.img" filename is the same as the above) BUT the "EF" image (which is a "common" floppy disk image, 2880 sectors in size or 1,474,560 bytes) has a Sector Count set to 1 sector, and - obviously - since Isobuster interprets this field as size of the image, if you right click on "BootImage.img" and Extract, the result is ONLY the first sector of the boot image. The extracted file CANNOT be re-used. ISOLINUX based: If you can download the mentioned on the reboot.pro thread Slitaz .iso (it is only around 30 Mb) and open it in Isobuster, and try to Extract the "BootImage.img", the saved file will be just the first 4 sectors of ISOLINUX.BIN (and thus at the time I half-@§§edly solved the issue through the batch). The extracted file CANNOT be re-used. Same will happen for *any* .iso where the no-emulation file is actually larger than the size to be loaded initially (Sector Count field in boot catalog) In the Acronis images (NOT the WinPE based ones) the issue with the first image is just like the above, but for the EF image it is even worse , as - since the good Acronis guys set the Sector Count field to 0, if you right click on "BootImage.img" and Extract, the result is a 0 byte file. The workaround I used for the ISOLINUX.BIN implies that the file is "listed" in an "accessible" part of the filesystem (and at the time considered only one entry in the boot catalog and would not work for the "EF" images of all kinds, since they are not "detected" by isoinfo.exe), the workaround I used now is to attempt parsing the first sector of the image looking for a FAT PBR and use that data (which works for all the "EF" images - since their first sector is actually a FAT PBR - but fails for the "special" Acronis first image) then I added temporarily a workaround to the workaround , parsing a bunch of sectors until I find (hopefully) a FAT PBR, but still it won't work with an ISOLINUX.BIN or GRLDR no-emulation bootsector. What Ultraiso seemingly does is to consider *anything* after the boot catalog and before the first "indexed LBA in one of the filesystems as "boot information file" and saves the whole lot of it as .bif. I have not right now a "valid" idea to solve all these issues, the only thing I can think of is to combine these different approaches, though cannot really say "how". jaclaz

How large (width) is it (can you measure it in mm)? At first sight (judging from the size of the other components) it seems much smaller than the cable you linked to, it is likely to be a mini sata or a micro sata: http://www.amazon.com/gp/richpub/syltguides/fullview/RBX0KM9DMNFEJ http://www.forensicfocus.com/Forums/viewtopic/p=6572674/ jaclaz

The issue here is not your education level. The issue is that you have it in the WRONG FIELD! The topic "stable Windows setup" is multidisciplinary, but mainly connected to theoretical physics, philosophy, and religion, basically you need to believe in it even if if you cannot see it, and should doubt it when you see it manifesting itself. jaclaz

No problem whatever. According to the widely accepted definition of Latin Mediterranean Time, two weeks in Real World Time (or RWT) need to be doubled and the next larger unit of measure is to be adopted: http://reboot.pro/topic/1013-h7pluginbuilder/page-9#entry16104 Besides Mediterranean Time (MT) we have to introduce MTM (Mediterranean Time Maybe sometimes also called JAGT acronym for "just a guess" ) that simply takes Mediterranean Time and multiplies it by a variable coefficient k, where 1<k<4, on average, and approximately, 2. Doing some math from the dates announced here: http://www.msfn.org/board/topic/172299-the-upcoming-new-tool-for-win-78-my-suggested-name-nlitex/?p=1084275 August 24 2014+1 week (MT)+2 weeks (MTM)=August 24+1 week (MT)+2*2 weeks (MT)=August 24+2 months (RWT)+2*4 months (RWT)= August 24 2014 +10 months (RWT) There are different interpretations on whether the year is made of 360 commercial days or of 365 ones, and as well it is debatable if it is to be used the actual month number of days or use a conventional 30 days month, however, to be on the safe side, in order to be able to easily express the number of days in hex as 0x20 and in binary as 100000 , in computing matters it is common to use a power of two, 32 days per month, so, taken into account that in the period there should be not a leap year, the calculation resolves to: August 24+320 days (RWT) = July 10 2015 Thus, here is the new countdown: http://www.timeanddate.com/countdown/generic?iso=20150710T235959&p0=1962&msg=Release+of+Nuhi%27s+Unnamed+tool&csz=1&swk=1 Just imagine Nuhi's satisfaction in managing to release the tool BEFORE that deadline! : jaclaz

Thanks to zamarac mixing liberally different versions there is a lot of confusion . There are TWO "types" of Acronis .iso discussed in this thread: a. Windows PE based ones b. Linux based ones The Windows PE based ones are NO issue in ANY way, they are normal, plain, Windows PE .iso's with TWO images in the boot catalog, they are created according to the "normal" way to create these DVD's: 1) First image is a "normal" El-Torito No-emulation bootloader, 4,096 bites in size, type 0 or "80x86", corresponding to etfsboot.com, EXACTLY according to documentation (already linked to): http://support.microsoft.com/kb/947024/en-us 2) Second image is a "normal" (for EFI booting) El-Torito No-emulation floppy image, 1,474,560 bytes in size, type EF or "EFI", corresponding to efisys.bin, EXACTLY according to documentation (already linked to): http://support.microsoft.com/kb/947024/en-us There is NOTHING to discuss, doubt or question about the Windows PE based .iso's (with a small exception that is however comprised in the more general issues, and that I might re-highlight later). Please, please, please, let's STOP talking or citing the Windows PE based .iso's for the moment, they have NOTHING "peculiar". Back to the "issues", this is about the "Linux based" .iso's (and NOT about the PE ones). BIOS booting: We are used to use in traditional BIOS booting any of the 4 El-Torito modes, from the batch: The fact that modes 1/2/3 do not really mean "given size floppy image" but rather "with same HS geometry as given size floppy image" is a relatively recent discover by Rloew (and cdob) details are here: http://www.msfn.org/board/topic/152399-on-bootable-cds-floppy-emulation/ (this shows how even after all these years the actual specifications were not fully clear) Traditionally ONLY actual floppy sized images were used for modes 1/2/3, but as seen this is not really-really what El-Torito says. As well, traditionally for mode 0 a loader was used, commonly: 1) "Arnesbootrecord" or "MicrosoftCorporation.img" image sized 2048 bytes <- Windows install CD's up to Server 2003 and PE's loading SETUPLDR.BIN in the \i386 folder on root of the "accessible area" of the CD (and BOOTFIX.BIN) 2) etfsboot.com sized 4,096 bytes <- Windows install DVD's since Vista and PE's 1.x, loading BOOTMGR in root of DVD (and BOOTFIX.BIN) 3) isolinux.bin based, this is LARGER than 2048 bytes, yet the "size to be loaded" is still 4 sectors, and I had to write a small batch: http://reboot.pro/topic/12406-editing-iso-files/ to extract it properly, BUT the isolinux.bin was also listed in the "accessible area" of the CD 4) grldr (gruib4dos) based, also larger than 2048 bytes, but still with the "size to be loaded" normally set to 4 sectors in the boot catalog and with the grldr file also listed in the "accessible area" of the CD. To recap, we are used to see "No emulation images" that consist in a smallish loader that when booting chainloads other file(s) that is/are on the normally accessible area of the CD. The Linux based Acronis .iso is different: the No emulation image is hundreds of megabytes in sizeit consists of a loader prepended to a large FAT volumeat boot the loader evidently "mounts" this large FAT volume and runs files in itthe contents of this FAT volume are NOT (nor the FAT volume itself as an image file) indexed/listed in the "accessible area" of the CDThe El-Torito standard does NOT include in the boot catalog entry a field for SIZE of the image, it only has a field for the LBA START (location) of the image and a field for the INITIAL LOAD size: Now, if the first sector at the LBA START address of the image is either a MBR (in the case of type 4 or hard disk emulation image) or a PBR (in case of type 1/2/3 floppy emulation) it is possible to calculate the size of the image from the data in them. As well, in the case of a No-emulation image where the image is also listed in the "normally" accessible area of the CD/DVD, it's size can be derived from the CD/DVD filesystem (be it ISO9660, Joliet ot Rockridge). As well (though not written anywhere in the specifications, and yet AFAIK to be found "in nature") if the image is set to no-emulation mode but it's first sector is a PBR (and possibly also a MBR ) it is possible to determine it's size from the data in this first sector. BUT the Acronis image has a loader pre-pended (in the image I analyzed 12x2048 sectors or 48x512 sectors in size) so there is no way to know it's real size if not by either "scanning" for a PBR or making calculations from the LBA addresses NOT used in the "normally accessible" CD/DVD filesystem. EFI booting: I am not familiar with a great number of EFI booting CD's/DVD's, but it is clear from this experience that the specs uses in boot catalog: a. a Type 0 "no emulation" image b. an ID "EF" c. the Initial Load size (even if the MS CD/DVD do set it to 1 sector or 512 bytes) is completely irrelevant as the EFI firmware (unlike BIOS) has a "full featured" FAT filesystem driver and accesses the \BOOT\EFI\ folder and the file bootia32.efi, bootia64.efi or bootx64.efi ignoring it (and the good Acronis guys, in their simplicity , set this field to 00's) d. it is mandatory that the image is a FAT image AND that it starts with a PBR on first sector Now the "issues". Ultraiso takes the "whole lot", including BOTH the "BIOS" no-emulation image AND the "EFI" no-emulation image and exports them as .bif, without differentiating or making access separately to both of them. The .bif file may (but seemingly only the first image in it) be parsable by the same ultraiso (or it may be not).Isobuster has NO issues with the second (EFI) image, as it's first sectror is a PBR and a PBR of a "known" filesystem (FAT) but it cannot do anything about the first image (since it starts NOT with a PBR, but rather with the Acronis loader).The fact that doing a "sector scan" it can find the first image volume fine :thumbsup: is NOT (IMHO) a "solution" (another CD/DVD may contain n other images or parts of them including a valid PBR) and there would be nothing to point out that one among them is part of the first no-emulation boot image, and pertains more to "recovery" than to access .iso contents.IMHO the "visual representation" that Isobuster does of the Boot Catalog as if it was a "file", naming it BootCatalog.cat is partially deceiving, as what the boot catalog represents is a set of addresses/names, not unlike what a directory represents, and as such it would be nicer if it was represented as a "folder" containing the boot images.The data shown when Bootable Disc is selected in the left hand pane is partially deceiveing and/or incomplete or "wrong" , as the only "useful" information in it is the LBA start of the images (the name - as seen - may be "real" or "faked" or "half-faked", the Size column is mislabeled, the last LBA can be either correct or wrong depending if the total size of the image is the same as the size set for initial loading).The "issues" are of course of relatively low relevance, as - as seen - they can be worked around with a simple batch or by knowing what we have found in this thread and use a disk/hex viewer/editor at the light of these findings, yet I believe that Isobuster could benefit from a more intuitive visual representation of the .iso structure and from being capable of automatically recognize this particular kind of structures. jaclaz

Well: http://www.windowsbbs.com/windows-xp/17859-xp-tape-drives-backupexec.html 11th May 2003: http://www.techrepublic.com/article/product-review-an-analysis-of-backup-mypc-from-stomp/ September 17, 2003 Maybe Wikipedia (which is where you made your research ): http://en.wikipedia.org/wiki/Backup_Exec has it right, maybe not. https://web.archive.org/web/20040701101836/http://www.stompsoft.com/bump/ July 1, 2004 jaclaz

@Isobuster The point is that besides the "main" (no-emulation in these cases) image, a boot catalog (per ISO standard) can contain more than one bootable image. If you peek inside the batches I posted I have inserted in them some references to the data structures. These structures are coded in the El-Torito specifications: http://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf (Figures 2, 3, 4 and 5) Isobuster deals with these correctly , listing ALL the available boot images. BUT there are a few issue (some only as my opinions, some as facts), when the left-hand "bootable disk" is selected Isobuster lists (in the .iso I am testing with): Opinions: BootCatalog.cat <- this is a "fake" filename AND IMHO it is NOT a "file" but rather a "folder", and of course the .cat extension is "arbitrary"Acronis.img <- this is a half-fake filename, as the text "Acronis" is actually in the boot catalog entry, but the .img extension is "arbitrary"BootImage.img <- this is a fake filename, as the text in the boot catalog entry is all 00's, and the .img extension is also "arbitrary" as aboveFacts: The column "Size" is "deceiving", as the data in the entries does NOT mean "size of the image" but rather "size to be loaded", actually the specifications do not have a field for "size of the image"As well the column "Last LBA" is "deceiving" and also actually "wrong" as clearly it is a "calculated field" from LBA+(apparent) size of the image.There is no distinction between the "main" image (Acronis.img) and the second one (BootImage.img)There is no hint about the Type of image or "Platform ID" (it is missing somehow a column), the Acronis.img is type "00" (i.e. 80x86) whilst the "BootImage.img" is type "EF" (i.e. EFI see below)I have NOT checked the UEFI specifications (that were more than 2000 pages last time I checked ) but I trust (the exception that confirms the rule ) the good MS guys when they say that the UEFI specifications extended the El-Torito addding an "EF" id for EFI platforms: http://support.microsoft.com/kb/947024/en-us Now, the fact that the specifications miss a real size for the image and an offset to the actual bootsector when the image, as the "Acronis.img" in the example, is marked as "no-emulation" but contains a whole largish FAT image with a loader prepended to it) and that the good Acronis guys have been "naughty" (IMHO breaking the compliance) with the "BootImage.img" by NOT filling any of the other fields in the entry (apart the 91 for the "last image", the "EF" for the "type" and the 88 for bootable and the actual LBA start) are not good reasons for a tool aimed to "bust" an .iso to "completely miss" the "Acronis.img" and to provide "queer" data for both the "Acronis.img" and the "BootImage.img". It would be nice if your nice tool could *somehow* deal with these little queernesses and provide *somehow* a way to deal with the "hidden image", i.e. an image that is listed on the boot catalog but that does not begin with a known filesystem data structure such as a bootsector and it's BPB, after all, without zamarac observations, looking at one of these Acronis iso's would have lead to completely "miss" the files listed in post #7: http://www.msfn.org/board/topic/172610-acronis-iso-boot-on-uefi-pc/?p=1084987 Of course if one "scans" the whole .iso looking for FAT ISOBUSTER willl find the "missing part", but it would be IMHO nicer if the tool could "parse deeper" the actual Boot Catalog entries. It would also be nice if (on the left tree) the "unnamed" FAT filesystem were given a "fake name" like: Start_%lba%_Extents_%sectors% i.e. basically the data that I get through my half-@§§ed batches, as this would IMHO make visually easier to interpret the contents of the .iso. @zamarac In other words, your results with the WinPE based .iso were EXPECTED. There is NO question about how a WinpE CD/DVD boots on BIOS, it boots through a "real" no-emulation bootsector, what is called in jargon "Arnes Bootrecord" or "MicrosoftCorporation.img" i.e. a self-standing real-mode loader that was 2,048 bytes in size in PE's 1.x and became 4,096 bytes since the advent of Vista/PE 2.x. (this is the thingy that checks the hard disk and if it is partitioned and has an active partition, loads BOOTFIX.BIN, which is the thing that prints on screen "press any key to boot from CD ....") I am not sure to understand this: What do you mean by "wrong" size? And what by resulting in mounting a CD instead of floppy? AFAIK the "automatic" setting in IMDISK uses "other parameters from size" to choose the device type (and no, I don't know exactly how it decides the kind of virtual device it auto-selects). Open the image with a hex editor and check the number of sectors in the BPB. In IMDISK do not let it choose "automatic" settings, choose yourself manually either "floppy" or "harddisk volume", set the volume to "read only", run CHKDSK on it. jaclaz

I understand , the idea being that Stompsoft seemingly (before Symantec took over) got the Seagate Backup Exec (which was seemingly Veritas made anyway), so it should be the thing more similar to the old Win98 app (though cannot really say if it will help you). jaclaz

Similarly, is it clear (to you), why UltraISO can show the content of ATIH2014_Linux.bif (what I call bios.img), but not the content of ATIH2015_Linux.bif (which is surprisingly only 2Kb in size compare to ATIH2014_Linux.bif at ~300Mb and ATIH2015_WinPE.bif at 4Kb)? No, I have no idea, though most probably the WinPE version uses a "normal" no-emulation bootsector, 1, 2 or however a few sectors in size. (i.e. there is in it no "hidden image" at all. The point is IMHO the other way round, i.e. how (the heck) it can access a .bif file which first sector is not a bootsector. Temporarily, try this modified batch (this is really @§§ed , it will list on "normal" .iso's with a "small" no-emulation bootsector the EFI image twice). Once the results are clearer, I may re-write the thingy with some more checks to avoid double detection (and possibly with some better structure). jaclaz AcroCD_003.zip

Why not/since when? When you drag and drop AFAIK the filename (including path) of the dragged an' dropped item is passed to the destination (like %1). http://www.msfn.org/board/topic/153292-dragndrop-with-cmd-batch/ And specifically, you can run that icon extractor from a command prompt fine with - as argument - the file (or folder containing the files) from which you want to extract the icons. What may be pointless is that the icons will go in a \icons folder in the same path as the BatchIconExtractor.exe, and you may soon have it full of "mixed" icons unless you empty it before extracting more icons. jaclaz

YMMGV: http://www.windowsbbs.com/windows-xp/17859-xp-tape-drives-backupexec.html https://web.archive.org/web/*/http://www.stompsoft.com/ https://archive.org/details/tucows_368095_Backup_MyPC jaclaz

Yep, you quoted TELVM's post and he burned all your allowance @TELVM Cannot really say why , but video reminds me of : jaclaz

I am starting to see. As hinted before it seems like the good Acronis guys are NOT making a "standard" CD. UltraISO is reknown (to me at least ) to do some non-standard things as well (often, additionally not particularly well documented) . In the 2012 iso image I have handy, the situation is as follows (and I believe the ones you have are not that much different). There is actually a "hidden" volume image (FAT16, making use of the proprietary Acronis BOOTWIZ bootmanager bootsector) that extends from sector LBA 52 (2048 bytes sector) for an extent of 194397 sectors (in 512 bytes sector). The actual Boot Catalog is on sector LBA 39 (and does NOT "index" this image). Sectors LBA 40-51 contain binary data (possibly a loader of some kind, I'll have a look at it), which is the file that both UltraIso and Isobuster see as "Acronis.img". The issue with a No-emulation entry in Boot Catalog is that it provides NOT the extension (size) of the image, but rather the number of Sectors to Load (usually 4, and that is the reason why originally the bextract.cmd batch was written http://reboot.pro/topic/12406-editing-iso-files/ ), all utilities will "see" (and incorrectly show as "size") only the "size to be loaded". The first "next" LBA sector actually indexed in the Boot Catalog is the "next" entry (the EFI one) on LBA 48652. What Ultraiso extracts as .bif is sized 187,869,184 bytes,i.e. 187,869,184/2048=91,733 (2048 bytes) sectors. The actual .bif then comprises BOTH the "LARGE El-Torito No Emulation image" i.e. is the extents 40-48651 that are made of: In 2048 bytes sectors: Loader 12 sectors FAT 16 image 194397/4= 48599.25 rounded to 48600 Some "mystery" sectors <- (need to double check) AND the whole extents 48652-91773 of the "EFI" image (that UltraIso *somehow* does not "detect/highlight" properly in the sense of "separating it from the first", it exports the .bif containing "all it can find"). 91773-40=91733 which is the size of the .bif, Q.E.D. So, if you mount in IMDISK the .bif, once with image file offset 12*4=48 (512 bytes block) you get access to what you call "BIOS.IMG", while if you mount the same .bif with image offset (48652-40)*4=194448 (512 bytes block) you get access to the "EFI.IMG" You will need to replace the 40 and 48652 in the above calculation with your values, and as well it is possible that the size of the loader is not in your .iso's 12 sectors, but once adapted it should work on your images as well. It is still not clear at all (to me) how can UltraIso later "show" the contents of the .bif (which actually are the contents of the first FAT image, most probably it simply scans the file to find a recognizable BPB :unsure., I'll have to check with some dummy data. About the little batch, if we put a "limit" (using common sense) to the possible size of the loader (let's say between 1 and 20 x 2048 bytes sectors) i.e. to the extents of the "search" for the bootsectors/BPB that needs to be performed, and we assume that the image is FAT formatted, it will be easy to find it and extract the corresponding sectors. Still it has to be seen what the "mystery sectors" are related to. jaclaz

I am not sure to understand what you mean by "BIOS.IMG" Do you mean the "no-emulation bootsector" or "no-emulation image"? I.e. the one that in the screenshot you posted: http://www.msfn.org/board/topic/172610-acronis-iso-boot-on-uefi-pc/#entry1085040 is 8 sectors in size and on LBA 186? Or *something else*? Can you post a more complete description of this "BIOS.IMG" or a screenshot of Isobuster or Ultraiso showing it? The issue with GRUB2 booting a .efi file from a "loopback" device is - I believe - similar to the reason why Firadisk or Winvblock is needed for grub4dos booting Windows XP / PE's 1.x from .iso (and a ramdisk is needed also for Windows 7 install from .iso), at a certain point in the course of the booting process the grub4dos "real mode" hook is lost (unless another driver hooks it) and in the case of GRUB2 and loopback device, if the booted object is a Linux, the "real mode" loopback is "kept" by the Linux kernel (or whatever) but is lost because the Windows PE 3/4/5 misses a ramdiskl or filedisk driver hooking the loopback device. jaclaz

At lest early attempts failed, but you never know what may happen : jaclaz

As said, the PE based .iso is likely to use an approach for EFI similar to the "standard" Windows 8/8.1 .iso's (which is a "1.44 Mb floppy image" even if the "type" is "No-emulation"). The posted batch was "targeted" to a "large" image only my bad. Find attached a modified version 0.02 of the batch that takes into account "small" images . More technically it attempts to parse the "Large sectors" of the FAT image and if they are 0 it parses the "Small sectors". If it is like that, i.e. there is a floppy image that contains a bootia32.efi or a bootx64.efi or a bootia64.efi in folder \efi\boot\, probably that is the file to be chainloaded On a "normal" Windows 8 install .iso, these files are also in the "normal" part of the CD/DVD, I believe that there are different kinds (how surprising ) of EFI/UEFI implementations, one, if you want more "strict", that looks for the "EF" image, and one that parses the UDF filesystem and finds the files in the "normal" part of the CD/DVD and these CD/DVD's are made in the attempt to cover all possibilties. Also, the mentioned "dual mode" switches for OSCDIMG use a somewhat third approach, linking to the efisys.bin file "directly" (i.e. the \efi\microsoft\boot\efisys.bin is a "whole" image, a FAT 1.44 Mb floppy one, that contains the \efi\boot\*.efi and that can thus be chainloaded by GRUB2 as if it was the EFI image). BUT I wouldn't be so sure that the GRUB2 loopback approach does actually work chainloading a .efi file, see: http://reboot.pro/topic/18313-grub2-iso-booting/ cdob surely will be able to comment more appropriately on this. jaclaz AcroCD_002.zip

Well, actually we were particularly critical on the tablet/touch oriented switch of the GUI of the newish stupid OS, but the difference between a laptop and a tablet has been always clear enough, at least according to the good guys @Lenovo: http://www.lenovo.com/us/en/faqs/laptop-vs-tablet/ (bolding is mine ) So, we were not the only ones to predict that the idea of completely replacing laptops with tablets was deemed to failure. jaclaz

My bad , I mistakenly read the price in Euro, which is € 23.75 (+22% taxes), corresponding to US$ 29.95 (+22% taxes). jaclaz

Well, the real issue with "electronic download" (as opposed to a good ol' box containing the install media and the manual) is that you cannot print on it (in large, unfriendly letters ) a message like RTFM!. Personally I like "aggressive" interfaces , even without going all the way to : http://xkcd.com/293/ one could add to the "nag" message a line like: But clearly, a registered user will input the key and never notice it. On the other hand, if I had US$ 1 for each user that posted on the 7200.11 thread without reading the Read-me-first, nor the FGA's and the specific thread "don't even think to make a PCB swap", all stickies here: http://www.msfn.org/board/forum/169-hard-drive-and-removable-media-issues/ asking about PCB swap's, I wouldn't be rich, but I could have had some more beer , so I guess that there is no possible solution making everyone happy. jaclaz

This is the part that "sounds" very different from previous experience. At first sight, it seems like *something* *somehow* changed the drive map, putting a "Cap" on it. You can *try* (of course with NO guarantees whatsoever) to reset the drive to deafult values with a F,,22 , but really cannot say if it can be of any use. Read around here: http://www.msfn.org/board/topic/128807-the-solution-for-seagate-720011-hdds/?p=985252 AND given link: http://www.msfn.org/board/topic/128807-the-solution-for-seagate-720011-hdds/page-19#entry832570 @Mrich0908 Nice to know , but of course *anything* that can send/receive TTL (at the right "low" TLL level) would do, usually people "playing" with Arduino's also have one or more suitable USB to TTL or Serial to TTL converters, and - more than that - they usually know how to interface things successfully, so I am not surprised that it wasn't mentioned before as posters on this thread - usually - post here looking for help/support as they are not familiar with the matter, while most people knowing where their towel is will simply run the commands an unbrick the drive, without ever posting about their experience. Thanks for sharing it . jaclaz

I found and checked the 2012 version. I kinda expected that Isoinfo would have listed only the first boot image, but I was surprised that it doesn't list properly the "normal" contents of the CD. I suspect that the good Acronis guys are making .iso's which are not fully-fully conforming to the standard. However, I am putting together one of my usual half-@§§ed batches to interpret directly the structure, and it seems to me that there won't be problems. @cdob The method of assuming that the extent of the image is "up to the next LBA" (while working ) is not entirely "foolproof", since the EF image needs to be FAT, I am instead parsing the bootsector of the image, counting the sectors in the BPB. @zamarac In Isobuster, go to: Options->File systems Settings->El Torito (boot) Check "Check boot-image(s) for FAT and list files and folders if present" you will see a new item in the left hand window "tree" which will be the FAT image (and it's contents) . BTW, once one has the "right" offset in 512 bytes sectors, the FAT image can be mounted in IMDISK fine . jaclaz P.S.: Attached the small batch, it may be more "verbose" than really needed, but anyone can remove the ECHO's that may be considered superfluous. It needs dumphex http://rbach.priv.at/DumpHex/ Have fun. AcroCD_001.zip

CTRL key? http://www.msfn.org/board/topic/170850-aero-glass-for-win81-125/?p=1067581 jaclaz

Actually it was more about automating the generation of the right offsets (and of the actual GRUB2 entry) avoiding the risks about mistyping the offsets read on a GUI tool. I have NO idea how the .iso's are actually made (and no I won't download a - ahem - of doubtable origin .iso just to check how it is made). I do have *somewhere* an old version, possibly 2011 or 2012,, if I recall correctly, IF I find it, I may have a look at it (provided that uses the same approach) and put together a quick batch. And as said, I presume that the WinPE version will be completely different, and will need a completely different grub.cfg entry, presumably similar to those of a "normal" Windows PE bootable CD/DVD. About the Linux based image, try dropping to the GRUB2 command line and try the commands: Then, issue command: you should get a directory listing of the files in the loopback device (and among them there should be a dat8.dat and a dat9.dat files, otherwise the following commands. would give you an error. jaclaz

Well, how did you derive these two values?: ElTorito (loop)582684+304124 Bootimage.img LBA (as seen in IsoBuster) 145671 *4 = 582684 (here you are simply transforming the address expressed in 2048 bytes/sectors - standard for .iso and CD/DVD media - into 512/bytes sectors - used in floppy and hard disk like devices) Lowest next LBA is 221702, hence 221702-145671= 76031 and 76031*4=304124 If the isoinfo tool works on that image, it is pretty easy to parse it's output to get those numbers, do th esimple calculations and output a "custom made" GRUB2 grub.cfg entry. Can you try getting isoinfo (part of the CDR tools): http://www.student.tugraz.at/thomas.plank/ and run the command isoinfo -d -i isoimage.iso An example output would be something like: The 37 above is the LBA address of the (only) Boot image in my .iso, if the isoinfo works on your image you might have two entries, one pointing to LBA 29 and one pointing to LBA 145671 (corresponding to your first isobuster screenshot) As well, if you run: isoinfo -l -i isoimage.iso you will have an output *like*: corresponding to your second isobuster screenshot, from which it will be easy to get the smallest LBA bigger than 145671 jaclaz