|
|
|
|
|
Linux Training 1825 Monetary Lane Suite #104 Carrollton, TX Do a presentation at NTLUG. What is the Linux Installation Project? Real companies using Linux! Not just for business anymore. Providing ready to run platforms on Linux |
Created by Terry Henderson on March 19, 2007, at 06:59 PM Project: (350 Mhz Dell Latitude laptop, 128M RAM) Here was my original my plan - (watch for [possible] flaws). dd if=/dev/hda1 | gzip - > /pub/image.gz Install 30G drive gzip -d < image.gz | dd of=/dev/hda1 Creating the backup image and writing it to the nfs server took a very long time. Answer - yes: I started over, using - using ssh: dd if=/dev/hda1 | ssh $user@$host 'gzip - > /pub/image.gz' (and this time via wired connection) It took about 40 minutes, as opposed to over 3 hours! (nfs is good and convenient but not for really large files) I used the second partition of the 30G drive [that I temporarily created and formated into an ext2 filesystem] to copy the image back to the laptop; I booted the Slax CD, cerated a mount point & mounted the second partition; mkdir /mnt/hda2 mount /dev/hda2 /mnt/hda2 and then: cd /mnt/hda2 Next, I used following command to retrieve the image: scp username@192.168.1.6:/pub/image.gz . At this point, I had [efficiently] copied the image across network to the second partition of my laptop's new drive. And then to uncompress and write the image onto the first partition of the new 30Gig drive [hda1], I used the following command: gzip -d image.gz | dd of=/dev/hda1 Meanwhile, (for the sake of experimentation); I kept the image I copied via nfs [for comparison] and found that; The process of compressing and copying images across a network is handled faster and [apparently] more accurate via ssh. I ran md5sum against the two compressed images and here are the results: fc61812e6ce08f5859b595fcc26a5af5 image2.gz a6e3d9851e03fde30f6c17091b882769 image.gz Further proof that the images differ: diff image.gz image2.gz Binary files image.gz and image2.gz differ I used the ssh version and it turned out to be accurate. BUT; When I first tried to boot to it, nothing happened. Why? There was no boot loader in the Master Boot Record (MBR). I realize at this point that I would have needed a separate image for the MBR. Since I never intended to use the MS Windows boot loader in the first place, I simply ignored this problem continued on to the next step. More partitions, more operating systems: On the free space I created a couple of other partitions, installed Slackware, downloaded and installed patches, updated KDE, made a few other tweaks and touches. Meanwhile, the Slackware install had automatically added the Win2K boot option to the Lilo boot loader and now I'm able to boot my choice, Win2k or Linux. Win2k boots and runs ok, Slackware boots and runs ok - so far - so good. Next, a Centos install .... CentOS and Red Hat Enterprise Linux, (RHEL), are one in the same pretty much - CentOS is just a re-spin of RHEL. Since I feel the need to "keep my finger on the pulse" of the world wide community we call Linux, having an RPM based OS is a must. The CentOS install came off without a hitch. The post-install, well, that's another story - quite an ordeal and it's opened up some questions that I've yet to fully answer. When it came to installing the grub boot loader I was disapointed to see that it only made entries for CentOS and Win2k. Finding no option to manually enter a third OS, I decided to go on with the grub install anyway with the intention of repairing it afterward. Repairing it afterward proved to be quite a chore, [due to some gaps in my knowledge of grub and of booting Linux kernels]. After a couple of failed attempts at editing the menu.lst file in such a way that I could re-gain access to my beloved Slakcware, I decided to give it a shot with lilo, (with which I'm a bit more familiar). I booted the Slax CD, mounted and chrooted to /dev/hda3, edited /etc/lilo.conf and ran the command: lilo Needless to say my first attempt failed, as did the second, third and forth. I'm still not sure why I never arrived at a lilo solution for booting the kernel on /dev/hda5, but may have had something to do with RedHat's use of LVM. I decided to abandon Slackware's version of lilo and go back to CentOS and grub. Using the "linux rescue" boot option on the install cd, I was able to boot and chroot to the /dev/hda5 filesystem. I needed to do some detective work: When I look at the fstab file, I see complications and what looks like smoke and mirrors to me:
If we look at the partitions: Device Boot Start End Blocks Id System we see that the CentOS installer created logical partitions hda5 and hda6. hda6 is LVM and contains the main root filesystem where the root directory resides (/) while hda5 is where /boot resides and contains the kernel. (hda4 is just the "extended" partition that contains logical partitions hda5 & hda6.) Grub is more complicated that lilo but has advanced capabilities. It is a very good boot loader, but just not as user friendly in some ways. I finally created an entry that would boot my Slackware kernel but it to took 7 or 8 attempts and a lot of googling. Here is what I ended up with - here is what works: default=0 root (hd0,2) kernel /boot/vmlinuz root=/dev/hda3 ro savedefault boot title CentOS (2.6.9-42.0.8.EL) root (hd0,4) kernel /vmlinuz-2.6.9-42.0.8.EL ro root=/dev/VolGroup00/LogVol00 ->rhgb\ quiet initrd /initrd-2.6.9-42.0.8.EL.img title CentOS-4 i386 (2.6.9-42.EL) root (hd0,4) kernel /vmlinuz-2.6.9-42.EL ro root=/dev/VolGroup00/LogVol00 rhgb\ quiet initrd /initrd-2.6.9-42.EL.img title Win2K rootnoverify (hd0,0) chainloader +1 title Slackware[<<] root (hd0,2)[<<]
kernel /boot/vmlinuz read-only Notice how I had to define the location of Slackware's root directory in two different paces: Quote: root (hd0,2) kernel /boot/vmlinuz root=/dev/hda3 ro That's the key to making it work [with grub]. I never found the solution for lilo - I could not figure out how to tell lilo to look at another drive or partition for CentOS' root directory. All I could come up with that would cause lilo to find the CentOS kernel was to copy it to Slackware's boot partition, which worked and got the kernel to boot, but it would hang because it could not find the root directory. I gave up before figuring out how to properly define the root directory on another partition. In other words, I had solved the problem of not being able to point to another partition for a boot directory, but still didn't solve the problem of pointing to yet another partition for the root directory. (Note: While Slackware's root and boot directories are both on the same partition, CentOS' boot directory is one partition and the root directory is on yet another partition; "/dev/VolGroup00/LogVol00", [LVM].) boot = /dev/hda vga = normal image=/boot/vmlinuz root=/dev/hda3 Label=Slackware read-only ...# First Linux bootable partition config ends...
...# Windows bootable partition config begins...
other = /dev/hda1 ...label = Windows ...table = /dev/hda ...# Windows bootable partition config ends...[[<<]
...# Second Linux bootable partiion config begins... root = /dev/hda6 Label = centos initrd = /boot/initrd-centos read-only append = "rhgb quiet" Notice the line image = /boot/vmlinuz-centos ...it is pointing to the CentOS kernel that I copied to Slackware's /boot directory and renamed to: "vmlinuz-centos". trryhend@gmail.com
Registered Linux User 188099 <>< Back to Site Blogs |
