> I had a vague attempt to remember the start and end blocks before giving up and reinstalling.
Next time, remember parted's <code>rescue</code> command.
>The first thing i did was plug it into my mac and made a dd image of it (dd if=/dev/disk2 of=/image.iso).
If it makes you feel any better, this statement alone tells me that you've got a much better chance at fixing the problem than 95% of the people who post on /r/techsupport. It was the first thing I was going to suggest.
Since you appear to have some understanding of *nix, I figure this might be useful for you: http://www.gnu.org/software/parted/manual/html_chapter/parted_2.html#SEC24
I have never used rescue on anything before, let alone an HFS+ drive that's been formatted to (presumably) NTFS. I'd guess that if a new partition table has been written, then your chances of simply using rescue to fix it seem pretty unlikely but it is possible that you could write a new partition table that matches the old one and see where that gets you. Worth a shot, better than resorting to piracy and working off of a disk image means you aren't at risk of losing anything anyway.
No. It creates a sparse bundle for all your backup stuff.
But your issue here will be that (I've just read) Time Machine can't work on a FAT-formatted drive. You'd have to repartition so that there's a HFS partition for Time Machine. GNU Parted is pretty good for this: http://www.gnu.org/software/parted
Fair enough (like I mentioned, I am open to either way ;-)
I was in a similar tough spot in the past (our VMware team changed their template to a 20G vmdk from our standard 50G and we did not catch it right away. So, we had to fix all of them after the fact.
Unfortunately I don't have time/cycles at the moment to test this out... but, take a look at
blockdev --rereadpt
parted - resize partition
I believe there are 2 methods to consider:
* grow the VMDK and add another partition at the end of the disk
* grow the VMDK and resize partition 1 to utilize the new space
Either way - I would definitely test a few reboots, possibly some other lvm-type activity, post-grow.
This feels like it is a task that should be doable - I'll try to build a VM this evening and see what I can break ;-)
EDIT: I totally missed one very important fact.. you're not wanting to mess with the OS disk. (correct me if I am wrong).
If that is the case:
* add a second disk (with enough space to accommodate your anticipated volume sizes)
* extend the VG
* pvmove everything to the second disk
* vgreduce the old disk out of the VG
* remove the disk
there is a bunch of stuff to fill in the blanks between those bullet-points, but I think you get the idea. I assume the goal is to have a VM which has only 2 x VMDK attached, and that method will achieve that, and without a reboot.
I'm also curious if I should/need to makefs.ext4 on each partition after running parted. http://www.gnu.org/software/parted/manual/html_chapter/parted_2.html the manual says if you specify it, parted should put it in the proper Filesystem. Unless I'm misunderstanding.
But going through the beginners guide it says to make the filesystem on each after running parted, and when doing so it says the filesystem (ext4) already exists. Again, thanks for all the insight! I don't know if I should just be putting all this in the main post or not.. Fairly new here.
*edit Also I know I can makelabels on partitions, is there a safe naming scheme I can use that will show up when I use lsblk on the dev so that I can easily see what each partition is?
Thank you for trying to help, but I think that most of your information is incorrect.
> A partition table isn't a label at all
It literally is. See e.g. the <code>parted</code> manual's description of the <code>mklabel</code> command, which is how you create a partition table. The footnote explicitly mentions that "everyone seems to have a different word for 'disk label' — these are all the same thing: partition table, partition map."
> GPT v. MBR merely describes the scheme in which the disk is partitioned
Yes; they are types of disk labels (aka partition tables).
> In the case of MBR, the partition table itself is chainloaded from the MBR
No.
Wikipedia has a very thorough description of what a Master Boot Record looks like.
Chainloading is something entirely separate. Wikipedia also describes it: "chain loading replaces the currently executing program in its entirety." In the context of booting a computer, you could chainload the MBR (which is an imprecise way of talking about chainloading the bootloader that the MBR typically contains, which is executable); this involves some other program (probably some other bootloader) transfering control to that bootloader. As an example, you see chainloading sometimes when you're using PXE or iPXE to boot a disk image.
The partition table is also part of the MBR (on an MBR-labeled disk) but cannot be chainloaded because it is not executable.
In any event, your response ignores the context of my comment, which is that it is relatively rare for disks to directly contain filesystems. Generally, the disk is partitioned, and each partition contains a filesystem.
Sorry, I haven't used parted very often...never formatted my disks with it..so not sure what is does there. Only switched recently from fdisk to parted because of GPT support...didn't even know it has a format option ;) I usally prefer the mkfs tools there.
Edit: It looks like parted has no format option..to format your disks you have to use the mkfs tools afterwards. You set the partition type with "mkpart" but that is only a type number in the partition table to help the OSes...nothing stops you to format a partition in a completely different format. The worst that can happen is that the OS then just overwrite your ext4 partition you put on a partition marked as swap ;)
parted has a rescue
command that will look for partitions on a disk and create them if found.
http://www.gnu.org/software/parted/manual/html_node/rescue.html
If the partition filled the whole disk, you would do something like rescue 0% 100%
.