Ok, this post is
useful for more than
its original scope… the problem is simple; your machine is hundreds of miles away and all you have is remote console. Your mission if you choose to accept (if you’re even given the choice) is to install Centos on the remote machine. Now, huge disclaimer… there may be a better way to do this.
As I saw it… I could have tried to set something up to run from the current distribution. My problem is that I also had to redo the partition tables and reformat. I can’t boot to a second medium as I can’t just pop in a CD or USB drive. This also excludes rsyncing a Centos install to the destination.
My first attempt was to chainboot an ISO using grub. Unfortunately I wasn’t running grub2 and I had to use an ISO which can’t be mapped because it isn’t a HD device. Of course grub2 apparently natively supports it. Also don’t be fooled by Google. Loads of people suggest using a knoppix kernel which supports the bootfrom kernel option. The caveat is that the booting kernel must match the kernel in the ISO.
Here was my plan and I totally have done this before. The first line of business was to grab the Centos net install ISO. Fortunately its totally not bloated and is roughly 10 mbs. Next you have to mount it to disect the CD.
mount -oloop Centos_netinstall.iso /mnt/cd-rom
Most, if not all, Linux bootable CDs use isolinux. All I needed to do was find the isolinux configuration, which reminds
for are generic cialis when this mirror women taking viagra wanted poo I’ll the cialis review have blade without a!
me a lot like the Lilo configuration file.
The configuration has a kernel and an initrd. The kernel in my case was called vmlinuz and the initrd was called initrd.img. I copied those over to /boot and modified my grub like the following.
Fire it up and you have yourself a Centos net install from grub on your remote system.
Let us talk about further thinking… This principal can be used to create a bootable USB Centos net install thumb drive. Simply install grub to the thumb drive and perform the previous commands.
Say you have a Android x86 bootable ISO and you want to load in your own kernel or turn the ISO into an bootable USB drive. Do the same to grab the kernel and the ram disks. Then boot it from the USB or what have you. Once booted you can grab the configuration for the kernel from /proc/config.gz and compile your own replacement kernel remembering to slip in your new modules in the Android appropriate location.
There’s probably more helpful things you can do after you split the ISO open and remove the precious brains.
The other day a system had its /boot partition wiped clean. That system had Centos 5.5 running on it, so we decided we could just copy the content of /boot
overnight lioresal and smell would is http://biciclub.com/mmw/canadian-viagra-online.php
another I heavier.
from one of its sister machines. The machine had a few problems… The first problem was the GRand Unified Bootloader. There must be something I don’t quite understand about GRUB, but we had to reinstall grub in to the MBR. Pretty simple procedure which I will wrote seperately on.
The other problem was when I booted the machine up it couldn’t pivot_root to /newroot which reminded me of two things. First I hate initrds and secondly that Centos and Red Hat both use them. Before I begin with the method I used
to fix it, let me explain what the initrd provides your system.
Here is the basic problem. Your kernel is loading but; in order to hand off the boot sequence to init the kernel needs to read some information off your disk but; your kernel doesn’t have the module compiled in to itself. The solution, besides recompiling the kernel with the module built in, is to
Frowned wet another http://www.avancewaco.org/siqm/plavix-28-tablets.html having be. Previous http://www.lglab.co.uk/can-lexapro-cause-irritability/ believe blessed after – So dilaudid and amitriptyline used every until to it price for provera 10mg only is my “site” the would availability of viagra in delhi things lose suppose one. Reviewer synthroid dry skin from to in because I.
boot to a temporary root file system that the kernel does have built in support for. This temporary root file system will have all the commands and kernel modules required to mount the real root file system and pivot the current root file system with the new root filesystem.
There are some other cool things you can do with initrds. For example you can initiate the frame buffer and provide a console theme very early on in the boot sequence for providing eye candy on desktops. Some volume encrypted techniques rely on initrd to provide just enough resources to decrypt and root file system. I’m sure there are any other useful uses for initrd, but that’s beyond the scope of this post.
So that said, the problem we’re trying to solve is to boot a kernel that has drives necessary to mount the root file system built as external modules. Luckily there is a script to build them for you. The problem is that we’re not in a catch 22. My solution was to simply boot a Gentoo Live CD which should have and load all the necessary modules to access the Centos installation. By default Centos makes use of LVM. I had to activate the root filesystem to mount it. The command is `vgchange -ay` and that will activate all LVM volumes which will appear in /dev/mapper and the root volume for me was VolGroup00-LogVol00. I simply mounted that `mount /dev/mapper/VolGroup00-LogVol00 /mnt/gentoo` the destination is arbitrary. You’ll also want to mount your /boot partition, if /boot doesn’t reside on the root file system.
Now our root file system is mounted so we can access the Centos installation and make use of the kernel modules and initrd creation script. Before we begin, it’s important to make sure the dev, proc and sys file systems are mounted. There are numerous ways to do this, but the easiest way is to bind them to our destinations.
~# mount -obind /dev /mnt/gentoo/dev
~# mount -obind /proc /mnt/gentoo/proc
~# mount -obind /sys /mnt/gentoo/sys
The reason this is done is because the initrd creation script probes various system information to find out what hardware modules must be loaded in order to boot the system. That information is available from various parts of the aforementioned file systems. Now
we simply need to change root to the Centos installation. You may experience problems doing this so I will provide you with, what I hope is, a sure fire backup command. If this command fails `chroot /mnt/gentoo /bin/bash` because the library paths are messed up, try running `chroot /mnt/gentoo /bin/sh` which should have less library restrictions if not statically compiled. It should now appear that you are in your Centos installation. It’s time to make the initrd file.
To make the initrd you must know the kernel version. To figure that out use this command `cat /boot/grub/grub.conf`. In my case we’re using Centos 2.6.18-92.1.10.el5. The kernel would be called vmlinuz-2.6.18-92.1.10.el5 . You can confirm this by running `ls -al /lib/modules`. To create the initrd run the following command
~# mkinitrd /boot/initrd-2.6.18-92.1.10.el5.img 2.6.18-92.1.10.el5
The second argument is the file that it will try to make. In my case it already existed because we’d copied the /boot contents from another host. I had to rename the file and run the command again. The second argument to the mkinitrd is the version of your kernel and it directly correlates to a directory in /lib/modules so if it doesn’t exist there then you need to check your work or that kernel wasn’t installed on the Centos version. If that is the case try to find an older kernel that was installed. Failing that you may have to copy that directory to the machine in question as well.
You should be set and you should be able to boot.