VOICE Home Page: http://www.os2voice.org | April 2003 [Newsletter Index] [Previous Page] [Next Page] [Feature Index] editor@os2voice.org

## An Adventure with LVM, a Multi-boot System,and Cloning the Operating Partitions

By Peter Hinckley© April 2003

If you're like me, you're an OS/2 user who's stayed with it because of its rock solid reliability and relative freedom from the upgrade treadmill. Unlike the average Windows user, you've acquired a fairly good grounding in the system's workings and how easily it can be configured to do what we, the users, want it to, rather than what some programmer off in operating system wonderland has decided is good for us. This article is an attempt at describing one user's tribulations installing, configuring, and moving existing system installations to a new, larger primary master IDE hard drive for those of us who don't do this sort of thing often enough to become system engineers, intimately conversant with the process.

My primary master hard disk drive, D1, was a 10 gig Western Digital IDE, on which I had installed Warp v4.50, upgraded to FixPak 15. Several months ago, I upgraded this to Warp 4.52 from SWC, and just recently, I became interested in experimenting with Linux. This already was a multi-boot set-up (OS/2, DOS 6.22, and W98, see figure 1), and I thought all I had to do was to resize a few partitions in order to make room for the new OS. After all, that is what I had done with FDISK and Partition Magic when I set up the drive a couple of years ago. However, the new OS/2 disk management program, Logical Volume Manager, which comes with v4.51+ and eComStation, consistently refused to commit ("write") changes to the MBR. I was stuck, faced with a complete re-partitioning of the disk and reinstallation of everything on it, a tremendous re- creation job. Since the local computer store was having a sale on new hard disks, I decided to install a new D1 and "clone" everything from the 10 gig disk.

Before proceeding any further, it's time to clarify the definitions of a few terms, some of which are used here, and some which are deliberately avoided. Hard drive, drive x:, disk, primary master, primary slave, primary partition, extended partition, logical partition, volume, compatibility volume, LVM volume, spanned volume -- it all gets very confusing because these terms tend to be used somewhat interchangeably and synonymously when they really shouldn't be.

A hard disk drive is a self contained unit with several platters and read write heads, hereinafter a disk. This is divided up into areas called partitions, which are [usually] assigned drive letters by the operating system. Partition managing tools like LVM will number all the disks they find in the system as disk 1, the first disk (abbreviated "D1") and disk 2, the second disk ("D2") and so forth regardless of whether they are IDE, SCSI, or PCMCIA (sorry, I have absolutely no experience with USB disks). With mixed systems (IDE + SCSI etc.) it's a bit difficult to say ahead of time which disk will be assigned which number because this is dependent on the hardware and system configuration.

With the IDE interface, there are typically two IDE controllers (sometimes called "channels") on the motherboard. Each controller can operate two hard disks, one of which is called a "master" and the other a "slave", making for a maximum of four disks, excluding of course any connected to an expansion card. These are called the primary master, shown by LVM as D1 (disk 1), and the primary slave, listed by LVM as D2 (disk 2). LVM calls the secondary master and secondary slave, D3 and D4. With the SCSI interface, D1 is the boot disk as determined by the how the system BIOS and the SCSI BIOS have been configured, "among other things" (LUN for the boot disk, LUN for the SCSI controller, presence of other SCSI controllers, etc.). No matter the inter-face, D1 is the first disk in the system. Some texts call D1 the "first drive", but it's the same thing.

This is the scheme I use herein: D1 for the first disk, D2 for the second, etc., rather than master/slave. My system uses two IDE hard disk drives on the first IDE controller, one CDrom on the second, a SCSI ZIP 100, and a PCMCIA card reader. LVM identifies the two IDE drives as D1 and D2, with D3 being either the ZIP or the PCMCIA reader (with a CF card inserted), with which ever isn't D3 becoming D5. It depends on which is inserted first and when I click on Refresh Removable Media. D4 appears to be the CDrom drive, but it doesn't matter for the purposes of discussion here.

In the world of LVM, one needs to think less in terms of "Drive C:", "Drive D:", etc. and more of the hard disk drives as being disk 1, disk 2, etc, in whatever order LVM finds them in the system.

Figure 1, pre-LVM Partition Magic 3.03 view of the Western Digital 10 gig drive as "D1". Boot Manager is the 3rd primary partition.

### Planning your adventure

