Re: migrate to new system disk
Sorry for top posting, there is just too much for individual responses. Thanks for all your advice. I made use of much of it. First, I ended up going with a SATA/PCI controller and 500GB WD SATA drive as my fastest onboard IDE controller was ATA/66. I installed both card and drive after compiling a new kernel with scsi_disk and libata support. I created a /boot partition of 100MB, a / partition of 35GB, and a swap partition of 1GB. I formatted the first two with ext2, and mounted them as /newboot and /newroot, then started copying all the files over, a directory at a time using your cp -a advice, though using cp -p on some individual files. Before copying over critical stuff, instead of entering runlevel 1 (as I did everything remote via SSH), I merely stopped most of the multi-user services, mainly postfix and postgrey. The last things I did were to edit /newroot/etc/fstab and /newroot/etc/lilo.conf. I then ran lilo to install the MBR on the new disk, and rebooted. I hit a couple of minor snags, but the machine is now runnin from solely the new disk, and AFAICT after much checking/testing, everything is working great. Now I just need to decide how to carve up the remaining 45GB of this sucker and put it to good use. I right now I'm going to move /home to a new partition of probably at least 100GB. I may install the samba server so other machines can use some of this 500GB goodness. Thanks again for the advice. Hit minor bumps along the way, but overall, I'm please that the migration went as smoothly as it did. If I'd anticipated a few things more correctly it would have been an almost flawless migration. -- Stan 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/hda146234865 1951897+ 82 Linux swap /dev/hda2 *46074622 128520 83 Linux /dev/hda3 1460636997663+ 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,
Re: migrate to new system disk
Mark Neidorff put forth on 12/2/2009 5:22 PM: On Tuesday 01 December 2009 09:22 pm, 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: 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 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. 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? 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. There is no concise guide to doing what you want, because it is a complex job. I guess I just figured someone had gone through the same process and documented it. Do your users store e-mail on the server? That is an issue. No local mail storage, it's primarily a Postfix anti-spam gateway. I do some occasional ftp on if someone wants to send me an ISO (or a dozen) or what not. It also hosts some static content via lighttpd, but it's very little, stuff like log file summaries, some personal stuff, basically utility knife web hosting. Do you have a second PC that you can use to install the software and test? That I do not have. Suggestion: Install mondorescue stop the mail server do a backup restore to the new disk (on a different computer) Install lilo move the new disk to the server start it up and see how it works. Mondorescue will take care of the bare metal restore and get you up and running just fine. I'll look into Mondorescue. What is its preferred backup media? Only storage devices I have on the box are an HD and 3.5 floppy. I was really hoping I could just go disk-disk and be done with it, using something like ghost, or just mirroring the old disk, then breaking the mirror and run with the new disk. I used to do that alot back in my Winders days. I guess none of the Linux mirroring utilities will work for this since no one has suggested it? -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: migrate to new system disk
On Thursday 03 December 2009 03:34 am, Stan Hoeppner wrote: I'll look into Mondorescue. What is its preferred backup media? Only storage devices I have on the box are an HD and 3.5 floppy. I was really hoping I could just go disk-disk and be done with it, using something like ghost, or just mirroring the old disk, then breaking the mirror and run with the new disk. I used to do that alot back in my Winders days. I guess none of the Linux mirroring utilities will work for this since no one has suggested it? Mondorescue will back up to whatever you have. Mailservers are not as simple as we see them. If you want to, try going disk to disk with a utility look at the partition magic software suite. Just remember that your mail server needs to be down when you are cloning the system. Best of luck, Mark -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: migrate to new system disk
On Wednesday 02 December 2009, Alan Ianson wrote: 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. I haven't used lilo in years.. but if I remember right I ran the command lilo after making any changes to it's config and that would rewrite it. If you (or anyone else) is using Grub, simply copying your files across your files will not work due to the presence of UUIDs in the Grub2 config files. I have been unable to find the proper procedure for updating those UUIDs. David -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: migrate to new system disk
David Goodenough wrote: On Wednesday 02 December 2009, Alan Ianson wrote: 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. I haven't used lilo in years.. but if I remember right I ran the command lilo after making any changes to it's config and that would rewrite it. If you (or anyone else) is using Grub, simply copying your files across your files will not work due to the presence of UUIDs in the Grub2 config files. I have been unable to find the proper procedure for updating those UUIDs. David Hi, tune2fs -U [old_partition_UUID] /dev/[new_partition] will change the UUID of the new partition to the one of the original one. If the partitions are inside the same machine, it is necessary to change the UUID of the old partition, so that UUID's remain unique... fstab needs adjusting if UUID are in use there too. This is how I do it when moving systems around, it works, not to say there isn't a better way ! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: migrate to new system disk
Stan Hoeppner: 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 Howto describes a few methods: http://tldp.org/HOWTO/Hard-Disk-Upgrade/index.html J. -- If you do not move for long enough, you might see a rat. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: migrate to new system disk
On Wednesday 02 December 2009, tv.deb...@googlemail.com wrote: David Goodenough wrote: On Wednesday 02 December 2009, Alan Ianson wrote: 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. I haven't used lilo in years.. but if I remember right I ran the command lilo after making any changes to it's config and that would rewrite it. If you (or anyone else) is using Grub, simply copying your files across your files will not work due to the presence of UUIDs in the Grub2 config files. I have been unable to find the proper procedure for updating those UUIDs. David Hi, tune2fs -U [old_partition_UUID] /dev/[new_partition] will change the UUID of the new partition to the one of the original one. If the partitions are inside the same machine, it is necessary to change the UUID of the old partition, so that UUID's remain unique... fstab needs adjusting if UUID are in use there too. This is how I do it when moving systems around, it works, not to say there isn't a better way ! while that will solve the problem, what I really want is a command that will update the grub config files (and fstab if that starts using UUIDs too) to the new disk. Issuing commands with UUIDs in them manually does not strike me as fun or something to be done regularly. David -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: migrate to new system disk
On Wed, Dec 02, 2009 at 09:59:21AM +, David Goodenough wrote: On Wednesday 02 December 2009, Alan Ianson wrote: 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. I haven't used lilo in years.. but if I remember right I ran the command lilo after making any changes to it's config and that would rewrite it. If you (or anyone else) is using Grub, simply copying your files across your files will not work due to the presence of UUIDs in the Grub2 config files. I have been unable to find the proper procedure for updating those UUIDs. heh, good point. last time I did this, UUID's were just not typically used. A signature.asc Description: Digital signature
Re: migrate to new system disk
On Wed, 02 Dec 2009 12:04:17 +, David Goodenough wrote: On Wednesday 02 December 2009, tv.debian wrote: tune2fs -U [old_partition_UUID] /dev/[new_partition] will change the UUID of the new partition to the one of the original one. If the partitions are inside the same machine, it is necessary to change the UUID of the old partition, so that UUID's remain unique... fstab needs adjusting if UUID are in use there too. This is how I do it when moving systems around, it works, not to say there isn't a better way ! while that will solve the problem, what I really want is a command that will update the grub config files (and fstab if that starts using UUIDs too) to the new disk. Issuing commands with UUIDs in them manually does not strike me as fun or something to be done regularly. I cannot imagine a way Grub could handle this situation automatically :-? Let's take there are 4 hard disk in the system, with 4 primary partitions for each of them. How can Grub (or Grub2) determine (on its own) what partition is holding the right system data? And the same goes for /etc/fstab file. Grub can know something about the UUID (label, id or path) of the device but knows little about the content of the partitions and how are they arranged by the user. Taking into account there can be may OS's installed across the partitions, autodetecting what is what is not an easy task for the bootloader. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: migrate to new system disk
On Wednesday 02 December 2009, Camaleón wrote: On Wed, 02 Dec 2009 12:04:17 +, David Goodenough wrote: On Wednesday 02 December 2009, tv.debian wrote: tune2fs -U [old_partition_UUID] /dev/[new_partition] will change the UUID of the new partition to the one of the original one. If the partitions are inside the same machine, it is necessary to change the UUID of the old partition, so that UUID's remain unique... fstab needs adjusting if UUID are in use there too. This is how I do it when moving systems around, it works, not to say there isn't a better way ! while that will solve the problem, what I really want is a command that will update the grub config files (and fstab if that starts using UUIDs too) to the new disk. Issuing commands with UUIDs in them manually does not strike me as fun or something to be done regularly. I cannot imagine a way Grub could handle this situation automatically :-? Let's take there are 4 hard disk in the system, with 4 primary partitions for each of them. How can Grub (or Grub2) determine (on its own) what partition is holding the right system data? And the same goes for /etc/fstab file. Grub can know something about the UUID (label, id or path) of the device but knows little about the content of the partitions and how are they arranged by the user. Taking into account there can be may OS's installed across the partitions, autodetecting what is what is not an easy task for the bootloader. Greetings, in the old procedure, you start by finding /boot/grub/stage1, then you set root to the one that you choose, and at this stage grub could at least notice that the UUID is wrong and offer to rewrite it. David -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: migrate to new system disk
If you (or anyone else) is using Grub, simply copying your files across your files will not work due to the presence of UUIDs in the Grub2 config files. I have been unable to find the proper procedure for updating those UUIDs. # chroot /newrootdiskmount then # update-grub -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: migrate to new system disk
On Tuesday 01 December 2009 09:22 pm, 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: 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 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. 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? 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. There is no concise guide to doing what you want, because it is a complex job. Do your users store e-mail on the server? That is an issue. Do you have a second PC that you can use to install the software and test? Suggestion: Install mondorescue stop the mail server do a backup restore to the new disk (on a different computer) Install lilo move the new disk to the server start it up and see how it works. Mondorescue will take care of the bare metal restore and get you up and running just fine. Mark -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: migrate to new system disk
Stan Hoeppner wrote: 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; 1. You can try dd (Try to clone your laptops Os first) 2. Grub is much better than Lilo in most cases. 3. Also you shuld make live usb, that will be helpful in case of emergency: http://feraga.com/library/howto_install_debian_linux_onto_a_usb_thumb_drive_with_the_root_partition_encrypted_using_uuids_initramfs_tools_dm_crypt -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: migrate to new system disk
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/hda146234865 1951897+ 82 Linux swap /dev/hda2 *46074622 128520 83 Linux /dev/hda3 1460636997663+ 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. A signature.asc Description: Digital signature
Re: migrate to new system disk
On Tue, Dec 01, 2009 at 07:54:01PM -0800, Andrew Sackville-West wrote: 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 [snip] 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 I would suggest looking at rsync, it main advantage over cp is it can resumes from an interrupted copy process [snip] A signature.asc Description: Digital signature
Re: migrate to new system disk
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/hda146234865 1951897+ 82 Linux swap /dev/hda2 *46074622 128520 83 Linux /dev/hda3 1460636997663+ 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.
Re: migrate to new system disk
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. I haven't used lilo in years.. but if I remember right I ran the command lilo after making any changes to it's config and that would rewrite it. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
