jaclaz

You are welcome jaclaz

Yes and no. Windows 7 (some versions, and later OS's) have "native" VHD drivers. Vista has them not, but you can use a fixed VHD (which is nothing but a RAW image with a single "Conectix" sector appended) mapping it in grub4dos, and using *any* of the available drivers (Firadisk, WinvBlock or - lately - SVbus). See: http://reboot.pro/topic/21787-svbus-virtual-scsi-host-adapter-for-grub4dos/ http://reboot.pro/topic/9715-firadisk-and-vhd-img-images/ http://reboot.pro/topic/15407-booting-from-vhd-in-grub4dos/ Vista being very little used, I don't think there is a specific set of instructions for it, surely not for the new kid on the block (actually recommended) which is SVbus, but since it needs not any value passed from grub4dos, it should be easier than Firadisk or WinvBlock. jaclaz

Hmmm. No. Those drivers are seemingly Kernel drivers and SERVICE_DEMAND_START (PnP), in this case (I believe) the LoadOrderGroup is ignored. I think that you can try disabling them (setting StartType=4) without uninstalling them and see if they are the actual culprits. You can also try using loadord: https://docs.microsoft.com/en-us/sysinternals/downloads/loadorder to see how they "fit" in load order, then try changing the LoadOrderGroup to something "later" than "Base", the list is in : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder but I don't think it may change anything Be warned, there is a risk the thingy will BSOD/hang, so have handy a way out. jaclaz

Semi-random thought, but maybe - just maybe - you can tweak loading settings for that driver/service. https://docs.microsoft.com/en-us/windows-hardware/drivers/install/specifying-driver-load-order jaclaz

Good , but it remains "queer". Maybe (not that I can understand the code, mind you) the issue is not gzip, but rather with the later added lzma: https://github.com/chenall/grub4dos/blob/master/stage2/gunzip.c the header for gzip seem fine: the issue must be *somewhere* here: https://github.com/chenall/grub4dos/blob/master/stage2/dec_lzma.c It seems (to me) that the file format has not any fixed signature bytes: https://svn.python.org/projects/external/xz-5.0.3/doc/lzma-file-format.txt http://fileformats.archiveteam.org/wiki/LZMA_Alone so it is a mis-detection of some kind. I guess it should be reported as well as a bug[1]. For the moment I just posted a reference to this thread on reboot.pro a a "heads up": http://reboot.pro/topic/22352-grub4dos-and-lnk-files-possible-lzma-collision/ jaclaz [1] BTW personally I find totally absurd that such detection code runs seemingly on *any* file in several commands, it simply makes no sense given that gzip and LZMA files may represent what? 0.001% of files, the decision to ignore file extensions and only attempt decompression on (say) .gz and .lzma is IMHO flawed, but as often happens hypothetically changing that would break half of the batches and/or existing workflows, in the case of gzip it may be fine[2] (because of the header, though it is IMHO too short to be reliable) but with LZMA (headerless) the approach becomes an issue, and since LZMA files are much less common than gzip ones, limiting that to file with the .lzma (or *whatever*) extension could be more than acceptable. [2] no, it isn't fine, more like "barely acceptable"

Aren't them avaialble just fine via the Wayback Machine? https://web.archive.org/web/2017*/http://www.vorck.com/windows/data/fdvfiles-xp.zip 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