The only thing that remained the same was the two hard drives.
Everything else changed. I had read that linux just loves being
upgraded, so I figured what the heck.
With my Ubuntu install, I didn’t have to set any hard disk controller
drivers to a default or anything like that. I simply assembled the new
machine, transplanted the hard drives to the new puter, configured the
BIOS, and let ‘er rip! The machine booted without a hitch, and this was
an “Ancient AMD to Modern Intel” type of upgrade. The only problem I
had was that it didn’t want to detect the new ethernet controller.
Rather than fighting with it by trying to install an ethernet driver
without a net connection on the box, I just plopped an old ethernet card
in a spare PCI slot, rebooted, et voila! The ethernet was
autoconfigured and I was 100% up and running again.
====================
http://www.linuxjournal.com/article/8219
====================
Hardware either works or does not work. Two pieces of hardware are
either compatible or icompatible. This is the rule. However, when the incompatibility-gap
between the two pieces of hardware is small, there is almost always a
way to make these two pieces work together as if they were fully
compatible. This generally involves the use of one of the various types
of adapters or converters. But, it may happen that the adapter is not
100% compatible with the rest of the hardware! So, what comes next in
such cases? An adapter for the adapter maybe? Fortunately, in my case it
was a small piece of software that came to the rescue and saved my day.
[...]
Under such complicated conditions, the only way to install a Linux
distribution on a hard disk of newer technology than my old Quantums,
was to:
- Disconnect the Western Digital hard disk from the PCI controller and leave an old Quantum HDD on the onboard IDE channel.
- Adjust the boot device sequence, so that the mobo boots from the CDROM device.
- Install Linux on the old HDD.
- Power-off and connect the newer HDD on the PCI controller.
- Move the Linux installation from the old HDD to the new one.
The move of the Linux installation would be possible by following the steps of a tutorial like the “Hard-Disk Upgrade HOWTO“,
- 1. Introduction
- 2. Install both disks on your system
- 3. Unmount non-Linux partitions and network drives
- 4. Partition the new disk
- 5. Format the new disk
- 6. Mount the new disk
- 7. Copy the files from the old disk to the new disk
- 8. Modify /new-disk/etc/fstab as appropriate
- 9. Prepare LILO to boot the new disk
- 10. Make a boot diskette (optional)
- 11. Remove the old disk
- 12. Reboot the system, modify LILO configuration file
if old-school partitions were used, or,
in the case of LVM partitions,
the move could be easily performed with the following procedure:
- Having connected the new HDD, I would initialize the free space as a physical volume, so it could be used in an LVM setup.
- Then I’d add this new physical volume to the existing Volume Group, eg: vgextend volume_group /dev/sdb
- Finally, I would use the pvmove utility in order to move the data from the old physical volume (on the Quantum HDD) to the new physical volume (WD HDD), eg:
pvmove sda sdb
One may think of other ways too, but these will do. For those of you
who do not feel very comfortable with moving your installation around,
read on…
Smart Boot Manager
One may wonder why I didn’t use Smart Boot Manager, which can boot the machine from any connected device, instead of doing all of this monkey stuff.
One may wonder why I didn’t use Smart Boot Manager, which can boot the machine from any connected device, instead of doing all of this monkey stuff.
The reason is simple. The smart-boot-manager image, which is
available from the project’s website, does not work for me. I tried to
boot that image in qemu without success. On the other
hand, smart-boot-manager images are all over the web, but… would you
ever write an image, which has been downloaded from Mr.Unknown‘s home page, to your server’s hard disk Master Boot Record? I would never do that, even if I had to do twice as much monkey stuff as I have described above!
Fortunately, I soon found out that a smart-boot-manager image is included in a source that I can fully trust; in the Ubuntu ISO image, under the
install
directory, you will find: sbm.bin
This worked OK under QEMU:
# qemu -m 64 sbm.bin
So, after all this, here is what I did in order to install Fedora 7
directly on the new hard disk, which was connected to the PCI IDE
controller.
- First, I removed the HDD from the PCI controller and left only the HDD on the onboard IDE controller.
- I set the boot sequence so that it boots from the cdrom.
- I used the Ubuntu CD in order to get to a console.
- I wrote the smart boot manager image to the Quantum hard-disk with: dd if=sbm.bin of=/dev/hda
- Powered-off the system and connected the new HDD to the PCI controller.
- I adjusted the boot sequence so to boot from the HDD on the onboard controller.
- Put the Fedora Rescue CD in the CDROM drive.
- Reboot the machine. At the Smart-Boot-Manager menu, I selected the CDROM option.
- IU performed a network installation and used 100MB of the HDD on the onboard controller for the
/boot
partition and the new disk for the rest of the system partitions using LVM.
Hardware manufacturers have managed to transform me to a monkey for a
couple of days. I have wasted time and money and I still cannot decide
about who I am supposed to blame for this mess.
No comments:
Post a Comment