Author |
how to convert physical Tru64 v4.0 d to virtual |
MNMC
Member
Posts: 7
Joined: 06.04.10 |
Posted on April 06 2010 18:40 |
|
|
Hallo
I have some special tru64 commercial midecal application that can`t be installed in an usuall tru64, but only on special tru64 from the company, and the special tru64 can`t be installed on usuall alpha worksation but on special alpha worksation from the company.
The tru64 and the main midecal applications was from "picker" in one CD, I tested to install the tru64 in "personal alpha" emulater, it boots from CD but tell me that this tru64 kernel can`t be installed exept in an alpha machine from picker named "odyssey FX" that I have.
The system is insalled in 2 GB disk divided 2 partitions:
/ 64 MB, contains the tru64 kernel, it`s a spicail kernel
/img0 contains the spicial applications and data
So... I think of making a virtual image of the whole tru64 system on a vitual disk, and to make network between this virtual tru64 and a physical computer of a Gamma Camera to get midecal images.
Is this possible??
Please help me for I well tell you the results. |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
John Manger
Moderator
Posts: 63
Location: nr Heathrow, Middlesex, UK
Joined: 18.03.10 |
Posted on April 06 2010 22:47 |
|
|
Hi,
I see this has been discussed on the HP ITRC forum as well :
https://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1419402
Over there, the question was raised as to how 'odyssey FX' differs from a 'standard' Alpha ? Also asked was have you contacted Phillips about how to move to a new (emulated) platform ?
> I think of making a virtual image of the whole
>Tru64 system on a vitual disk, and to make network
>between this virtual tru64 and a physical computer of a
>Gamma Camera to get medical images.
>
> Is this possible??
Maybe.
You should be able to copy the boot disk of your Alpha using dd. You will need to dd the 'c' partition in order to copy the entire physical volume including the boot sectors and disk label. You will need somewhere to 'capture the dd output, and then copy/ftp/export/move the file to the Windows system on which you will run FreeAXP. If you only have 1 disk in your Alpha, you may need to use NFS to another Un*x (or Windows) system to provide the neccessary disk space.
The sequence might look like this :
ofx # mount bigsys:/bigspace /mnt
ofx # dd if=/dev/rz0c of=/mnt/OFX.img bs=128k
bigsys # ftp /mnt/OFX.img -> windows machine
start FreeAXP wizard, set OFX.img as DKA0 (ie. rz0)
start FreeAXP, boot DKA0
(in the above, ofx is the odessy system, bigsys is an NFS server, and rz0 is your oddessy root disk, your actual disk name may be different - 'scu sho edt' and mount or showfdmn, will reveal which disk is the root disk)
Then post us the results in the forum.
Also, can you tell us more about 'odessey FX' ?
Can you post a sys_check -all output ? or the boot messages ? to help us see what is unique about the platform.
John M |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
MNMC
Member
Posts: 7
Joined: 06.04.10 |
Posted on April 07 2010 06:10 |
|
|
>can you tell us more about 'odessey FX' ?
Can you post a sys_check -all output ? or the boot messages ?
Yes, to my pleasure.
I prefere to try copying the system myself to freeAXP before asking Philips, for it seems difficult for them to deal with such old systems.
I have read your reply, but not undrestand all thing, for english isn`t my own language or for Im not tru64 expert user, Im newuser, but somehow old user of "Odyssey FX" imager.
Today I have managed to share and mount an windows folder by NFS in tru64, so I have new 10 GB free space.
Is OFX.img will contain both two partitions / ,/img0, and swap partition?
Please,I have undertood all things expet:
>'scu sho edt' and mount or showfdmn, will reveal which disk is the root disk).
>Can you post a sys_check -all output ?
How?
>or the boot messages ?
can`t write down them, they are faster than I could.
With very thanks.
Edited by MNMC on April 07 2010 18:06 |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
MNMC
Member
Posts: 7
Joined: 06.04.10 |
Posted on April 10 2010 20:49 |
|
|
Im not sure about the name of disk device in my alpha.
scu sho edt
CAM Equipment Device Table (EDT) Information:
Bus/Target/Lun Device Type ANSI Vendor ID Product ID Revision N/W
-------------- ----------- ------ --------- ---------------- -------- ---
0 0 0 Direct SCSI-2 DEC RZ28D (C) DEC 0008 N
0 4 0 CD-ROM SCSI-2 DEC RRD46 (C) DEC 0557 N
0 6 0 Sequential SCSI-2 TANDBERG TDC 4100 =05O N
I tried dd if =dev/RZ28D of=/mnt/OdysseyFX.img bs=128k
/dev/RZ28D: No such file or directory
try
ls /dev
MAKEDEV prf rmo0c.FX729 rrz29e rz17c sad
MAKEDEV.log printer rmt0a rrz29f rz17d snmpinfo
SYSV_PTY ptm rmt0h rrz29g rz17e streams
acqproc0 ptmx rmt0l rrz29h rz17f tmp
acqproc1 ptmx_bsd rmt0m rrz30a rz17g tty
acqproc2 pts rmt1a rrz30b rz17h tty00
acqproc3 ptyp0 rmt1h rrz30c rz21a tty01
audit ptyp1 rmt1l rrz30d rz21b tty02
binlogdmb ptyp2 rmt1m rrz30e rz21c ttyp0
cam ptyp3 rmt1x rrz30f rz21d ttyp1
cdrom ptyp4 rrz0a rrz30g rz21e ttyp2
console ptyp5 rrz0b rrz30h rz21f ttyp3
fd0a ptyp6 rrz0c rrz4a rz21g ttyp4
fd0c ptyp7 rrz0d rrz4b rz21h ttyp5
fddrive ptyp8 rrz0e rrz4c rz29a ttyp6
kbinlog ptyp9 rrz0f rrz4d rz29b ttyp7
kcon ptypa rrz0g rrz4e rz29c ttyp8
keyboard0 ptypb rrz0h rrz4f rz29d ttyp9
klog ptypc rrz16a rrz4g rz29e ttypa
kmem ptypd rrz16b rrz4h rz29f ttypb
lat ptype rrz16c rrz8a rz29g ttypc
lockdev ptypf rrz16d rrz8b rz29h ttypd
log ptyq0 rrz16e rrz8c rz30a ttype
lp0 ptyq1 rrz16f rrz8d rz30b ttypf
mem ptyq2 rrz16g rrz8e rz30c ttyq0
mmsess0 ptyq3 rrz16h rrz8f rz30d ttyq1
mo0 ptyq4 rrz17a rrz8g rz30e ttyq2
mo0.FX729 ptyq5 rrz17b rrz8h rz30f ttyq3
mo0a ptyq6 rrz17c rz0a rz30g ttyq4
mo0a.FX729 ptyq7 rrz17d rz0b rz30h ttyq5
mo0c ptyq8 rrz17e rz0c rz4a ttyq6
mo0c.FX729 ptyq9 rrz17f rz0d rz4b ttyq7
mouse0 ptyqa rrz17g rz0e rz4c ttyq8
msb0 ptyqb rrz17h rz0f rz4d ttyq9
nrmt0a ptyqc rrz21a rz0g rz4e ttyqa
nrmt0h ptyqd rrz21b rz0h rz4f ttyqb
nrmt0l ptyqe rrz21c rz16a rz4g ttyqc
nrmt0m ptyqf rrz21d rz16b rz4h ttyqd
nrmt1a rcdrom rrz21e rz16c rz8a ttyqe
nrmt1h rfd0a rrz21f rz16d rz8b ttyqf
nrmt1l rfd0c rrz21g rz16e rz8c ws0
nrmt1m rmo0 rrz21h rz16f rz8d zero
nrmt1x rmo0.FX729 rrz29a rz16g rz8e
null rmo0a rrz29b rz16h rz8f
pfcntr rmo0a.FX729 rrz29c rz17a rz8g
pipe rmo0c rrz29d rz17b rz8h
Then I try dd if =dev/rz0c of=/mnt/OdysseyFX.img bs=128k, it is ok but im not sure if the device is true.
I have copied the image, it taked 11 hrs !!!!, windows make a restart due to some error during copy, but the "dd" go on copying automatically after the restart.
this is the output:
dd if =dev/rz0c of=/mnt/OdysseyFX.img bs=128k
NFS3 server "windows" not responding still trying (this during the restart)
NFS3 server "windows" ok
16056+1 records in
16056+1 records out
The size of OdysseyFX.img in windows is (1.95 GB, 2,104,565,760 bytes), size on disk is the same, the physical disk is 2GB, with about 10 MB free space in / , and 581 MB free space in /img0.
|
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
MNMC
Member
Posts: 7
Joined: 06.04.10 |
Posted on April 11 2010 18:41 |
|
|
error:
my PC in single core, celeron 3.4, Ram 875.
how to test it at least before buy new dual core? |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
John Manger
Moderator
Posts: 63
Location: nr Heathrow, Middlesex, UK
Joined: 18.03.10 |
Posted on April 12 2010 06:51 |
|
|
From your 'scu' output, RZ28 is 0/0/0, so yes it is /dev/rz0 (or /dev/rrz0).
The dd should be from rz0c, which is what you did.
The resulting size looks reasonable.
So you should be able to boot an emulator from OdysseyFX.img.
However, as you say, you will need to find a system with at least 2xCores, and 2GB of memory (~1G may work, but slowly).
If you can't find one, PM me (or Bruce) and perhaps we could test it for you ?
John M |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
MNMC
Member
Posts: 7
Joined: 06.04.10 |
Posted on April 13 2010 18:38 |
|
|
Thanks very much, I have found a system with at least 2xCores, and 2GB of memory of some friend, so I well test it.
But before, let me tell about testing in Personal Alpha, and Im sory for testing on competing product, but let me tell you the results, the logging information is in this file:
http://www.zshare.net/download/74945871ab5c6eef/
Alpha Emulator Firmware
Version 2.0.16 build Oct 8 2008 09:38:01
Initialized physical memory: 128 MB
Loaded HWRPB: physical address 2000
Initialized CPU0
CPU0 halted: reason: power up
>>> b dka0
(boot -file '' -flags '' 'dka0' )
BOOT_RESET is ON: cold boot
Booting from the device 'dka0' file ''
Loaded the primary booter; size 0x40000
Digital UNIX boot - Mon Dec 29 18:50:44 EST 1997
Loading vmunix ...
Loading at fffffc0000230000
Current PAL Revision <0x100538>
Switching to OSF PALcode Succeeded
New PAL Revision <0x2012d>
Sizes:
text = 3147296
data = 491360
bss = 1222976
Starting at 0xfffffc0000413aa0
CPU0 halted: reason: double error
restart failed: auto_action is HALT
>>>
Now the proplem is one or more of these:
1- This system can`t be run on other alpha exept it`s "Picker" alpha named "OdysseyFX" alphastation 255 233 MGz.
2- The copying error when windows restart, I well make onther new copy.
3- The personal Alpha itself can`t run tru64 V 4.o D, I well test FreeAXP on 2 core system.
Edited by MNMC on April 13 2010 19:14 |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
MNMC
Member
Posts: 7
Joined: 06.04.10 |
Posted on June 01 2010 19:48 |
|
|
hallo
sory for delay
yesterday I have test it with laptop core 2 due 2 mega ram, the result encourage me for more tests.
the image boots but to single user mode, no graphic login appear, I try to open the /img0 partition, but it was empty, /img0 contain all applications and user profile I need to work.
the result of boot at FreeAXP is in this txt file:
odyssey.txt - 0.01MB
what is the matter? the image hasnt /img0, or what? |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
Bruce Claremont
Moderator
Posts: 623
Joined: 07.01.10 |
Posted on June 02 2010 09:53 |
|
|
For the graphics you are going to need an X-Window client to log in with. Something like ReflectionX or Cygwin/X. FreeAXP does not include a built in graphics card. Test the X-Windows client against the real Alpha, then try the same configuration to access the FreeAXP virtual Alpha. |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
MNMC
Member
Posts: 7
Joined: 06.04.10 |
Posted on June 02 2010 18:00 |
|
|
[b]...Test the X-Windows client against the real Alpha, then try the same configuration to access the FreeAXP virtual Alpha.
do you mean that the test is sucsessfull?
I have already tested the real alpha in windows pc connected network to him, by "winaxe", it was works good.
so you mean I should install the X-Windows client in the same computer that I have installed FreeAXP, and to treat with FreeAXP as if it was aonther real alpha network connected? |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
John Manger
Moderator
Posts: 63
Location: nr Heathrow, Middlesex, UK
Joined: 18.03.10 |
Posted on June 03 2010 03:17 |
|
|
If real axp -> winaxe PC works OK, then try
FreeAXP -> winaxe PC. Ie. Treat the FreeAXP instance as a real separate Alpha (which it is).
John M |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
John Manger
Moderator
Posts: 63
Location: nr Heathrow, Middlesex, UK
Joined: 18.03.10 |
Posted on June 03 2010 04:17 |
|
|
MNMC wrote:
the image boots but to single user mode,
..... I try to open the /img0 partition, but it was empty...
what is the matter? the image hasnt /img0, or what?
From prevoius discussion(s) it seems /img0 is a UFS filesystem under /dev/rz0g, and should be in the /etc/fstab file, so to mount /img0 try :
# mount -a
or
go to multi-user by # init 3
or
boot the system image with '-flags A'.
or
# fsck /dev/rrz0g
# mount /dev/rz0g /img0
John M |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
zalmyc
Member
Posts: 2
Joined: 03.10.12 |
Posted on December 06 2012 19:15 |
|
|
Hi John. I had looked into this a while back. I got to know a little bit about the system (though not nearly enough). So perhaps I can provide a little more info to get this going.
Picker released software called Odyssey that runs on a few different DEC machines. Most of the machines we use are branded 'Odyssey FX xxx,' where xxx is a different model number (830, etc). My system happens to be an Personal Alpha Workstation 500au, but at least one other colleague uses an even older machine that they branded as a 'VP' (in constrast to the FX Series). In regards to the info about PersonalAlpha by Stromasys, I believe that that emulator (is that the correct word?) is akin to the VP series, whereas FreeAXP emulates one of the FX series.
From what I know about the installation, 3 partitions are used: the rz16a partition is mounted as root, the rz16g partition as the storage area (including the Odyssey software), and the rz16b partition as a swap space. Any additional hard drives have their rzXXc partitions mounted and are used only for additional hd space. There are also optical, tape, and cdrom drives. There are additional ports for camera hookups but I don't know anything about those.
The Odyssey installation disk installs the Odyssey software on top of a (customized?) Digital Unix 4.0D kernel. As a true newbie, it's difficult for me to know where the Odyssey sits in terms of the OS (I have been using Windows my entire life (gasp!). The installation also installs the X Window system on the computer during the process. The initial installation file checks the current DEC model. For example, when trying to install on PersonalAlpha (sorry for including your competitor in this post), the script declares that the current disk is only for the FX series (I don't have the VP installation disk). I was able to work around that by commenting out that check using sed, and I believe I completed the installation process, but upon reboot, it dropped me into single-user mode.
Previously, I had tried to install Odyssey on FreeAXP. When installation finally began after all the initial questions, the system would hang (I would get the CAM_Logger error similar to this post). Recently, I attempted again and was surprised to discover that the installation proceeded. I ran into a few issues. First, the installation would check (or write?) blocks, but then would err, saying that it ran out of room on the cylinder. I didn't run into this problem when using those 'canned rz distributions' you generously provided (however, those are quite small compared to what I'd perfer: >4G. So recently, I (almost) successfully installed Odyssey on FreeAXP (and mucked it up when it didn't fully work - sorry). Installation completed with no errors reported, but upon reboot, I was dropped into single-user mode because it couldn't find the swap partition (note that the fstab file was correctly written and at the beginning of the installation it asks the user to choose a partition strategy (root size/swap size/image size).
To clarify the whole "img0" thing, Odyssey creates directories img0 through img15 in the root directory (and you can create more, up to img99). At installation, you choose one that is essentially your /usr path, and the others are used to mount other Odyssey workstations as NFS shares.
Perhaps this is naive to think, but I feel that without the X Window (or rather, any graphical system), the Odyssey is pointless. You mentioned that FreeAXP does not contain built-in graphics, and that you need an X Server like Cygwin/X. I have successfully exported my physical Odyssey display using MobaXTerm, and I can see my Odyssey desktop as if I were in front of it. I can run some of the programs. However, the main programs like viewing images using color stripes, etc (i.e. the main programs of Odyssey) won't display, instead alerting me "control is already running" and "no shared key for control." Control is, I believe, the heart of the software - a control panel that controls all aspects of the imaging programs of Odyssey. Closing the control program on the physical Odyssey doesn't work. At one point, I disabled the shared key check by commenting out a line in the control program startup script that dictates running only one instance of the control program. The control program then runs (although not visually), but upon trying to start one of the graphic-intense programs, I get "X Error of Failed Request: Bad Atom..."; on starting a different program, I get "no pseudocolors available." I have not been able to figure these errors out, perhaps you have a better understanding? My thinking is that I need to copy the custom color files (whatever those may be) into my X Server folder, but I don't really know what I'm actually to do. |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
Bruce Claremont
Moderator
Posts: 623
Joined: 07.01.10 |
Posted on December 07 2012 12:53 |
|
|
Nice post. Thanks for all the details. Any chance we could obtain a copy of the installation media to play with? |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
zalmyc
Member
Posts: 2
Joined: 03.10.12 |
Posted on December 07 2012 17:15 |
|
|
The installation disk belongs to my firm, so I need to run that by them first. I'm not sure what the proprietary situation is with that disk (I believe it's still a Phillips/Picker copyright, but I'd rather not release anything before getting approval). I hope that's understandable. I certainly don't want to hold back after you've obviously provided us with this fabulous, free product . |
|
Author |
RE: how to convert physical Tru64 v4.0 d to virtual |
Bruce Claremont
Moderator
Posts: 623
Joined: 07.01.10 |
Posted on December 08 2012 02:12 |
|
|
No problem. If you are able to release the kit, we can see if we can get it to boot. We can put an NDA in place if required. |
|