jaclaz

I think it is just like there isn't XP or Vista on the list, 7 is considered "end of life" since 2020, maybe 8 and 8.1 are still there because "extended support" for them ends in January 2023. jaclaz

Well, there is very little to write on the specific topic. It simply works. It is essentially an additional choice/possibility, personally I prefer (on USB as well as ln any other device) to use (if an XP or a 7 is involved) this approach, as it allows booting grub4dos without mingling with the MBR and following few sectors and because (though nowadays it is far less common) the grub4dos MBR code might have some incompatibilities with a given BIOS (making, whilst the MBR->PBR->NTLDR->BOOT.INI chain is more likely to be compatible (at least on not recent hardware) as *any* motherboard would have been booted to XP or 7. The even lesser known fact is that the Windows 7 BOOTMGR (but not AFAICR later versions) parses the "old" XP BOOT.INI just fine for the entries that are NOT leading to a windows (i.e. NOT the (multi) ones), see here: http://reboot.pro/index.php?showtopic=19730&page=2 https://msfn.org/board/topic/140412-release-siginets-plop-usb-boot-manager-installer/ So by adding or editing a simple text file you can add (or remove) the option to boot to grub4dos to both "normal" XP and 7 installs. jaclaz

As said, I cannot confirm (nor deny) anything, I am only pointing you at the little I know on the matter, based on what I read here and there. All the evidence I could find point to the conclusion that the "switch" between IDE and AHCI/SATA needs to happen in the BIOS, whether this needs a modified BIOS or can be triggered (I presume only on some BIOSes/chipsets, not on all of them, but the given resource is actually about the specific ICH-7) via direct editing/poke the PCI settings, at least for Linux. Both the above possibilities are rather low-level and complex, which makes me believe that a much simpler, I would dare to say obvious, solutions such as a Registry edit or the modification of a .inf file cannot possibly work. I have NO idea on how a IDE, let alone SATA/AHCI driver actually works, but I presume that loosely at every request from the OS it checks something (the 8-bit MAP—Address Map Register at offset 0x90 in the PCI area of the *whatever* hold these data) and, depending on what it finds there, issues this (or that) slightly different command, and likely the chips themselves additionally check that value/register. This said, I wouldn't exclude that if you look at your PC with enough intensity (evil eye ) you can switch the settings, but I would classify that event as highly improbable . jaclaz

I don't know, from your previous reports it seems that the "culprit" is the disk (hd2) or the volume (hd2,4) (the disk with 30401 cylinders), yet it doesn't seem from the partinfofw data to be in any way problematic (or at least not more problematic than the other disks). I am afraid I wasn't clear, you don't really need to "save from Tiny Hexer" the text or html of the view, the MBR_Backup makes a 1:1 (or dd-like) copy of the relevant sectors, with "appropriate" names and I can open them in Tiny Hexer and view them through the structure viewers I am starting to suspect that there is some incompatibility between grub4dos and your PCI IDE controller. Right now (question) if I get it right, the only disk that you "really-really" need is the disk 0, connected to the internal IDE controller, right? And on that disk you have on C: a WIndows XP system that is bootable and on E: some data. If the disk can boot (alone) to XP you can add to your boot.ini a line: and copy to the C: volume the grldr file. This should be able to boot (to grub4dos prompt) without any other disk connected. Then try again to boot after having added the disk (the one with 30401 cylinders) only to the other on-board IDE. Does the slowdown happen? Then try again booting after having moved the second disk from the on-board IDE to the PCI controller. Does the slowdown happen? This way we remove from the equation the other disks and compare results for the same disk when differently connected. jaclaz

You can try adding two 27C4 lines BUT it won't work. See it like this, if it was so easy, why the Linux trick, the BIOS provision (missing in your case) or the suggested need of a specific BIOS mod? jaclaz

Hmmm, I don't know. Seemingly the HD0 is just fine (this should be the one you just re-partitoned). The HD1, HD2 and HD4 have the same issues (or non-issues): The Extended partition entry in the MBR points to sector 16065 (correctly represented as CHS 1/01/) first partition should normally be on 63=0/1/1 or, with the new MB alignment 2048=0/32/33, but it is perfectly possible that a whole head is reserved when making the Extended partitioning the first and only one. The entry for the volume in the EMBR is not balanced, the sectors before are 63 (correct, same as in the bootsector) that translates to 0/1/1, but the CHS entry is 1/1/1 (which corresponds to LBA 16128), this is IMHO strange, but it shouldn't be a problem. The HD3 is mish-mash, the first partition has 2048 (0/32/33) which is a sign that the partitioning was made with MB alignment, there is a hidden one head partition with ID21 (this could be the effect of using some USB related tools like RMPREPUSB), then there is a partition with ID0 (which for windows is a non-partition) that it is inside the extent of the first partition (this could be an effect of a grub4dos partnew command mapping an image, manually or by some "boot from iso/img" automation for some Linux distro). The volume on HD4 has another issue: Sec Per Clust: 128 (should be 8). But is the slowness/need to issue [ geometry --lba1sector (130) ] now solved (changing cables/HD settings)? about: The grub4dos should see: HD0=2 volumes/partitions HD1=1 volume/partition HD2=1 volume/partition HD3=3 volumes/partitions HD4=1 volume//partition total of 8. If instead of uuid you run: geometry (hd0) geometry (hd1) etc. you should be able to verify how many (and how many are seen as "invalid") volumes/partitions on each disk. If my guess is correct, the invalid ones should be the volumes on HD1, HD2 and HD4 (3 in total because of the unbalanced CHS/LBA) but maybe they are counted differently. jaclaz

The others are seemingly fine, it is only the disk 0 that looks problematic from what I could observe. The ID for the Extended Partition is 0x05 that means (if specifications are followed) "Hey, I am based on CHS addressing". The CHS address is saying "Hey, the EMBR is on sector 16,434,498" The LBA address is saying "Hey, the EMBR is on sector 29,543,538". Windows NT's normally use LBA addresses, so if (as I presume) the EMBR is actually on sector 29,543,538, and from then on everything is correct, the volume inside the extended is normally accessible/mountable. Grub4dos (or any other bootmanager) might look for the EMBR on sector 16,434,498, find it not, then try to find it via the LBA address and attempt to auto-correct internally the addreses/settings, and this could be the reason for the delay/issue (but not necessarily this is the actual cause, there may be other issue not detected till now). You don't need to secure erase the disk, there is no real reason for that, it would take time and stress the disk with continuous writing. jaclaz

First thing rest assured that MBR's and PBR's do not contain any "meaningful" (from a privacy/virus/malware point of view) info, they contain "common" code + a few specific data (geometry/addresses/etc.) that are not of interest to anyone and the Disk Signature (in the MBR) and the Volume Serial (in the PBR) that - while "unique" - are anyway random generated at partitioning and formatting times, so as well not particularly interesting. What you posted are the MBR's which - in a case such as yours with use of logical volumes inside extended are only a small part of the story. To check a primary partition/volume one needs: 1) the MBR (first absolute sector of disk) 2) the PBR/VBR (first sector of the partition/volume) To check a logical volume one needs: 1) the MBR 2) the chain of EMBR/EPBR's (first sector of the extended partition AND in case of more than one logical volume the "next" EMBR until all logical volumes are mapped) 3) the VBR Most of the common tools used in "booting matters" are very useful for primaries but not so much for logical volumes inside extended. About the 4 MBR's you included, they are seemingly just fine BUT DISK0.MBR has a few issues, the Extended Partition is marked as being type 0x05 (which is "CHS mapped") but its extents exceed the CHS mapping limit AND it doesn't fall on a cylinder boundary, then the CHS start data 1023/0/4 doesn't correspond to the LBA value, and there is a "queer" 66 sectors gap between the primary and the extended. Such wrong/unbalanced situation may well be an issue in grub4dos. The other ones look fine, the Extended Partition is marked as 0x0F ("LBA mapped") the CHS and LBA addresses are balanced, they are only unusual as they don't start "normally" at LBA 63 but rather at LBA 16065 (and in CHS at 1/0/1 rather than on 0/0/1). About DISK0, first thing one must understand is if the EMBR is on LBA sector 29,543,538 (the LBA address in the entry) or on sector 16,434,498 (the LBA address corresponding to the CHS entry 1023/0/4). Are you familiar (generally speaking) with hex/disk editors and their operation? You could get Tiny Hexer and my templates for it from here: http://reboot.pro/index.php?showtopic=21999 The MBR backup program by Wimb in the above should be capable of saving also the EMBR's and PBR's. Otherwise there is a little program by Terabyte that should be able to: https://www.terabyteunlimited.com/kb/kb-articles/explanation-of-the-partinfo-utility/ https://www.terabyteunlimited.com/downloads-free-software/#partinfo If you have Excel or a compatible spreadsheet program, you could also find of use my spreadsheet CHS_LBA to check the values : http://reboot.pro/index.php?showtopic=2959 http://reboot.pro/index.php?showtopic=2959&p=74116 Again, I know I am throwing at you a number of "advanced" tools/concepts, don't worry the whole stuff seems more difficult than it really is, but you will need some patience, the TLDR; is: I don't like (and I presume grub4dos also doesn't ) the way your DISK0 is partitioned, the issues - once understood - can be corrected but if you can (i.e. you are experimenting and the disk/volumes do not contain important data or you already have these data backed up) it would be easier to start from scratch re-partitioning the disk and recreating the volumes. jaclaz

