jaclaz

Good . I would add "unexpectedly". I really don't get it, maybe it is just me, but I don't understand people that asks for assistance/suggestions/ideas and then completely ignores them insisting on doing random things they know nothing or very little about. Probably I am too old (besides grumpy) for this kind of non-communication , jaclaz

Ok, The blocklist command tells you where exactly (on which extent(s)) a file resides on the volume. The (hd2,0)284918+3 is ok. The file is non-resident (on NTFS), is contiguous and it takes three sectors. The (hd2,0)6412[296-682] is the peculiar case of a resident in the $MFT file, and it makes sense since later you have it as (fd0)1262+1, i.e. it occupies only one sector (for max sizes of $MFT resident files on 512 bytes and 4KB sectored devices, please read as record 1KB and 4KB), see: https://www.forensicfocus.com/forums/general/mft-resident-data/ Earlier version of grub4dos had issues with these (hence the "default" file was made 2KB) But evidently that is not the problem. The problem must lie in something similar (or connected) to the gzip issue (but the gzip header is completely different 1F 8B) The 4C (or more likely the 4C 00 or the 4C 00 00 00 or the 4C 00 00 00 01 14 02 00) must be triggering *something*. What happens if you cat --hex the blocklist? (no idea if it changes something ) I.e. try blocklist /lnkfiles/irfanW10.lnk (hd2,0)284918+3 cat --hex --length=16 (hd2,0)284918+1 jaclaz

Then use nlite. No wait, nlite didn't work for you. Only for the record, the difference is that nlite integrates (slipstreams) drivers in the install source media (let's say on CD[1]), while the IntegrateDrv integrates them on a later stage, on the pre-expanded[2] installation media. Hint: #1 is almost entirely in \I386 #2 is in two directories: '$WIN_NT$.~BT' and '$WINT_NT$.~LS' It doesn't seem to me like hidden info: As said, no idea if it may make a difference in your case, it is perfectly possible that there is no way to install 2K on that PC, but right now we have listed 3 among the maybe 5 possible ways, and you ony tried (failing) one. And, once again: Personally I would still try making a plainer attempt with no AHCI, via DOS and WINNT.EXE on FAT32. https://msfn.org/board/topic/181798-the-installation-of-windows-2000-was-blocked-in-lenovo-g500/?do=findComment&comment=1186272 but again, no idea if it can work on your hardware, there are too many variables and unknowns (both known unknowns and unknown unknows). jaclaz

No. The MBR has nothing to do with that, it ONLY defines the addresses of the extents assigned to a partition or volume. Scandisk, chkdsk, etc. do not work at disk (whole thing) level, but at drive (please read a partition, volume, filesytem or "whatever gets a drive letter in windows") level. Cross-linking of file (if any) depends on FAT tables on FAT or $MFT (or $Bitmap) on NTFS corruption. jaclaz

Scandisk? You mean Chkdsk? However no, both are "high level", i.e. at filesystem level, chkdsk (and scandisk) simply take note of a bad cluster and promises (it has to be seen if the promise is maintained ) to never let NTFS use it again. What may (should) have made a difference if the WD tool. Buy if you have HD sentinel (the pro version not the free one) you can try "repairing" weak/slow sectors: https://www.hdsentinel.com/hard_disk_case_weak_sectors.php Alternative free tools may be Victoria for Windows, MHDD and hddat, all of these are very "powerful" tools, that if used incorrectly can easily make big holes in your hard dik, so they should be used with attention. jaclaz

With which switch? Is that with /B? Added colour/bolding to the relevant entry. Presuming that it is the same cluster which is first removed and then re-added , it is one cluster in total. Assuming that (as it is normal) that NTFS fileystem is 4KB/cluster, a single "bad" sector (512 bytes) out of 8 in a cluster will cause the whole cluster to be added to the $BadClus. Still it is strange that the manufacturer tool didn't find and remap it maybe that (those) are not really-really bad sectors but just weak/slow ones. jaclaz

