VOICE Home Page: http://www.os2voice.org
[Newsletter Index]
[Previous Page] [Next Page]
[Feature Index]
|
VOICE Home Page: http://www.os2voice.org |
April 2003
[Newsletter Index]
|
| 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.
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
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:
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
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.
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:
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).
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).
All screen shots made with PMView and edited using PhotoTiger.
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:
|
[Feature Index]
editor@os2voice.org
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org