jaclaz

There is no new firmware that is to be loaded to "fix" an issue, that is something one can do once (and only once) the drive has been revived to not hit the same issue again. The original issue (either the LBA0 or the BSY one) can happen because the firmware hangs/enters a no-exit loop when the event log hits 320 or a multiple of (320 + x*256), The procedure(s) reset this in such a way that - typically - the disk is fully functional for 3-6 months of use or more. Hence in there is the point "IMPORTANT" that says: If the drive doesn't work after the procedure(s) have been applied (or if it works intermittently as in your case) it simply means that it suffers from another problem that needs to be diagnosed, which requires specific knowledge (besides possibly specific tools ). There is somewhere on the thread a somewhat detailed list of commands that are available via serial, but most probably you need omething *like* SEDIV: http://www.hddgod.com/ and some training in using it. If you don't care about data on the drives, it is simply not worth the time/money/hassle. jaclaz

The VEN_8086&DEV_27D8 is seemingly another ID for the generic "PCI\CC_0403" see: https://github.com/DriverPackSolution/DP_Sound_Others/blob/master/5x86/UAA/FORCED/fix.inf but no idea how exactly to use that "fix" or how to install the file outside the drp.su: https://drp.su/en jaclaz

It depends. The connectors and rails are seemingly "normal" ones, but the overall power is on the low side, 305 W total, 150 W on 3.3/5 V and 264 W on 12 V is not that much. You need to calculate the power requirements of your motherboard+processor+other stuff, there are online calculator for this, examples: https://enermax.outervision.com/ https://www.asus.com/microsite/power_supply_calculator/ https://www.newegg.com/tools/power-supply-calculator/ The most complete/detailed should be: https://outervision.com/power-supply-calculator in "basic" mode should give you an idea, the "expert" mode is needed to have the details of the expected power requirements divided by voltage rails. jaclaz

Only for the record, more properly that is (in the west) a marking knife: https://en.wikipedia.org/wiki/Marking_knife traditionally there are two of them, a left and a right one, but nowadays they are more commonly "merged" in a single one with a "spear point" *like*: https://www.fine-tools.com/anreissmesser.html The type you found is an el-cheapo "common" tool, a kiridashi kogatana, of the type that is (was) used in Japan by kids at school, corresponding - loosely - to what we would call an utility knife: https://www.fine-tools.com/messer1.html Anyway, in UK: https://www.workshopheaven.com/kasaya-brass-bound-japanese-marking-knife.html in US: https://melanieabrantes.shop/products/brass-knife jaclaz

Ok, in the meantime I did a few checks (in XP). You were right. The "magic bytes" (55AA at the end) are irrelevant. As well the "jump bytes" (EB5290 at the beginning) are irrelevant. What is relevant is the "OEM string" ("NTFS ", i.e. NTFS followed by 4 spaces or 4 hex 20 bytes). Simply making the first letter small case, i.e. nTFS instead of NTFS, is enough to make the volume/partition RAW (but you need to unassign and re-assign the drive letter to have the OS "sense" the change). Viceversa, i.e. while having a volume seen as RAW because of the "nTFS", the moment you write the capital N, the change is immediately sensed by the OS. 7 may behave differently, though. jaclaz

Yep, first 512 bytes or first sector. The general idea is the following (even if for a number of reasons this actual message has not been clear). What we call "Partition ID's" are actually "Protective Partition ID's", not different from the concept of the 0xEE "Protective ID" used on GPT disks to avoid MBR-only enabled OS to access them. So what the 0x3C was intended to do was "let's mark this partition with a number that the OS knows nothing about". And I don't think that 7 has changed anything in the mechanism. In a nutshell DOS up to 6.22 recognized only ID's 0x1, 0x4, 0x5. 0x06 NT 4.00 only the 0x07 in addition to the above DOS 7,x/8.x and Win9x/ME added to them the 0x0b,0x0c,0x0e,0xf From 2K all of the above. More recently, when exFAT came out, its ID is still 0x07, definitely making clear that 0x07 does not mean "NTFS", but rather "DOS! Here be lions!". There is another ID (actually a non-ID) that you can try using which is 0x00. 0x00 essentially means for Windows "there is no partition entry in this slot" (but Linux can usually mount the partition in the slot just fine, this trick/quirk is used with grub4dos to directly map ISO images in the MBR). But if the issue revolves around something that uses not the MBR but *some other* mechanism/setting that is "sticky" the change to only the MBR partition ID will be ineffective . If you completely blank the first sector of a volume, on the other hand, for all Windows knows you are in the same situation as when you create a volume/partition in Disk Manager, you first create a partition and later you are asked to format it, if you choose to not format it, the partition/volume exists, it is defined in the MBR (and it is normally assigned a drive letter but its properties will show it as RAW and if you try to acces it you will be asked to format it). Now, what is "enough" to have it "recognized as RAW" (i.e. not-recognized) is another thing, the "magic bytes" are irrelevant, and as well the "NTFS " filesystem description, I believe the need is to blank the pointer to the $MFT, but at the end of the day it is easier/faster/better to just blank the whole sector. If you blank with 00's the whole first sector is surely enough and it is (relatively) safe as in NTFS there is a backup copy of that sector, last sector of the partition (outside the volume but inside the partition), so you can do everything with a couple dd commands (in Linux) or similar, the bootsector is generally "locked" on a booted windows NT system[1] so you need a suitable tool or a workaround, see also this: http://reboot.pro/topic/8200-grubinstexe-write-failed-vista-ntfs-bootsector/ Unfortunately I think that in your case you cannot use LockDismount (just in case): http://reboot.pro/topic/12413-lockdismount-v0300-update/ as it operates at \\.\PhysicalDrive (i.e. whole disk) level. jaclaz [1] meaning the stupid post-XP ones