The bootsect.exe need depends on which OS you partition and format the USB stick. Windows 2000 and XP have a single type of PBR code/bootsector. Vista and later will automatically use their own bootsector but there is this tool, bootsect.exe that can write either the /NT52 bootector (please read as 2000/XP one) or the /NT60 one (Pleae read Vista/7, etc. one). If you have on the other PC where you partition/format the USB stick 2000 or XP you don't need to run it. If you have on the other PC where you partition/format the USB stick Vista or 7 you need to run it with the /NT52 swotch to change the PBR. http://vm1.duckdns.org/Public/IntegrateDrv/IntegrateDrv_1.1.9.zip contains BOTH the 32 bit and 64 bit executables, the 32 bit one is in \IntegrateDrv\x86\ See the picture on the given page: http://vm1.duckdns.org/Public/IntegrateDrv/IntegrateDrv.htm You want to extract somewhere the whole \IntegrateDrv\ folder, then navigate to the \IntegrateDrv\x86\ and run the IntegrateDrv.exe from there. jaclaz

You can try to use the Winnt32 approach with Windows 2000: http://reboot.pro/topic/18107-integratedrv-install-xp-2003-to-a-usb-30-disk-and-boot-from-it/ You need to make an on USB "localsource" with Winnt32 running on another PC, then add the Wait4UFD driver, then add the AHCI/SATA driver with integratedrv. Will it work? Cannot say. Personally I would still try making a plainer attempt with no AHCI, via DOS and WINNT.EXE on FAT32. https://msfn.org/board/topic/181798-the-installation-of-windows-2000-was-blocked-in-lenovo-g500/?do=findComment&comment=1186272 jaclaz

@Ximonite @Win32 I know that the direct links won't work to download, but they can be seen/copied from the search reults and they are an easy way to check (filename) that we are talking of a same file. jaclaz

Perfect: Does any of those two (these are the corresponding links): http://win2k.org/cgi-bin/dl.cgi?file=iata76_cd2kd.zip&lang=ja http://win2k.org/cgi-bin/dl.cgi?file=iata76_cd2ke.cab&lang=ja contain any .inf file with contents compatible with the PCI\VEN you posted earlier: If no, those drivers are not suitable. The first driver seemingly has not that PCI\VEN. The second driver: Intel Matrix Storage Manager 7.6 for Windows 2000 (Intel 8 Series 蟇 ｾ 蠢 �-type e) http://win2k.org/cgi-bin/dl.cgi?file=iata76_cd2ke.cab&lang=ja actually contains in iaAHCI.inf that id: %PCI\VEN_8086&DEV_1E03&CC_0106.DeviceDesc% = iaStor_mobl_Inst, PCI\VEN_8086&DEV_1E03&CC_0106 and: so it should be the "right" one, even if it is described for Intel 8 Series. BUT maybe there are other incompatibilities. In TXTSETUP.OEM there is: but then there is NO corresponding entry iaAHCI_7_1 in the rest of the file. So, for *some reasons* the TXTSETUP.OEM does not correspond to the .inf. This may (or may not) be connected to the issues you are having. Surely the 8.9 version (that requires the extended kernel, whatever it is): iata89bw2k.zip http://win2k.org/cgi-bin/dl.cgi?file=iata89bw2k.zip&lang=en does have in TXTSETUP.OEM the entry: AND: jaclaz

