Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I posted the same question on the Debian forums, but didn't get a single response. So I thought I'd try my luck here.
I'm currently building a new webserver based on Debian Etch and have everything running on a single 80GB HDD. But now I want to convert it to two 160GB HDDs in a RAID 1 setup. What's the best way to do it? It took me quite some time to setup the new server (software wise) just the way I want it to, so I would really like to avoid having to start from scratch.
Is there like a simple path? Like copy the entire contents from the 80GB to a single 160GB, then convert the single 160GB to software RAID 1 using a second 160GB HDD? Or perhaps do a base Debian install on the two 160GB HDDs (in RAID), then copy everything from the 80GB (sans the kernel) to the new drives?
Any suggestions, help, tips, tricks, URLs, RTFMs? I'm no Linux newbie, but I'm no expert-hax0r either...
1. Copy the contents of your 80gb disk to the 160gb disk, making sure that your partitions are the way that you want them on it.
2. Make sure that you also get grub installed on the new 160gb disk as well.
3. Remove the 80gb drive from the system and make sure that you can boot the 160gb disk and everything appears to work as you expect it to.
4. Once you are sure that the 160gb disk is good for you, you should begin the process of making the system a RAID 1 configuration. There are instructions on the web for this that should do you just fine.
The nice thing about this situation is that if you screw up somewhere, you can always put your 80gb drive back into the system and start from the beginning again.
Some handy commands for the copying:
Copying files: cp -axu / /mnt/sda1 * Copies files that are only on that filesystem.
Copying partition table: sfdisk -d /dev/sda | sfdisk /dev/sdb * Copies partition table from one disk to another (handy for duplicating the partition table from the first 160gb disk to the second!)
Ok, this is what I have done so far. I hooked up the new 160GB drive using USB, partitioned it and copied over the contents from the old 80GB drive. The reason it's attached as an external USB drive is because the motherboard does not support SATA (and this is a SATA drive). The 160GB drives will eventually end up in another system that does support SATA.
Now I'm a bit confused on how to install Grub on the new 160GB drive. The drive is /dev/sda and when I try to install grub on it, I get an error:
Code:
$ grub-install /dev/sda
/dev/sda does not have any corresponding BIOS drive.
So I did
Code:
$ grub-install --recheck /dev/sda
Probing devices to guess BIOS drives. This may take a long time.
Searching for GRUB installation directory ... found: /boot/grub
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.
(fd0) /dev/fd0
(hd0) /dev/hda
(hd1) /dev/hdb
(hd2) /dev/sda
$
I'm sure it will allow me to install Grub on /dev/sda now, but will that mess up Grub installed on the original 80GB HD? Like I said, the 160GB will end up in another system and I want to keep the current system (with the 80GB HDD) intact.
After I did a grub-install /dev/sda, I took the HD to its new home (a new system) and tried to boot from it. At boot time I get the folowing error:
Code:
GRUB Hard Disk Error
I guess that's because the grub files (device.map, menu.lst) are copies from the old HD in an entirely different system. Is there an easy way to fix this?
You would have to change which dev is the one you want to install it to, but this should do the trick for you. By doing it this way, you ensure that the install is going to the right disk.
I still had to edit menu.lst because it was referring to /dev/hda which of course no longer existed.
Now it turns out the on-board NIC from the new motherboard is not working... Which means I'll have to take the system apart again and go replace the motherboard. It's always something innit?
I'm now following this How-To to convert the single 160GB HDD setup to a RAID 1 setup and all goes well until I need to adjust the ramdisk with update-initramfs -u. This throws an error:
Code:
$ update-initramfs -u
/boot/initrd.img-2.6.22-4-686 does not exist. Cannot update.
The error message is correct. That image indeed does not exist. I installed a 2.6.22 kernel image a few days ago to test if it would recognize a network card. Since it didn't I uninstalled it and reverted back to 2.6.18. But apparently, it stuck somewhere.
How can I get rid of this error message? Or can I simply ignore it?
From the man page for that command (which I don't have on any of my systems, but is available on the net) we see this:
Code:
-k version
Set the specific kernel version for whom the initramfs will be generated. For example the output of uname -r for your currently running kernel. This argument is optional for update. The default is the latest kernel version.
So what I suspect the command is doing when you do NOT use the -k option is that it is looking in /lib/modules for the latest set of modules there and using that. Try using the -k option for this command and see if that helps you.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.