Most probably the "issue" has been "fixed" in Win9x but not "backported" to real mode MS-DOS 7.x. jaclaz

Actually AFAIK the "temporary" partition ID used by Partition Magic was 0x3C: https://www.win.tue.nl/~aeb/partitions/partition_types-1.html But no idea if it changes anything. The issue you describe (as a side note it would be interesting to know WHY you do that procedure) seems to me more like an issue with a drive letter/device GUID that is "sticky" in the Regitry. I mean a GUID (and a drive letter) is assigned by having a Disk Signature + an offset to the volume, there is no direct reference to partition ID. If a given volume has been (once) mounted in the second (on second partition) intance of windows it will have two entries in the Registry in Dosdevices (not connected to partition ID), it is possible that Windows tries to access the volume nonetheless and does something triggering the need to run CHKDSK. "NTFS" is not a "magic number", it is the filesytem ID in the bootsector. The last two bytes (in the MBR and as well in the bootsector) 55AA are the "magic numbers". Replacing them in the MBR (with - say - 0000) will make the whole disk "need to be initialized". No idea if replacing them in the bootsector/VBR will do anything, in theory it should make the volume "not formatted", but it has to be tried. Personally I would rather make a backup of the bootsector (only the first sector) then 00 it all (and later restore the backup). jaclaz

But ... power requirements have shifted, the +12V was once largely in use by 3.5" disks motors, nowadays more power is needed at +5V (think of all the USB devices) and the +12V on the PCI bus can be used by the GPU ... it has to be seen on a case-by-case basis ... BTW (and as a side-side note) new-new PSU's are (will be) 12 V only (with DC-DC converters on the mainboard); What can possibly go wrong? jaclaz

Before I forget, 7 and 10 MUST be installed on NTFS (they CANNOT be installed to FAT32, or - better - 7 can only be installed on FAT32 with some limitations, 10 possibly not at all ): http://reboot.pro/topic/19643-winsxs-hardlinked-files/ Win2k and XP CAN be installed on FAT32 (but installing them on NTFS would definitely be "better"). AND, in the case of logical volumes inside Extended partition, IF you use "plain" MB alignment you should NEVER (and I mean NEVER) use Disk Management from XP (and possibly also from 2k) to change ANYTHING in the partition tables: http://reboot.pro/topic/9897-vistawin7-versus-xp-partitioning-issue/ https://web.archive.org/web/20171111042401/http://www.dcr.net/~w-clayton/Vista/DisappearingPartitions/DisappearingPartitions.htm jaclaz

Well, you have to take a decision, then we will work on the details and possibilities. As said, personally I have all my multiboot systems[1] with a defined drive letter that never changes no matter which of the OS is installed, as I find it easier this way to know at once which OS is currently running and avoid the risk of copying/overwriting the "wrong" file (in the sense of the "right" file on the "wrong" partition), but it is only a matter of preferences You want grub4dos (which is not GRUB, i.e the thing that can be either GRUB legacy or GRUB2), https://github.com/chenall/grub4dos/releases It has a number of additional features (some, many, of which you won't need), but essentially it has capabilities to directly chainload the various MS system loaders and/or bootmanagers AND it can be called/invoked by DOS AND there is not any real *need* to install it (which is a huge advantage). If you use it, you can even have not *any* of the later system bootloaders/bootmanagers in the first primary partition, and have the booted system always have (say) the C:\ drive letter[2] (though I personally do not advise this, as the hiding/unhiding of partitions at each boot is anyway a complication, in case it would be better - on the systems that allow it (the NT ones) - to avoid the mounting of the volumes in the OS). With a trick or two, logical volumes inside extended can be directly bootable. 8 GB is more than enough for DOS/WIn9x, and you would have 4 Kb cluster size that is just the "right" size (but on SSD you won't notice any practical advantage), but 16 GB would be fine as well, going over it , up to 32 Kb cluster size, i.e. 32 GB, it is bigger than that that becomes the (not "real", only "common sense") limit: https://support.microsoft.com/en-us/help/140365/default-cluster-size-for-ntfs-fat-and-exfat jaclaz [1] only for the record, the one I have that also has Win9x installed has it as well in a volume inside extended (but DOS remains in the primary, active partition, as it was made at the time with "traditional" methods) [2] this may be a little bit trickier at install time and it may depend on the number of disks installed, because of DOS and NT automatic letter assignment, particularly for 2K and XP but is doable.