I will try again (last time). There is seemingly NO "7.6" version of the Intel driver for the Intel 7 Series on that site. Ximonite gave a very vague reference (whole site). And did not provide a link to the actual driver. I found on that site a SINGLE driver version 8.9 for the Intel 7 series and tentatively provided a link to the actual 8.9 driver. Win32 gave a less vague one, mentioning version 7.6 (that seemingly does not exist or at least is not listed for the 7 series) AND did not provide a link to the actual 7.6 driver. Windows2 tested reportedly both the 8.9 and 7.6 version AND did not provide a link to the actual 7.6 driver. It is not difficult, it is called "attempt to communicate inequivocally", someone asks something CLEARLY, someone else, that presumably knows the answer or has an idea to suggest, replies with EXACT information. So, I will ask again. WHICH driver of the 7.6 version did you try? The answer to the above question is a direct link to the file, NOT any vague description. And now, for no apparent reason, a couple of EXACT references (links): http://vm1.duckdns.org/Public/IntegrateDrv/IntegrateDrv.htm http://reboot.pro/topic/18107-integratedrv-install-xp-2003-to-a-usb-30-disk-and-boot-from-it/ jaclaz

Boy do I hate this. WHICH one is the 7.6 version for the Intel 7 series? Snippet of the Search results on http://win2k.org/ : jaclaz

Add there a link to the relevant posts on this thread, and/or some details, no offence intended , but if I was a grub4dos developer, reading your two lines I would think "Here comes another loonie that has not undestood the #102 issue that is solved." Mind you I like it when communication is simple, streamlined efficient and not verbose, but maybe you could have been a taf bit more descriptive. jaclaz

The source is on NTFS? Try on those .lnk files the blocklist command. There is (was) an issue with resident data in $MFT entries that should have been resolved, but maybe it was accidentally re-introduced, or maybe .lnk files have some special attribute. But you have a backslash in some of those commands, is that an escape for the space in the name? Does it happen no matter if there is a space in the name of the .lnk? Try with an explicit path AND use [TAB] autocompletion to read the file, example: cat --hex (hd0,0)/lnkfiles/w[TAB] Try with a .lnk file with no spaces in the name. Or maybe - for some reasons - the header of the file is automagically (please read as "stupidly") recognized as *something* I seem to remember vaguely that there was an issue with some files that were recognized (did I say stupidly?) as being gzipped files (.gz) and attempted to decompress on-the-fly. Try changing the first 4 bytes of the file to (say) 20 20 20 20 and see if the behaviour is the same. If you prefer the issue could logically be connected to: 1) "nature" of the file on the filesystem 2) name/path of file 3) contents (header) of file jaclaz

Ximonite, with all due respect , that is not entirely unlike saying they are "on the internet". If you search for: Windows 2000 Drivers English Intel you have several result, none with name exactly corresponding to your post. Should be this one: Intel Rapid Storage Manager 8.9a for Windows 2000 + Extended Core(Intel 7 Series 蟇ｾ蠢�) http://win2k.org/cgi-bin/dl.cgi?file=iata89bw2k.zip&lang=en that does have "PCI\VEN_8086&DEV_1E03&CC_0106" in ahci.inf. jaclaz

Good , but do you still have those bad sectors in chkdsk (or other OS level tool) now? jaclaz

@Zhuma Only to assure you that for *some reasons* your posts on bbs.wuyou are perfectly (and I mean perfectly) understandable in Google translate: https://translate.google.it/translate?hl=en&tab=wT&sl=zh-CN&tl=en&u=http%3A%2F%2Fbbs.wuyou.net%2Fforum.php%3Fmod%3Dviewthread%26tid%3D388226%26mobile%3Dno https://translate.googleusercontent.com/translate_c?depth=1&hl=en&pto=aue&rurl=translate.google.it&sl=zh-CN&sp=nmt4&tl=en&u=http://bbs.wuyou.net/forum.php%3Fmod%3Dviewthread%26tid%3D414353%26mobile%3Dno&usg=ALkJrhgjfNyvUjjX-UYtysAVQ0ENFTYWdw Unlike many other post by - say - the Authors/Mantainers of grub4dos that I often have to struggle with to understand. Since I doubt that "suddenly" Google translate has improved so much, it should mean that your posts are written in the original Chinese in an extremely clear way . @JFX sorry for the OT. jaclaz

