Andrew Sackville-West put forth on 12/1/2009 9:54 PM: > On Tue, Dec 01, 2009 at 08:22:57PM -0600, Stan Hoeppner wrote: >> I currently have a 40GB IDE boot disk in a Lenny server. I boot with >> LILO, but not INITRD. I have the following partitions: >> >> Device Boot Start End Blocks Id System >> /dev/hda1 4623 4865 1951897+ 82 Linux swap >> /dev/hda2 * 4607 4622 128520 83 Linux >> /dev/hda3 1 4606 36997663+ 83 Linux >> >> Partition table entries are not in disk order >> >> >> I would like to add a new IDE disk between say 160GB and 250GB, on >> another IDE channel, and copy/mirror/etc the exact contents of the >> current system disk to the new disk; make the new disk the system (boot) >> disk, and remove the original disk from the machine. I've never done a >> disk migration such as this with Linux. > > This is very doable. I've done it, throwing in niceties such as lvm on > the way across as well. > >> This is a production email firewall/gateway. Thus, I need to have the >> system down as little as possible to complete this. I know I'll need to >> enter single user mode to do the work. I'm just not sure what work I >> need to do in order to properly accomplish this task. > > only parts of it need to be done in single user mode, and that at the > very end, so downtime should be minimal. And, if it doesn't work, you > can always reboot into the old disk while you sort it out. > >> So, what's the best method to pull this off, guaranteeing (as best as >> possible) that all the data made it across the river intact, with an >> identical partition and directory structure, will identical permissions >> on all dirs and files, and that will be bootable? > > why exactly do you want an identical partition structure? That's > really not necessary. What is necessary is that the whole file tree > makes the migration with permissions and structure intact. Little bits > like tweaking /etc/fstab are easily done to accomodate a new partition > structure. > > >> If I start up Postfix >> after the migration to the new disk, and the queue directory/file >> permissions are incorrect, my mail server would be dead in the >> water. > > right. > >> I've been unable to find a concise how-to via Google so far that gives >> me the right comfort level on this. I'm sure one of you can point me to >> a good set of docs. > > I doubt there is a concise how to, but here are the steps I've used in > the past, as well as I can remember them. > > 1. get yourself a rescue cd of some kind. Make it one you are familiar > with. If you messup, you might need it. > > 2. make good current backups. > > 3. shutdown the machine, install the disk, restart. > > 4. take your time creating partitions and filesystems on the new > disk. > > 5. Begin to migrate chucks of the filesystem. Here's where things get > itneresting, because it depends on hoow you like to structure stuff. I > like to have many partitions for various bits of the fs, and this > really helps in this case, but you can make it work in a monolithic > file system as well. > > Typically, since it's all on the same machine, I just use cp -a (which > handles all the permission). There are other solutions use tar and > friends, but I don't really think it's necessary. Start out by > migrating over things that are fairly static like /usr, /bin, /sbin, > /boot, /root etc. If /home is pretty static on this machine, then move > it over as well. YOu have to make a judgement call about each section > of the file system, but the ones to save for the very end are /var and > /tmp. > > Now, here is where you can really take your time. Move over just one > chunk, say /usr, and then remount it back into the current running > system and use it and make sure it's working properly. YOu can do this > with each piece of the file tree as you go. > > For migrating /var and /tmp(debatable whether this even needs to be > done for /tmp as it'll get handled on a reboot), you'll want to go to > single user mode, copy it over, remount the new copy back into the > system and then go back to multi-user mode and make sure it's all > working. > > Doing things this way, you can test each piece as you go and you > aren't messing with the original working install, so rolling back on > problems is simple. > > Now fix up /etc/fstab, if needed, on the new disk. > > Finally, once you've got this all working the way you like, you'll > want to install a bootloader into the new disk, although, if you use > grub, even that can be avoided until later. You *can* reboot and edit > the grub entries to boot from the new disk using grub from the old > disk. At the end of this, you'd be running the system off the new > disk, but booting from the old. Then install grub on the new disk, > shutdown, remove the old disk and see if it comes back up. > > Sorry it's not *specific* instructions. But, depending on your skill > level, it's really not that hard. THe key is the -a flag on cp, taking > your time, and jsut doing it one piece at a time.
Don't apologize. They're more than specific enough to get me going. A couple of things though. 1. My fstab mounting skills are rusty, but I'll refresh 2. I'm sticking with LILO. I've never "manually" installed a boot loader, only during Debian clean/scratch installations using the Deb installer. The last time I did that was with Woody, like 4 years ago. How do I manually install LILO to the boot sector of the new disk? I'm sure it's simple, I just don't know the command. Thanks so much for your very helpful insight to this point Andrew. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