The controller 27C4 in IDE mode becomes 27C5 in SATA/AHCI. AFAIK (frankly not a lot on this specific matter) the BIOS setting is simply a switch between 27C4 and 27C5 id, then the driver (either the plain IDE/ATA or the SATA/AHCI) is installed and started depending on this PCI ID. There is some Linux trickery (via GRUB) possible, but no idea if the PCI settings change "sticks" also in windows, nor if it actually works on your specific BIOS: https://dreamlayers.blogspot.com/2016/11/switching-from-ide-to-ahci-on-ich7-m.html I don't think that there is any other way than the above or a BIOS mod, this latter probably non-existing and in any case seriously dangerous/risky. You can of course try UNIATA, but no idea if it will give you any advantage: http://alter.org.ua/soft/win/uni_ata/ jaclaz

It could be due to several reasons, AFAIK: an incompatibility of some kind (between grub4dos and the controller or - more probably between grub4dos and the BIOS+specific controller) an actual issue with the disk *something* unbalanced in the MBR or PBR or both (or in the EMBR of the Extended partition), possibly in the BPB (some data in it may be used/checked when booting but not necessarily when accessing the disk/volume from a booted system, that usually does not rely on some lower level interface such as BIOS) a bad cable/connector (do not underestimate this, in the years I have seen intermittent issues of this kind, sometimes temperature connected, sometimes plain voodoo) The #3 is "normal" as you haven't mapped nor hooked anything. If you can avoid using this interface/disk it would be easier, as this - unless the exact cause is identified and the problem solved - represents an issue that may (or may not) affect the mapping and possibly then the functioning of Svbus/firadisk/winvblock. jaclaz

