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

JFYI, you need to also change the font to a suitable one to be allowed to call that "The Matrix" credibly. Namely you want to use the White Rabbit font: https://www.dafont.com/white-rabbit.font jaclaz

More generally searching the Registry for "PRODUCTNAME" may result in one of the two places Ucyborg suggested. jaclaz

@loblolly986 Bootpart must be the longest running (good) NT program ever, it came out in NT 3.5 (or possibly even NT 3.1) times , so no doubts about it (it does work and it does work since almost 30 years). The issues may come in this particular setup with the requisites for the Windows 95 underlying DOS in terms of capability of booting from a first but not active partition and possible issues with automatic drive lettering. The "added" values of inserting (one way or the other) grub4dos in the booting sequence is some of its abilities in managing partitions/volumes entries in the MBR but also the capability to mount (floppy) images, i.e. the NT recovery floppy you described could be saved into an image on hard disk and chainloaded to boot. Particularly in the testing phase it allows to make experiments without changing anything (or very little, easily reversible) on the disk. jaclaz

Not really, if you actually read bootpart page, it says: The only thing I highly suggest is : your active partition on your first hard disk must be a FAT16 primary partition. This may be a small partition. The DOS (in Windows95) must be on first disk active partition (and this cannot be FAT32 if you use the NT NTLDR). jaclaz

The issue is then the following. Normal Windows 95 booting: BIOS->MBR->PBR(of active primary partition)->IO.SYS Normal Windows NT booting (normal or in dual boot): BIOS->MBR->PBR(of active primary partition)->NTLDR->BOOT.INI choices(if any)->either Win95 or NT in this case What likely happens in your case: BIOS->MBR->invalid PBR (as it doesn't exist in NT the concept of FAT32 filesystem)-> a suffusion of yellow or BIOS->MBR->PBR-> NO NTLDR(as it doesn't exist in NT the concept of FAT32 filesystem)-> a suffusion of yellow Possible workarounds: 1) creating an additional (small) FAT16 partition 2) converting your existing C: to FAT16 3) using the Windows 2000 (or possibly even XP ) version of NTLDR and NTDETECT.COM (as these do understand FAT32) 4) using grub4dos to chainload the NT NTLDR (that must however reside on either a FAT16 or NT NTFS filesystem or in a (floppy) image #1 is the most "natural" way BUT you might have issues with drive lettering (that can BTW solved, but far from easy-peasy) #2 is fine, but it will deprive you of some advantages of FAT32 over FAT16 (smaller cluster size), and anyway the 6 GB are "too much" for FAT16, so you would need to shrink it to around 4 GB, and in any case it would have a huge (64K cluster size). #3 would be the easiest/next "normal" approach, #4 while being (slightly) more complex is the "less intrusive" one in the sense that it can be tested without changing anything in your partitioning. Personally I would advise you to try #4 first, because should it not work for *any* reason there are not any complex changes to partitions, filesystems etc., and thus no damage to existing install of windows 95. Brief instructions for #4 Get latest grub4dos from here: https://github.com/chenall/grub4dos/releases from the package extract only grub.exe and copy it to the root of your C: Boot to Windows 95 command prompt and in it run grub.exe. You should get to a grub> prompt. In it type: root [ENTER] and take note of the output, should be (hd0,0) find --set-root /ntldr [ENTER] root [ENTER] and take note of the output, should be (hd0,1) if the D: partition is primary or (hd0,4) if it is a logical volume inside extended cat --hex --skip=446 (hd0)+1 [ENTER] you should have two lines "populated with data" and two lines with 00's and a final 55AA If everything is as above, try: chainloader /ntldr [ENTER] you should see something *like* Will boot NT .... boot [ENTER] What happens? (there might be an issue with "sectors before" in the logical volume PBR/VBR that may need to be corrected) jaclaz

It is perfectly normal to install NT in dual boot with windows 95 (as a matter of fact NT was designed to be installed on logical volumes inside extended). Which filesystem, does your C: volume have (if it is FAT32 then that might be the base issue, NT knows nothing about FAT32, but there are possible workarounds). Also, which filesystem does your D: volume have? (if it is NTFS you won't easily access its contents from Win95) And can you confirm that it is a logical volume inside extended? (from what you reported it seems to me more likely that it is a second primary) What might have happened is (if my guess about FAT32 is correct) that the NT install somehow attempted to make the second volume active ignoring altogether the Win95 installation. Check where (if) the files: NTLDR BOOT.INI NTDETECT.COM have been written to (either C: or D:), since they are hidden and system files you will need to configure correctly explorer or use attrib on command line or use anothe file manager that shows hidden and system files. Normally in these kind of setup the boot partition (what the good MS guys call "system"), i.e. the primary, active partition should be FAT16 (to be accessible by both Win95 and NT), it can be a very small one, containing only the three files above and the Windows 95 DOS files. If you cannot move/shrink/resize or convert partitions, there are other workarounds, though, but you will need to use a third party bootmanager (grub4dos is suggested). jaclaz

If the thingy has not been used for some years, or it has been used or stored with the headphone plug inserted I wouldn't exclude oxidation in the headphone jack switch. jaclaz

... and then what happened? jaclaz

Go here: http://win2k.org/ hover on hyperlinks until you see http://win2k.org/drivers.htm and click on it once there click on Intel Matrix Storage Manager, you should land here: http://blog.livedoor.jp/blackwingcat/archives/813816.html Here you can find links to various versions (listed as cab, but the link is to the zip file) jaclaz

Wouldn't these do? https://msfn.org/board/topic/177106-running-vanilla-windows-98-in-2020-and-beyond/page/18/#comment-1176514 jaclaz