In <list-11055208@2rosenthals.com>, on 09/30/24
at 11:07 PM, "Lewis G Rosenthal" <ecs-isp@2rosenthals.com> said:
Hi all,
>QEMU can do it, but it's not for the feint of heart. I have no directions
> for you, as I've never personally been able to get ArcaOS to boot under
>it (though I know that dixie has, and AFAIK, he uses it regularly - but
>that being said, I do not know what the network performance might be
>with it).
See the appended. This is collected from Walter Dnes over the years.
Walter hangs out on the SCOUG help list and elsewhere, I am sure.
It appears that he has worked with dixie on some of the issues.
I've not had the time to try the instruction here, but I'm sure Walter
would assist wih any issues that might arise.
Regarding QEMU/KVM, OS/2 runs in QEMU mostly fine. Except the trap in
os2lvm.dmd and non-working netbeui.os2 and tcpbeui.os2. The problem with
os2lvm.dmd is because QEMU closely follows the intel spec, which is
incorrect. The spec says that 16-bit SGDT instruction behaves the same like
in i286 processor. But it's not true, it behaves like i386 instruction. So,
QEMU emulates SGDT 16-bit instruction incorrectly. OS2LVM.DMD uses 16-bit
SGDT instruction and it hits the problem. But there's a patched version of
OS2LVM.DMD by _dixie_, you can change it to the patched version and
everything will work. The link is:
A link to a zip file named OS2LVM_QEMU.ZIP which eventually had a patched
OSLVM.DMD is there...but I think it is broken.
[scoug-help] [SOLVED] ArcaOS 5.0.4 install in QEMU VM problem
2020-05-23
It's qemu-4.2.0-r6 on Gentoo linux with the following flags enabled...
aio alsa bzip2 curl fdt gtk jpeg opengl oss png ssh usb vhost-net vnc xkb
It selected building qemu, qemu-i386, qemu-io, qemu-nbd,
qemu-system-i386, qemu-x86_64, qemu-edid, qemu-img, qemu-keymap,
qemu-pr-helper, and qemu-system-x86_64. I installed on a 4 gigabyte
virtual drive "arcac.img", which I created with the command
"qemu-img create -f raw arcac.img 4G". The initial install script I
used was...
Assuming your qemu isn't customised differently... you have to be
root or sudo to launch the "system" version and "-enable-kvm" and
"-cpu host". The "-runas waltdnes" drops root privilages right after
launch, dropping down to my regular usedID. Change the userID to your
own as appropriate.
I don't recall being asked for anything special. I think I selected
"Boot with default values". Try my install script, with appropriate
changes to file names and userID. The qemu syntax had changed since the
previous time I did an install. The older syntax may have been causing
problems for you; it certainly did for me.
The goal of this document
=========================
The goal is to list the steps necessary to...
* Install an OS/2 Warp 4 VM inside a QEMU host on linux
* Set up simple outbound networking (TCP and UDP only).
* Upgrade to Fixpack 15
* Install SciTech display drivers offering up to 1600x1200x16777216
video (if the host machine's video card and monitor support it)
QEMU specific information
=========================
* {CTRL}{ALT}{2} switches to the monitor
* {CTRL}{ALT}{1} switches back to the running program
* Alternatively, the user can click on "View" and select "Show Tabs".
- Selecting the "compat_monitor0" tab switches to the monitor
- Selecting the "VGA" tab switches to the running program
* {CTRL}{ALT}{G} toggles the QEMU window mouse cursor grab on and off
* {CTRL}{ALT}{F} toggles the QEMU window fullscreen mode on and off
* The "Machine" menu contains
- "Pause", which pauses the VM. This can be used anytime.
- "Reset", "Powerdown", and "Quit". ***DO NOT USE ANY OF THESE UNLESS
OS/2 SAYS IT'S SAFE TO TURN OFF YOUR VIRTUAL MACHINE***
* The OS/2 VM *ALWAYS* boots up with {NUMLOCK} and {CAPSLOCK} off. To
keep things synchronized and avoid confusion always turn off {NUMLOCK}
and {CAPSLOCK} on the host machine, just before booting the OS/2 guest.
To further confuse the issue...
- the host toggles {NUMLOCK} and {CAPSLOCK} whenever the user toggles
them inside the guest
- the guest does *NOT* toggle {NUMLOCK} and {CAPSLOCK} when the user
toggles them in the host, when the QEMU window is not currently
selected
* There are a few easy ways to copy files from the host to the guest
that do not involve starting up a server
1) Assuming that basic networking is functional, the following 2 lines
as part of the boot script will cause the guest to see a very simple
read-only tftp server at address 10.0.2.2. Only the files in the
specified directory will be visible. Files may be added/deleted after
the bootup.
2) The following line, as part of the boot script, will cause the guest
to see a virtual read-only FAT drive populated by the files in the
specified directory...
-drive file=fat:<directory name>
The advantage is that unlike tftp, this will work even when networking
is not functioning. The disadvantage is that the FAT table is read only
at the guest bootup. Files that are added/modified after the guest
boots up will *NOT* be accessable.
* To copy files from the guest to the host
-drive file=fat:rw:<directory name>
This variant of the virtual FAT drive includes ":rw", i.e. the virtual
directory is read-write enabled. Files can be passed in both directions
between guest and host.
Numbers
=======
The use of powers-of-1024 is prevalant in the computer world. Unless
otherwise specified, in this document...
1 K = 1024
1 M = 1024 * 1024
1 G = 1024 * 1024 * 1024
Virtual Drives and Install Strategy
===================================
Because it uses 1980's and early 1990's technology, the original OS/2
Warp 4 will not boot from a partition greater than 504M. See https://en.wikipedia.org/wiki/Cylinder-head-sector for the technical
details. That limit will not apply to users with updated drivers.
Given the trend to bloat in modern software, 504 M will fill up rapidly.
It is strongly recommended to have 2 (virtual) hard drives from the
start. While original Warp 4 will not boot from a partition over 504 M,
it will quite happily read/write/format larger D:/E:/F: etc partitions.
The 504 M limit applies to just the boot C: partition. Other partitions
can be up to 2 G (FAT) or 64 G (HPFS). In the linux host, create the 2
virtual drives, which will become C: and D:. In this document, they are
called "os2c.img" and "os2d.img", respectively.
qemu-img create -f raw os2c.img 504M
qemu-img create -f raw os2d.img 2G
Linux-based HPFS-formatting tools are difficult to find. It is
possible to HPFS-format the 2 partitions early in the install before it
starts copying files over to the hard drive(s).
"Advanced Install" will be used for 2 reasons...
1) It allows the user to first jump in and partition and format the C:
and D: drives before the install starts copying files to the hard
drive(s)
2) It offers the option to select which drive to install some items to.
The goal is to divert as many files as possible to the D: drive.
Comments on script
==================
* sudo to *START* as root. But the following "-runas username" drops
root privileges and runs as user "username". The --enable-kvm option,
which sets up hardware emulation gives the best performance. But
itrequires either root premissions, or the use of acls, to run. It's
generally a bad idea to run a regular program as root. The "runas"
option solves that problem by starting as root, and immediately dropping
down to a regular user level, once hardware emulation is started..
* "qemu-system-x86_64 -enable-kvm" to get maximum performance.
* Do *NOT* set "monitor stdio". Bad idea for a GUI. Use "monitor vc"
* The files used to emulate virtual drives are...
- diskette0.img ==> aka "Install Diskette", the bootable floppy
- diskette1.img ==> Diskette 1
- diskette2.img ==> Diskette 2
- warp4.iso ==> the install CD
QEMU VLAN <------> Firewall/DHCP server <-----> Internet
| (10.0.2.2)
|
----> DNS server (10.0.2.3)
|
----> SMB server (10.0.2.4)
The QEMU VM behaves as if it was behind a firewall which blocks all
incoming connections. A DHCP client will automatically configure the
network in the QEMU VM. The DHCP server assigns addresses to the hosts
starting from 10.0.2.15
* A user can use "tftp=" to expose a directory of their choice on the
host via a built-in read-only tftp server. This is useful for
searching for files via the host's web browser, and fetching them,
before the guest has a functional, up-to-date web browser installed.
* "-device pcnet" is specified, because the AMD PCNet card is the only
NIC that exists in both the Warp 4 install and QEMU emulation. It
has to be used, at least at the install stage. Any legal string can
be substituted for "mynetwork". But the "id" string in the "-netdev"
line *MUST* match the "netdev=" string in the "device" line that follows.
* An option not used in this document is a Virtual FAT filesystem ( see https://en.wikibooks.org/wiki/QEMU/Devices/Storage ). The parameter...
"-drive file=fat:/dev/shm"
will expose /dev/shm (or any other directory the user specifies) as a
virtual drive.
- Disadvantage
- The virtual FAT is read only at the time the QEMU VM boots up.
Any files added/modified later will not show up, and could confuse
the QEMU program
- Advantages
- This will work even if networking is not functioning
- Specifying read-write allows the VM to write to the directory.
Read-write is specified like so...
"-drive file=fat:rw:/dev/shm:
* -m size=96 (96 megabytes of RAM for the OS/2 VM should make it happy)
-name "OS/2 VM" (the name for the VM)
-boot order=ac (PC's are supposed try floppy A: first, then drive C:)
* -vga std (*ALWAYS* use the standard vga card emulation. If Bochs
VESA VBE extensions have been enabled in the linux host's kernel, the
SciTech virtual display allows up to 1600x1200x16777216 resolution,
assuming the host machine's physical video card and monitor can handle
it. QEMU also emulates an ancient Cirrus card that offers nowhere near
that resolution. Do *NOT* specify the Cirrus card.
* ${@} picks up any additional drives/floppies/whatever that the user
specifies on the commandline.
* Do *NOT* specify a sound card in the install script. The install gets
very flaky, often crashing part way through the OS/2 install. The option
"-soundhw cs4231a" and "sb16" do match Warp 4 drivers. Install later
if required. Adding the "-parallel=none" option is strongly suggested
in that case, because some sound chips default to IRQ7, the same IRQ
used by parallel printers.
Manipulating virtual floppies in the monitor
============================================
for this document, the following diskette image names are used
diskette0.img (aka the "Installation Diskette")
diskette1.img
diskette2.img
The user will need to access the QEMU "monitor" to eject/change virtual
floppies, etc. When the first VM screen comes up, a "Machine View" menu
will show up on the menubar. Click on "View" and then on "Show Tabs" on
the "View" dropdown menu. This will set up another menubar with tabs.
To can switch between the VM and the monitor, click on the "VGA" and
"compat_monitor0" tabs respectively.
If the user's desktop/WM does not intercept {CTRL}{ALT}{1} and
{CTRL}{ALT}{2}, there is also the option of using {CTRL}{ALT}{2} to
switch to the monitor and {CTRL}{ALT}{1} to switch back to the install
session. This is in addition to the method listed above.
Note that all commands in the monitor console require the {ENTER} key
to be pressed at the end. This can be confusing, because the user often
has to...
* switch to the monitor
* type a command and press {ENTER}
* switch back to "VGA" (i.e. the install), and press {ENTER} again
The monitor has some line-editing ability...
1) {UP-ARROW} and {DOWN-ARROW} scroll through previously-issued commands
2) {CTRL}{H} is a destuctive backspace
3) {LEFT-ARROW} is a non-destructive backspace
Typical commands look like...
change floppy0 diskette1.img
sendkey ctrl-alt-delete
eject floppy0
If the floppy images are QEMU raw format, each time the floppy is
changed, QEMU will issue a warning on the console that launched the VM.
Don't worry about it.
========================================================================
WARNING: Image format was not specified for 'diskette0.img' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions
========================================================================
The Install Process
===================
===================
Run the script
./install
when prompted for Diskette 1
Change to the monitor (Click on "View" "Show Tabs" first if required).
In the monitor enter the command "info block" to see what QEMU thinks is
connected. The floppy is the important part. Usually, it's "floppy0".
So enter the command...
change floppy0 diskette1.img
and press {ENTER}. Change back to the install session and press {ENTER}.
The screen changes. Several seconds later, a prompt will appear to
insert Diskette 2 and press {ENTER}.
Change to the monitor
One could manually type
change floppy0 diskette2.img
*OR*
hit {UP-ARROW}
hit {LEFT-ARROW} 4 times
hit {CTRL}{H} once
type the number "2", and submit the command.
and press {ENTER}. Change back to the install session and press {ENTER}.
The "Welcome!" screen appears. We diverge from the straight and narrow.
***WARNING***WARNING***WARNING***
In the sequence that follows
- a prompt will appear to "Please press Ctrl-Alt-Del".
- *DO NOT* press Ctrl-Alt-Del on the host machine; that will reboot
your host.
- The "fdisk" program doesn't know that the system is currently at the
beginning of the install, and requires a bootable floppy in drive A:
before rebooting.
- Don't get any ideas about swapping out the floppy drive early. fdisk
sits on diskette 2, which must be left in, until fdisk is exited.
- instead, do the following...
* Hit {F3} for a command prompt, rather than the default {ENTER}.
* At the A: prompt type "fdisk", and hit {ENTER}
* There should be 2 disks available. Partition each one as a having one
primary partition that occupies the entire disk. Do both virtual
drives in one session, to save time.
* Hit {F3} twice to save and exit
* A red and white notice pops up, saying...
"Drive Letter changed. Please press Ctrl-Alt-Del".
* Do *NOT* press Ctrl-Alt-Del on the host; that would reboot the host
machine. Instead...
Change to the monitor, and enter the 2 following commands in order...
diskette0.img *MUST* be in virtual drive A: when the machine boots at
this time.
* The first 2 floppy-swapping operations (and hitting {ENTER} will repeat
as above. Note that one can {UP-ARROW} 4 times in the monitor to bring
up the command.
* Back at the "Welcome!" screen again. Hit {F3} for command prompt again.
* The next step is to format both drives as HPFS. If D: is not
formatted, it will not be possible to divert any files to it during
the install process.
* The FORMAT command on the install CD is not on the default PATH at
this stage. Similarly, UHPFS.dll is not in any directory in LIBPATH.
But LIBPATH almost always contains ".", i.e. the current directory.
Enter the following commands at the A: prompt
E:
cd \os2image\disk_3
format C: /fs:hpfs (A warning will appear. Type "Y" and hit {ENTER})
format D: /fs:hpfs (A warning will appear. Type "Y" and hit {ENTER})
cd \
A:
exit
Back at the "Welcome!" screen yet again. But this time HPFS-formatted
C: and D: drives are present.
* Hit {ENTER}
* Select "Advanced Installation" and Hit {ENTER}
* The default install drive offered on the next screen, actually the
only valid install drive, is C:. Select "1. Accept the drive", and
hit {ENTER}.
* The next screen offers to format the installation partition, e.g. to
switch between HPFS and FAT. Select "1. Do not format the partition",
and hit {ENTER}.
The automated install process take over. It'll display...
Installing OS/2 Warp 4
A progress bar below it.
After a few minutes
==========================
Remove the diskette and
press Enter to restart the
workstation and continue
the installation.
==========================
Change to the monitor
This time enter the command
eject floppy0
Change back to the install
Back at the install screen, press {ENTER}
The install tries to boot from floppy, and fails, because the floppy has
been removed. Then it tries the hard drive and continues. It takes a
while to boot... *DON'T PANIC*. Approximately a minute later, the
"System Configuration" menu appears.
The System defaults are generally OK. Click "Next" at the bottom.
The next screen is "Additional Hardware Support". Users generally don't
have any of the items listed there, so click "Next" at the bottom.
Next is the printer install screen. Leave it at "Do not install
default printer" for the time being, and click "OK" to dismiss the
dialogue.
Next comes a lot of optional stuff, much of which is nice to have.
***IT IS IMPORTANT TO CLICK ON THE "More..." MENU FOR EACH OPTION THE
USER WISHES TO INSTALL***, for 2 reasons...
1) The "More..." menu allows granular control of features installed
2) The "More..." menu allows many features to be installed on D:
It is strongly recommended on the "Assistance Center" "More..."
submenu, to uncheck "WarpGuide User Interface Agent". This is the
annoying "helpfull" yellow dialogue that tries to assist you. Sad to
say, IBM invented the prototype for "Clippy".
Disable "Optional System Components" totally.
Under "BonusPak", select everything on the left side except for CIM
(Compuserve Information Manager!!!). Note that every item has the
option to install on C: or D:. Set each one to D:.
Under Tools and Games, enable everything except Optional Bitmaps
Under WIN-OS/2 support, some files can be diverted to drive D: from
the "More..." menu.
Under "Multimedia Software Support" "More..." select everything
except Multimedia OpenDoc Support, and force it to drive D:.
Then click "Next" at the bottom.
Next screen, select "Add existing programs to your Desktop"
Then a dialogue with multiple checkboxes. Chose "TCP/IP Services"
for TCP/IP, and "Remote Access Client" if dialup access is required.
The rest will usually be useless, so ignore them. Then click "Next" at
the bottom.
The next screen is "Configuration" for the chosen services.
For "Remote Access Client" chose Installation drive D: and entered the
dialup ISP's phone number. For modem, select "** Any Modem Not In This
List**" unless an old one from the list is attached.
For "TCP/IP Services" choose Installation drive D:. QEMU does use a
DHCP server. Select that option. It assigns...
10.0.2.15 to the Warp 4 client
10.0.2.2 as the outbound gateway, and the IP address of the optional
QEMU tftp server
10.0.2.3 as the DNS server
10.0.2.4 as the optional Samba server
For "Router", specify 10.0.2.2
For "Network Adapters and Protocol Services", change Installation
Drive to D:, and leave everything else as is, i.e.
AMD PCNet Family Ethernet Adapter
0 - IBM TCP/IP
Then click "Install" at the bottom. The install asks for
confirmation. Click "OK".
This brings up a "Transferring files to your hard disk" display, along
with a progress bar. It flashes in and out multiple times as different
items are installed.
The process may display an error dialogue...
====================================================================
An error occured while starting a new session. [DSPINSTL.EXE]:
SYS0318: Message file OSO001.MSG cannot be found for message 00002.
Do you want to retry the operation?
====================================================================
Click "Yes". This is probably due to DSPINSTL.EXE trying to do a
"hardware probe" of the virtual display, and getting confused.
Eventually... "Your workstation will restart shortly". Note that the
bootup process may take a while, especially if the host computer
emulation is slow... *DON'T PANIC* and shut it down. Have a cup of
coffee, or whatever, while waiting for it to come up.
"Setup and Installation" continues, and reboots once more. And the
spinning startup screen comes up. The basic installation is complete.
Click on "Remove this window" at the bottom right.
With all the hard work so far, it would be a shame to lose it. So...
* {RIGHT-CLICK} on a blank area of the screen
* Select "Shut down..."
* Once the prompts are finished, and the display says it's safe to
power off, from the menu of the QEMU window select "Machine ==> Quit".
* ***MAKE A BACKUP COPY NOW*** of os2c.img and os2d.img. In linux...
cp os2c.img os2c.img.000
cp os2d.img os2d.img.000
bzip2 the backups and move them to an external USB drive if space is a
problem on the host machine.
bzip2 -9 os2c.img.000
bzip2 -9 os2d.img.000
Users who don't make backups *WILL* regret it one day.
It is normally launched with the command "./os2boot" (without the
quotes). The "${@}" allows it to include any additional parameters that
were specified on the command line. E.g., to run "Selective Install",
which pulls in files from the OS/2 install CD, the command would be...
./os2boot -cdrom warp4.iso
Boot OS/2 with the command...
./os2boot
Additional tweaks to make OS/2 Warp 4 usable
============================================
============================================
The following assumes that basic networking is functioning in the
OS/2 guest, and that it can fetch files directly from the internet. If
that's not possible, fetch the files on the host, and start the guest
with the command...
./os2boot -drive file=fat:<directory name>
... where "<directory name>" is the directory, on the host machine,
where the desired files have been downloaded to. The named directory
will show up as a FAT-formatted drive. ***IMPORTANT*** the pseudo-FAT
table is read and defined only once, namely when the guest boots up.
Files added later will *NOT* become visible to the guest.
There are some nagging issues that have to be fixed before the OS/2
install is really usable. Here is the process. Note that some of these
tips will not take effect until after a reboot.
Warp 4's "nslookup" program doesn't like the fact that the default
QEMU nameserver (10.0.2.3) does not have a name. "nslookup" refuses to
work. Other network apps appear to work, but I don't know if there are
other problems. To be safe...
* open an OS/2 command window
* enter the command TCPCFG
* select the "Hostnames" tab on the right hand side
* click on "10.0.2.3" in the "Nameserver addresses"
* click on "Change"
The menu allows you to replace 10.0.2.3 with any nameserver that does
return a name for itself. This can be Google's 8.8.8.8 or your ISP's
nameservers. I inserted 192.168.123.254, the internal-facing address of
my ADSL router/modem which identifies itself as "dsldevice.lan". The
router/modem picks up DNS from my ISP. Warp 4 networking will now work
without any complaints from "nslookup".
Click on the notebook icon in the upper left corner, and select
"Close", and then "Save" when prompted. And click "No" to the
"Ultimail" prompt.
Infrastructure
==============
Next is a list of "cascading dependancies".
* 640x480x16 colours is hard on the eyes, and has little screen space
* free+legal video drivers are available but require a fixpack
* both the fixpack and the video drivers come as zip files, requiring
the presence of an unzip program. While we're at the InfoZip site, it
would also be nice to grab their zip and gzip programs.
* many programs are ported from the Open Source linux community, and all
the readme and documentation textfiles seem to be in Unix text format,
i.e. lines end with just {LINEFEED}, not {CARRIAGE-RETURN}{LINEFEED}
like in DOS and OS/2. This does not display properly in OS/2, so a
unix2dos utility is required.
* we need a standard place to put program executables, rather than
extending the PATH statement into infinity.
* since we're going to be editing C:\CONFIG.SYS, let's move the swap
file to D: and make it larger, so that OS/2 isn't constantly growing
and/or shrinking it, negatively impacting program performance.
Create a couple of directories on the D: drive...
D:
MD \BINOS2
MD \SWAPPATH
Make the following edits to C:\CONFIG.SYS
* add D:\BINOS2; to the PATH statement
* change the SWAPPATH statement to
SWAPPATH=D:\SWAPPATH 32767 32767
Save the file and exit the editor. Then exit the command window.
* Remove Artchron the dancing elephant
- Open the "OS/2 System" icon on the desktop
- Open the "Minimized Window Viewer" inside the system folder
- If an elephant icon is present, {RIGHT-CLICK} on it, and select "Close".
This will prevent a "file in use" error when removing.
- In the system folder, click on the install drive, i.e. C:
- Dive down into...
the "\OS2 folder"
the "\OS2\INSTALL" folder
the "\OS2\INSTALL\Installed Features" folder
the "\OS2\INSTALL\Installed Features\Install Object - Inventory" folder
- {RIGHT-CLICK} on "ART - inventory" and select "Uninstall" if available
- Somebody decided to make it more difficult. If "Uninstall" is greyed out
- {LEFT-CLICK} on "ART"
- this brings up a split window
- in the bottom half, check "ART - Inventory"
- in the top half, click on "Uninstall"
- a confirmation dialogue appears; click "Uninstall" again.
- the files are uninstalled, and a prompt appears to shut down and
restart the system
- {RIGHT-CLICK} on empty space in the OS/2 desktop
- select "Close"
- once the desktop says it's safe to do so
- click "View ==> Show tabs" in the QEMU window
- change to the monitor and enter the command
sendkey ctrl-alt-delete
- change back to VGA
The bootup is long, with OS/2 re-organizing itself internally, but
eventually it comes up. Open an OS/2 command window and do the
following...
* enter the command
DIR D:\SWAPPATH
If "SWAPPER.DAT" shows up in the listing, then the old one can safely
be removed to free up some more space on drive C:, with the command...
DEL C:\OS2\SYSTEM\SWAPPER.DAT
* enter the command...
PATH
...and confirm that D:\BINOS2; is part of the path
===============================
Multiple apps will be needed. So let's group them in one subfolder to
avoid cluttering up the D:\ root directory. Enter the commands...
D:
MD \MY_APPS
CD \MY_APPS
MD UNZIP
MD ZIP
MD GZIP
MD UNIX2DOS
The first requirement is UNZIP, in order to be able to extract
downloaded zip files. Assing that the network connection is running,
this can be done directly from the OS/2 VM...
CD UNZIP
ftp ftp.info-zip.org
("anonymous" login)
cd pub/infozip/os2/
bin
dir
download the latest versions. Here's what they were as of the time this
documentation was done...
get unz600.exe
get zip300c.zip
get gz124-32.zip
bye
We're back at the OS/2 command prompt. First, move files to their
proper directories...
MOVE zip300c.zip ..\ZIP
MOVE gz124-32.zip ..\GZIP
Then extract the unzip binary and list the results...
UNZ600
DIR
Note the "32-bit" subdirectory. Issue the command...
COPY 32-bit\*.EXE \BINOS2
Now execute the command...
UNZIP -h
...and the UNZIP help screen should appear. We now have a working unzip
implementation that can be called from anywhere. But the documentation
text files are all in unix format. "tedit" loads these files properly,
but loading documentation files into a text editor poses obvious risks.
So we need to get a dos2unix implementation up and running immediately.
The commands are...
CD ..\UNIX2DOS
ftp hobbes.nmsu.edu
("anonymous" login)
bin
cd pub/os2/dev/util
dir dos2unix* (Yes, it's counterintuitive. The latest version at the
time of writing was 7.3.2. The Watcom compiled version,
i.e. dos2unix-7.3.2-os2-watcom.zip, is a lot smaller than
the regular version, so let's download that)
get dos2unix-7.3.2-os2-watcom.zip
bye
Back at the OS/2 command prompt
UNZIP *
DIR
The results include
- a "readme.os2" file
- a documentation directory share\doc\dos2unix-7.3.2
- a bin directory with files...
- dos2unix.exe
- max2unix.exe
- unix2dos.exe
- unix2mac.exe
So once again, copy the executables to D:\BINOS2
COPY bin\*.EXE \BINOS2
There are a whole slew of options covered in "dos2unix.txt". For
first-time users the most important ones are the "-n" ( --newfile ) and
the default "-o" ( --oldfile ) options. The commands...
...will leave the original files untouched. ***WILDCARDS WILL DESTROY
SOME FILES. DO NOT USE WILDCARDS WITH THE "-n" OPTION***. The "-n"
option obviously requires exactly 2 arguments; the original file, and
the new modified version that will be created. Ironically, the first
invocation of unix2dos is to run unix2dos on its own documentation...
CD SHARE\DOC\DOS2UNIX-7.3.2
UNIX2DOS *.txt
This rectifies all the text files in the unix2dos documentation
directory. Next is the documentation for unzip...
CD \MY_APPS\UNZIP
UNIX2DOS COPYING.OLD LICENSE README WHERE *.TXT
* the zip and gzip programs need to be extracted to their directories,
executables copied to D:\BINOS2, and documentation set to DOS mode
CD ..\ZIP
UNZIP ZIP300C.ZIP
COPY *.EXE D:\BINOS2
UNIX2DOS README WHATSNEW WHERE *.TXT
Open an OS/2 command window and create directory C:\OS2SERV
c:
md \OS2SERV
cd \OS2SERV
ftp
open ps.boulder.ibm.com
("anonymous" login)
cd /ps/products/os2/rsu/xr_m015
bin
prompt
mget *
bye
This will download everything you need, totalling 26,192,246 bytes in 20
files. Once this is done run:
unzip csf143.zip
md os2serv
(Yes - that is right - this will make an 'OS2SERV' directory under the
'OS2SERV' directory)
cd os2serv
unzip ..\f*.zip
unzip ..\x*.zip (select 'A' for All when prompted)
cd ..
os2serv
This will start the FixPack installation program - you should then
* Click on "C:\OS2\INSTALL\SYSLEVEL.OS2 XR04000 5639A6100..." in the
"Serviceable Products" area.
* Click on the "Install" button.
* A prompt will ask which drive to archive on. Select D:, because it
has more space, and press "OK".
* The process takes a few minutes, or more, depending on the speed of
the host system. Press {CTRL}{ESC} and select FSERVICE.EXE to if you
want to follow the "Progress Bar".
* Whether or not you follow the progress bar, the Fixpack will
eventually finish and pop up a dialogue saying...
=============================
Installation complete. Please
shutdown the system and reboot.
=============================
Shutdown and reboot the guest. In order to confirm that the FixPack is
installed, open an OS/2 command Prompt window and run 'SYSLEVEL' and
check the Base Operating system level; it should be 'XR0M015'.
Assuming it worked, it's safe to remove the Fixpack 15 install files,
to free up approximately 50 megabytes on drive C:. The quickest and
safest approach is to open the C: drive from the "Drives object", select
the C:\OS2SERV folder, and click on "Delete"
After this, it's time to shut down OS/2 and back up again
In linux...
cp os2c.img os2c.img.002
cp os2d.img os2d.img.002
bzip the backups and move them to an external USB drive if space is a
problem on the host machine.