For some uses: jaclaz

Semi-random questions/doubts. (NO actual solution) Could it be an issue with PATH or have you tried to run that from the Windows folder ? Could it be connected to winoldapp.mod? jaclaz

The error message is "normal" (not unlike the one you would get in DOS or in Windows command prompt). If you want, grub4dos is very similar to those command line interfaces, intended to run commands one at the time BUT a menu.lst behaves as a sequence of commands, not unlike a batch file (which BTW are available in grub4dos as well, by convention using the .g4b extension), so you run a sequence of commands (that you cannot see) and when you get an error there is no way to know which command (and its arguments) created it, and this is exactly the reason why - generally speaking, before creating a menu.lst (particularly if complex) it is a good idea to test their contents on command line, one command at the time. Or you need to make commands much more explicit, adding custom echo messages (always or in case of error), setting differently the debug level, enable stepping, etc. but these are as well some more advanced topics. About the drivers, I would try first SVBUS (as it is the newest and usually just works), winvblock and firadisk are good as well but they are more "sensitive" to the specific setup (i.e. the actual hardware, virtual in your case, but that later may become "real") and to the specific contents of the image, i.e. on some setups firadisk works a treat while winvblock has issues and viceversa on some other case. jaclaz

To hopefully clear some doubts. The (ud) is a "special" device partitioned/formatted by fbinst: https://rmprepusb.com/tutorials/021-guide-to-grub4dos/ (it doesn't normally apply/you will probably never use it), anyway the "calc *0x82A0=*0x82b9&0xff" basically means "check that memory address 0x82A0 is the same as the (rightmost/least relevant, i.e. &0xff) byte in memory address 0x82b9, 0x82b9 is fb related, while 0x82A0 is current root drive number, now that you know about this, you can happily forget about that line/formula (it is simply too advanced and regarding a corner/edge case only that you probably will never experience). https://rmprepusb.com/tutorials/021-guide-to-grub4dos/021b/ You can have - in theory - as many menu.lst files as you like, the embedded one looks for one of them in the order of the commands, and as soon as it finds one it passes control to it (and any other menu.lst is ignored), the devices are scanned in a given order, the commands in the embedded menu try to find the menu.lst first on the current root, then it scans devices, the issue may be - on some BIOSes - that with (example) a USB stick the disk order may be altered so, it is possible that in these cases the menu.lst found (if not on current root or /grub or /boot/grub/ below root) is not the intended one. The embedded menu.lst is embedded at the end of the actual code in both grldr and grub.exe, it can be viewed opening the file with Wordpad and going to the very end of the file, and can be edited with a hex editor or (much easier) with BootIce, since its scope is to find the "real" external menu.lst file, in some setups it can be changed to directly do the *whatever* you want it to do and get rid completely of the external menu.lst, it is automatically loaded and executed by grub4dos at boot time. Windows NT (and conversely 2K, XP, etc.) was originally designed to work and run from a logical volume inside extended, no problem there, in the good ol' times DOS allowed only a primary and an extended partition, so typically you would have a FAT16 partition (primary, active) containing the DOS and the NTLDR+BOOT.INI+NTDETECT.COM (+ ntbootdd.sys) and a volume inside extended containing the actual OS, this is essentially the difference (that the good MS guys call "reversed") between "boot" and "system" partition, see: http://www.multibooters.co.uk/system.html The problem with this kind of setup (in a single disk setup) is that the primary would get drive letter C: whilst the logical volume would get drive letter D:, something that may (or may not) be wanted/liked. For what it matters once you are booted to grub4dos (and there are several methods to do that) you can use a NT boot floppy image (i.e. containing NTLDR+BOOT.INI+NTDETECT.COM) just fine (without needing any extra driver), there is no end to the tricks that can be used, including (shameless plug ) the special MBR code and the underfloppy image in not used sectors or the UMBR. These are ONLY for your info, to know that alternatives do exist, do not even think of using these methods (yet): http://reboot.pro/index.php?showtopic=19516 http://reboot.pro/index.php?showtopic=22317&p=215423 http://reboot.pro/topic/19516-hack-bootmgr-to-boot-windows-in-bios-to-gpt/page-11#entry197690 http://reboot.pro/index.php?showtopic=21856 Yes, you are not the first one to report that Qemu on 64 bit is not (yet) working well, the 32 bit did work just fine, personally I am using now (but what do I know?) Virtualbox (32 bit) for my little experiments using RAW images+VMDK descriptors, just in case/JFYI: https://www.forensicfocus.com/forums/general/boot-a-dd-into-a-virtual-machine-with-virtualbox/ The 7b error technically means "inaccessible boot device", typically it comes from a mismatch between what the "real" mode of the NTLDR sees (essentially BIOS) and what the "protected" mode part sees, on real hardware it is typical of a missing or misconfigured driver, but there are several reasons why it can happen, all related to accessing the boot device in the early stages of booting. To map an image (i.e. not booting from a volume/partition on disk, but rather booting from a volume/partition inside the image) you will need a special driver, namely firadisk, winvblock or svbus. I know I am giving you lots of info, some rather complex, you will need some time to digest these, and you should simply ignore what doesn't sound useful (yet), but feel free to ask questions if there is something you have difficulties in grasping. jaclaz

