[Nevermind] Archaeology: Debian Etch, Ontrack, and passing module parameters at boot.

[steve_v]

First and foremost, yes, I know. Etch is ancient, and Ontrack is even more so. I have my reasons, chief of which is that I need a usable system on a DX4-100 with 48MB of RAM, and modern Debian is a: compiled for i686, and b: far, far too fat to run reasonably with so little memory.
This machine will not be used for anything security sensitive, obviously.

That out of the way, here's my problem:
Ontrack Disk Manager (or Mangler, if you prefer) shifts the real MBR by 63 sectors and inserts it's own (with a special partition type) so it can load itself into memory before DOS boots. A chainloader if you will.
The data on the disk is actually unmangled, as is the real MBR and partition table... it's just in the wrong place. I need to read that disk from Debian.

There are, AFAIK, two approaches to reading such a disk from GNU/Linux. One is to mount it with the loopback driver (or device mapper) and specify the correct offset. The other is to pass the "hd[x]=remap63" parameter to the ide driver, something which was added for exactly this scenario.

I cannot, however, get either of them to work with Etch.

Option one produces a loopback device (/dev/loop0) containing a valid partition table and one FAT32 (yes, some DOS variants support FAT32) partition. fdisk sees it just as it should... But I can't for the life of me get the kernel / udev to create a device node (/dev/loop0p1) for said partition.

Various archived information suggest using:
losetup --partscan --find --show
partprobe (from parted)
partx (from util-linux)
kpartx (from multipath-tools)
blockdev --rereadpt

#1-4 do not exist, at least not in the package versions shipped with Etch. losetup in particular doesn't understand any of those flags.
#5 responds with "invalid argument" no matter how I give it the device name, and does nothing if I don't. Does it not work on loop devices? I can't find any documentation that is relevant (read "old enough").
No amount of mucking about with 'udevtrigger', 'udevsettle' etc. produces anything useful.

The loop driver doesn't appear to support the 'max_part' parameter, so I guess Etch didn't get this? Presumably that means I'm SOL using the loop driver with partitioned "images"... Or am I just missing something obvious?
I get exactly the same results with dmsetup as as I do with losetup, but I can't find any reference to using it on top of a partitioned device...
Everything just bangs on and on about LVM and encryption.


So near, and yet so far. But anyway, on to option two, IMO the cleaner solution. I know this works in Slackware.

I can pass 'hda=remap63' on the kernel command line all day long, to no effect. It was suggested to use '$modulename.$option for things loaded by the initrd (which ide appears to be), but I can't find a permutation of that which works either. TBH I suspect it's a post-etch feature.
Trying to pass other valid options to that driver (such as idebus=33, which I also want) also has no effect.
I'm beginning to think that a mechanism to pass options to initrd-loaded modules on the kernel command line is simply missing in Etch, or at least it sure looks that way.