Research on the internet and in a few books provided a basic outline of what I needed to do in order to set up the new hard disk: the Master Partition Boot Record is set up to describe a maximum of 4 partitions. One of these can be an extended partition, which is a device used to enable defining a series of logical partitions through a linked chain of logical partition tables (the maximum number of logical partitions allowed depends primarily on how many a given operating system can see). Practically speaking, this means that for a multi-boot system, there is a maximum of three usable primary partitions per drive, and the various operating systems have differing constraints on what can be placed on what kind of partition. DOS-based operating systems (DOS, Windows) are very particular; they insist on being installed on the first active primary partition on the first disk. Linux is a little less picky: it wants only its /boot directory to be on D1 or D2 (see further explanation below), while OS/2 v2.1x and up can reside 100% on a logical partition (constraints on OS/2's location have decreased with the progressive upgrading of version and fixpak levels -- today's OS/2 can be almost, but not quite, anywhere). Boot Manager must be on a primary partition on D1 or D2. Thus, I had to be careful to make sure everything got placed on the partition of its particular preference.

So I settled on this scheme: the first primary partition would be Boot Manager; the second, Windows; the third one Linux /boot (this turned out to be incorrect -- I had mixed up Linux' requirement for "below the 1024 cylinder limit" with "primary partition", see Windows, DOS, Linux, and OS/2, below), and the fourth would be the extended partition "container" for the logical partitions, two of which would be the OS/2 ones while the rest would be a varied collection of FAT16, HPFS, JFS, and ext3 (the new journaled version of ext2, the Linux file system).

I also discovered why I couldn't re-arrange the partitions on the 10 gig disk: using DFSee and it's excellent customer support revealed that this state of affairs was the result of boundary errors in the extended partition table.

Jan van Wijk explains it this way: partitions are described using two methods, CHS (cylinder-head-sector, "start here and end there"), and LBA (logical block addressing, linear mode, "start here and go this far"). Both methods are always present in the partition table, and they need to be synchronized with each other. Most modern disk tools look only at the LBA information, ignoring CHS values, but the ones which look at both, like LVM, will refuse to do anything if the two are out of sync, except to delete partitions. Conflicts between the CHS and LBA information can be caused by a number of things. Among them are changing drive geometry in the BIOS, changing motherboards, or changing disk drivers. CHS can't handle drives larger than 8 gb because there is no way to describe a cylinder number greater than 1023 in the space allotted to
do so.

Over the years, I had tweaked the BIOS settings for the drive, changed motherboards (upgrading from an Asus P2L97 to an Abit KT7E), and done some partition reconfiguration with PQMagic. Regardless of the cause, LVM found errors and wouldn't write changes to the disk, including "LVM /NEWMBR:1", which is supposed to fix MBR problems.

It was this state of affairs which decided me on buying a new hard disk and cloning the existing set-ups to it. I should point out here that "cloning" has nothing to do with DFSee nor it's CLONE command. While I did use DFSee, it was to re-assign a drive letter and troubleshoot some problems, and not in connection with transferring the configurations of the 10 gig disk. DFSee is quite a set of disk utilities and worthy of a separate set of articles. The new disk's partitions have the same sequence and drive letter assignments as those on the old one (except for the very last partition). If the receiving partitions are to have different drive letters, it's necessary to change all drive letter references manually in all the system in individual ini files to reflect the change, which is a very time consuming and tedious process. For further information on moving OS/2 applications to a different drive letter see the Southern California OS/2 User Group's Know It All page: http://www.scoug.com/os24u/2003/scoug302.mrkia.html. I cloned only one C: partition, the one for Win98. If there are other primary bootable partitions on the new disk, and you're cloning a DOS-based OS, you must hide the ones which you aren't cloning to.

For the future D1, I bought a 40 gig Maxtor IDE hard drive and connected it temporarily as D2. Using LVMGUI, and not the Maxblast program supplied by Maxtor, I created the following primary partitions (see the bar graph for D1 in figure 2):

    Boot manager, 1 cylinder (created as free space)
    C:, 2 gb FAT16, for W98
    and these logical partitions:
    ?, ext3 78 mb (light gray), Linux /boot
    2929, ext3 (gray), Linux /root
    D: HPFS, OS/2 operating
    E: HPFS, OS/2 maintenance
    F: FAT16, common data between OS/2, W98, and Linux
    G: HPFS, OS/2 programs and data
    8401 MB, ext3 (gray) Linux
    16 MB, (gray) Linux swap
    H: HPFS, data
    M: HPFS, data

Figure 2, LVMGUI view of the Maxtor 40 gig drive as D1, after partitioning, configuration, and connection as IDE0, the new primary master. D2 is the same one used with the 10 gig drive (and not shown in figure 1) and consists of data partitions. Boot Manager is now the first primary partition on D1. The future Linux /boot partition is highlighted.

### OS/2's Logical Volume Manager

LVM is silent about creating extended partitions and doesn't display them (PMagic shows them, see figure 1). The Linux partitions were actually formatted and installed after the screen capture for figure 2 was made, so those partitions appear as unformatted (light gray).

Almost all personal computer operating systems use the same scheme for organizing hard disks: dividing them into areas called partitions. LVM.EXE (PM version: LVMGUI.EXE) is OS/2's new wrinkle for managing disk drive partitions and replaces the time-honored FDISK.EXE. It can be a bit mysterious at first glance if you're used to FDISK and fixed drive letters.

When installing or upgrading to v4.51+ or eCS, LVM must be used to add its special information to all hard drives in the system. You can do this yourself or allow it to be done automatically by VCU.EXE, which has pitfalls if your hard disk drivers aren't current enough to see the new, larger drive properly (see below). There is no choice; these versions of OS/2 must have LVM-converted partitions. Non LVM-aware operating systems (OS/2 v3, OS/2 v4.50, Linux, DOS, Windows, etc.) won't be adversely affected by this change. They can't see the LVM information and will continue to assign drive letters to the partitions according to their own internal specifications, just as they always have. Only LVM-aware OS/2 and eCS will recognize any manual drive letter assignments and spanned volumes made using LVM. Since it replaces FDISK, attempting to run [OS/2's] FDISK on an LVM-ed system will advise you to use LVM.