Ok, let's start from the beginning. Grub4dos (both grub.exe and grldr) have an embedded menu.lst that amounts (in recent versions) to: configfile default 0 timeout 1 title find /menu.lst, /boot/grub/menu.lst, /grub/menu.lst errorcheck off configfile /boot/grub/menu.lst configfile /grub/menu.lst if "%@root%"=="(ud)" && calc *0x82A0=*0x82b9&0xff if "%@root:~1,1%"=="f" && find --set-root --devices=f /menu.lst && configfile /menu.lst find --set-root --ignore-floppies --ignore-cd /menu.lst && configfile /menu.lst find --set-root --ignore-floppies --ignore-cd /boot/grub/menu.lst && configfile /boot/grub/menu.lst find --set-root --ignore-floppies --ignore-cd /grub/menu.lst && configfile /grub/menu.lst configfile http://b.chenall.net/menu.lst errorcheck on commandline title commandline commandline title reboot reboot title halt halt Basically this is a mechanism to look for a /menu.lst file in a number of default paths from current root and if it is not found start looking for it in all available/accessible volumes. The menu.lst entries consist of THREE parts: 1) a title (which is what you will see when the menu.lst is loaded, i.e. the entry text you can select and choose to boot 2) one or more commands that will be executed sequentially 3) an implied boot command (this is issued after the last command in an entry and before the next title or before the EOF marker) If you prefer, generally speaking you can have the same effect of a menu.lst entry by dropping to command line and typing the commands in the entry, pressing [ENTER] at each new line, and then issuing: boot [ENTER] This final boot command is "final", there is no undo, nor way back, the control is passed from grub4dos to *whatever* you specified in the previous issued command(s), usually chainloading a MBR, PBR or other bootmanager/OS loader. In the special case of a configfile directive, you are essentially passing control to the target of the directive, and this happens immediately, there is no need of the boot (explicit or implied) directive, which plainly means that any command after the configfile one (if the target is found and it is valid) will be ignored. There is no need for this target to be called menu.lst, and not even to have the .lst extension. i.e. for all it matters you can have a "main" menu.lst (this MUST be called menu.lst AND MUST reside in one of the preset paths unless you edit the embedded menu.lst) with an entry *like*: title My nice OS boot find --set-root /myosname.tag configfile /myosname.tag echo you won't ever see this as long as the /myosname.tag is found and its contents are a valid grub4dos menu, the last line will never be executed. The /myosname.tag could contain an entry *like* (root will have been already established by the previous find --set-root directive): title My nice OS boot - 2nd level chainloader /ntldr or title My nice OS boot chainloader +1 The first one might work, the second won't as what you are chainloading (the PBR or VBR or bootsector) has an incorrect number of sectors before (in your case of a logical volume inside extended) in the BPB (Bios Parameter Block), these data can be corrected manually. At this point the NTLDR will be running, and it will be looking for a boot.ini (in the same current root where the NTLDR is), this boot.ini needs an entry to the current (other) XP, on 1st logical partition of 2nd disk, probably something *like*: multi(0)disk(0)rdisk(1)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect the 2 in the above is only a guess, the actual number depends on how many primary partitions you have on this second disk (rdisk(1)), as unlike grub4dos (where 0-3 are primary and logical start from 4), the boot.ini numbering of partitions is not "fixed" but rather "dynamic", see: https://www.terabyteunlimited.com/kb/kb-articles/how-partition-numbers-are-assigned-in-boot-ini/ then, hopefully, this second windows will be booted BUT you will likely have issues with drive lettering as they are also assigned along a set of dynamic rules (you may need to use migrate.inf or a modified setupreg.hiv to install the XP with a non-calculated drive letter): https://msfn.org/board/topic/178185-how-to-install-windows-xp-into-2nd-partition-and-get-c-as-systemdrive/ https://web.archive.org/web/20160817074749/http://www.911cd.net/forums//index.php?showtopic=19663 jaclaz

