Disk images, virtual disks etc
Sum1
like WinHex read the physical disk to display the ODS signatures,
layout etc.
Is there some way that I can make a container disk look the same? When
I tried to look at the container disk from PersonalAlpha and FreeAXP
using WinHex, they didn't look the same as reading the physical disk in
WinHex.
Cheers
bart...@gmail.com
It is not clear to me what you might achieve by using WinHex to read a
diskimage.
You may find LDDRIVER (http://www.digiater.nl/downloads/
lddriver_v95.zip) useful to have a look at the contents of the
containers of PA and FreeAXP.
HTH,
Bart Zorn
Sum1
The requirement is to view the disk structure of an ODS-2 and ODS-5
disk from a non-VMS environment, in this case, Windows, Linux & OSX.
So, I can attach an EIDE drive from, say, a DS10L to a USB-based reader
and plug it into a Windows machine running WinHex, have3 WinHex read
the ohysical disk rather than the disk presented to Windows via the USB
interface, and then examing the contents of the disk sectors directly.
However, I also want to examine the sector contents of disks created
from FreeAXP and PersonalAlpha (and others), but they don't apper the
same as physical sector-evel reads. Hence, I am lookinf for some
Windows/Linux/OSX based tool that will allow me to see sector-based
structures in these container files.
Cheers
JF Mezei
> However, I also want to examine the sector contents of disks created
> from FreeAXP and PersonalAlpha (and others), but they don't apper the
> same as physical sector-evel reads. Hence, I am lookinf for some
> Windows/Linux/OSX based tool that will allow me to see sector-based
> structures in these container files.
A container file, if read at very low level, might give you the local
operating system's own headers prior to reaching the actual data
contents. (with the data contents being the VMS disk image).
The LDdriver on VMS allows you to create a VMS container file. You then
use BACKUP/PHYSICAL or BACKUP/IMAGE to populate the container file. You
could then FTP (binary mode) the container file to your windows box and
use your utility to browse the contents and compare it against that of
an emulator's container file.
Sum1
Hi JF
I was sort of expecting that behaviour in the PA and FreeAXP container
files, but it isn't quite the same. I guess that something in the
emulators gets at the OpenVMS disk driver and presents the information
to it as if it *were* a real disk.
Interestingly, I was looking at the OpenVMS Guide to File Applications,
which hasn't been updated since 2002 (at least that is the latest
version on HP's site) and it gives an overview of the ODS disk
structure, but not what I want. I am trying to get a sector-level
description of what is going on, much like one can get for MBR/GPT
disks. And then I want to look at that through WIndows/Linux/OSX.
So, I guess a good starting point could be a graphical description of
the ODS structure at a sector level, a la MBR etc.
Cheers
JF Mezei
to my mac and used by SIMH (ODS2 only).
So SIMH's doesn't need extra headers in the container file to define the
device. But you do need to provide a description in the SIMH config to
map the type of drive to the file.
Does the utility you use on widnows really just give you raw contents of
the data file, or does it also give you file headers that are part of
the windows file system ? (remember that to windows, the container file
is just a data file with a windows file header, windows file name etc.)
Sum1
WinHex on Windows will allow me to read a RAW disk - so I can examine
the MBR and contents, the partition table - anything at all on the disk
as raw blocks. I can even read into the protected area to see what is
going on.
I can't look at the container files as a RAW disk as they are Windows
files, and if I look "into" them, I don't see what I would if I was
looking at a real
RAW disk. So, I am looking for a way to look into them physically, but
from Windows/Linux/OSX.
Looking at the OpenVMS System Manager's Manual Vol 2, Appendix A, it
gives a nice description of how Files-11/ODS-5 is layed out, but not at
the level I want. For example, MBR disks have a physical layout with a
disk sgnature at a particular offset, partition descriptions at
particular offsets etc.
I am looking for the same level of detail for Files-11/ODS-5. Foe
example, in the manual under Boot Block, it says "Block 0 on a system
disk is the boot block. It contains the location and size of the
primary bootstrap image, which is used to boot the system. Certain
processors, in order to boot, must read this boot block to obtain the
location of the bootstrap image. For more details, see the Process
Control chapter in the HP OpenVMS System Manager’s Manual, Volume 1:
Essentials."
Great, I can't find that reference in Volume 1 anywhere!! So I guess
that I am trying to build a graphical layout of the boot block, the
home block and what is in them and at what offset.
Cheers
R.A.Omond
The book you really want is this:
http://www.amazon.com/VMS-File-System-Internals-VAX/dp/1555580564
"VMS File System Internals" by Kirby McCoy.
Unfortunately I've loaned my copy to someone many years ago, and I don't
remember who that was :-(
VAXman-
Winhex? Is that an evil spell cast by the followers of that Redmond cult?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.
Wilm Boerhout
>
> Great, I can't find that reference in Volume 1 anywhere!! So I guess
> that I am trying to build a graphical layout of the boot block, the home
> block and what is in them and at what offset.
>
> Cheers
>
MBR for example is a logical concept that is only meaningful to some
disk structures and corresponding operating systems.
Inside a (SIMH, LD, CHARON, Personal Alpha) container I would not expect
to find DOS/NTFS MBR structures, because these container files are
generally only looked at (mounted) by VMS. If you $Mount a VMS disk
/Foreign, it's just a sequence of bytes anyway.
So, what do *you* expect to find *inside* a container that has a ODS-2
structure imposed on it by VMS? Right: ODS-2/5 structures.
/Wilm
Sum1
>> in the HP OpenVMS System Manager’s Manual, Volume 1: Essentials."
>>
>> Great, I can't find that reference in Volume 1 anywhere!! So I guess
>> that I am trying to build a graphical layout of the boot block, the home
>> block and what is in them and at what offset.
>>
>> Cheers
>>
> Remember however that a physical disk *is* just a sequence of bytes.
> The MBR for example is a logical concept that is only meaningful to
> some disk structures and corresponding operating systems.
>
> Inside a (SIMH, LD, CHARON, Personal Alpha) container I would not
> expect to find DOS/NTFS MBR structures, because these container files
> are generally only looked at (mounted) by VMS. If you $Mount a VMS disk
> /Foreign, it's just a sequence of bytes anyway.
>
> So, what do *you* expect to find *inside* a container that has a ODS-2
> structure imposed on it by VMS? Right: ODS-2/5 structures.
>
> /Wilm
Agreed, and that is what I would like to look at in hex, and
understand. What is the order, what does it mean. Starting with the
contents of the bootblock would be good! At some point I can then dive
into the $RMSDEF macros and work my way through the other structures at
leisure. But I want to understand the detail of loading the bootblock,
what is in it and where and what other structures exist that
Files-11/ODS-5/RMS look at.
Cheers
Graham Burley
>Agreed, and that is what I would like to look at in hex, and
>understand. What is the order, what does it mean. Starting with the
>contents of the bootblock would be good! At some point I can then dive
>into the $RMSDEF macros and work my way through the other structures at
>leisure. But I want to understand the detail of loading the bootblock,
>what is in it and where and what other structures exist that
>Files-11/ODS-5/RMS look at.
Follow the Hoff at:
OpenVMS Tips: ODS-2 And ODS-5 Disk Structures
http://labs.hoffmanlabs.com/node/209
Including the Freeware links to ods2.doc (text) that describes ODS-2 at:
http://decuslib.com/freeware/freewarev50/ods2/
Sum1
I had previously read through Hoff's tips, but they didn't give me what
I needed - perhaps I was just not understanding it. However, the
document by Andrew Goldstein contains almost all the information that I
need. The missing bit is the boot block structure.
So, to simplify (and please point out if this is wrong), on an Alpha
for example....
1. Machine is booted
2. SRM reads configuration and knows what type of disks are attached and where
3. Reads LBN0 (how does it know which one that is?)
4 LBN is the bootblock, SRM loads into memory and executes it.
Bootblock is also a component of the INDEXF.SYS, placed there along
with the other mandatory files described in Goldstein's document.
Block 1 of INDEXF.SYS is the bootblock, next is the homeblock
(structure described in Goldstein's book), followed by the rest in
logical order.
5. Control transferred to APB.EXE which then finishes the boot sequence
according to the assorted parameter files/startup.com etc.
So, all I need is the structure of the bootblock which is, I guess,
APB.exe I suppose that means it is a 512 byte executable in a format
readable and executable by the SRM?
Cheers
hb
> I can't look at the container files as a RAW disk as they are Windows
> files, and if I look "into" them, I don't see what I would if I was
> looking at a real
> RAW disk. So, I am looking for a way to look into them physically, but
> from Windows/Linux/OSX.
On Linux you can set up a loop device for a file. That is, a block
device pointing to your container file. The loop device then can be
used as a disk device. Given the file system on the container file,
you can then mount that device in a Linux directory. There is an ODS5
file system for some Linux distros available just doing that. It can
read ODS2 disks as well, it is readonly. But from your postings I
think you just want to look with a tool at the ODS structure of the
container file or the block device. I don't know of any non-VMS based
one. But given the available tools/file systems to read VMS disks on
Linux it shouldn't be difficult to write one.
I haven't seen a PA or FreeAXP disk image. So I don't know wheater
they are VMS disk images (aka LD devices or created with backup/
physical) or they have additional data to describe the geometry of the
disk. I can only guess and would guess that such information would be
in the first blocks, that is 512 byte chunks. On Linux, losetup (the
tool to set up a loop device) lets you specify an offset where your
disk data really starts. That would hep you if there is geometry
information in front of the disk blocks..
Jan-Erik Soderholm
> I haven't seen a PA or FreeAXP disk image.
> So I don't know wheater they
> are VMS disk images (aka LD devices
If I do not completely missunderstand...
An LD-disk is a *VMS* file
(that internaly looks like a VMS-disk).
A PA or FreeAXP disk is a *Windows* file
(that internaly looks like a VMS-disk).
So the containing file layout will be host-OS dependant
and the internal structure will be target-OS dependant,
with some uncertantly in how the drivers handle/read it.
It's the combination of the file itself together with the
driver that reads it that produce a VMS disk emulation.
The driver could do "things" that complements what's
actualy on the disk to make up the full ODS2/5 emulation.
It's not absolutely needed that a LD-container, if read
with something else then the LD-driver, must look like a "true"
ODS-2/5 disk. It probably does, to some extent, but anyway...
FredK
"Sum1" <n...@real.address.com> wrote in message
news:4c824e0c$0$28651$c3e...@news.astraweb.com...
> Hi Graham
>
> 1. Machine is booted
> 2. SRM reads configuration and knows what type of disks are attached and
> where
> 3. Reads LBN0 (how does it know which one that is?)
An SRM NVRAM variable set by the users determines which device is the boot
device. The first block of that disk is the boot block.
> 4 LBN is the bootblock, SRM loads into memory and executes it.
No. The bootblock contains the LBN and length of the file APB.EXE, which
the SRM then uses to load file file (which is physically contiguous).
> Bootblock is also a component of the INDEXF.SYS, placed there along with
> the other mandatory files described in Goldstein's document. Block 1 of
> INDEXF.SYS is the bootblock, next is the homeblock (structure described in
> Goldstein's book), followed by the rest in logical order.
> 5. Control transferred to APB.EXE which then finishes the boot sequence
> according to the assorted parameter files/startup.com etc.
>
> So, all I need is the structure of the bootblock which is, I guess,
> APB.exe I suppose that means it is a 512 byte executable in a format
> readable and executable by the SRM?
>
Get the Alpha architecture reference manual. The bootblock is not
executable. It simply contains the pointer and length of APB.EXE which is
the primary bootstrap which th SRM loads and executes.
VAXman-
>On Sep 4, 12:12 pm, Sum1 <n...@real.address.com> wrote:
>
>> I can't look at the container files as a RAW disk as they are Windows
>> files, and if I look "into" them, I don't see what I would if I was
>> looking at a real
>> RAW disk. So, I am looking for a way to look into them physically, but
>> from Windows/Linux/OSX.
>
>On Linux you can set up a loop device for a file. That is, a block
>device pointing to your container file. The loop device then can be
>used as a disk device. Given the file system on the container file,
>you can then mount that device in a Linux directory. There is an ODS5
>file system for some Linux distros available just doing that. It can
Hartmut, do you have more info on this ODS5 file system for Linux?
Hein RMS van den Heuvel
> I can happily connect an ODS-5 disk to a USB reader and have something
> like WinHex read the physical disk to display the ODS signatures,
> layout etc.
Good.
> Is there some way that I can make a container disk look the same? When
> I tried to look at the container disk from PersonalAlpha and FreeAXP
> using WinHex, they didn't look the same as reading the physical disk in
> WinHex.
They looks exactly the same, and just fine to me...
As example I used a 'container' file which can be booted under FreeAXP
or Personal Alpha
The best tool to LOOK at this is of course $ DUMP on OpenVMS
(note, under 8.4 I had to set my default to a non-existing directory
for DUMP to go into logical block mode)
$ dump/block=count=2 BUNDY$DKA0:/wid=80
Dump of device BUNDY$DKA000: on 4-SEP-2010 11:15:40.45
Logical block number 0 (00000000), 512 (0200) bytes
03039401 001E65C0 11C00200 15C600A0 ..Æ...À.Àe...... 000000
8BDFFF76 905F0000 000501FB 000609F7 ÷...û....._.v.ß. 000010
34385359 53414850 4C410087 80FDFF74 t.ý...ALPHASYS84 000020
74737973 20616870 6C412020 20202020 Alpha syst 000030
0000000A 0A0D2020 206B7369 64206D65 em disk ...... 000040
:
53595341 48504C41 20202020 20202020 ALPHASYS 0001D0
20202020 20202020 20202020 20203438 84 0001E0
7CBE0000 20204231 31454C49 46434544 DECFILE11B ..¾| 0001F0
Same file from CYGWIN:
Administrator@blah /cygdrive/m/vms_personal_alpha
$ od -N 1024 -a -X FreeAXP_OpenVMS_84.img
0000000 sp nul F nak nul stx @ dc1 @ e rs nul soh dc4 etx
etx
15c600a0 11c00200 001e65c0 03039401
0000020 w ht ack nul { soh enq nul nul nul _ dle v del _
vt
000609f7 000501fb 905f0000 8bdfff76
0000040 t del } nul bel nul A L P H A S Y S 8
4
80fdff74 4c410087 53414850 34385359
0000060 sp sp sp sp sp sp A l p h a sp s y s
t
20202020 6c412020 20616870 74737973
0000100 e m sp d i s k sp sp sp cr nl nl nul nul
nul
64206d65 206b7369 0a0d2020 0000000a
:
0001740 8 4 sp sp sp sp sp sp sp sp sp sp sp sp sp
sp
20203438 20202020 20202020 20202020
0001760 D E C F I L E 1 1 B sp sp nul nul >
|
46434544 31454c49 20204231 7cbe0000
0002000
And the same file with WINHEX ( Select-section ... Edit... Copy
Block.. Editor Display )
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
000000000 A0 00 C6 15 00 02 C0 11 C0 65 1E 00 01 94 03 03 Æ À
Àe ”
000000010 F7 09 06 00 FB 01 05 00 00 00 5F 90 76 FF DF 8B ÷
û _ vÿß‹
000000020 74 FF FD 80 87 00 41 4C 50 48 41 53 59 53 38 34 tÿý€‡
ALPHASYS84
000000030 20 20 20 20 20 20 41 6C 70 68 61 20 73 79 73 74
Alpha syst
000000040 65 6D 20 64 69 73 6B 20 20 20 0D em
disk
:
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
0000003D0 20 20 20 20 20 20 20 20 41 4C 50 48 41 53 59 53
ALPHASYS
0000003E0 38 34 20 20 20 20 20 20 20 20 20 20 20 20 20 20
84
0000003F0 44 45 43 46 49 4C 45 31 31 42 20 20 00 00 BE 7C
DECFILE11B ¾|
>>> However, I also want to examine the sector contents of disks created
from FreeAXP and PersonalAlpha (and others), but they don't apper the
same as physical sector-evel reads. Hence, I am lookinf for some
Windows/Linux/OSX based tool that will allow me to see sector-based
structures in these container files.
Nonsense. Container files are just streams of bytes, related to in 512
byte blocks.
No 'sector'/MBR/GPT stuff (until you talk about an Itanium boot disk)
>> I am trying to get a sector-level
description of what is going on, much like one can get for MBR/GPT
disks.
What you see is what you get.
In the OpenVMS Guide to File Applications, just focus on chapter 1.2
Use the OpenVMS structure definitions in SYS$LIBBRARY:LIB.MLB for
explanation
But best of all get the 'file systems internals book'
For the structures you mostly need:
$ libr/out=tt:/extr=$fh2def sys$library:lib.mlb
BTBDEF - boot block def
HM2DEF - home block def
FH2DEF - file header
>> At some point I can then dive into the $RMSDEF macros and work my way through the other structures at leisure.
RMS deals with what is inside the file, which is orthogonal to how the
file structure plays out.
The file systems allows you to find blocks with data
RMS makes senses out of the data in the form of records.
Good luck!
Hein
i
>
> Cheers
John E. Malmberg
You may get better luck asking at the FreeAXP forum on
www.openvmshobbyist.org. I have seen some posts there about conversions
between disk containers.
-John
wb8...@qsl.network
Personal Opinion Only
Hein RMS van den Heuvel
> On 9/3/2010 9:12 PM, Sum1 wrote:
> > When I tried to look at the container disk from PersonalAlpha and FreeAXP using
> > WinHex, they didn't look the same as reading the physical disk in WinHex.
Sum1, So why don't you describe to us, or show, how they do not look
the same ?
We can but speculate.
And yeah, Andy's 1985 document will do fine if you can not get Kirby
McCoy's VMS File Systems Internals.
What are you trying to do? Just a better understanding? Homework
exercise?
> You may get better luck asking at the FreeAXP forum onwww.openvmshobbyist.org.
John, IMHO this has very little to do with FreeAXP itself, but ok.
As I replied earlier though, FreeAXP could nicely give our standard
DIR, DFU, DUMP tools to check out the data.
Notably DUMP/HEAD for INDEXF.SYS should be very handy with the
formatted mapping pointers. Keys to the kingdom.
Hein
John E. Malmberg
>
> John, IMHO this has very little to do with FreeAXP itself, but ok.
> As I replied earlier though, FreeAXP could nicely give our standard
> DIR, DFU, DUMP tools to check out the data.
> Notably DUMP/HEAD for INDEXF.SYS should be very handy with the
> formatted mapping pointers. Keys to the kingdom.
Sumi had earlier stated that he could read ODS-2 formatted disks on
Windows, at least in Hex. There is also the ODS-2 reader software that
I think is open source on the Freeware disk collection, which should
allow reading ODS-2 format disks directly. So ODS-2 disks can be read
by other platforms.
I found 3 variants on the Freeware
http://decuslib.com/freeware/freewarev80/ods-2-reader-for-osf-1
http://decuslib.com/freeware/freewarev80/ods-2-reader/
http://decuslib.com/freeware/freewarev80/ods2/
Reading ODS-2 disk images on FreeAXP is easy, as all you have to do is
use a utility like MagicDisk and have FreeAXP use that as the CD-ROM.
But what Sumi has indicated he wants to read the container files that
FreeAXP and Personal Alpha uses directly and understand them with out
using the Emulator. Apparently there is additional information on those
volumes besides being a direct image of the disk contents. That
conclusion is also based on discussions in the FreeAxp forums about
converters for those containers.
I have not checked if SimH has anything different on its files. I was
able to point SimH on Ubuntu Linux to unpartitioned space and it was
able to use it directly.
VMware and VirtualBox container files contain additional information on
them, as they have different types of container files.
Sumi has also asked about the boot block information. The boot block
should be the same on all OS's and disk structures, so should be present
in Linux and other open source OSes that can boot on Alpha.
hb
> Hartmut, do you have more info on this ODS5 file system for Linux?
Sure, there is a web site: http://www.vms2linux.de/ods5fs.html
Hein RMS van den Heuvel
> On 9/4/2010 3:28 PM, Hein RMS van den Heuvel wrote:
> But what Sumi has indicated he wants to read the container files that
> FreeAXP and Personal Alpha uses directly and understand them with out
> using the Emulator. Apparently there is additional information on those
> volumes besides being a direct image of the disk contents.
Show me yours. I showed you mine in my reply @ Sep 4, 11:37 am
Bit-for-bit the same, as seen from FreeAXP, Cygwin and winhacks
(winhex)
ODS-2 probably, but I don't see how it would be different for ODS-5
> Sumi has also asked about the boot block information. The boot block
> should be the same on all OS's and disk structures
b.s. Unless you mean that the boot block is the same for an Linux or
Windows based emulator. The bootblock will be the same period.
Linux does not boot OpenVMS.
Alpha emulators under Linux boot OpenVMS.
They know to read LBN 0, and look for the boot code LBN.
Cheers,
Hein.
VAXman-
>On 9/4/2010 3:28 PM, Hein RMS van den Heuvel wrote:
>>
>> John, IMHO this has very little to do with FreeAXP itself, but ok.
>> As I replied earlier though, FreeAXP could nicely give our standard
>> DIR, DFU, DUMP tools to check out the data.
>> Notably DUMP/HEAD for INDEXF.SYS should be very handy with the
>> formatted mapping pointers. Keys to the kingdom.
>
>Sumi had earlier stated that he could read ODS-2 formatted disks on
>Windows, at least in Hex. There is also the ODS-2 reader software that
>I think is open source on the Freeware disk collection, which should
>allow reading ODS-2 format disks directly. So ODS-2 disks can be read
>by other platforms.
>
>I found 3 variants on the Freeware
>
>http://decuslib.com/freeware/freewarev80/ods-2-reader-for-osf-1
>
>http://decuslib.com/freeware/freewarev80/ods-2-reader/
>
>http://decuslib.com/freeware/freewarev80/ods2/
>
>Reading ODS-2 disk images on FreeAXP is easy, as all you have to do is
>use a utility like MagicDisk and have FreeAXP use that as the CD-ROM.
>
>But what Sumi has indicated he wants to read the container files that
>FreeAXP and Personal Alpha uses directly and understand them with out
>using the Emulator. Apparently there is additional information on those
>volumes besides being a direct image of the disk contents. That
>conclusion is also based on discussions in the FreeAxp forums about
>converters for those containers.
Maybe ODS-2/5 atop FLAB-32 akin to VMS running atop that tinker-toy OS when
using FreeAXP.
VAXman-
>On Sep 4, 5:20 pm, VAXman- @SendSpamHere.ORG wrote:
>
No source there and no builds for Linux 2.6.31-22-generic-pae #64-Ubuntu SMP
bart...@gmail.com
wrote:
> On 2010-09-04 16:21, hb wrote:
>
> > I haven't seen a PA or FreeAXP disk image.
> > So I don't know wheater they
> > are VMS disk images (aka LD devices
>
> If I do not completely missunderstand...
>
> An LD-disk is a *VMS* file
> (that internaly looks like a VMS-disk).
>
> A PA or FreeAXP disk is a *Windows* file
> (that internaly looks like a VMS-disk).
>
Yes, and when you transfer them in either direction (in binary mode,
of course) they are still just that: an image of an OpenVMS ODS2 or
ODS5 disk. I have created and initialized disk images with PA and used
them with LD, and vice versa, without problems.
Bart
hb
> No source there and no builds for Linux 2.6.31-22-generic-pae #64-Ubuntu SMP
Which is a 32-bit version of Ubuntu 9.10 with an updated generic-pae
kernel for more than 4GB, right?
There is build for that version in the untested subdirectroy.
VAXman-
>On Sep 5, 12:41=A0am, VAXman- @SendSpamHere.ORG wrote:
>> No source there and no builds for Linux 2.6.31-22-generic-pae #64-Ubuntu =
>SMP
>
>Which is a 32-bit version of Ubuntu 9.10 with an updated generic-pae
>kernel for more than 4GB, right?
>There is build for that version in the untested subdirectroy.
Well, since this "untested subdirectroy" isn't published in any of the
links on the pages that the posted URL takes me, my statement maintains
its veracity.
hb
> Well, since this "untested subdirectroy" isn't published in any of the
> links on the pages that the posted URL takes me, my statement maintains
> its veracity.
The builds in http://www.vms2linux.de/untested are just done with
additional kernel header files, they are not tested as the other
"announced" kits, because of lack of resources. In that "untested
subdirectory" there is a u0910-22-generic-pae.zip file with a ods5.ko
built for "2.6.31-22-generic-pae SMP".
VAXman-
>On Sep 6, 1:27 am, VAXman- @SendSpamHere.ORG wrote:
>> links on the pages that the posted URL takes me, my statement maintains
>> its veracity.
>
>additional kernel header files, they are not tested as the other
>"announced" kits, because of lack of resources. In that "untested
>subdirectory" there is a u0910-22-generic-pae.zip file with a ods5.ko
>built for "2.6.31-22-generic-pae SMP".
Thanks Hartmut. There wasn't any link to this on the pages originally
posted. I see that 5 Sept. build now. I'll download it and give it a
go soon. I'm busy working on other things at the moment.
Bob Koehler
>
> Winhex? Is that an evil spell cast by the followers of that Redmond cult?
No doubt Redmond now has it's own hexadecimal number system, and if
you don't use MS software to read it your data won't look right.