Re: Problem after converting FDisk Partitions to LVM



Hi Mike,

apparently my post was slightly mistakable. The issue I was reporting about was, that my 2 freshly installed W4.0 partitions didn't boot up anymore, after the eCS beta was installed and changed FDisk to LVM in the process.

At the moment I'm about to recreate the situation and then additionally install the beta again, to get the exact wording of what the installer/LVM was saying about the converging process from FDidk/BM to LVM/BM to respond back to Alex T.

I wasn't trying to migrate an existing, over time matured W4 system to eCS, rather than trying to learn about the shortcomings of the latest FDisk and potential dangers in possibly switching my W4 FP16+ box to LVM, in order to install and boot additional OS' from HDD areas beyond FDisk's (14.056/082) limited abilities.

And from the outcome of my first test round, leaving the 2 W4.0 partitions unbootable after LVM took over, disaster is closer than assumed.
Or earlier, when FDisk screwed up, while creating a messed up partition table, when it eagerly seemed to be able to handle logical installation partitions, reaching slightly beyond the magic 8032MB border. As a result, neither FDisk nor LVM could deal with the mess anymore, so I had to erase the partition table with a tool from the HDD manufacturer by writing "0" to the disk.
Thank goodness, it's still just a test disk, at least for now.


Am 30.04.07 13.08 schrieb mike luther:
Quick summary of a lot of past work here..

Wolfi wrote:
Does the conversion (or what exactly it is called) of existing W4 FDisk partitions through LVM depend on a specific fix level on them or is it supposed to be successful on fresh vintage W4.0 installations as well?

For evaluation purposes I had created a few partitions with Warp4.0 and FDISK 14.082 on an empty test HDD and installed 3 instances of unfixed W4.0 on it. One in a primary, the other 2 in an extended partition still smaller than 8032MB.
Then I added eCS2.0b3 to the extended one beyond the 8032MB limit, which offered to modify the existing W4.0 partitions to be usable with the LVM boot manager instead.

Now when I try to boot any of those W4.0 partitions, rather than seeing the white boot blob of that selected system, I only get to see a black screen with a blinking under score and that's it.

So first question:
- does the replacement of FDisk through LVM depend on a certain fix level on those existing FDisk W4 installations.

- if not, how can I recreate the partition boot sector of those W4.0 partitions?

Trying to upgrade Warp 4 to MCP level code only worked reliably for me under two conditions.

A.) The Warp 4 box was at Fix Pack 15 level with all the at that time upgrades for everything from PEER to MPTS and TCP/IP in place. That also includes all the as of that time Device Drivers from at least a level two version for disk work and so forth. Recall that the device driver updates were separated out of the formal OS/2 Warp 4 Fix Packs. And in no case, per what I found should any of this ever be attempted on a level 12 system or earlier!


B.) As cautioned by IBM, the conversion from Warp 4 to MCP first has to be done with a move to MCP1, followed by the Fix Pack 1 for MCP1 under certain conditions. The conversion to LVM which is a part of the MCP1 install only was supported and, per what I understand, works properly and interfaces with the other needed code with it. It does not work properly with MCP2.


I didn't try this at all with eCs. At the time I spent many hours researching and then doing this on many boxes, it was admitted that the eCs tool set did not and would not work through the conversion process with the collection of things installed on your desktop, many changes made to your CONFIG.SYS file, development tools installed like VAC++, the IBM Developer Tool Box and on and on and on. I couldn't afford even more time to work with yet another layer of interface issues beyond all this, thus the time to research eCs was, and up until now has remained beyond me. This is no criticism of eCs, please....


The conversion to MCP1 from Warp 4 also means you must move the whole desktop operation from Warp4 to the new MCP1 desktop. This means hand migrating the folders, applications and the whole user added works to the bare OS/2 install. But that is *NOT* the same thing as re-installing everything. It does mean you must be very careful about keeping track of every step of the process so that you don't mistakenly delete something without getting it moved to the new MCP1 desktop so that the exact same interface functionality is assured.


Then, sigh, you must go through the very same process AGAIN to convert the MCP1 system to MCP2, including the whole hand move desktop game all over again! Only after extensive use to prove you are where you want to be, in my opinion, should you kill off the Previous Desktop. Which if you have carefully moved, verified operation in the new arena, and are darned sure you have got it right, you will have deleted the old Previous Desktop object, thus leaving the Previous Desktop back to the pristine object it was when you started this whole diamond studded life you had with Warp 4.


In the process anyone who goes down this pig trail had better have and use Checkini, Cleanini, Unimaint or whatever over and over to assure that the whole OS/2 INI operation remains stable in the process - at least as I went through it and saw all this.


Further, in no case have I ever tried to work with OS/2 on a hard disk with any other operating system jointly installed on it. Thus the LVM issue and compatibility of the boot system with other operating systems is totally out of my experience level. I've avoided ever thinking about multiple operating systems except the possible use of virtual system hosting. Used mobile drive trays in a few cases to accomplish this and networking to connect things.


I would really be interested in whether eCs can migrate a Warp 4 system now that it is up to 1.24R and headed for version 2.0. I actually have a proper paid for copy of 1.24R here never used, but reserved for 'what if' should that be the way needed toward a future. Thus if you can provide detailed information on that vector, I'd appreciate you posting your findings!


Thanks!
.



Relevant Pages

  • Re: Windows kill Linux?
    ... Now during every install after CD1 ... a dual boot with Windows. ... Windows can not detect ext3 partitions. ...
    (alt.os.linux)
  • Re: which 64 bit Linux distro for best OS/2 eCS compatibility?
    ... Is this applicable even to an ACPI driven system? ... configuration information that can be used as a goal for the eCS ACPI ... bootable JFS partitions with eCS RC2 and RC6a respectively, ... install a 64 bit Linux distro on additional JFS partitions and to boot it ...
    (comp.os.os2.misc)
  • Re: Install hangup....
    ... you at a download for it - perhaps boot into the livecd desktop and run ... fsck on your created partitions? ... setup your partitions before you run the install, ... I did the memory test and found some interesting little tidbits about this computer.... ...
    (Ubuntu)
  • Re: dual boot with windows xp question
    ... I have a book that explains how to install an older ... It said I have to make a boot disk. ... he should not attempt to create Linux partitions with Microsoft ... He should leave the space intended for Linux unpartitioned. ...
    (comp.os.linux.setup)
  • Re: Windows kill Linux?
    ... Now during every install after CD1 ... a dual boot with Windows. ... Windows can not detect ext3 partitions. ...
    (alt.os.linux)