Maybe it is a typo, but Name.tag is NOT the same as name.tag (grub4dos is CaSe SeNsItIvE on NTFS). (hd1,4) is correct, hd1 is second disk (as first disk is hd0) primary partitions are partitions #0,1,2,3, #4 means "first logical volume inside extended". If you don't want to use the .tag file, you can use UUID, see: http://reboot.pro/topic/14640-how-to-use-uuid-in-this-code/ This makes apparently little sense : Menu.lst #Contents find --set-root /Name.tag configfile /menu.lst chainloader +1 commadline The moment the configfile /menu.lst is executed control passes to the loaded /menu.lst so it is unlikely that it will ever return to the chainloader +1 command (that won't anyway work as this is an uncorrected PBR of a logical volume inside extended, you would need to correct the sectors before). The best image format is the NON-growable (i.e. static) RAW image + vmdk descriptor or a (still static) VHD (which is a RAW image with an appended Conectix sector that will be ignored by grub4dos). I am not sure to understand the "final goal", whatever you boot in the VM is inside the VM, the "real" disk is not visible/usable from inside the VM normally : jaclaz

Actually Vincent Price was quite good. jaclaz

You are missing the third dimension. Having snow 2.54 cm thick or 25.4 cm (1 vs 10 inches in your local dialect) is not the same thing, and actual shoveling performance is traditionally expressed in cubic units (per hour or per minute)w*l*h/t. jaclaz

