On Wed, 10 Mar 2021 at 22:37, Jon Brase <jon.br...@gmail.com> wrote: > Unfortunately, it's not working. OnTrack sees the same ultra-small capacity > for the drive as the BIOS and Linux see on that machine. It picks up the > other 40 GB 2.5" PATA drive, but the SSD + Adapter can't be extended from > what the BIOS sees to the actual size of the drive. I even tried a different > SSD on the adapter, and got almost the exact same crippled size (130 MB), so > I don't even get to test if Linux's offset parameter works, even OnTrack > isn't seeing the full drive size. > > My working theory at this point is that the adapter is detecting that it's > working wtih an old BIOS and "helpfully" setting up a temporary Host > Protected Area on the drive, after which it refuses to acknowledge that any > area after the 130 MB mark even exists until poweroff. I haven't been able to > boot an environment that has hdparm(8) available, so I haven't been able to > test this.
OK, I was alarmed by the mention of "SSD + adapter" so I went back and reread the root message. (I can't go back 2 months because I only just re-subbed to the list after a decade (!) away.) But it's a SATA-to-PATA adapter? That introduces an extra layer of complexity to the question. :-( Also, IIUC, you are trying to access _existing_ partitions? No, I do not think a disk manager will help you there. Disk managers bypass the BIOS restrictions by remapping or translating disks' real values, but they do not just fix the problem. Once you have a disk manager installed, I think you will need to create _new_ partitions after getting a DiskMgr working, using whatever translated scheme it creates. Therefore I would backup the data on the existing drive onto another machine, perhaps a networked one; zero the disks, or at least their first 1kB or so, to erase any exiating partitions; try to create _new_ partitions with the DiskMgr's translation in effect; then copy the data back. (If this includes a bootable OS, then e.g. boot from a Linux live medium, CD or DVD or USB, and connect to the machine with the backups over the network and use Linux to restore the data onto the newly-repartitioned machine. However, saying all that: I do not see any info about what the host machine is. If it is new enough to have PCI slots, then a SATA controller with a BIOS of its own should, in theory, bypass all this nightmare. Citation with model recommendations: https://www.vogons.org/viewtopic.php?t=62958 A firmware-equipped SATA controller (i.e. not some cheap thing that just adds additional ports and is not bootable) will appear to the PC as a SCSI controller and its firmware will take over the INT13 BIOS calls for disk access completely. If you do decide to go that route, though, I advise _against_ mixing SATA and EIDE/PATA disks. Let the SATA controllers' firmware take over completely and do not use the motherboard's EIDE channels at all. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
