Re: Transferring install to another HD
Thomas Adam wrote: On Thu, Aug 26, 2004 at 10:46:08PM +0800, John Summerfield wrote: Not on _my_ computers you won't. That's a completely unreliable way of restoring the directory. He's chrooting into a Debian install. Enough said. It works. Sometimes. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transferring install to another HD
Stephen Tait wrote: At 15:46 26/08/2004, you wrote: Not on _my_ computers you won't. That's a completely unreliable way of restoring the directory. Why doesn't someone read the man page for cp? It tells you how not copy /proc. man cp Personally, I prefer tar ... | tar which seems to work far better for me than cp. man tar -- Cheers John I've had more than a cursory glance at the man pages for cp (TBH, I didn't even think of using tar) but Pay close attention to "-x" aka "--one-file-system couldn't find any particular reference to /proc files (maybe cos I'm using woody...?). There were plenty of references to "special files" to be warned about (such as never ever use the --copy-contents switch, etc), which I assume includes most of /proc as well as the more exotic parts of /dev, but there weren't any specific references. Looking at it now with a few examples from Thomas' page, it does look like tar is the best way to do it (if a little more convoluted), but all I've copied so far are the non-special stuff (just user profiles, apps and so on), but am now sorely worried about my procs and devs. What is it about Thomas' makedev line that I should avoid? At least some distros come with /dev already populated. MAKEDEV won't necessarily create all of the devices you are using. Sometimes, sysadmins such as you find it necessary to create an extra deviceor two because of some new software they want to use. MAKDEV won't recreate those either. If at all possible, backup/restore is the way to go: in your specific instance that means "copy." The incantation of tar I would use would be something like this. First, the preliminaries> mount stuff. mkdir /mnt/(srce,dest} mount source /mnt/srce mount dest /mnt/dest tar cC /mnt/srce . boot... | tar xpC /mnt/dest You can expand on this use of tar to copy across a network, with/without compression. For more, man tar I'm quite tempted to switch to GRUB, as I find it's syntax nicer, although I'm used to just using it on IDE systems (under gentoo). I take it all I need to do is supplant hd* for sd*...? Grub is grand. If you need a rescue disk, grub on a floppy may be all you need. Read the docs closely. On Debian there's a script that will create your initial configuration. Beware: Cricketers coming:-) -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transferring install to another HD
On Thu, Aug 26, 2004 at 10:46:08PM +0800, John Summerfield wrote: > Not on _my_ computers you won't. That's a completely unreliable way of > restoring the directory. He's chrooting into a Debian install. Enough said. It works. -- Thomas Adam -- Quis custodiet ipsos custodes? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transferring install to another HD
At 15:46 26/08/2004, you wrote: Not on _my_ computers you won't. That's a completely unreliable way of restoring the directory. Why doesn't someone read the man page for cp? It tells you how not copy /proc. man cp Personally, I prefer tar ... | tar which seems to work far better for me than cp. man tar -- Cheers John I've had more than a cursory glance at the man pages for cp (TBH, I didn't even think of using tar) but couldn't find any particular reference to /proc files (maybe cos I'm using woody...?). There were plenty of references to "special files" to be warned about (such as never ever use the --copy-contents switch, etc), which I assume includes most of /proc as well as the more exotic parts of /dev, but there weren't any specific references. Looking at it now with a few examples from Thomas' page, it does look like tar is the best way to do it (if a little more convoluted), but all I've copied so far are the non-special stuff (just user profiles, apps and so on), but am now sorely worried about my procs and devs. What is it about Thomas' makedev line that I should avoid? I'm quite tempted to switch to GRUB, as I find it's syntax nicer, although I'm used to just using it on IDE systems (under gentoo). I take it all I need to do is supplant hd* for sd*...? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transferring install to another HD
Thomas Adam wrote: On Thu, Aug 26, 2004 at 03:33:53PM +0100, Stephen Tait wrote: Gak! I've just thought. What do I do with all of the weird stuff in /proc and /dev? Will cp handle these things seamlessly, or will I have to create /proc and /dev are virtual. What you should therefore do is omit these from your cp. When you chroot into your new install you can do: cd /dev && MAKEDEV generic to create your /dev nodes. Not on _my_ computers you won't. That's a completely unreliable way of restoring the directory. Why doesn't someone read the man page for cp? It tells you how not copy /proc. man cp Personally, I prefer tar ... | tar which seems to work far better for me than cp. man tar -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transferring install to another HD
On Thu, Aug 26, 2004 at 03:33:53PM +0100, Stephen Tait wrote: > Gak! I've just thought. What do I do with all of the weird stuff in /proc > and /dev? Will cp handle these things seamlessly, or will I have to create /proc and /dev are virtual. What you should therefore do is omit these from your cp. When you chroot into your new install you can do: cd /dev && MAKEDEV generic to create your /dev nodes. > all the nodes etc manually, or do they get created automagically by the > kernel? You may (or may not) find the following of use to you: http://www.hantslug.org.uk/cgi-bin/wiki.pl?LinuxHints/OneDiskToAnother -- Thomas Adam -- Quis custodiet ipsos custodes? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transferring install to another HD
At 15:00 26/08/2004, you wrote: On Thu, Aug 26, 2004 at 03:03:10PM +0100, Stephen Tait wrote: > Once all the files have done transferring, I'm guessing all I have to do is > do a chroot /mnt/newdrive /bin/bash, and then run the LILO thing to get > myself a boot block in my MBR. That'll do it. Also make sure you change /etc/fstab as appropriate. -- Thomas Adam -- Quis custodiet ipsos custodes? Gak! I've just thought. What do I do with all of the weird stuff in /proc and /dev? Will cp handle these things seamlessly, or will I have to create all the nodes etc manually, or do they get created automagically by the kernel? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transferring install to another HD
On Thu, Aug 26, 2004 at 03:03:10PM +0100, Stephen Tait wrote: > Once all the files have done transferring, I'm guessing all I have to do is > do a chroot /mnt/newdrive /bin/bash, and then run the LILO thing to get > myself a boot block in my MBR. That'll do it. Also make sure you change /etc/fstab as appropriate. -- Thomas Adam -- Quis custodiet ipsos custodes? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
