Image appears to be partitioned, resize aborted

Post /proc/mounts too, just in case. What filesystem do you use? The resizer supports only ext2/ext3, I think.

It's ext3, so that's not it. But it's not the filesystem… I can resize that myself if need be. It's the underlying partition I need to have resized.

The other requested bit of output is below, but be warned that it is a dreadfully boring setup:

esben@musvit:/etc$ cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,relatime,errors=remount-ro,barrier=0,data=writeback 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,size=5120k,mode=755 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=50944k,mode=755 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,relatime,size=10240k,mode=755 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,relatime,size=101888k 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0

Yeah, but the dashboard's resize command assumes partition = filesystem, and wants to resize the ext3 inside at the same time as the datafile.

And ugh, that wasn't very well-thought on my end. /etc/mtab says /dev/xvda, or /dev/xvda1? And well, to ask yet another obvious question…

You aren't trying to resize with the Linode powered on, I hope?

/etc/mtab shows /dev/xvda as expected:

esben@musvit:/etc$ cat /etc/mtab 
/dev/xvda / ext3 rw,errors=remount-ro 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,size=5242880,mode=755,size=5242880,mode=755 0 0
tmpfs /run tmpfs rw,noexec,nosuid,size=10%,mode=755,size=10%,mode=755 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
udev /dev tmpfs rw,mode=0755 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,size=20%,mode=1777,size=20%,mode=1777 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620,gid=5,mode=620 0 0

The resize was while not booted.. it wouldn't let me do an online resize, disappointingly enough.

I have a wild theory this is due to grub trying to install itself on /dev/xvda , but that doesn't help me finding a solution.

Hmm!

If it helps any, first two bytes of my disk image (so where the partition table and boot code would be) is all zeros for me.

You can check it out yourself.

# dd if=/dev/xvda bs=512 count=4 | hd
4+0 records in
4+0 records out
2048 bytes (2.0 kB) copied, 3.1051e-05 s, 66.0 MB/s
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  00 c0 0b 00 00 e0 2e 00  00 00 00 00 91 64 21 00  |.Ŕ...ŕ.......d!.|
00000410  e1 ac 0a 00 00 00 00 00  02 00 00 00 02 00 00 00  |áŹ..............|
00000420  00 80 00 00 00 80 00 00  00 20 00 00 d8 b3 52 4c  |......... ..ŘłRL|
00000430  ce b3 52 4c 05 00 23 00  53 ef 01 00 01 00 00 00  |ÎłRL..#.Sď......|
00000440  38 22 1a 4c 00 4e ed 00  00 00 00 00 01 00 00 00  |8".L.Ní.........|
00000450  00 00 00 00 0b 00 00 00  80 00 00 00 3c 00 00 00  |............<...|
00000460  06 00 00 00 03 00 00 00  e4 41 fa 60 cf 65 49 c1  |........äAú`ĎeIÁ|
00000470  92 24 ff 09 58 d3 53 4a  00 00 00 00 00 00 00 00  |.$˙.XÓSJ........|
00000480  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000004c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 3f 00  |..............?.|
000004d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000004e0  08 00 00 00 00 00 00 00  e8 e1 05 00 34 71 39 a6  |........čá..4q9Ś|
000004f0  d4 9d 4d fd b5 90 78 6d  18 64 e6 50 02 01 00 00  |Ô.Mýľ.xm.dćP....|
00000500  00 00 00 00 00 00 00 00  d7 d0 9d 49 49 01 00 00  |........×Đ.II...|
00000510  4a 01 00 00 4b 01 00 00  4c 01 00 00 4d 01 00 00  |J...K...L...M...|
00000520  4e 01 00 00 4f 01 00 00  50 01 00 00 51 01 00 00  |N...O...P...Q...|
00000530  52 01 00 00 53 01 00 00  54 01 00 00 55 01 00 00  |R...S...T...U...|
00000540  56 05 00 00 00 00 00 00  00 00 00 00 00 00 00 02  |V...............|
00000550  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000560  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000570  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800
#

Note the beginning - the asterisk means "repeat line", so from 00000000 to 00000400 there's all zeros.

Your fdisk call from earlier makes me thing there IS something in there in your case, as it shows data; trash data, but still. Quite possibly the GRUB code.

You may try zeroing those two sectors, if you're brave and have backups.

It'd be a matter of

qq if=/dev/zero of=/dev/xvda bs=512 count=2

except with dd instead of qq.

If you can spare the cost, a quick way to make backup would be to purchase a new Linode for a moment, clone the disk to it (you don't have to boot the machine up at all), and then play on one of the copies. You can then cancel the "backup", and get all the money except one day's worth (~75c for Li512) credited back to the account, which'll then be used to cover part of your payment next month. Rest will come from your card, as always.

(Just don't abuse this system; it's a really useful safety valve sometimes, it'd suck if we'd lose it.)

This is getting into "open a trouble ticket" territory. This is a weeeeeeeird one.

Ok, I did have a look at the boot sector, wildly guessing that the problem is there. It is indeed a grub loader. The difference between all zero in the first many bytes and the grub loader sector is the jump instruction

00000000  eb 63 90 00 00 00 00 00  00 00 00 00 00 00 00 00  |.c..............|

which would cause a loaded version to jump into the cdoe proper.

I think I will open a problem ticket… installing grub (by accident) really should not throw off the dashboard tools.

Well, I'm not really sure what they should do in this case. You have a non-standard (or at least not empty) MBR which probably could never happen with normal Linode Manager disk image management. So once the tools see that, I'd think all bets are off and they just consider it unsafe to perform any further operations.

It would be interesting to hear back on any ticket resolution, and if this analysis - that it's the grub installation interfering - was accurate.

– David

> Thank you for contacting us. Due to the grub installation, the Linode Manager would not be able to resize your image because grub does write to your boot record. You'll most likely need to redeploy. If you need to get data off the current image, you can use finnix or deploy a new image and use finnix to copy over the data to the new image. We have a guide on finnix here-

http://library.linode.com/troubleshooti … escue-mode">http://library.linode.com/troubleshooting/finnix-rescue-mode

If you have any other questions, please let us know.

So it appears it is, indeed, the grub image. It is a danger to be aware of when copying an image from an existing server to linode, as the existing server will likely have grub installed.

@esben:

So it appears it is, indeed, the grub image. It is a danger to be aware of when copying an image from an existing server to linode, as the existing server will likely have grub installed.
You're probably ok as long as you copy individual partitions rather than an entire drive, since that more directly maps to Linode disk images. Copying an entire drive really would include partitions (beyond grub) and then definitely not be something the manager could manipulate.

In your case, if the grub installation is erroneous and there really aren't any partitions (e.g,. /dev/xvda is a single filesystem), I'd second the earlier suggestion that zeroing out the MBR might be a simple workaround. You can duplicate the disk image (to a test Linode or just your current Linode if you have space) so you aren't risking your current primary image.

– David