Per Joshuas comments ...
I've had good luck with
gparted, booted from a live CD/USB, for resizing/moving partitions. It understands many filesystem formats. And, if a partition is resized, it will adjust the filesystem inside the partition.
For example, the tough part is shrinking a partition.
gparted will "do the right thing" and shove data down to the front of the partition and adjust any block pointers and free block maps as needed.
But, as Joshua pointed out, this would be difficult on such an old PC directly (i.e. no CD/USB boot and the code may assume something a more recent CPU arch than a 386 (even in 32 bit mode).
My solution would be to use an additional PC/laptop. With a fresh/modern [additional] PC, a SATA/PATA/IDE-to-USB adapter is ~$20:
- The old drive can be [physically] pulled out of the 386 PC and connected to the newer PC via the adapter.
gparted can run on the newer PC, and repartion/reimage the old HD with that.
- It can also install
grub2 on the front of the disk
- Also, the entire disk image can be saved [byte-for-byte] to a file on the laptop, so it can be restored if a misteak [mistake :-)] is made. This aspect could be worth its weight in gold, even if we don't use
gparted for resizing.
- As an additional safety, with the adapter, the [existing] DOS files could be backed up to a
.zip file or other backup media
How that will handle the geometry difference? The 386 sees a 504 MiB drive with 1024/16/63 geometry, even if the drive itself is 7769/16/63,
That may be a valid point: (BIOS aside) Can the 386's disk adapter address the extra disk space?
I assumed that it could because OP was booting linux off a floppy and it was able to access the linux partition (via linux device drivers that talk directly to the adapter).
Also, Compaq was somewhat ahead of its time--in its day, so I'm guessing yes [I actually had to do some work on one circa 1989]. But, OP's Compaq is 1992, the year that LBA addressing was introduced. IIRC, Compaq tended to be an early adopter of such things, so the system might support LBA addressing (even if DOS or the BIOS didn't).
and USB has no notion of geometry and linux may use any made-up geometry on the drive. Especially if the drive is repartitioned without care. –
gparted, it accesses the disk via the raw device, so it does its own mapping. It's pretty flexible as it's intended for crash repair scenarios as well (IIRC).
I haven't used such USB adapters before, so this is just a guess. It doesn't present (doesn't have to present) as a USB disk/stick in the classic sense of an LBA scheme. You can send special commands to the adapter that mimic the ancient port H/W (e.g. set cyl, head, sector). So, the USB adapter functions like a dumb IDE adapter of the era.
Can you show the partition table (e.g.
fdisk -l output)?
What is the starting offset of the first partition? If part1 starts at (e.g.) 1024 sectors vs directly abutting the MBR, you can install grub.
As an alternative, you could create a contiguous file in the DOS filesystem and point the grub MBR/boot block to read from that contiguous area instead of physical sector 2.
This gets the grub second stage going.
Now, grub has a driver for DOS fat FS available.
You can put the
/boot directory (holding grub
.mod files, ramdisk images, and vmlinux images) in a subdirectory in the DOS filesystem. You can point grub to that (instead of a partition with a small linux FS).
This gets around any BIOS limitation with not supporting full CHS addressing. That is, if it didn't you couldn't boot DOS.
So, no need to resize the DOS partition!
After grub brings up the kernel, the kernel can access the disk controller directly. It will read the partition table. You just need to add an entry in the MBR for the linux FS (e.g.
Your 4GB IDE disk is (CHS?) 7769/16/63. So, this seems to be EIDE/ATA-2 (vs. IDE/ATA-1)? See: https://computer.howstuffworks.com/ide.htm
You do not need LBA addressing because CHS can go up to 8GB.
Justme has a good point. You MUST BE CAREFUL when taking a hard drive out of an old non translating non LBA supporting BIOS like this. The new drive controller and/or the disk utility might assume that the drive is being accessed in translation mode and completely mess up the CHS geometry.
gparted is [much] smarter than the disk partition programs you're probably used to under DOS.
This is a common situation when trying to partition a drive on the more modern system to use in the old one. In this case I believe it would be safe because the CHS geometry is stored in the MBR, and the disk utility should use that.
Yes, and that is exactly what
Whether a filesystem uses CHS or LBA addressing [internally] is specified by the partition type byte in [classical] MBR partition entry.
Even if the FS uses LBA on a strictly CHS disk controller (integrated into the disk drive itself), the filesystem software device driver would have to translate the LBA block addresses back into CHS given to the disk controller (via the host adapter card).
Note that linux filesystems do not store CHS in inodes, etc. Never have, never will. So, they always had to translate them into CHS before passing them to the controller (if the H/W controller didn't support absolute block addressing). And, linux was bootable on 1992 era hard disks just fine.
Remember that IDE et. al. is a logical H/W interface. The PC host adapter card just passes digital commands to the controller that is integrated into the card in the disk drive.
By contrast, the older ST506 interface was (MFM) bit stream oriented at 5MHz. https://en.wikipedia.org/wiki/ST506/ST412 The disk drive had an integrated analog formatter board that could translate a bit stream from the PC disk controller to levels to the magnetic disk heads.
Because the drive had to maintain 5Mhz compatibility, this limited the amount of data that could be stored. By going to the logical IDE interface (the controller and formatter were now in the drive), the drive could take advantage of any special enhancements in the drive's recording surface.
Also, with ST506, the drive was at the mercy of the quality of the particular computer system's disk controller. A badly implemented controller would make the disk "look bad".
Also, it was [more] difficult to pull a given disk from one computer manufacturer's controller to another due to minute differences in how the controller implemented the standard:
- The exact format of the sector preamble/marker.
- The sector CRC algorithm.
- How much time/space to allot for the "write splice" area.
- How many sectors per track.
Side note: For example, I worked for a computer company that actually "overclocked" the [earlier] 8" disk drives to increase the total capacity by putting in 3 extra sectors per track. IIRC, we also did this for the 5.25" ST506 drives, so we had greater capacity than competitors but the drives had to be reformatted [at the bit level] to be used by other manufacturers.
Of course it won't boot in the modern system unless transation is disabled. –
Obviously, we don't want it to boot from the USB-to-IDE adapter on the modern system. We just want it to arrange the tables and images correctly.
This is similar to having an SD card reader/writer on a PC to create a bootable linux SD card image that we then put into a Raspberry Pi (e.g.).
MFM drives do not have a "bit stream to magnetic signal" conversion inside the drive.
The encoded signal (MFM or whatever) is presented at a "standard" level (e.g. 5v TTL and/or differential or whatever) between the system's controller board and the drive's formatter board.
It is converted (level shifted) to whatever voltage/current level the drive's magnetic heads require by the drive's formatter board.
The MFM/RLL data cable does not carry a raw PC bit stream, but an MFM encoded bitstream at 5MBps or an RLL encoded bitstream at 7.5MBps.
I believe I [already] said that:
the older ST506 interface was (MFM) bit stream oriented at 5MHz
The formatter / decoder that translates between MFM/RLL and a raw data bit stream is part of the controller.
There may be some confusion as to terminology.
Early ST506 drives had a board on (or in) the drive itself. This was the formatter board.
The controller board was a separate board, provided by the computer system manufacturer, that plugged into the system's bus (e.g. ISA, VME, etc.).
The controller would DMA in/out data bytes from system memory and convert to/from an MFM stream when talking to the formatter board. The formatter did not understand anything about disk sectors (or even bytes). It just knew bits [again, encoded].
The controller would send cylinder/head to the drive, the drive would seek the heads, and the controller would wait for the heads to settle on a track.
Then, the controller would read/write the bits as a stream to/from the drive/formatter.
It was the responsibility of the controller to manage anything related to the sector format of the track. It could/would wait for the index pulse from the drive, write sector headers, data areas, CRC, inter-record gap, write splice, etc.
The [typical] format of a track was a series of sectors, with a format like:
preamble_bits | sector_number | sector_header_CRC | header-to-data-gap (bits)
preamble_bits | data_bits/bytes | data_CRC | inter-sector gap/write splice (bits)
This byte/sector formatting was at a level higher than the MFM stream. Only the controller knew about this format as the formatter only knew bits.
The controller (and not the formatter) would decide:
- How many bits for preamble and what value
- Whether the bytes were encoded little-endian or big-endian
- How many bits to have for the sector-header to data block gap
- How may bits to have in the inter-sector gap. This had to be larger to allow the logic to recover from the write splice which appeared as a "glitch" (after the data for a sector was rewritten).
- When reading, the controller would look for the sector header, read the data, verify the CRC.
- When writing, the controller would look for the sector header, wait a bit, enable the write current, write the data preamble, the data bytes/bits, write the data CRC, disable the write current.
There was some variation in performance/reliability of the drives because the sector formatting/density, CRC verification, etc. was done by the controller [provided by the computer system manufacturer and not the drive manufacturer].
This changed with ESDI: ESDI puts all the bitstream encoding logic into the drive, and transfers a raw bit stream at 10MBps over the data cable. –
ESDI came later as the time frame I was talking about was 1981-1986. It was this integration that allowed the drive to take full advantage of whatever [proprietary] recording technology it had.
As I mentioned, with IDE, the system's disk controller was renamed the "host adapter" and talked to the drive in byte/sector "logical" mode, now giving the sector number to the drive.