DOS, pre-LVM OS2, and Windows systems assign each partition a drive letter automatically, starting with C:. With LVM-aware OS/2, LVM writes special information into unused space at the end of the MBR track which OS/2 uses to determine drive letter assignments. Except for primary partitions, a drive letter is no longer necessarily one specific partition. In addition, a drive letter can be assigned "manually" to a partition regardless of where it appears in the actual sequence of partitions on the disks in the computer (within certain limits - CDROM drive letters can't be assigned by LVM, although they can be reserved). You can also create a spanned volume, consisting of several partitions on more than one disk, and assign a single drive letter to the assemblage. In other words, drive letters can represent separate partitions just as they always have (called "compatibility volumes"), or they can serve as a signpost pointing to "drive x:" which can consist of several disk partitions on more than one disk (called an "LVM volume"). LVM-aware OS/2 doesn't care what a drive letter is (or where the pieces are) as much as what it's called.

It's also necessary to be careful that any boot disks you use for conversion to LVM (or if cloning, the operating partition you are working from) have updated drivers, i.e. drivers which will recognize the geometry of the new disk correctly, or the partition tables can be destroyed. Jan van Wijk advises that it's possible to recover should this happen, but it's a complicated process. He recommends booting from floppies which have the newest drivers available and running LVM.EXE create the LVM information rather than rely on VCU.EXE, or to use the VCU implementation in DFSee, and then proceed with the installation. My experience was that since I had installed Daniela Engert's most recent drivers, I was able to partition the new disk without any problems booting OS/2 from my old D1.

OS/2's LVM shouldn't be mixed up with the logical volume manager which comes with Linux, also called "LVM" in order to avoid confusion, because even though it can create spanned volumes too, the results aren't compatible. For further details about OS/2's LVM, see pages 13 and 53 in INSTALL.PDF found in the the directory \books\pdf in the eCS and SWC CDs . USINGLVM.PDF describes the LVMGUI interface. "HELP LVM" at a command line will display LVM help, but it needs translation for us mere mortals.There is also a good discussion of LVM by Bob Eager at: http://www.tavi.co.uk/os2pages/lvm.html. Alex Taylor is working on a redesigned graphical interface: http://www.cs-club.org/~alex/os2/lvm/redesign/index.html.

Once your disks have been converted to LVM, it's not advisable to use other disk partition managers to change partitioning information (OS/2's FDISK, DOS/Windows FDISK, Partition Magic, Linux' partition managers, etc.) unless you really know what you're doing. It's possible to use them to manipulate partitions, but since they don't update the special LVM information, OS/2 won't be able to detect the altered configuration. It's then necessary to update the LVM information separately, which can be tricky (see Overby, http://www.os2voice.org/VNL/past_issues/VNL1100H/vnewsf5.htm and Eager, above).

Resizing partitions on an LVM system essentially consists of adding or subtracting disk partitions from LVM volumes rather than increasing or decreasing the size of the individual partitions. With JFS partitions, this can be done anytime, so to speak. You can add a partition (unformatted or JFS formatted) to a JFS LVM volume at any time without destroying data already on the volume. However, with HPFS and FAT formatted partitions, partition spanning must be done at the time the partitions are created; it can't be done afterwards (see the IBM pdf files and Eager for more details). So with non-JFS volumes, resizing means backing up everything on the partitions you are going to manipulate, using LVM to make the desired changes, and then restoring from the back-up. Spanned partitions are visible to LVM-aware OS/2 and eCS only.

Drive M: (figure 2) illustrates LVM's capability for assigning drive letters manually. My system had a great many shadows pointing to items on drives I: and J:, which are on D2. By assigning the last partition on D1 drive letter M:, these links were preserved, avoiding a great deal of tedious re-creation work.

After creating and formatting the various partitions, I ran `SYSINSTX x:` against the two future OS/2 operating partitions to transfer the system files, followed by `XCOPY x:\*.* y:\ /H /O /T /S/E /R /V` to transfer all other files and directories, where x is the OS/2 partition you are cloning from and y is the partition on the new disk. Except for not using the SYSINSTX step, the process is the same for data partitions.

### Boot Manager

Since LVM permits only one copy of Boot Manager on any of the disks in a system, it was necessary to disconnect the 10 gig disk, change the 40 gig to D1, boot from floppies, and run "`LVM /BOOTMGR:1`" on a command line. Boot Manage insisted on being installed with its partition as unformatted free space. After this, it was necessary to run LVM.EXE from the floppies to make the final adjustments: assign the correct drive letters to the new OS/2 partitions and add them to the BM menu. The last step was to reconnect the old 40 gig D2 hard disk.

The Boot Manager partition doesn't necessarily need to be the first one on a disk (see figure 1); it can even reside on the second disk. However, it must be a primary partition, and it must be the only startable partition in the system.

Figure 3, LVM.EXE (command line) physical view of D1, equivalent to the bar graph for D1 in figure 2, made after installing Linux, and converting drive M: to JFS. This illustration is a paste-up made using PhotoTiger and two PMView screen captures.

### Windows, DOS, Linux and OS/2

Research also uncovered a Win98 version of the process: disable virtual memory, run the Windows version of SYSINSTX against the new partition, followed by the Windows version of XCOPY. You must have sufficient memory for doze to run without using a swap file. First I formatted the drive to FAT16 under OS/2 -- Win98SE changed this to VFAT, enabling long file names. Then with x being the new partition: with the existing drive C:, boot Windows; run `SYS x:` in a DOS window to install the system files; then go to Control Panel->System->Performance-> Virtual Memory->check the "Disable Virtual Memory" box. At this point Windows will warn you about potential problems with trying to run without virtual memory, which is why you must have enough RAM. Then reboot and run XCOPY: Start->Run and enter `XCOPY c:\*.* x:\ /c /e /f /h /r /s`. You must run XCOPY with Start->Run because this uses XCOPY32.EXE, which can read and write the long file names. Be sure to turn virtual memory back on when you're done.

Before finding this trick, I tried using OS/2's XCOPY, which worked after a fashion. The resulting W98 partition booted to safe mode a few times before booting normally. Each time it proudly announced finding all the "new" devices connected in the computer, but there were no links to any of the previously installed programs.

With Win's addiction to the first active primary partition on the first disk, it was necessary to boot the 10 gig disk as D1 and clone it to the new 40 gig disk as D2, with the new Win partition being assigned a drive letter automatically; then disconnect the 10 gig disk; reconnect the 40 gig disk as D1; boot OS/2; and use LVM add it to the Boot Manager menu.

The DOS 6.22 partition on the 10 gig disk wasn't cloned because I planned to experiment with Linux (Red Hat 8.0). With Linux, there are no drive letters. Each IDE hard drive partition is identified with the terminology "/dev/hdln" with l being a letter representing the individual disks (D1 is hda, D2 is hdb, and so on) and n being the partition number on drive l. /dev/sdyn are SCSI drives, where y is the SCSI disk number and n the partition number on disk y. In a sense, OS/2's LVM is midway between FDISK and Linux' world of no drive letters. It manages the partitions without using drive letters, but it provides them because that's what OS/2 needs in order to function.

Most, if not all, distributions of Linux require the /boot partition to be below the 1024 cylinder limit on drive 1 or 2, unless your BIOS has the LBA32 extension (most BIOSes after 1994 can do this; however if you're not sure, Bob Eager has written a small program which can be used to test your BIOS, located at: http://www.tavi.co.uk/os2pages/extdisk.html). This is what shoved DOS 6.22 off the 40 gig disk (or so I though because of my confusion over "below the 1024 cylinder limit" and "primary partition" with respect to Linux). If you're adding Linux to a multiboot system which includes LVM-aware OS/2, don't allow Linux' partition managing programs to make any modifications to the MBR (in other words, don't use them), and put the boot loader (GRUB, LILO, etc) in the Linux /root directory. Otherwise, the MBR can be corrupted to the point where LVM and Boot Manager won't be able to use it, creating serious problems for OS/2. After adding to the Boot Manager menu, RH 8.0 shows no drive letter because none is used.

LVM-aware BM hides primary bootable partitions slightly differently than the old version does. With the old BM, all you had to do was select which system you wanted to boot, and the other was hidden automatically. This isn't the case with the new BM, so for those systems which can't see the LVM-assigned drive letters, in order to boot one C: or another, it's necessary to use a partition table editor, like DFSee or AirBoot, to change the partition types manually so that the one you're booting is active and the unused ones are hidden. For OS/2, there can be only one partition per letter -- only one drive C:, not an active C: and hidden ones. To see a particular partition as drive C:, it's necessary to re-assign the drive letters manually (i.e. remove C: from one partition and apply it to another).

When I installed Warp 4.52, the DOS 622 partition happened to be active, and as a result, OS/2 could never find the Win98 one (even if I booted Win98, shut down, and booted OS/2 right afterwards). In order to change this, the C drive letter assignment had to be removed from the DOS partition and reassigned to the Win one. LVM wouldn't do this (those boundary errors again) so I had to use DFSee in fdisk mode with this set of commands:

>      -w+ -Q lvmset -B 1 -l- #lvmset -B 2 -l:C

which say essentially, "turn on windowed mode, quit after the last command is completed, delete the letter assigned to partition 1 on drive 1, the next command is: apply the letter C to partition 2 on drive 1". After this, OS/2 would see the Win98 partition as drive C: but couldn't see the DOS one anymore. To make the DOS partition visible again, this series of commands would have to be re-issued, suitably modified to remove the C from partition 2 and assign it to partition 1.

A bit tedious if you're used to the older method, but necessary because of the new ways of hiding and unhiding partitions and the manually assigned LVM drive letters.

I recommend DFSee quite highly. I finally bought a license after looking at it every now and then over the years and being quite a bit mystified by its complexity. It comes with first rate tech support. Be very careful using it, though, while it can save the day in sticky situations, you can inadvertently make changes which can lead to disaster.

I recommend DFSee quite highly. I finally bought a license after looking at it every now and then over the years and being quite a bit mystified by its complexity. It comes with first rate tech support. Be very careful using it, though, while it can save the day in sticky situations, you can inadvertently make changes which can lead to disaster.

All the operating partitions now work exactly as before with the 10 gig disk, wall papers, applications, shadows (and shortcuts), and all. The 10 gig disk is now IDE0 in a second box, which I have set up for tinkering with hardware and configurations.

After getting things up and running, I converted drive M: and all the partitions on D2 to JFS and set up two partition spanning LVM volumes in order to reduce the number of drive letters on my system in anticipation of setting up a home network. Figure 4 is an LVMGUI view of this reconfiguration, and figure 5 is a LVM logical view.

Figure 4. LVMGUI view showing revisions for partition spanning with drives I: and J: as LVM volumes. I: spans the first two partition on D2, while J: spans the last partition on D1 and the last two on D2. The details listed at the bottom of the window change in sequence depending on which partition is highlighted (in this view, the last partition on D1 has been highlighted). D4 is my Zip 100 drive (SCSI).

Figure 5, The equivalent LVM.EXE logical view showing D1 with drive J: highlighted. The upper box is equivalent to the bar graph for D1 in figure 4, and the lower box to the partition details at the bottom of the gui view.

The only LVM-aware alternative to Boot Manager I've come across is AirBoot, a Netlabs project: http://air-boot.netlabs.org/ I've also seen sites advertising boot managers which claim to be able to start any operating system from any partition, like V-Com's System Commander, which I tried several years ago but found rather cumbersome. However, the majority of these don't say much about OS/2, and when they do, not a word about LVM-aware OS/2. Since BM manager has suited my needs so far, I've not tried any others (yet).

### Step-by-step recap

After wading through the this process, shuffling the 10 gig and 40 gig disks back and forth between D1 and D2 a few times before getting a good grasp of how to use LVM and in what sequence to do things, I'd like to recommend the following set of guidelines (be sure to turn off the computer and disconnect the power cord when unplugging and plugging in the drives):

1. Carefully lay out what you want to do.
2. Identify what needs to be primary, what can be logical, and on which disk.
3. Install the new disk as D2 or higher (i.e. not as D1).
4. (Recommended by Jan van Wijk) Make a set of boot/installation floppies equipped with the latest drivers and use these when running LVM in step 5 in order to be sure the correct geometry of the hard disk is detected. Be sure theses floppies can see the new disk properly before continuing.
5. (an alternative to 4) Unless the drivers in the old operating partition can't recognize the new drive, boot from your old partition and use LVM.EXE or LVMGUI.EXE to create the partitions.
6. Format the partitions with the appropriate file systems.
7. Install the system files to the operating partitions (`SYSINSTX`).
8. Clone all partitions (`XCOPY /H /O /T /S /E /R /V`). After this process has completed, if you have any doubts about the drivers from the old disk being able to read the new one properly, it's a good idea to go into the \OS2\BOOT directories on the new disk and update them and make any necessary modifications to config.sys before continuing any further. If you are using 3rd party drivers, they can either be renamed or the necessary statements in config.sys modified (I use Daniela Engert's divers without renaming them in order to make it easier to keep track of system modifications -- DaniDASD.DMD doesn't work on LVM systems).
9. Disconnect the old disk and move the new one to D1.
10. Boot from floppies and use LVM to install Boot Manager, assign proper driver letters, and set up its menu.

Everything should now be ready to go.

All screen shots made with PMView and edited using PhotoTiger.

Master Partition Boot Record - This is frequently shortened to Master Boot Record, "MBR". It contains the Master Partition Table and the Master Boot Code.

Boot Manager Note - Prior to v4.50, BM's primary partition had to be specifically on D1.

LBA32 extension - This is another name for the BIOS interrupt 13 extension, which is also frequently written as int13x, and further abbreviated to I13x.

References: Eric Baerwaldt's 3-part series Partitioning Hard Drives Under OS/2: http://www.os2voice.org/VNL/past_issues/VNL1001H/vnewsf2.htm http://www.os2voice.org/VNL/past_issues/VNL1101H/vnewsf7.htm http://www.os2voice.org/VNL/past_issues/VNL0702H/vnewsf6.htm Eric Overby's article on disk partitioning: http://www.os2voice.org/VNL/past_issues/VNL1100H/vnewsf5.htm Michal Necasek's article on LVM and JFS: http://www.os2voice.org/VNL/past_issues/VNL1100H/vnewsf4.htm Bob Eager's discussion of LVM: http://www.tavi.co.uk/os2pages/lvm.html#define previous vnewsf4.htm EXTDISK: http://www.tavi.co.uk/os2pages/extdisk.html DFSee : http://www.dfsee.com AIR-Boot: http://air-boot.netlabs.org/ Southern California OS/2 User Group's Know It All page: http://www.scoug.com/os24u/2003/scoug302.mrkia.html Bibliography: "Upgrading and Repairing PCs", by Scott Mueller, QUE, Indianapolis, IN, 8th ed 1997 and 13th ed 2002 (the 13th has less information regarding HPFS than the 8th). "The Multi-Boot Configuration Handbook", by Roderick W. Smith, QUE, Indianapolis, IN, first printing, April, 2000 I would also like in particular to express my gratitude to Jan van Wijk for his ongoing patience in answering my dumb questions.

[Feature Index]
editor@os2voice.org
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org