17 Jan
2009
17 Jan
'09
12:35 p.m.
This is a short story about getting data off an old xenix pc. delete
now if that is not interesting :-)
A while ago friend brought over an old pc which was dead. It's a 386
Compaq, very old. It had been running xenix and it was never turned off
but one day the power failed. When the power came back it would not
boot - the clock battery was long since dead and had lost it's disk
setup.
Inside is a 386 with about 4mb of ram and a Compaq ESDI controller. And
a dead Dallas clock chip.
I dremel tooled the Dallas clock chip and soldered in a new battery
pack. I got a floppy disk image to reset the bios from someone here
(thanks!) But despite many tries it would not boot. The diag program
would not let me set the disk parameters exactly the way they needed to
be set. most frustrating.
So, I yanked the controller (ESDI), changed the jumpers and put
it in another old pc which had linux on it. I booted linux and
gave it the disk geometry via the command line ("hdc=1224,15,34")
Once in linux I made an image of the disk using dd. It turns out that
the "conv=" option is very important. I used
"conv=noerrors,notrunc,sync".
Originally I use "conv=noerrors" and the resulting image was bad because
the disk had errors.
dd conv=noerrors,notrunc,sync if=/dev/hdc of=disk.img
I then put the resulting disk image on another linux box and wrote a
tiny C program to search for valid sysv super blocks. It found 3. I
then used "dd" to copy part of the image, with an offset (the start of
the first superblock), to a new file.
dd if=disk.img of=d4 bs=512 skip=2040
With that I had a valid sysv file system in a single file. I then
mounted the new file using the loopback option:
mount d4 /mnt -t sysv -o loop
and viola! I could see all the files and could make a tar file of
the root directory.
Flush with success (don't you just love it when things actually work? :-)
I decided to try and boot it. I used a recent copy of qemu and told
it the geometry of the original disk
qemu -hdachs 1000,15,34 -boot c -hda disk.img
Much to my shock, it booted xenix, cleaned the file system and gave me a
login prompt.
Now I just have to clean up the mess in my office :-) Man that thing
had a lot of dust and dirt in it.
-brad
17 Jan
17 Jan
3:54 p.m.
I then put the resulting disk image on another linux
box and wrote a
tiny C program to search for valid sysv super blocks.
Mind posting the source?
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- BOND THEME NOW PLAYING: "Die Another Day" ----------------------------------
4:13 p.m.
Cameron Kaiser wrote:
no problem. it was just a quick hack.
--- cut here ---
#include <stdio.h>
#include <fcntl.h>
#define __packed2__ __attribute__ ((packed, aligned(2)))
typedef unsigned short u16;
typedef unsigned int u32;
typedef short s16;
typedef int s32;
typedef u16 sysv_ino_t;
typedef u32 sysv_zone_t;
/* Xenix super-block data on disk */
#define XENIX_NICINOD 100 /* number of inode cache entries */
#define XENIX_NICFREE 100 /* number of free block list chunk entries */
struct xenix_super_block {
u16 s_isize; /* index of first data zone */
u32 s_fsize __packed2__; /* total number of zones of this fs */
/* the start of the free block list: */
u16 s_nfree; /* number of free blocks in s_free, <= XENIX_NICFREE */
u32 s_free[XENIX_NICFREE]; /* first free block list chunk */
/* the cache of free inodes: */
u16 s_ninode; /* number of free inodes in s_inode, <= XENIX_NICINOD */
sysv_ino_t s_inode[XENIX_NICINOD]; /* some free inodes */
/* locks, not used by Linux: */
char s_flock; /* lock during free block list manipulation */
char s_ilock; /* lock during inode cache manipulation */
char s_fmod; /* super-block modified flag */
char s_ronly; /* flag whether fs is mounted read-only */
u32 s_time __packed2__; /* time of last super block update */
u32 s_tfree __packed2__; /* total number of free zones */
u16 s_tinode; /* total number of free inodes */
s16 s_dinfo[4]; /* device information ?? */
char s_fname[6]; /* file system volume name */
char s_fpack[6]; /* file system pack name */
char s_clean; /* set to 0x46 when filesystem is properly unmounted */
char s_fill[371];
s32 s_magic; /* version of file system */
s32 s_type; /* type of file system: 1 for 512 byte blocks
2 for 1024 byte blocks
3 for 2048 byte blocks */
};
char buffer[4096];
main()
{
int fd, ret;
struct xenix_super_block *sb;
int offset;
fd = open("d1", O_RDONLY);
sb = (struct xenix_super_block *)buffer;
printf("size %d\n", sizeof(struct xenix_super_block));
//printf("offset %d\n", ((char *)&sb->s_magic) - buffer);
offset = 0;
while (1) {
ret = read(fd, buffer, 1024);
if (ret != 1024)
break;
if (sb->s_magic == 0x002b5544 &&
(sb->s_type >= 1 && sb->s_type <= 3))
{
printf("offset %d 0x%x\n", offset, offset);
printf("block %d\n", (offset-1024) / 512);
printf("s_magic %08x\n", sb->s_magic);
printf("s_type %08x\n", sb->s_type);
printf("s_nfree %04x\n", sb->s_nfree);
}
offset += 1024;
}
}
I then put the
resulting disk image on another linux box and wrote a
tiny C program to search for valid sysv super blocks.
Mind posting the source? 
17 Jan
17 Jan
8:01 p.m.
On Sat, 17 Jan 2009, Brad Parker wrote:
Inside is a 386 with about 4mb of ram and a Compaq
ESDI controller. And
a dead Dallas clock chip.
I dremel tooled the Dallas clock chip and soldered in a new battery
pack. I got a floppy disk image to reset the bios from someone here
(thanks!) But despite many tries it would not boot. The diag program
would not let me set the disk parameters exactly the way they needed to
be set. most frustrating.
Well, ESDI controller are so-called intelligent controllers. You can't
(and must not) set the drive parameters in the BIOS. Instead (at least
with the WD or Adaptec ESDI controllers) you have to select drive type 1.
The controller knows the drive parameters as they are read from the drive.
And the controller BIOS doesn't care about the BIOS drive geometry, it
used the values from the drive.
What exactly is the problem with booting? Any special error codes?
Don't forget to disable the onboard hard disk interface, if available. If
the board has e.g. an onboard IDE interface, a BIOS reset would most
probably enable it, and the resources would collide with those of the ESDI
controller.
I then put the resulting disk image on another linux
box and wrote a
tiny C program to search for valid sysv super blocks. It found 3. I
then used "dd" to copy part of the image, with an offset (the start of
the first superblock), to a new file.
Or you could just write the disk image back e.g. to an IDE disk and put
that into the old PC.
and viola! I could see all the files and could make a
tar file of
^^^^^
That's a music instrument, I think you meant voil? ;-)
Christian
18 Jan
18 Jan
7:40 p.m.
Christian Corti wrote:
Well, ESDI controller are so-called intelligent controllers. You can't
I misspoke. It is an rll disk. The bios (and linux) need to know the
CHS. For some reason both default to 36 sectors per track but it
was formatted with only 34.
> and viola! I could see all the files and could
make a tar file of
that was a joke.
-brad
19 Jan
19 Jan
5:25 p.m.
Brad Parker wrote:
Flush with success (don't you just love it when
things actually work? :-)
I decided to try and boot it. I used a recent copy of qemu and told
it the geometry of the original disk
Congrats :) It's nice when hackery like that works.
Once in linux I made an image of the disk using dd.
It turns out that
the "conv=" option is very important. I used
"conv=noerrors,notrunc,sync".
Originally I use "conv=noerrors" and the resulting image was bad because
the disk had errors.
Yep. Note that some drives benefit from subsequent read attempts when they go
bad - I've hacked together a shell script before to read a single block at a
time and attempt x number of retries for bad blocks, which worked pretty well.
I always intended to rewrite that script as a more useful C program, but
haven't yet got the tuits together...
I then put the resulting disk image on another linux
box and wrote a
tiny C program to search for valid sysv super blocks.
That's a good idea. For my Tek, I managed to reverse-engineer the partition
table (took a while), but your approach is probably better, given that the fs
shouldn't care if you end up with extra data (from the 'next' filesystem)
tacked on the end of the image.
cheers
Jules
8:43 p.m.
Jules Richardson <jules.richardson99 at gmail.com> writes:
I always intended to rewrite that script as a more
useful C program,
but haven't yet got the tuits together...
Something like this?
http://offog.org/darcs/misccode/pcat.c
I wrote it for reading data from damaged CD-ROMs, but it sounds like it
does the same job as your script. It could really do with some options,
though...
--
Adam Sampson <ats at offog.org> <http://offog.org/>
9:21 p.m.
Adam Sampson wrote:
Jules Richardson <jules.richardson99 at
gmail.com> writes:
Yep :)
I always intended to rewrite that script as a
more useful C program,
but haven't yet got the tuits together...
Something like this?
http://offog.org/darcs/misccode/pcat.c It could really do with some options, though...
I think that's why I never quite got those tuits together... my script was a
quick hack that I could edit to tweak params, rather than something with full
CLI-parsing, help etc.
I suppose there's a lot could be done with logging and features like changing
the 'pad' byte, track zeroing/re-seeking upon bad reads, optionally swapping
byte pairs etc.
cheers
Jules
5829
days inactive
5831
days old
9 comments
6 participants
participants (6)
-
ats＠offog.org -
brad＠heeltoe.com -
cc＠informatik.uni-stuttgart.de -
doc＠mdrconsult.com -
jules.richardson99＠gmail.com -
spectre＠floodgap.com