27 Mar
2005
27 Mar
'05
4:12 a.m.
Does anyone happen to know the organisation of a SunOS 4.x hard drive?
Looking at the disklabel under Linux, I get the following:
| Disk /dev/sdb (Sun disk label): 15 heads, 131 sectors, 1701
| cylinders Units = cylinders of 1965 * 512 bytes
|
| Device Flag Start End Blocks Id System
| /dev/sdb1 0 48 47160 0 Empty
| /dev/sdb2 48 152 102180 0 Empty
| /dev/sdb3 0 1701 1671232+ 0 Empty
| /dev/sdb4 152 264 110040 0 Empty
| /dev/sdb7 264 1701 1411852+ 0 Empty
(ignoring the 'empty' - think that must be a bug in Linux fdisk as I
know there's a valid OS on the disk)
Googling shows the first entry to be the root partition on such a drive,
second entry to be swap, third to be the whole disk entry, and the rest
to presumably be aux partitions...
However, obviously some space is taken up by the partition table itself,
so the first (root) partition can't start at block zero. What I'm trying
to find out is the offset that it does actually start at, so that I can
mount the root partition from Linux.
Hopefully someone knows, if not it's trial and error time... :-)
ta
Jules
27 Mar
27 Mar
5:14 a.m.
I crossposted this on the sun rescue list, somethere should be able to help.
Dan
5:52 a.m.
On Sun, 2005-03-27 at 14:14 +0100, Dan Williams wrote:
I crossposted this on the sun rescue list, somethere
should be able to help.
Thanks. The Sun board in question is the front-end for an early 1990's
DSP-based RAP 'supercomputer', so it'd be nice to try and get it running
again!
cheers
Jules
7:51 a.m.
On Sunday 27 March 2005 07:12, Jules Richardson wrote:
However, obviously some space is taken up by the
partition table
itself, so the first (root) partition can't start at block zero. What
I'm trying to find out is the offset that it does actually start at,
so that I can mount the root partition from Linux.
Actually, the root partition does start at sector 0. With a sun disk
label, it's always on sector 0, and usually overlaps with the first
partition. Thus, the filesystem is supposed to not occupy the first
sector of its partition, which is the same for how PCs work (the first
sector is usually called the 'boot sector' in PC land; in Sun land, the
partition table/disk label and 'boot sector' can overlap, as there is
no 'master' boot sector for the disk (ala the PC's MBR), thanks to the
intelligence of the Sun's boot prom).
Pat
--
Purdue University ITAP/RCS --- http://www.itap.purdue.edu/rcs/
The Computer Refuge --- http://computer-refuge.org
8:05 a.m.
Jules Richardson wrote:
Does anyone happen to know the organisation of a SunOS
4.x hard drive?
Looking at the disklabel under Linux, I get the following:
| Disk /dev/sdb (Sun disk label): 15 heads, 131 sectors, 1701
| cylinders Units = cylinders of 1965 * 512 bytes
|
| Device Flag Start End Blocks Id System
| /dev/sdb1 0 48 47160 0 Empty
| /dev/sdb2 48 152 102180 0 Empty
| /dev/sdb3 0 1701 1671232+ 0 Empty
| /dev/sdb4 152 264 110040 0 Empty
| /dev/sdb7 264 1701 1411852+ 0 Empty
(ignoring the 'empty' - think that must be a bug in Linux fdisk as I
know there's a valid OS on the disk)
The ID of 0 and the "Empty" System label mean that fdisk doesn't
recognize the partition type, or more likely in this case, the ID field
in the partition/slice table at all. It doesn't refer to whether
there's data or filesystem on the slice.
However, obviously some space is taken up by the
partition table itself,
so the first (root) partition can't start at block zero. What I'm trying
to find out is the offset that it does actually start at, so that I can
mount the root partition from Linux.
Given the output of fdisk, I'm going to guess that your Linux kernel
doesn't support the SunOS 4 filesystem type. I've got an email out to a
friend who just installed on a 3/60 yesterday, so mayhap he can shedsome
light on this. Meantime, see if your kernel has "sysv" filesystem
support. I have a glimmer of a memory that that's what you'll need. ;)
Doc
8:41 a.m.
On Sun, 2005-03-27 at 10:05 -0600, Doc Shipley wrote:
Given the output of fdisk, I'm going to guess
that your Linux kernel
doesn't support the SunOS 4 filesystem type. I've got an email out to a
friend who just installed on a 3/60 yesterday, so mayhap he can shedsome
light on this. Meantime, see if your kernel has "sysv" filesystem
support. I have a glimmer of a memory that that's what you'll need. ;)
Ahh, that's interesting. I expected it to be an ffs-derived format - in
other words using a type of 'ufs' under linux and supplied with a
"ufstype=sun" flag to the mount prog.
A quick test reveals that I do have sysv filesystem support compiled in,
but mount is no happier trying to mount the system as sysv :-(
(Incidentally I noticed that linux fdisk defaults to reporting the
blocks count in 1024-byte blocks, rather than the 512-byte blocks that
the disk itself is using)
From what Patrick says, it should just work assuming I
have the
filesystem type right; the root partition is the first on the disk and
incorporates the partition table, so has an offset of 0. Maybe support
under Linux is a little broken (I know already that ufs/sun makes
assumptions about the endian-ness of the filesystem in some places)
Hmmm...
cheers
Jules
8:57 a.m.
Jules Richardson wrote:
It looks like the endian issue may be your problem. Don't have
another SPARC to hang the disk from?
Doc
On Sun, 2005-03-27 at 10:05 -0600, Doc Shipley wrote:
Actually, that's my bad. A little googling reveals that v4.x is
indeed ufs.
Given the output of fdisk, I'm going to
guess that your Linux kernel
doesn't support the SunOS 4 filesystem type. I've got an email out to a
friend who just installed on a 3/60 yesterday, so mayhap he can shedsome
light on this. Meantime, see if your kernel has "sysv" filesystem
support. I have a glimmer of a memory that that's what you'll need. ;)
Ahh, that's interesting. I expected it to be an ffs-derived format - in
other words using a type of 'ufs' under linux and supplied with a
"ufstype=sun" flag to the mount prog. (Incidentally I noticed that linux fdisk defaults to
reporting the
blocks count in 1024-byte blocks, rather than the 512-byte blocks that
the disk itself is using)
That confuses the students in my Linux classes as well, since fdisk
reports in 1024-byte blocks even on ext partitions that have
4096-byte-block filesystems. :)
From what
Patrick says, it should just work assuming I have the
filesystem type right; the
root partition is the first on the disk and
incorporates the partition table, so has an offset of 0. Maybe support
under Linux is a little broken (I know already that ufs/sun makes
assumptions about the endian-ness of the filesystem in some places)
Hmmm...
1:14 p.m.
On Sun, 2005-03-27 at 10:57 -0600, Doc Shipley wrote:
Jules Richardson wrote:
Sure, at the filesystem level disk blocks might be combined - I'm just
surprised that fdisk doesn't report the block counts using the block
size of whatever media it's dealing with. It obviously knows that it's
dealing with a disk that uses 512-byte blocks, but it still shows the
block counts as though they were 1024 byte blocks. Just struck me as
odd!
I'll be back at the museum tomorrow where I've left the DSP
supercomputer system that this hard disk is part of, so hopefully I'll
have a chance to do some more work on it and try to fix its console
port. Darn thing's too big to bring home with me! :-)
cheers
Jules
(Incidentally I noticed that linux fdisk defaults
to reporting the
blocks count in 1024-byte blocks, rather than the 512-byte blocks that
the disk itself is using)
That confuses the students in my Linux classes as well, since fdisk
reports in 1024-byte blocks even on ext partitions that have
4096-byte-block filesystems. :)
4:39 p.m.
Jules Richardson wrote:
On Sun, 2005-03-27 at 10:57 -0600, Doc Shipley wrote:
I'm allowed to say this, as a long-time Linux supporter and bigot.
A LOT of Linux tools are "dumbed-down" to be accessible to people
like I was when I first used it. I had a little DOS experience, no Unix
or under-the-covers network or security knowledge at all, and the
user-friendly mods and shortcuts made it much easier and much less foreign.
Think about root's home directory in most Linux distributions - /root
exists because noobs like me were running the system day-to-day as root,
and mucking up the real root directory.
Jules Richardson wrote:
Sure, at the filesystem level disk blocks might be combined - I'm just
surprised that fdisk doesn't report the block counts using the block
size of whatever media it's dealing with. It obviously knows that it's
dealing with a disk that uses 512-byte blocks, but it still shows the
block counts as though they were 1024 byte blocks. Just struck me as
odd! (Incidentally I noticed that linux fdisk defaults
to reporting the
blocks count in 1024-byte blocks, rather than the 512-byte blocks that
the disk itself is using)
That confuses the students in my Linux classes as well, since fdisk
reports in 1024-byte blocks even on ext partitions that have
4096-byte-block filesystems. :) I'll be back at the museum tomorrow where I've
left the DSP
supercomputer system that this hard disk is part of, so hopefully I'll
have a chance to do some more work on it and try to fix its console
port. Darn thing's too big to bring home with me! :-)
I'd think you'd find a way.... ;)
Doc
11:11 a.m.
Maybe support under Linux is a little broken (I know
already that
ufs/sun makes assumptions about the endian-ness of the filesystem in
some places)
Yes, if the filesystem really is a SunOS 4.* filesystem, it will be
big-endian. Your Linux FFS support has to be prepared for big-endian
data structures on disk, which if you're on a little-endian
architecture like i386 it may not be.
That presumably-root partition is only some 46 megabytes. If you can
get a dd image of it to me (offlist!), I can poke at it; I've written a
bunch of tools for working with such things.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
3:01 p.m.
Yes, if the
filesystem really is a SunOS 4.* filesystem, it will be
big-endian.
Even a SunOS 4.* filesystem written by a Sun 386i?
3:14 p.m.
On Sun, 2005-03-27 at 18:01 -0500, der Mouse wrote:
Woo, I forgot about the roadrunner. A 386i-written filesystem will
quite likely be little-endian.
Linux certainly treats the two as seperate - with a 'sun' UFS type for
normal machines and a 'sunx86' type for the 386i, so I suspect you're
right there.
cheers
J.
Yes, if the filesystem really is a SunOS 4.*
filesystem, it will be
big-endian.
Even a SunOS 4.* filesystem written by a Sun 386i? 
11:58 a.m.
On Sun, 27 Mar 2005 14:11:14 -0500 (EST)
der Mouse <mouse at rodents.montreal.qc.ca> wrote:
I have a question about this that might be answerable by somebody here.
Awhile back I had a drive from an RS/6000 system and was attempting to
figure it out and get into it.
I decided that I would need to use another big-endian system to copy the
drive onto an image file to poke around in it. So I mounted the (SCSI)
drive on a Sparc box here (everybody should have a lunchbox sparc around
for such purposes) running NetBSD and used the dd command to make an
image.
Would it have made a difference if I'd used a little-endian system to
image the drive? My impression has been that it would have, but it's
not something I know a lot about (I'm dyslexic enough in real life
without extending it to hard drives and filesystem endianess)
-Scott
Maybe support
under Linux is a little broken (I know already that
ufs/sun makes assumptions about the endian-ness of the filesystem in
some places)
Yes, if the filesystem really is a SunOS 4.* filesystem, it will be
big-endian. Your Linux FFS support has to be prepared for big-endian
data structures on disk, which if you're on a little-endian
architecture like i386 it may not be.
1:04 p.m.
On Sun, 2005-03-27 at 14:58 -0500, Scott Stevens wrote:
On Sun, 27 Mar 2005 14:11:14 -0500 (EST)
der Mouse <mouse at rodents.montreal.qc.ca> wrote:
I have a question about this that might be answerable by somebody here.
Awhile back I had a drive from an RS/6000 system and was attempting to
figure it out and get into it.
I decided that I would need to use another big-endian system to copy the
drive onto an image file to poke around in it. So I mounted the (SCSI)
drive on a Sparc box here (everybody should have a lunchbox sparc around
for such purposes) running NetBSD and used the dd command to make an
image.
Would it have made a difference if I'd used a little-endian system to
image the drive?
Generally, no. 'dd' just copies raw bytes as it sees them; it knows
nothing of any structure on top of the raw data (such as a filesystem
layout). It's only the code that you may then use to analyse the image
which needs to worry about byte order where necessary.
However, there do seem to be caveats. When I pulled raw data off my NCR
Tower's drive I had to swap bytes before anything made sense, but I
think that's an exception to the rule rather than the norm.
FWIW, 'dd' supports the 'swab' argument to swap adjacent pairs of bytes.
Why it's called swab rather than swap, I don't know - must have been
done that way for a reason...
cheers
Jules
Maybe
support under Linux is a little broken (I know already that
ufs/sun makes assumptions about the endian-ness of the filesystem in
some places)
Yes, if the filesystem really is a SunOS 4.* filesystem, it will be
big-endian. Your Linux FFS support has to be prepared for big-endian
data structures on disk, which if you're on a little-endian
architecture like i386 it may not be.
1:09 p.m.
>>>> "Jules" == Jules Richardson
<julesrichardsonuk at yahoo.co.uk> writes:
Jules> FWIW, 'dd' supports the 'swab' argument to swap adjacent pairs
Jules> of bytes. Why it's called swab rather than swap, I don't know
Jules> - must have been done that way for a reason...
Because that's the opcode symbol for the PDP11 instruction that SWAps
Bytes, I would think.
paul
12:56 p.m.
On Sun, 2005-03-27 at 14:11 -0500, der Mouse wrote:
Actually I used the Sun UFS support under Linux to mount one of the
partitions from my Tek XD88 (once I'd manage to reverse-engineer the
partition format) - that's despite the 88k CPU being big endian (I
assume!) whilst my desktop PC will be little endian. The only thing that
screwed up under Linux were the file timestamps - everything else seemed
to be OK. I assume that the spec for FFS must dictate byte-order in most
places where it's necessary...
Maybe support
under Linux is a little broken (I know already that
ufs/sun makes assumptions about the endian-ness of the filesystem in
some places)
Yes, if the filesystem really is a SunOS 4.* filesystem, it will be
big-endian. Your Linux FFS support has to be prepared for big-endian
data structures on disk, which if you're on a little-endian
architecture like i386 it may not be. That presumably-root partition is only some 46
megabytes. If you can
get a dd image of it to me (offlist!), I can poke at it; I've written a
bunch of tools for working with such things.
I've had a couple of offers along similar lines - I really need to check
there's no sensitive data on the machine first, though :-( *If* I can
get the 4/330 board with the broken console port itself running, then at
least I can check the data and then upload the root partition image so
people can mess with it.
(FWIW Linux doesn't support the various UFS-type systems in anything but
read-only mode; my main aim was to get a raw image of the Sun's drive
backed up - which I've done - I'm just trying to mount it out of
curiousity to see if it can be done!)
cheers
Jules
3:14 p.m.
I assume that the spec for FFS must dictate byte-order
in most places
where it's necessary...
I don't think it does. I think all, and certainly within epsilon of
all, multi-byte quantities are stored in host-native byte order.
(Assuming, of course, that you haven't mounted it with opposite
endianness, on systems that can. And, of course, it's possible that
someone has built an implementation that *always* swaps, eg as I
spectulated Sun may have done for the 386i.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
2:15 p.m.
On Sun, 2005-03-27 at 14:11 -0500, der Mouse wrote:
That presumably-root partition is only some 46
megabytes. If you can
get a dd image of it to me (offlist!), I can poke at it
I've got further. Linux Sun UFS support is a little braindead; it
doesn't know to assume that the first 16 blocks of the filesystem are
special and so skip over them - it expects meaninful data right from
block zero. Hacking the first 16 blocks from my test filesystem image
has got around that problem...
... now mount's complaining because the filesystem is marked as
unchecked (which is true - last shutdown was unclean due to us having a
bust console port on the Sun). Unfortunately there's no option to
override and just try mounting anyway. Presumably there's a flag
somewhere in the superblock that I could change to indicate that the
filesystem's OK, but finding it might be tricky.
I need to fix that console port, get a running machine, then take an
image of the checked disk I think!
cheers
J.
9:45 a.m.
On Sun, 27 Mar 2005 12:12:27 +0000
Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
Does anyone happen to know the organisation of a SunOS
4.x hard drive?
[...]
However, obviously some space is taken up by the
partition table
itself, so the first (root) partition can't start at block zero. What
I'm trying to find out is the offset that it does actually start at,
so that I can mount the root partition from Linux.
SunOS 4 is BSD and uses the BSD
FFS. This in turn doesn't use the first
8 kB (16 blocks) in a slice. The first 8 kB (in slice a) are reserved
for the disklabel(5) and first stage boot code. Therefore slice a starts
at sector 0.
You may try to use NetBSD to mount those disks. In the days of NetBSD
1.4 I mounted a SunOS 4 drive from NetBSD/sparc without any trouble.
NetBSD uses the same disklabel(5) layout as Sun and the file system is
AFAIK just the same. (Nevertheless I recommend to mount read only or to
make a image backup before mounting read / write.) It should be easy to
boot your sun3 or sun4 machine diskless with NetBSD from a Linux box.
If you use a litle endian machine with NetBSD to analyze the disk read
options(4) about FFS_EI.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
2:58 p.m.
You may try to use NetBSD to mount those disks. In
the days of
NetBSD 1.4 I mounted a SunOS 4 drive from NetBSD/sparc without any
trouble. NetBSD uses the same disklabel(5) layout as Sun and the
file system is AFAIK just the same.
In the 1.4 days these were within epsilon of true. They are less so
now (NetBSD now keeps a BSD label on the disk, with the Sun label kept
around just for PROM bootcode compatability, and NetBSD ffs has evolved
significantly beyond the SunOS 4.x filesystem), but I think that even
NetBSD-current can grok Sun-labeled disks and UFS filesystems.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
10:29 a.m.
Does anyone happen to know the organisation of a SunOS
4.x hard
drive?
Well, I've worked with SunOS 4 quite a bit, in a previous job.
Looking at the disklabel under Linux, I get the
following:
| Disk /dev/sdb (Sun disk label): 15 heads, 131
sectors, 1701
| cylinders Units = cylinders of 1965 * 512 bytes
|
| Device Flag Start End Blocks Id System
| /dev/sdb1 0 48 47160 0 Empty
| /dev/sdb2 48 152 102180 0 Empty
| /dev/sdb3 0 1701 1671232+ 0 Empty
| /dev/sdb4 152 264 110040 0 Empty
| /dev/sdb7 264 1701 1411852+ 0 Empty
(ignoring the 'empty' - think that must be a
bug in Linux fdisk as I
know there's a valid OS on the disk)
Note that Sun disklabels (certainly Sun disklabels of that era) do not
have any partition typing.
Googling shows the first entry to be the root
partition on such a
drive, second entry to be swap, third to be the whole disk entry, and
the rest to presumably be aux partitions...
Normally, yes. I don't think root _had_ to be the a partition, or swap
b, but those certainly were the normal way. c being the whole-disk
partition was, I think, not optional.
However, obviously some space is taken up by the
partition table
itself, so the first (root) partition can't start at block zero.
Not true, actually. The partition table occupies sector 0 of the drive
(actually, only part of the first sector, but the whole first sector is
given over to it). Any bootable partition has bootcode in sectors 1
through 15. SunOS 4's filesystem, like the Berkeley FFS that it
basically is, avoid doing anything with the first 16 sectors on its
partition specifically to make room for bootcode (and, later, partition
tables - the 16-sector carveout dates back to real BSD, farther back
than on-disk partition tables). Yes, this means wasting 8K of space on
partitions that are neither bootable nor first-on-disk, but that was
apparently considered acceptable.
Furthermore, Sun disklabels, while they store partition sizes as sector
counts, store partition start points as cylinder counts, so you can't
easily just skip the first 16 sectors - you'd have to skip the whole
first cylinder. (You could, today, lie in the sector and track counts
to get small cylinders, but back then, if you did that your disk likely
wouldn't work right - some disks were addressed by <cyl,head,sect>
triples rather than linear block numbers.)
What I'm trying to find out is the offset that it
does actually start
at, so that I can mount the root partition from Linux.
As in the disk label. If your Linux system can't mount it, it must not
support that filesystem type.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
12:01 p.m.
It was thus said that the Great der Mouse once stated:
I always wondered why that was (and I think NetBSD wants it the same
way---I seem to recall setting up the partitions like that on the HP/Apollos
I have (but that are currently in storage at the moment)). It's such an odd
arrangement (to me).
-spc (Can't imagine *why* partition C needs to be the whole disk ... )
Googling shows the first entry to be the root
partition on such a
drive, second entry to be swap, third to be the whole disk entry, and
the rest to presumably be aux partitions...
Normally, yes. I don't think root _had_ to be the a partition, or swap
b, but those certainly were the normal way. c being the whole-disk
partition was, I think, not optional. 
12:29 p.m.
Sean 'Captain Napalm' Conner wrote:
-spc (Can't imagine *why* partition C needs to be
the whole disk ... )
It needs to 'C' the whole disk. All this talk of disks and MSDOS reminds
me of when
I was looking at primeval C online a few days back and the UNIX
directory entry
was something like char name[14], short unsigned int inode. While I
don't know how
big a unix disk block is that is still about the range of DOS's limit of
32 MEG/ disk.
It is only once you got windows DID C take up the whole disk and small
computing
became BLOATWARE. The same thing in hindsight seems to be what happened
with the VAX, and the 11 dropped.
It does seem odd that DEC had the better product with the PDP-11 and
UNIX 10 years
before PC's came out yet missed the Personal Computer market totally.
Ben alias woodelf.
1:10 p.m.
On Sun, 2005-03-27 at 15:01 -0500, Sean 'Captain Napalm' Conner wrote:
I think it's done to enable things like whole disk backups, where the
size of the usable data area on the disk might not always be the entire
addressable range of the drive (spare sectors, things optimised for
cylinder boundaries resulting in some wastage etc.).
Plus of course ST412 type drives don't have any notion of any "get drive
geometry" command like SCSI does.
Most machines of the era seem to support / require a "whole disk" entry
(from memory it's entry #6 rather than #3 on my Tek)
Why it's the third entry on Suns I don't know. Maybe it's something odd
like OS bootable tapes support a condensed table with less entries than
a disk or something...
Normally, yes.
I don't think root _had_ to be the a partition, or swap
b, but those certainly were the normal way. c being the whole-disk
partition was, I think, not optional.
I always wondered why that was (and I think NetBSD wants it the same
way---I seem to recall setting up the partitions like that on the HP/Apollos
I have (but that are currently in storage at the moment)). It's such an odd
arrangement (to me).
3:03 p.m.
Normally, yes.
I don't think root _had_ to be the a partition, or
swap b, but those certainly were the normal way. c being the
whole-disk partition was, I think, not optional.
I always wondered why that was
(and I think NetBSD wants it the same
way---I seem to recall setting up the partitions like that on the
HP/Apollos I have (but that are currently in storage at the moment)). It's such an odd arrangement (to me).
The only odd thing, to me, is why it's the third of eight partitions
that's the whole-disk partition.
-spc (Can't imagine *why* partition C needs to be
the whole disk ... )
Compatability, that's about it. You could define RAW_PART to 7 in
NetBSD and build yourself a system on which partition h is the whole
disk and partition c is a perfectly vanilla partition. (You could set
RAW_PART to 0 and get partition a as the whole-disk partition, even,
but given the way the ROM bootcode defaults to using the a partition
from the disklabel, that could be, um, confusing.)
Having RAW_PART at all is a rather ugly kludge. The sane way to do it
is to have separate devices for the whole disk and for the partitions,
somewhat akin to the wedges that have been talked about (in NetBSD - I
think one of the other BSDs already has something of the sort). But
back when partitioning was first invented, I doubt anyone thought much
about that, and now we're stuck with legacies.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
7209
days inactive
7210
days old
25 comments
11 participants
participants (11)
-
bfranchuk＠jetnet.ab.ca -
chenmel＠earthlink.net -
doc＠mdrconsult.com -
fmc＠reanimators.org -
jkunz＠unixag-kl.fh-kl.de -
julesrichardsonuk＠yahoo.co.uk -
mouse＠Rodents.Montreal.QC.CA -
pat＠computer-refuge.org -
pkoning＠equallogic.com -
spc＠conman.org -
williams.dan＠gmail.com