Try and see. That equates more or less (more less than more) to one of the possible usages of winnt32, i.e. using the syspart switch: but no, it won't work, unless you dd the whole disk or however the volume information and disk signature (much more complex than the manual way already suggested to you. jaclaz

Ah well, if you say so ... jaclaz

Strange that you have not values 187 and 188, however the 197 and 198 (that more or less reflect the 5-7 bad sectors you reported) do not look good, particularly if coupled with the recent increase of failed RAW reads. The fact that it is a 320 GB drive is a good thing as - likely - it has a relatively low data density and - empirically - they tend to suffer less from "diffusion" of bad sectors (when compared to - say - 1 or 2 TB ones). What I would do if I were you: 1) of course have a verified backup 2) run the WDC testing tool: https://support.wdc.com/downloads.aspx?p=3 (extended test, which is not "data destructive" and may help in re-mapping the currently bad sectors[1]) 3) see if the disk drive "passes" Then, if it passes, and if (see note below) the tool manages to remap those bad sectors you are good to go. If it doesn't, it doesn't mean that you have to throw the disk in the trash , only consider how it surely has lost some (most) of its reliability. Anecdotally, once, many years ago, I had a (Samung) 4.3 GB disk (no, it is not a typo) that developed a "cluster" of bad sectors (some 80-100 of them) all in a definite area. At the time I demoted it to secundary backup media , and partitioned it in such a way that a few MB around the area containing the bad sectors was unused in the partition table, and it never failed (though of course it was much less used than when inside the actual PC). If the bad sectors seem to be all in a same area, you could try doing the same. jaclaz [1] please understand how, even if the disk drive "passes", there is a risk that the test will find an increased number of bad sectors, however, after the test they should be re-mapped and not be seen in chkdsk, at least in theory

Ok, but what error(s) you have? Historically (but not necessarily in your case) issues with WinsetupFromUSB derive from either a modified source or from "queer" BIOSes (and the Insyde BIOS is notorious for making these) it may be necessary to make change to the grub4dos commands on some BIOSes. There is still (just in case) the good ol' manual method 911cd is long tiime MIA, via Wayback Machine: https://web.archive.org/web/20160417164143/http://www.911cd.net/forums//index.php?showtopic=16713 jaclaz

Well, you didn't really-really expect that installing Windows from USB is possible without some (more than one) tricks? We have an entire sub-forum dedicated to the matter and to the various possible approaches/related programs, etc. https://msfn.org/board/forum/157-install-windows-from-usb/ You probably want to try : jaclaz

