I know what I did to myself - I had an sdcard with Arch Linux for Arm installed. It was in my sdcard reader, and I was copying over to a backup drive, and something went wrong in the rsync stage. I started getting exec format errors, nothing would work, and I gather I rsync'ed some Arch stuff onto the / drive, from looking in there later. My disk is formatted
sda1 1G /boot
sda2 swap
sda3 / for Slackware
sda4 - extended partition
sda5 /home for Slackware
sda6 / for Mint-19.3 (has the lot) mounted as /media/hd0 in Slackware
sda7 scratch disk & has the VMs mounted as /mnt/virtual in Slackware.

Arch has the standard set of unix directories, and I stopped it quick enough. It boots all the kernels in /boot, I gather it mounts / ro, screen clears, and I get
[CODE]/sbin/e2fsck: Is a directory when trying to mount /
/:
[CODE]
It then gives me this lecture about how it's dropping me to a single-user shell because it can't find a valid ext2/3/4 filesystem and to press Ctrl-D to continue or the root passwd, but the thing is frozen, and I can do nothing.

I have backups. I quickly found Mint-19.3 is spouting errors, but Arch doesn't have /media/hd0 so it can hardly have attacked that. For Slackware, I deleted sda3, remade the parttition, made a new ext4 filesystem and restored my backup from February. I still get that error. /boot seems clean, I can mount sda3 and it's fine. Ny standards, this is a good one

[OT]Rationale for not having created a GPT for this drive?[/OT]

[OT] Simple - M$ appeared to write the BIOS. I got this in 2013, when UEFI was out, and linux was struggling with it. If I had a GPT drive, the BIOS presumed UEFI no matter what I had configured. To get a legacy system, fdisk partitions were a necessity.[/OT]

Further on the problem, I can mount all partitions fine and they all check out with e2fsck. I have a live usb disk I can get in with. I restored the common boot - no change. It was clean, as I suspected. /sbin/e2fsck in Slackware is not a directory, it's an executable, and it's been restored from known good stuff. On Slackware, the reason the screen clears is that there's a page of greps. Because / isn't mounted, so each one takes a few lines.

On my Mint Install, that fails for the lack of finding /etc/inittab. But /etc/inittab is there, and I don't know how the Arm sdcard could have done anything to /media/hd0 when it didn't have a 'media/hd0' of it's own to overwrite it with. USB boot works fine. But at least it's mounting it's / dir, shrinking the fonts, and looking for inittab.

I'd be thinking 'hardware fault' despite my messing with the Slackware install except everything works off the usb key. I'm close to wiping the disk, because I'm in a reasonable state with backups, but everything is restored in Slackware, and it still pukes. I've kernels with ext4.ko compiled in and others with an initrd, and all of them go belly up. As a last resort, I'll get rsync to do checksumming, and restore again. Lucky this little Arm is running - I find the live usb more awkward.

Got to the bottom of this:

In post #1, the partition list was incorrect - but that was the way I remembered it. I gave slackware a little more space at some stage. I couldn't increase sda3 without moving sda4. So, I swapped it with sda6, and forgot about it Then when I went restoring, things went AWOL.

So I did a wipe, repartition, and restore. After a little tweaking, I can boot slackware. I can't log in yet, my passwords are refused, and I can't sort grub permanently. It also explains Mint going belly up at the same time. The lessons from this are

1. Don't be a twit - like I was
2. If your error messages are unbelievable, that's because they are.

If for some reason I can't sort passwords, I'll post again. I don't rate the liveusb too highly on it's chroot behaviour, but I'm sure it wasn't built for that.