On 2013-06-16, Philip Pemberton <
phi...@philpem.me.uk> wrote:
> Hi guys,
>
> I'm sure a few of you will remember my other thread about bringing a 3B1
> back to life ("3B1 Parts Needed"). Well, that 3B1 is working -- I've
> replaced:
>
> * The burned and oxidised power supply connectors.
> * The equally burned power-supply-to-motherboard cable. Replaced with a
> bundle of Alpha Wire ECO-WIRE 18SWG in red, black, yellow and blue (coded
> to match the power rail per ATX specs).
> * The utterly defunct PCB-mount CMOS memory backup battery - now a
> CR2032 in a cute little PCB-mount holder.
Great! Yes, that soldered-in cell for the CMOS is a poor
design. A coin cell clip is a good improvement, and what I did years
ago.
> I had a bit of a false-start to begin with - it seems the power rails
> aren't commoned at the motherboard (though the grounds are). Basically,
> the different 5V/12V pins go to different places... this might explain
> why some pins on the PSU burn out sooner than others (overloading?),
> causing the well-known connector burning.
And -- why particular oxidized pins have specific problems as a
result. That which provides power to the floppy and hard disk
controller chips results in increasing counts of bad blocks -- as blocks
are being written during a glitch, resulting in a corrupted sector, or if
you are really unlucky, a damaged sector ID record. Memory and the CPU
result in the system going off to never-never land until you reboot,
usually by forcing a power cycle. :-)
> My power supply of choice is a Seasonic 235W ATX PC power supply. It
> seems happy enough and can deal with the inrush current demanded by the
> two Miniscribe 5.25" HH MFM drives.
Great!
> But back to my point :)
>
> The machine boots quite happily from the hard drives, sets up the
> screen... then promptly asks me for a login and password. Which I don't
> know.
Oops! You got a system with a drive already installed, then.
> Does the standard 3B1 install have any accounts without passwords set (or
> with known default passwords) which I could use to get in?
Well ... it depends on how serious about security the original
owner was. There is a guest account, which has no password. You can
use this to create your boot disks, once you install some kind of modem
program (kermit is nice, or was back when you did not have to pay for
the PC version of that. :-) Since the format of the floppys is either 8
sectors/track or 10 sectors/track, instead of the IBM PC's 9
sectors/track, making boot disks on a PC is tricky. There was a driver
for older versions of lunix which could be installed to do this.
Anyway -- there was a trick to use the e-mail system to allow
you to exit from the guest account and reset the root password. I
forget what it was, but it should be documented somewhere, likely in the
archives of this newsgroup. IIRC, you sent yourself an e-mail, then
when the mail icon popped up, you clicked on it and '!' (banged) out of
the editor, at which point you were root, and could change the root
password.
> Failing that -- is there any way I can force the kernel to boot single-
> user, or will I need to make some install disks?
The diagnostic disk (IIRC, that one has to be a 8 sectors/track,
not a 10 S/T) can be used. You get a shell, mount the hard disk, and
edit the /etc/passwd file to null out the root password. (That was
before the shadow file became common.) Beware that unless the
development system was installed, all you will have is ed(1) (or was it
just plain e(1)?. Anyway, one of the terrible design ideas was to make
it the default editor when you click on a file -- and the man page for
everything comes with the development system -- which also gives you
vi(1)
Maybe you want to save the old root password, if you are curious
enough to run crack50 or john the ripper on it -- and any other
passwords.
I rather quickly compiled and installed jove (Jonathon's Own
Version of Emacs), as I dislike vi, and ed is just too klugy. It really
does not give you a clue what is happening (no useful prompt, even).
Picture what happens when Mr. Businessman clicks on a file with no other
editor installed, no prompting, and no documentation on how to use it.
(Not even a way to know that it is ed(1) and not some other editor, so
he could *maybe* look it up somewhere else. He is just trapped in the
editor, doing various things to the file as he tries to find letters
which will get him out of the editor. (And if he did have something
else installed, it would be something like WordMark Composer -- a word
processor, not a programming editor.)
It would be interesting to see what is actually installed in the
system -- and what survived the power glitches which flooded the system.
Note that once you have the system running, and have everything
explored, you really should do a fresh install (including low-level
format from the diagnostic disk) to clean up all the hard disk errors.
You should be able to dd the image of the diagnostic floppy to
an 8 S/T formatted floppy even as guest -- once you have a way to copy
it to the system from some other system.
IIRC, the menus enable copying from a MS/DOS formatted floppy to
the system disk, so you may not need kermit or whatever to get your
network cards and the floppy tape system) in /kernel, so I could boot to
image of the diagnostic disk. (Note that I make a practice of putting
all the special kernels like the diagnostic (named "s4test", and the
ones for testing one of them instead of the normal OS. (You can simply
put it in the root directory and boot to that, too.) I forget whether
the reboot command allowed me to specify the kernel to boot or not.
If you have the encryption disk set (they used to be forbidden
to export them from the US, which is why they were separate), and don't
have the development set, it is possible to get vi/ex from that. You
have to create a dummy file for ex/vi (link one to the other) before
running the encryption install, and it will replace the (supposedly
neutered vi/ex with the version which will encrypt files as it saves,
and decrypt as it reads them back in.) Since the encryption system is
not that good anyway, this is mostly a way to get vi/ex to work with.
(If you don't have the development set, you won't be able to compile
something like jove or emacs anyway. But hopefully, you do have the
development set.
Note that the encryption set should be the last thing to
install, because it does tricky things to decide what to install, based
on what it finds. And the test for the presence of "vi" was especially
tricky -- but it did not run a checksum on what called itself "vi". :-)
The following four lines at the top if the install script:
======================================================================
ENHED=`echo "\0166\0151"`
EDLINK1=`echo "\0145\0144\0151\0164"`
EDLINK2=`echo "\0145\0170"`
EDLINK3=`echo "\0166\0151\0145\0167"`
======================================================================
become:
vi
edit
ex
and
view
all alterate names for vi.
O.K. It tests for them in /usr/bin.
And it only works if the install is done in the /tmp directory,
*and* /tmp is not on a different partition from /usr/bin, since it does
it all with links, leaving the normal clean of /tmp during reboot to get
rid of the excess copy.
Interesting -- Solaris 10 "file" returns the following on "vi":
======================================================================
vi: iAPX 286 executable large model (COFF)
======================================================================
I guess that 68010 magic numbers are just too old. :-)
Good Luck,
Don.
--
Remove oil spill source from e-mail
Email: <
BPdnic...@d-and-d.com> | Voice (all times):
(703) 938-4564
(too) near Washington D.C. |
http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---