There are two main schools of thought on the matter. 1) The one I follow (which is objectively more complex to realize) is that first thing "boot" and "system" volumes must be separated, in the case of a Windows NT OS, installing it in a volume inside Extended, and in a multiboot scenario a volume must have a same drive letter assigned in each and every OS that accesses it AND that all volumes should be accessible from all OSes installed. The caveat is that more than a few (poorly conceived) programs will insist on installing (or however using files) on C:\, and in some cases they are a nuisance, on the other hand a (very stupid) malware virus hardcoded with C: or blindly wiping the active partition in the MBR will be able to make much less damage. 2) Alternatively, nothing prevents you from having completely separated installs, with the partition(s)/volume(s) of the "other" OS hidden from the "current" one. This gives a number of advantages, i.e. the install of each OS will be more "standard" so you won't have any issue with programs hardcoded for C:. Both are valid approaches, what I recommend in the second is to NOT have normally the "other" drive/volume visible, the idea is that before or later one is booted in the "other" OS and makes something destructive on the "wrong" volume because of a same volume having different drive letters under different OS. Of course, even in this second situation, the "other" drive/volume in a dual boot can be made visible - in case of need - to repair/fix the "other" OS. Example for #1: 1) small, FAT32 partition primary active drive letter C: 2) NTFS volume (logical volume inside Extended) Vista drive letter D: 3) NTFS volume (logical volume inside Extended) Windows 8.1 drive letter E: 4) NTFS volume (logical volume inside Extended) Common Data/Storage drive letter F: Example for #2: 1) NTFS volume active[1] primary partition Vista drive letter C: (hidden when 8.1 is booted) 2) NTFS volume active[1] primary partition 8.1 drive letter C: (hidden when Vista is booted) 3) NTFS volume primary partition or logical volume inside Extended Common Data/Storage drive letter D: from BOTH OSes 1st example for a "mixed mode": 1) small, FAT32 partition primary active drive letter C: 2) NTFS volume primary partition or logical volume inside Extended Vista drive letter D: (hidden when 8.1 is booted) 3) NTFS volume primary partition or logical volume inside Extended 8.1 drive letter D: (hidden when Vista is booted) 4) NTFS volume primary partition or logical volume inside Extended Common Data/Storage drive letter E: from BOTH OSes Of course there are other possible setups, including having the small FAT32 partition have not a drive letter assigned normally, which is what more or less is already happening on UEFI/GPT disks, i.e.: 2nd example for a "mixed mode": 1) small, FAT32 partition primary active no drive letter assigned 2) NTFS volume primary partition or logical volume inside Extended Vista drive letter C: (hidden when 8.1 is booted) 3) NTFS volume primary partition or logical volume inside Extended 8.1 drive letter C: (hidden when Vista is booted) 4) NTFS volume primary partition or logical volume inside Extended Common Data/Storage drive letter D: from BOTH OSes jaclaz [1] this approach needs a bootmanager capable of changing the active status of the partition and hide the "other" one at boot time

Good, thanks for sharing your experience/opinions . jaclaz

A tool that is often used to check that size is Sysinternals NTFSinfo. Example data from a couple volumes of mine (NTFSinfo), same size 320 GB, this is a "system" volume with a zillion little files: MFT Information --------------- MFT size : 546 MB (0% of drive) MFT start cluster : 786432 MFT zone clusters : 59059648 - 68687552 MFT zone size : 37609 MB (12% of drive) MFT mirror start : 39070076 And this is a "data only" volume: MFT size : 111 MB (0% of drive) MFT start cluster : 786432 MFT zone clusters : 48915648 - 49332416 MFT zone size : 1628 MB (0% of drive) MFT mirror start : 39070076 These are volumes of exactly the same size, on two identical disk drives, used in a very different manner for a few years, you can see the noticeable difference in $MFT size. What happened in your case, most probably , is that over time you wrote and deleted on that volume a large number of files, and most (if not all) $MFT defragmenter/cleaners do actually defragment/clean, but they do not "shrink" the $MFT, which remains "of increased size", see: https://docs.microsoft.com/en-us/windows/win32/fileio/master-file-table? AFAIK there is (or was) only a single (BTW commercial) tool from Paragon that allowed to "compact" the $MFT once the entries were emptied/cleaned, see page 21 here: https://www.paragon-software.com/docs/TD2009_Manual.pdf the tool (or its successors) does not exist anymore: https://kb.paragon-software.com/article/1807 but the function is in the hard disk manager: https://www.paragon-software.com/home/hdm-windows/ no idea if the trial of the old thing allows that : https://www.softpedia.com/get/System/Hard-Disk-Utils/Paragon-Total-Defrag.shtml There are "rumours" that if you fill the disk up to the brim (adding a single or very few very large files), the NTFS will try to reduce the (unused) $MFT areas, but I have no real confirmation. Since it is only a data volume, it might be worth a try to do that experiment (of course after having made a copy of the data), otherwise it would make sense to copy the data to an external disk, re-format the volume and copy back the data, a 232 GB volume, not completely filled should be all in all a matter of a few hours. If you want to try the "fill up to the brim" experiment, get the dsfok toolkit: https://web.archive.org/web/20190910101150/http://members.ozemail.com.au/~nulifetv/freezip/freeware/dsfok.zip and use fsz: jaclaz