No. (but thanks anyway for sharing your opinion ) There are not that much differences between 7/8.1 and 10, your personal line is way above the one I described. Since the number of machines around with 16 GB Ram AND NVMe (which are obviously faster and "better") are only a minimal fraction of the installed Windows 10 (again we are talking of ordinary, low power, office machines) you are telling me that - say - 95% of the offices in the world cannot do what actually is done (or cannot do it swiftly enough). jaclaz

Very likely . 32767 in hex is 0x7FFF. So it is a limit for a (signed) integer in 2 bytes. The actual limit for the number of files in FAT32 is anyway 65535 (or 0xFFFF), i.e. 2 bytes unsigned integer; https://stackoverflow.com/questions/466521/how-many-files-can-i-put-in-a-directory The reference document (by Microsoft) as often happens says this (and the contrary of it) explicitly: http://download.microsoft.com/download/0/8/4/084c452b-b772-4fe5-89bb-a0cbf082286a/fatgen103.doc (at the very end, pages 33/34) BUT see also: http://reboot.pro/topic/19643-winsxs-hardlinked-files/ https://stackoverflow.com/questions/37135262/fat32-number-of-files-per-directory-limit there is the added complication of file name length (it shouldn't affect specifically your case since they are 8.3 "normal" file names) Anyway, I wouldn't be surprised if in MS-DOS 7.1 the DIR used a signed integer instead of an unsigned one. jaclaz

@JFX Please can you make available (as a separate download) last version supporting 32 bit? jaclaz

Personally I wouldn't install 9x+2K+XP on a same partition. too many risks of conflicts. Partitions are free, and you can have up to 4 primary ones or 3 primaries+1 Extended containing as much volumes as you want and - besides the whoie NT family of OS's has been originally designed to be installed to a volume inside extended. Besides, creation of FAT32 volumes larger than 32 GB is not allowed by XP and later, and - strange as it might be - this artificial limitation has its reasons, as a too large cluster size, particularly on OS sytem volumes with thousands small files is not "efficient". Yes, you should align partitions BUT additionally since you are planning to use FAT32 you should align the volumes, see: https://msfn.org/board/topic/151798-does-fat32-align-its-clusters/ Then you should decide how do you want drive letters to appear, there are two school of thoughts: https://msfn.org/board/topic/181501-installing-vista-from-scratch/?tab=comments#comment-1186267 And finally you should decide which bootmanager you want to manage the multibooting (I am partial to grub4dos, but there are less powerful/flexible alternatives that may be good enough). jaclaz

Generally speaking a capacitor is essentially a power storage device capable of releasing the power it stores when needed, and they are usually employed to "level" the power passing in the circuit. So - since during booting there is a peak request of power by the motherboard (and other devices) - if capacitors on it have lost some of their capacity, a more beefy power supply is more likely to provide enough instant current to be able to boot the machine whilst a less powerful one simply cannot. In multi-disk systems (like RAID storage) it was common to set them for staggered spin-up: https://en.wikipedia.org/wiki/Spin-up to avoid the initial peaks. jaclaz

The MBR doesn't know that, the PBR does. ALL the MBR code does (a "normal", "standard" MBR) is: 1) check if in the partition table a primary partition table is defined AND it is marked active 2) chainload the first sector of that partition (the PBR or bootsector[1]) Then the PBR code invokes (chainloads) the OS file (like io.sys for DOS) or the bootmanager/bootloader (like NTLDR or BOOTMGR) which filename is embedded in it. In Vista (and later) there is a program, bootsect.exe that with the options /NT52 or /NT60 changes the bootsector code to invoke either NTLDR or BOOTMGR, the booting mechanism remains exactly the same. Within limits (same length), you can even hexedit the string with the name of the file in the bootsector, as an example it is possible (though NOT advised) to change "NTLDR" to "GRLDR" to have the /NT52 boosector invoke the grub4dos grldr file. If you prefer, the normal boot sequence (BIOS) is: BIOS->MBR->PBR of primary, active partition->*whatever* the PBR invokes jaclaz [1] even if technically in NTFS the bootsector is actually 16 sectors long (or in FAT32 usually 3 sectors long) or - more properly - the boot code is multi-sector - the MBR only chainloads the first sector and the code in it loads the "rest of itself".

