Re: openbsd 4.9 based UTM
What IS an UTM? Clearly, citoyen is building a Universal Turing Machine. :)
anyone need old PC crap?
Are there any developers (or anyone else) in the NY area who have a use for old PC crap? A 286, a 386, at least one 486 motherboard, some Pentiums, some P2s, etc? Before I cart it to the recycling center...
Re: MFM disk geometry
The wrap-up: So I got the data off the drive. :) One issue is it turns out the drive is a bit flaky. I'm not sure how much of the issue is heat, and how much is tilt. I had done most of my fiddling with the drive perched in places that weren't quite flat, and I think these old drives must have been more sensitive to that, considering that I discovered this morning that the data sheet on TH99 says not to tilt it more than 5 degrees (!) from horizontal. I tried older hardware, and DOS-type stuff, but didn't get anywhere, although there were intermittent moments when things worked. See above. What finally worked was the same P3 setup and a bit of kernel hacking, plus getting past the flakiness. However, I think I found an obscure kernel bug that probably wouldn't affect anyone except people trying to do what I did. In wd_get_params() in dev/ata/wd.c, if the kernel gets an error when it tries to get ATA info from a drive (and this one is pre-ATA), it uses 1024/8/17 and single-sector transfers with no ATA capabilities. This is the comment: /* * We `know' there's a drive here; just assume it's old. * This geometry is only used to read the MBR and print a * (false) attach message. */ However, that doesn't seem to be the case. The P3's BIOS doesn't even provide info about the MFM drive, but on a P1, with an old OBSD boot floppy, 'machine diskinfo' at the boot prompt gave me 614(?!)/4/17, which is more or less correct - and then the dmesg used 1024/8/17. And I know that it wasn't just faked for the dmesg, because of the numbers in the error messages I got, eg 'blah blah fsbn xxx (bn x: cn y, tn z, sn q)' - to get those c/t/s numbers for that block number meant the kernel was using 1024/8/17 to access the drive. I haven't replicated this with a more recent kernel, but I suspect this code hasn't been touched in a while, considering that 4.6-release does the same thing. Presumably, if the kernel is actually going to use LBA mode, or the ATA-info error is transient or whatever, this hack won't cause any problems. But has anyone else tried to use a CHS-mode-only drive with geometry other than 1024/8/17 with success? Is there a provision somewhere else to get the correct numbers? In any case, I changed those numbers to the correct ones for the drive and recompiled the kernel. Initially it didn't work (flakiness), but when I tried again this morning with the drive level and cold, I was able to get almost everything off the drive. The rest is probably attributable to bad sectors, considering the drive is around 20 years old. Here are the results you've been waiting for :) --- dmesg: wdc0 at isa0 port 0x1f0/8 irq 14 wd1 at wdc0 channel 0 drive 0: ST506 wd1: 1-sector PIO, CHS, 68MB, 1024 cyl, 8 head, 17 sec, 139264 sectors wd1(wdc0:0:0): using BIOS timings --- fdisk: Disk: wd1 geometry: 615/4/17 [41820 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: 04 0 1 1 -613 3 17 [ 17: 41735 ] DOS FAT-16 --- disklabel: # /dev/rwd1c: type: ST506 disk: ST506/MFM/RLL label: ST506 flags: bytes/sector: 512 sectors/track: 17 tracks/cylinder: 4 sectors/cylinder: 68 cylinders: 615 total sectors: 41820 rpm: 3600 interleave: 1 boundstart: 0 boundend: 41820 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c:418200 unused i:41735 17 MSDOS --- df: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/wd0a 5038086 3078892 170729064%/ /dev/wd0d 148271564 101606904 3925108272%/data /dev/wd1i 20810 8924 1188643%/mnt
Re: MFM disk geometry
Try looking for Total Hardware '99 - your controller might be documented in there. Nice! Thanks. http://th99.dyndns.org/c/C-D/20069.htm Unfortunately, it doesn't look like it's actually all that configurable. Although I don't know what some of those settings actually mean. Does anyone else see ways this can help, or care to explain the settings? :) [Ports I understand. Rate I understand but I don't know why you'd need to set it unless maybe it was a question of really really old controllers/CPUs being slower? The others...] [P.S. The controller and drive were pulled from a Wyse 286. Which I have, but seems not to want to boot ATM. The last time I got it to boot, it didn't seem to see the HD. And anyway, I'd like to avoid having to move 20 megs of data on floppies if possible. I'm guessing that that and serial cables would be the only workable choices, given driver difficulties with DOS 3.3 and the fact that the BIOS setup program was apparently originally on a disk which I don't have...]
Re: MFM disk geometry
I think my first course of action would be to use DOS, or possibly OS/2, to override the disk geometry, unless the disk has data on it that can only be accessed from OpenBSD. Yes, I know it's intellectually more fun to get OpenBSD to do it, but for a one off with little practical future use I think I'd use something else. DOS, OS/2 and OpenBSD can of course all be booted from floppy, thus avoiding any early initialisation nastiness. I'm not sure what you're describing here. Also, accessing the data from DOS still leaves the problem of moving it. Or perhaps I didn't make it sufficiently clear that the goal was to copy the data off the drive...
Re: MFM disk geometry
Alternatively, can disktab be used? The documentation is not entirely transparent on this, but it does appear that disktab might be able to override BIOS parameters. Apparently not. disktab looks like it's mostly used by disklabel. It turns out disklabel with -e will let you edit the geometry, but the kernel doesn't actually change the values it uses for drive access, even though the disklabel remains correct/consistent upon reload.
MFM disk geometry
I'm trying to pull data off an old MFM HD, and I've gotten to the point where the only obstacle is disk geometry. I have a P3 machine which will disable the primary IDE controller in favor of the MFM controller, but boot off of an OpenBSD disk on the secondary IDE. OpenBSD sees the MFM disk just fine, but gives it the wrong CHS, which wouldn't matter except that it's evidently too old to do LBA, since OpenBSD is using CHS mode. I can pull the first few sectors off of the disk, but then I get errors I'm guessing are because of the geometry mismatch. Is there any way at all to change the CHS values the kernel is using for a disk? fdisk with -chs doesn't seem to produce a permanent change (I guess the values are just used for calculating?), and the machdep.bios.etc sysctls are read-only. Google and the archives haven't turned up anything terribly useful, although it sounds like what I'm trying to do may not be possible. If not, anyone have any alternate suggestions? Incidentally, I have a bunch of other old crap around, but my efforts to get everything working on a machine that will let me set the CHS in the BIOS haven't gotten anywhere yet...
Re: MFM disk geometry
holy cow. of all the times NOT to post a dmesg! (and fdisk output). It probably wouldn't help diagnose the problem, but it would be cool to see. :) Obviously, you got a PIII machine with ISA slots, not the most common of beasts (though they certainly exist). (actually, the dmesg would probably just show wdc0 at ... , but it would be kinda cool to know that it was REALLY a wdc, not a low-end IDE interface pretending it was an AT controller). Heh. It does. I'll have to remember to save copies when I finally get all this working. :) And the machine is a Dell Dimension with one PCI/ISA shared slot. I think you need to go back to a P1 (or maybe some PII?) system before you will find one with manual drive parameter selections. That will lead to another problem, very, very very few of those will allow you to directly boot from the secondary controller. HOWEVER, you may be able to set the primary controller to the IDE, and put your MFM controller as secondary (many of the original ones had such a jumper) and be set, or install a SCSI controller and drive and use a boot floppy to boot from hd1a:/bsd... Yeah, I found it rather odd that it would do that in the first place. I think what's happening is the BIOS can tell there's a controller there, but then it doesn't recognize the drive as something bootable, so it goes to the next hd. The 90 MHz Pentium I tried was, well, highly bizarre. For example, the IDE jumpers were labeled 'PCI IDE' and 'ISA IDE'... and even with the IDE turned off in the BIOS, and a drive attached to the 'ISA IDE', it attempted to boot from that drive, which gave me a dmesg including wdc0 @ pci0. Oh, and I have no docs on the controller, and haven't found any online, and the (many) jumpers are unlabeled. So unfortunately... Yeah. Plus, the controller is physically HUGE (lengthwise). Not all of the machines I've tried can even get it into a slot. (Just found this... Looks pretty similar. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=250157575469 ) As you have probably (re)discovered, the OS takes its cues on the drive geometry from the BIOS. On modern IDE drives, it just doesn't matter, but on an MFM drive, head 3 was really head 3, cylinder 138 was really cylinder 138, and there were 17 sectors on each track, and where the OS requested is where the controller placed the drive and Yes. 615/4/17, although I've also seen 616 mentioned (it's an ST225 with no values on the label). The partition ends at 613 (i.e. 614th cyl), and I think the last track is the landing zone, so I'm going to go with 615 if I can get to that point... where the data came off, so yes, it really needs to be right. Yes, source could probably be modified to hard-code this in the OS, but getting it right would be interesting...and very much in untested code paths, I suspect. Well, on the one hand this seems like something you should be able to shoot yourself in the foot with if you really want, not to mention another way to be BIOS-agnostic. On the other, this is about the only time it would ever matter, so I guess the kernel doesn't need the added complexity of a way to change it... good luck, I'm curious how it all works out... Well, I can post the dmesg and fdisk when I get there. :) Thanks.
Re: less minor install issue
On 10/22/2009 2:41 AM, Theo de Raadt wrote: There used to be a message before the install script wiped out filesystems with newfs, listing the partitions and asking if you were sure. Was this removed, or did I somehow miss something? And WHY??? Because it is the install script. What did you think it was going to do. It's installing. It's job is to wipe disks. There is no need for stupid questions. Ah, the sarcasm I was expecting. And here I thought I remembered the new installer being described as easier to use. (Or did I make that last part up? Seems the same from a user perspective, just in a different order. Not that I had a problem with the ease of use either way, other than this.) In fact, there was a particular reason for my question. I had the vague impression, probably erroneous, I suppose, that it was possible to get the old install script to only newfs those systems for which you specified a mount point. I was attempting to check that in the anticipation that the script was actually going to tell me what it was going to do. Granted, I probably should have tested it in a more careful way, but at least the only real damage was to cause a certain amount of aggravation. So assuming that the install script can't do what I was expecting, is there some other way to do a fresh install to only one/some partitions on a drive, or are the choices only a) blow the whole drive away b) install to a clean disk or c) do an upgrade? P.S. I look forward to experiencing the usual wonderful work of the OpenBSD team once I finish cleaning up this mess...
Re: less minor install issue
On 10/22/2009 4:31 AM, Jan Stary wrote: On Oct 22 03:34:45, Daniel Malament wrote: In fact, there was a particular reason for my question. I had the vague impression, probably erroneous, I suppose, that it was possible to get the old install script to only newfs those systems for which you specified a mount point. Which is exactly what happens with the new install script, too. Hm. I think I may have tried things the wrong way first. (Which like I said, I would have expected to notice _before_ it was too late.) Glad to know I didn't make that bit up, though. :) Also, FAQ 4.5.1 says Install: load OpenBSD onto the system, overwriting whatever may have been there. Note that it is possible to leave some partitions untouched in this process, such as a /home, but otherwise, assume everything else is overwritten. I missed that, but regardless, I'm not seeing anything about how to do that in the FAQ... So assuming that the install script can't do what I was expecting, is there some other way to do a fresh install to only one/some partitions on a drive, or are the choices only a) blow the whole drive away b) install to a clean disk or c) do an upgrade? Just leave the partition without a mount point for it in disklabel. Thanks. I think I may test this out a bit more thoroughly on a spare drive next time before risking further aggravation, though...
Re: less minor install issue
On 10/22/2009 5:37 AM, William Boshuck wrote: And here I thought I remembered the new installer being described as easier to use. It is. Were it not so quick it would be positively boring. Just don't set mount points for the partitions Perhaps I should clarify: IMO, not double-checking with the user about what specifically to wipe, especially when it used to, is a step back in 'usability' (in the Jakob Nielsen sense) - or to put it another way, user-friendliness. (I know, not particularly an OBSD-prized value). While I don't have difficulty with using the installer to (ahem) install, I also don't necessarily think 'easy to use' has to be synonymous with 'easy to shoot yourself in the foot with'. Even an explicit message about not setting mount points for partitions that shouldn't be erased would be useful. Actually, s/Even an/Also, an/. But thanks for the tip.
less minor install issue
There used to be a message before the install script wiped out filesystems with newfs, listing the partitions and asking if you were sure. Was this removed, or did I somehow miss something? And WHY???