I have read that update-initramfs is supposed to read /etc/modprobe.d/* and /etc/modules, but this does not appear to be the case in Etch, as nothing I put in there changes the generated image in any way. Module options included.
Frustration intensifies...

The only mention I can see of the ide module WRT initramfs-tools is a one liner in '/usr/share/initramfs-tools/scripts/local-top/udev_helper' asking udev to load it, with no options. Attempting to override that script in /etc/initramfs-tools/scripts gets me nowhere.
TBF I'm probably just doing it wrong, the initramfs-tools documentation is not an easy read.

So, how, for the love of ancient Debian releases, do I pass a module parameter to a module that is loaded from the initrd? This problem should be as simple as passing it on the kernel command-line, but apparently the (incredibly janky IMO) initrd setup Debian Etch uses is trolling me.

Anyone here old enough and grizzly enough to remember this junk? Or point me to some documentation that actually still exists?

If push comes to shove I guess I could compile the ide driver into the kernel to get around this initrd madness, but I'm not really all that keen... Compiling a 2.6.x kernel on a 486 is going to take days. Literally. I know, I've done it before, it sucks.
Hell, given that it will inevitably involve a swap partition, and the disk this is running from is on an ISA bus controller that can do ~3MB/s... I might actually die of old age before it's done.

[brian_p]

[quote=steve_v post_id=739276 time=1626425117 user_id=143888]
First and foremost, yes, I know. Etch is ancient, and Ontrack is even more so. I have my reasons, ...

I tries on hamm and bo. No success. Do you think it is worth a bug report? I have my reasons for asking this, just like you.

[steve_v]

I tries on hamm and bo. No success. Do you think it is worth a bug report? I have my reasons for asking this, just like you.

Presumably this is satire, as nobody sane is going to file a bug report against a ~15 year old release.
It's also not particularly helpful.

Note that I'm not looking for somebody to go back and fix Etch, what I'm looking for is information. Specifically whether the loop / dm drivers in Etch support partitioned devices (and if so, what's the magic word), and more generically, how to pass module parameters into the initramfs.

The latter is a non-problem on at least 3 other distros of comparable age I have used (Slackware, Redhat, Gentoo), so it's something specific to Debian... Which Is why I ask here, thinking that maybe, just maybe, there are users still on this board who remember this stuff. I personally wasn't running Debian back in the early 2k's, so I'm looking to someone who was for some guidance.
Perhaps that's a fools errand, and as it appears most of the old-school sysadmin types I used to talk to left in the last big (systemd) forum blowup, perhaps it's nothing but crickets and windows 10 refugees in here anyway. But I thought it was worth a poke.

If I'm horribly mistaken and you do actually have something constructive to add, my apologies. Please continue.

Alternatively, if you have a suggestion for a different distro that will run (and by run I mean boot in less than 3 minutes and consume less than ~20MB RAM at the CLI) on this hardware, is suitable for a traditional HDD install (so not TinyCore or old knoppix-respins), and has repos that are still up, I'm all ears.

[p.H]

I used Etch in its time, like all Debian releases since Potato, but cannot remember much about it except it came with Linux 2.6.18 or 2.6.24 (etch-n-half). I still have a few i386 installation CD-R, so I could check if one is still readable, install it on an old enough PC and do some tests.

[steve_v]

I still have a few i386 installation CD-R, so I could check if one is still readable, install it on an old enough PC and do some tests.

I wouldn't dare ask anyone to go to such lengths, but then I'm not about to to say no to an offer either.
If you can figure out how to pass anything useful to the IDE driver (something like idebus=XX sticking or not should be easy to check from the boot messages), that'd be awesome. I'm pretty confident it's all I need.

Right now I'm slightly distracted setting up Slackware 8.1, and so far everything is going swimmingly, Ontrack mangled disk included.
Whether that's down to the 2.4.x kernel, the fact that ide isn't a module (slack ships multiple kernel images instead), or just a simpler boot process is an investigation for a little later, once I have the base system installed.
I would kinda like a real package manager though, and udev would be a nice-to-have as well - hence initially selecting the somewhat less archaic Debian Etch for this exercise.

When I get hold of some more blank CDs (also getting hard to find here, WTF ), I might give some earlier, 2.4.x based Debian release a go for the sake of comparison.

Trivia: Slackware 8.1 is actually what I was running the last time my main PC was a 486, and the specs on this one are eerily familiar.
It's even running the very HDD that came out of my old box, and it's still a minter. I'm kicking myself because I wiped it to install FreeDOS at some point in the past... IIRC to run some '80s PLC programming software and the 8-bit ISA comms card that goes with it, for work of all things.
The CPU is a little slower, but that may be rectified shortly, ebay permitting... Sadly I might have to settle for an AM5x86-133, as DX4-120s look to be almost impossible to get, and that probably means no 40Mhz VLB for me.

[p.H]

The first CD-R was good, so I just booted it and launched the installer in expert mode.
It appears that Etch's 2.6.18 binary kernels already switched from IDE to ATA drivers (I do not remember when exactly that happened), so IDE/PATA/SATA drives are detected as SCSI drives /dev/sd* instead of /dev/hd* and kernel parameters related to the old IDE drivers are ignored.

As a last resort you can use a loop device for each partition with the proper offset and length.

[steve_v]

It appears that Etch's 2.6.18 binary kernels already switched from IDE to ATA drivers (I do not remember when exactly that happened), so IDE/PATA/SATA drives are detected as SCSI drives /dev/sd* instead of /dev/hd* and kernel parameters related to the old IDE drivers are ignored.

Well that's odd, I definitely got the old IDE drivers here (both dmesg and lsmod confirm - ide, ide_core and ide_generic are loaded). My disks are indeed presented as /dev/hdx too, even the CDROM.

I didn't have to pass anything to the installer for that either (though I did need edd=off, which is not documented AFAICT), the initrd loaded it automagically. Perhaps because the chipset is PIO only? I have a vague recollection that the new ATA stuff needs DMA, but I could very well be wrong on that.
Note this is not the etch-n-half kernel, it's the default image from debian-40r9-i386-xfce-CD-1.iso, retrieved with jigdo (linux-image-2.6-486_2.6.18+6etch3).

As a last resort you can use a loop device for each partition with the proper offset and length.

I could, and though annoying it will likely work... But I can't install to that like I can with the in-driver remapping, now can I?
I know originally I said "read" an ontrack-ed disk, but going from ~2.9MB/s on a secondary IDE controller to ~7 MB/s on the primary disk is a fairly convincing reason to try installing to a partition there IMO.

[p.H]

Well that's odd, I definitely got the old IDE drivers here

Maybe your chipset is only supported by IDE drivers, yes. I only tested with a rather "recent" machine (Core 2 with SATA controller in IDE mode). I dumped my last 486-based PC years ago, but I still have a 586-based PC I haven't used for years.

But I can't install to that like I can with the in-driver remapping, now can I?

Install ? How exactly do you want to use this drive ? And why do you need Ontrack Disk Manager ?

[steve_v]

Install ? How exactly do you want to use this drive ? And why do you need Ontrack Disk Manager ?

Let me back up a bit...

The machine I'm playing with is an IBM pizza-box from ~1994. It has space for exactly one 3.5" HDD, one FDD, and one optical drive. That HDD is a 20GB Seagate (horrifically expensive when I bought it), running Ontrack DM... Because I desire to have more than 500MB of it available to put a bunch of DOS games and development stuff on, and because the IBM CrippleBIOS(TM) doesn't appear to have int13h extensions... Or at least sane ones anyway, this BIOS is very strange.

Due to cabling and space constraints, the HDD and the CDROM are on the primary 32bit (VLB) IDE channel. I have no real choice in this.
The secondary IDE channel is on the 16bit ISA bus, and currently driving an IDE to CF adapter, which takes up the one available (after the SB16 and 3c509) expansion slot. There are no front-accessible locations to move this to, and VLB IDE cards are unobtanium where I am even if it were an option. So anything other than the primary HDD and CDROM gets 16-bit performance, and that's kinda painful.

The goal, in the end, is to dual-boot DOS and GNU/Linux, with both having access to that single large and (relatively) fast disk.

Initially, the plan was to install Etch on a CF card and gain access the primary HDD, potentially after repartitioning it to provide some "shared" space.
However, having tried installing to said CF card, I have concluded that the ISA bus is simply too slow for running GNU/Linux from... Or at least too slow for my patience. So I would now very much like to install to a partition on the HDD, likely booting with loadlin since Ontrack eats the MBR.
That means (unless you have a better suggestion OFC) keeping the overlay for DOS, and working around it's idiosyncrasies from GNU/Linux. I've done this before in the deep past and it works just fine... So long as the IDE driver is aware of that pesky one-track offset.
The CF card can then be used for watching grass grow moving stuff on and off the machine.

I now have Slackware installed to just such a partition, and everything works nicely ... It's just, well, Slackware, with the usual annoyances that entails.
I'd really prefer it was Debian.

Oh, and before you ask, yes, I am aware of XT-IDE. However I don't have an EPROM burner, a free ISA slot, or a network card with an option ROM. I'd really rather not purchase a 'prom burner and replace my NIC when I know a little software hackery solves the problem.

It seems to me that my options are a: install a distro that still ships a 2.4.x kernel without this newfangled SCSI-emulation stuff, or b: beat Etch's initrd into submission such that it passes the requisite parameters to the driver. Alternative suggestions that don't involve nuking my large-disk-aware DOS install are of course welcome.

[steve_v]

Ya know what? bugger it.
Slack is running so nicely, all my hardware is autodetected flawlessly with the default kernel image (and far more quickly than the likes of knoppix), and it's simple BSD-style initrd-free startup is such a delight to work with, I think I'll just leave it be. Seems I had forgotten how clean, lean and mean that distro is.

The pesky ontrack MBR is actually detected and accounted for with no boot parameters at all, if it wasn't for a message from the ide driver about finding an ontrack partition type, one wouldn't even know it was there.
I probably won't bother with loadlin either, since dual-boot from LILO was so incredibly easy to set up.
Now that's how this stuff is supposed to work.

Best of all, I'm looking at <4MB RAM in use at the CLI, with sshd and a bunch of other default services running. Performance is pretty dang snappy too, all things considered.

At this point, I feel this is somewhat appropriate:

No offence to Debian of course, but hey, If the shoe fits...

[p.H]

Well, if you change your mind, here is what I found after installing with a Debian Etch Xfce 4.0r4 image on the oldest PC I have : Pentium 166, 64 MiB DRAM, Intel PIIX3 PCI IDE chipset, 2GB IDE hard disk.

1) This chipset was supported by the old IDE piix driver instead of the new ATA ata_piix driver.

2) The installation was painfully slow, and that was not because of the CD-R speed.

3) When the IDE core driver is compiled as a module ide-core, IDE options must be passed in the "options" module parameter. The following command works when the module is not loaded :

Code: Select all

modprobe ide-core options=hda=remap63

4) module.param=value parameters are ignored by the installed system. I guess it depends on the version of modprobe. Etch included modules-init-tools, newer versions include kmod.

5) However module parameters can be set with a file under /etc/modprobe.d/. For example /etc/modprobe.d/ide-remap containing

Code: Select all

options ide-core options=hda=remap63

The initramfs must be rebuilt to include the file with

Code: Select all

update-initramfs -u

You can check that the file is included with

Code: Select all

gunzip -c /boot/initrd.img-$(uname -r) | cpio -t | grep ide-remap

(Etch did not include lsinitramfs yet)

Now, that is for an installed system. What about the installer ?

6) The ide-core and piix modules are loader early by the installer, before any possible user interaction, and cannot be unloaded. So it is not possible to load the module and pass the option by hand in a shell.

7) Fortunately, as mentioned in the help (F1-F10), module parameters can be added to the installer command line. A file /etc/modprobe.d/local is created and contain options lines with the parameters.

8\) Unfortunately the kernel command line parser seems to be broken (at least in 4.0.r4, maybe fixed in your 4.0r9) : it translates

Code: Select all

ide-core.options=hda=remap63

from the command line into

Code: Select all

options ide-core options=hda=hda=remap63

in /etc/modprobe.d/local (see how "hda=" is doubled). I suspect the presence of an "=" sign in the parameter value is not handled properly.
I tried all sorts of things like single and double quotes to work around it, but no luck. However I found out that the module fails to load if passed an unknown parameter. This is all I needed, even though hackish. So I added "ide-core.whatever" to the installer command line. Then I could enter the shell in tty2, remove or edit /etc/modprobe.d/local and load ide-core with the proper option. Maybe it is better to fix /etc/modprobe.d/local if the installer adds it to the installed system (didn't try a new installation, too long).

[steve_v]

When the IDE core driver is compiled as a module ide-core, IDE options must be passed in the "options" module parameter.

That'd do it alright. My memory, all the (probably far too new) docs I was reading, and the modprobe manpage in my Slackware install all say 'modprobe module symbol=value' is the correct syntax.
Not sure where that screwey options=symbol=value syntax came from, (or where it went) but it's new to me. Is it a Debianism, or just specific to particular modprobe versions?

For example /etc/modprobe.d/ide-remap containing

Code: Select all

options ide-core options=hda=remap63

Yep. That'll be why my /etc/modprobe.d/foo files did nothing useful. Again I was using the syntax I'm familiar with.

Where'd you find this stuff anyway? Granted I didn't get far enough into the install to actually read the included manpages before i gave up in disgust , but I didn't see it anywhere obvious in any of the web-documentation I pulled from archive.org.

Unfortunately the kernel command line parser seems to be broken (at least in 4.0.r4, maybe fixed in your 4.0r9) : it translates

Code: Select all

ide-core.options=hda=remap63

from the command line into

Code: Select all

options ide-core options=hda=hda=remap63

in /etc/modprobe.d/local (see how "hda=" is doubled). I suspect the presence of an "=" sign in the parameter value is not handled properly.
I tried all sorts of things like single and double quotes to work around it, but no luck. However I found out that the module fails to load if passed an unknown parameter. This is all I needed, even though hackish. So I added "ide-core.whatever" to the installer command line. Then I could enter the shell in tty2, remove or edit /etc/modprobe.d/local and load ide-core with the proper option. Maybe it is better to fix /etc/modprobe.d/local if the installer adds it to the installed system (didn't try a new installation, too long).

Holy mackerel. Giving up on Etch in all it's complexity and sticking with Slackware intensifies...
Having that driver compiled into the default kernel image (and no initrd at all) makes things about a bazillion times less annoying, and a bazillion times faster to boot (pun intended).

Still, your help is greatly appreciated. I'll be bookmarking this lot for a time when I... Have more time. I still have that CF card, just not the patience to boot it. I'm having far too much fun getting X to run properly on my 1MB GPU.
Don't suppose you know where I can get a copy of the "badram" patch for 2.4.18 do you? If memory serves I'm going to need it to remap the VGA memory hole...

[p.H]

Not sure where that screwey options=symbol=value syntax came from, (or where it went) but it's new to me. Is it a Debianism, or just specific to particular modprobe versions?

Neither. It is just the usual syntax, the symbol name being "options" and the value being an arbitrary string containing an "=" sign. This is just the same as the root parameter when using (PART)UUID or (PART)LABEL :

Code: Select all

root=UUID=xxx-yyy-zzz...

Where'd you find this stuff anyway?

To be honest, I figured it out. I checked which IDE modules were loaded with lsmod, then I checked which parameters they accepted with modinfo, assuming that "hda=remap63" was to be assigned as a value to one of them. Later, I found this in Documentation/ide/ide.txt from the kernel documentation :

Code: Select all

When ide.c is used as a module, you can pass command line parameters to the
driver using the "options=" keyword to insmod, while replacing any ',' with
';'.

Giving up on Etch in all it's complexity

This is just a trick to work around an installer bug. No complexity added to the installed system.

Having that driver compiled into the default kernel image (and no initrd at all) makes things about a bazillion times less annoying, and a bazillion times faster to boot

IME an initramfs comes in handy in some situations. E.g. you cannot use UUIDs or LABELs without an initramfs (which are mandatory when the device names are not stables, as commonly seen with /dev/sd*). Also the embedded shell has helped me in a lot of situations when something goes wrong at boot time. Also it allows a smaller generic kernel image, as all disk and filesystem drivers can be built as modules.

[CwF]

Threads like these make me want to play with some closet hardware. I came late to the party, but do use i386 for some vm play and wonder... I tried some older scsi controllers under amd64 a few years back and they didn't work, so I never pressed it. But...I have a few older higher end setups that I'd think would do well. I was at 4 GB ram and dual 1.4's before XP came out, that might do ok with modern debian? They have adaptec scsi, never tested, and mylex/buslogic were the amd64 test, and unknown chip 8 port sata not tested...I should find the time.

The mylex are in my 233mmx, still works. Even back then IDE was just not worth it.

[steve_v]

I was at 4 GB ram and dual 1.4's before XP came out, that might do ok with modern debian?

Pretty sure that'd do just fine. I have modern-ish Debian on slower & smaller.

Even back then IDE was just not worth it.

Non-busmastering non-DMA IDE sucked pretty hard for sure. But it was cheap, it was common... and have you seen what VLB SCSI cards go for these days?
I'd love SCSI in this box, but it's pre-PCI so that's a big fat nope unless the hardware practically falls on me.

[CwF]

have you seen what VLB SCSI cards go for these days?

$200+ back then, I almost bought one. Sorry sold off a few 1542's, might have a 2940 left. I had no problem liquidating all pre pci pentium stuff. Kept my Abit IT5H with 4 wide channels, skipped a bunch and kept many P3T boards and ran them all 10+ years. That 8 port sata is pci66, and the gigabit, along with an amd 5450 pci that likes the 66 bus, so maybe I should try it. The dual adaptec versions have agp-pro Z1's I think, I'll bet the 5450 is faster...

Yes, I should...It'll be fun they say....