Not that much old, only like a week old. The question came out because quite a few friends with this continued lockdown are getting short of devices (typical dad AND mom working from home AND one or two children doing remote schooling with - again typically - one "current" pc or laptop, an old (or older) one, one el-cheapo tablet, and one - quite capable BTW - smartphone but with a too tiny screen). Family fights to get a decently large screen assured. jaclaz

I think you really need the additional RAM, XP runs just fine with 1 GB, but nowadays browsers (please read a stupidly bloated websites) think it is one of those "all you can eat" places, and 2 GB is probably the bare minimum to have a "normal" experience with a few tabs/sites open in the browser at the same time. As a side note, the more you can access with QTweb (and with javascript disabled), the better. jaclaz

Which is good, but completely unrelated, since my note (and method) is NOT AT ALL about the "embedded" menu.lst in grub4dos, it is about embedding booting commands in the target .iso (or .vhd, or .img, etc.). I think you are still missing the point (which is about compatibility), sure we should use the right commands, but by having a non-existing command produce a warning (and/or a non-blocking error) the non-existing command can remain where it is. jaclaz

Sure, as if copy/paste was not a thing. Besides, one could use n .lst files and have in menu.lst each entry ponting to a specific "other" .lst. Example (BIOS /menu.lst): title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram find --set-root /CD/linuxmint-19.3-cinnamon-64bit.lst configfile /CD/linuxmint-19.3-cinnamon-64bit.lst Example (UEFI EFI/grub/menu.lst): title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram find --set-root /CD/linuxmint-19.3-cinnamon-64bit.lst configfile /CD/linuxmint-19.3-cinnamon-64bit.lst linuxmint-19.3-cinnamon-64bit.lst title linuxmint-19.3-cinnamon-64bit.iso set iso_path=/CD/linuxmint-19.3-cinnamon-64bit.iso map (hd1,4)%iso_path% (0xff) map --hook root (0xff) kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=%iso_path% quiet splash -- initrd /casper/initrd.lz And of course this would be useful for my personal approach (COSMIAS, which noone else uses BTW) with "embedded" batch and self-mounting (JFYI): http://reboot.pro/topic/17807-release-cosmias-a-new-approach-to-g4d-images/ Yep. jaclaz

What you should try is to add to the menu.lst entry a: map --hook Two possible results: 1) the entry fails because the "unknown" command creates a blocking error 2) the unknown command creates a warning and the entry works nonetheless If this latter, you can use (minus the iftitle ) the same entry on both normal grub4dos and on UEFI grub4dos. jaclaz

USB sticks can be seen EITHER as "fixed" (very few) or "removable" (most), at least on XP/Vista/7. Windows won't put a MBR on "removable" sticks, or if you prefer, "removable" USB sticks are NOT partitioned, they are normally "super-floppies", i.e. their first sector is a PBR and not a MBR. There are several different approaches to have the MBR on a removable stick, mainly: 1) write manually a MBR and partition table to it[1] 2) add a driver to the running Windows install that can make the stick be seen a "fixed" 3) use the stick "Manufacturer's tools" to "flip" the removable bit 4) make an image of the stick, mount it in a virtual drive, partition/format it, then dd it back to the stick Then there may be some issues with the BIOS of the specific machine, some *need* a second (minimal, hidden) partition to see the stick as "fixed" at boot time. Then the booting sequence remains the same: BIOS->MBR->PBR of active partition->bootloader or system file (i.e. IO.SYS or NTLDR or BOOTMGR)->OS Of course either BOOT.INI or /boot/BCD need to have correct settings. Choose among 1-4 above and I will point you to the details/tools needed, though the easiest would still remain uing one of the several partitioning/formatting tools that we have now available, namely I would recommend you RMPREPUSB. jaclaz [1] once there is a pre-written MBR and partition table on the stick, Disk Manager will allow formatting of the partition/volume in it BUT (if there are more than a single volume on a "removable" stick, only one will be mounted and assigned a drive letter)

Naah, JFYI: but - to be fair - with the Service Packs it is not that bad (and as I see it Windows 7 is actually a Vista service Pack 3+) jaclaz

Sure , but you started it . BTW, and JFYI deleting posts is usually frowned upon, if you wrote something that you later find to be incorrect, it is better to format the text by striking it, so that people can understand what happened. This is an example of something that is striken. jaclaz