Trouble with cloned Linode
I have a 1gb Linode that's been running great for over a year. Has a LAMP install on it. Today, I cloned for someone I'm building a site for (just using the Linode clone option). The new Linode did its thing, booted OK, but I cannot SSH into it. Using the AJAX LISH console I can get in, but apt-get update and such all fail. Any ideas?
8 Replies
Did you leave DHCP enabled, or did the Linode have a static IP configured?
It sounds like networking isn't working for some reason, which leads me to believe some vestige of the other node is still there.
Left the Linode as is. Just shut it down, clicked the clone tab, and then cloned the profile over to the new linode.
Looks like DHCP is still enabled in /etc/network/interfaces:
auto eth0
iface eth0 inet dhcp
I actually did the original install with the LAMP stackscript if I remember right.
I ran ifconfig and oddly enough nothing was returned. JshWright, not sure what you mean by try eth1. I wasn't aware linodes had more than one NIC. You have a command I can run?
Whenever I try editing a file, any file, I get Error writing
The URL you pasted is out of date; the instructions in the Linode Library
Once you're at the finnix prompt, run:
e2fsck -fnv /dev/xvda | tee /tmp/fsckerrors.txt
… and post the results here. They'll be stored in /tmp/fsckerrors.txt for your convenience. This command invokes the ext2/ext3/ext4 filesystem checker with -f (force fsck even if filesystem is clean), -n (read-only/don't change anything), and -v (verbose output).
Omitting the -fnv and perhaps using -p (preen: assume consent for minor low-risk fixes) or -y (yes: assume consent for any fixes) will actually let it fix stuff, if you want.
If the filesystem is too far gone, another possible solution is to restore a backup of the donor Linode to the target Linode. That avoids the whole spaghetti-filesystem problem by creating a new one based upon a snapshot, but it is still susceptible to the spaghetti-database problem.