Yep, *something* in the Registry could be as said another possible reason, but I too don't think that that particular hive/key is related. It is good to be sure about something , I tend to have often doubts . Another tool that might be tried is smartmontools: https://www.smartmontools.org/wiki/USB direct: https://www.smartmontools.org/wiki/Download#InstalltheWindowspackage or via: https://gsmartcontrol.sourceforge.io/home/ I believe both are still Vista compatible. jaclaz

Well, the whole point is that HDDscan (which is a different tool) also fails, hence the need to confirm that HDDscan (again a different tool) does work on another machine with the same USB disk. jaclaz

I think this will remain an unresolved mystery, I take for granted that on other systems, possibly running other OS's HDDscan manages to read the specific USB hard disk SMART data and temperature. If this is the case, and it is confirmed, and since it worked before on that specific Vista machine, the only logically possible culprit is the driver (or more properly the set of drivers related to the USB stack in use) or *something* (be it some obscure Registry setting or some other software interfering with the USB communication) else, what could it be I have right now no idea about. jaclaz

I don't know, you can try HDDscan: https://hddscan.com/ jaclaz

Yep, only for the record this can work (on UEFI and NTFS) only because Rufus' Author Pete Batard includes a UEFI NTFS driver (that also WOEUSB uses optionally), as most UEFI impèlementations miss a way to access the NTFS partition/volume (the actual UEFI specs cover only FAT/FAT32). jaclaz

Most probably it is an issue (of some kind) with the drivers, USB connected hard disks are - generally speaking - a PITA as there is this "overlay" (the USB bus/protocol) that does not often allow some info to "go through", usually (when possible) to diagnose a USB hard disk it is better to take it off the enclosure and connect it "directly" (PATA or SATA) to avoid those issues, eSATA drivers are (obviously) unaffected. What you report is "strange" however, it working one day and not the day after, it is however possible that *for some reasons* some different drivers were in use and that *somehow* changed. The Drivecleanup tool is a good tool but it is well possible that *somehow* in the past some particular (working) driver was installed and then still *somehow* it was replaced by a "standard" one missing the functionalities the old one had, and after the DriveCleanup ran the same "standard" driver was re-instated. jaclaz

@NotHereToPlayGames The tiny nitpick being that the variant that we had a year and a half ago was far more dangerous than the one that is around now. And numbers have a meaning. Worldometer, in this moment, sets the US deaths at https://www.worldometers.info/coronavirus/country/us/ 902,140 (in roughly two years time), which is a number that could be compared to - say - Civil war https://en.wikipedia.org/wiki/United_States_military_casualties_of_war 1,129,418 or WWII 1,076,245 (but both over the course of roughly 4 years). If you want to compare to another pandemic, the Spanish Flu killed roughly 675,000 US people, https://www.cdc.gov/flu/pandemic-resources/1918-pandemic-h1n1.html (and US had all in all a smaller amount of deaths per milllion than most EU countries). jaclaz