Post-Migration Drive Issue

smitty825,

You should ask Linode Support about this. If they don't have an answer for you (which they probably will) I'm sure they'd want to know about this just in case others encounter the same problem.

I don't know if this is the same problem that you're encountering, but there have been a few issues posted in this forum about 32 bit kernels running into some issues after migrating. Booting with a 64 bit kernel seemed to correct the issue.

Which distro/version are you running? It probably shouldn't be referring to filesystems by UUID, but rather by actual device (/dev/xvd*)…

@hoopycat:

Which distro/version are you running? It probably shouldn't be referring to filesystems by UUID, but rather by actual device (/dev/xvd*)…

Heh…forgot the important things :-)

I'm running Ubuntu 12.04. I'm booting off of the "Latest 64-bit Kernel", but the userland is 32 bit.

This might be a bit of a newbie question, but why wouldn't I want to refer to the file-systems via their UUID? The idea of using the UUID is that even if the filesystem names change, the actual filesystem that gets mounted is always the same. Is there something different when running on a Linode (Xen)?

I'll submit a ticket with Linode (just in case it isn't something I did :-) )

On a Linode, the UUID will change under various circumstances (e.g. when restoring from a backup, a new filesystem is created); however, the actual device name will not change from what is set in the configuration profile. It is also possible for the UUID to not be unique, if you clone a filesystem and then attach both the clone and the original to the same Linode. (I don't believe the cloning operation generates a new UUID, but I may be wrong.)

I have a Ubuntu 12.04 deploy from a month or two back, and it does use device names (/dev/xvd*) instead of UUIDs… it is a 64-bit userland, tho, so it isn't the exact same image you're running.

I don't think I've ever had a Linode configured by UUID either (mine are all straight 32-bit). fstab always uses the xvd* device names.

While I think the UUID mounts can make sense in a physical machine where it helps to have a configuration that can be independent of what port a particular disk may be plugged into, I think it has less use (and can even be problematic) in a Linode where the xvd* devices are themselves logical and easily configured.

That is, using xvda (for example) for the root device delegates control over what that device is to the Linode Manager configuration, so you can easily pick and choose (or change temporarily) what disk image that maps to. I know I switch out various images for testing - sometimes just user partitions, but also sometimes the boot to test out a different distribution. Having a UUID would break in such cases, at least where you were changing non-boot devices.

– David

Thanks for the advice. I switched the fstab to use the hard-coded /dev/xvd* paths, and the system boots without any issues. I appreciate the help!

For the good of the cause, I also had drive migration issues, but they were different:

While booting, the kernel started printing the following messages over and over on my root partition xvda:

xvda: rw=0, want=2585907792, limit=8396800
attempt to access beyond end of device 
Buffer I/O error on device xvda, logical block 1292953895
attempt to access beyond end of device 

The solution after a few quick rounds with Linode support was to boot to Finnix and run fsck on my root partition. Fsck fixed a bunch of inode issues and then the machine booted cleanly. I also moved to an older 32-bit kernel, but I don't believe this made a difference.

This was the first time (in my memory) running fsck on this machine image in over 5 years with Linode. Impressive.

This happened to mine as well, I had them manually copy the disk image from the old host.