Welp, I went and installed a linux mint vm and see that grub.cfg has the root pointed at hd0 and a big fat UUID.  Gotta love it.  The lesson here is if you're playing with your partitions, rerun the grub stuffs.

On Tue, Dec 30, 2014 at 9:38 PM, Michael Havens <bmike1@gmail.com> wrote:
so then why did his virtual machine not look at the partitions as UUIDs but rather as /dev/sd?? ? 

:-)~MIKE~(-:

On Tue, Dec 30, 2014 at 9:29 PM, James Mcphee <jmcphe@gmail.com> wrote:
Hrmph, I guess you don't need one these days.  I'm working off an old system that's been upgraded since the bronze age.


On Tue, Dec 30, 2014 at 9:13 PM, Michael Havens <bmike1@gmail.com> wrote:
I suppose not..... so where are UUID and  logical addresses kept?

:-)~MIKE~(-:

On Tue, Dec 30, 2014 at 9:04 PM, Michael Havens <bmike1@gmail.com> wrote:
well I thought to myself that I should investigate the file before asking any questions but:

 cat /boot/grub/device.map
cat: /boot/grub/device.map: No such file or directory

I then reasoned that I would play the <tab><tab> game and see what the files were in /boot/grub .

grub.cfg  grubenv

so I suppose it is grub.cfg?

:-)~MIKE~(-:

On Tue, Dec 30, 2014 at 8:27 PM, James Mcphee <jmcphe@gmail.com> wrote:
/boot/grub/device.map keeps things mapped by logical location and uuid.  if you created a new partition, even if it had the same UUID, it would have a different logical address.

On Tue, Dec 30, 2014 at 7:41 PM, Michael Havens <bmike1@gmail.com> wrote:

:-)~MIKE~(-:

On Tue, Dec 30, 2014 at 7:38 PM, Michael Havens <bmike1@gmail.com> wrote:
I'm part of another discussion in which we are talking about UUIDs.
This is what one of the participants said:

As pointed out earlier by bmike1 in response to my comment about GRUB2 not being able to find the OS if you move the partitions, by default on Linux Mint GRUB2 will use UUIDs (the id tag for your partitions) instead of partition numbers(eg: sda1, sda2, etc), so I was incorrect when I said GRUB2 won't be able to find the boot partition. Linux Mint's fstab (a config file read at boot to tell Mint which partitions should be automatically mounted) also uses UUIDs by default so no issues there. Therefore I do not see any reason why moving your installation would be an issue (keep reading), so I decided to test it in a virtual machine. I installed Linux Mint 17.1 - Cinnamon 64bit (I've been wanting to try Linux Mint for a while. I've been downloading a little bit of the ISO each day) with a partition layout similar to yours (http://i.imgur.com/3qg0bSv.png ). I wasn't able to move the extended partition using Gparted, or create a new one. In the end I just created 3 new primary partitions and cloned the Linux Mint logical partitions to them using dd (dd is a sector based cloning tool that comes pre-installed on most Linux operating systems. I used it because this way the new partitions will have the same UUIDS as the Linux Mint ones did. This is important since GRUB2 is using UUIDS to identify the boot partition and because the fstab uses UUIDs to identify your swap partition). Then I deleted the old partitions ( http://i.imgur.com/hDBT5ns.png ). The result was that GRUB2 was unable boot Linux Mint because it couldn't find the boot partition (I don't know why this is, but if I had to take a guess it would be that GRUB2 was probably storing part of itself on the extended partition's VBR which no longer exists because I deleted the extended partition). So GRUB2 needed to be repaired. Using a Linux Mint Live-cd, I ran "sudo add-apt-repository ppa:yannubuntu/boot-repair"(this adds a third party repo that has boot-repair in it, because it's not available in the default Linux Mint repos), "sudo apt-get update" (to update apts package list), "sudo apt-get install boot-repair" (to download and install boot-repair), and then I ran boot-repair with its default settings (be warned by default boot-repair uploads information about your computer online, you can disable this). This successfully fixed GRUB2, and I was able to boot Linux Mint again (http://i.imgur.com/ZJhXRbe.png ).

I then said:

I think I know why it needed repairing. The reason is that you created new partitions (new UUIDs) and deleted the old partitions (the existing UUIDs).

to which he responded:

The partitions were cloned with dd so that they would have the same UUIDs. I also used "sudo blkid" to verify the uuids of the new primary partitions matched before deleting the original logical partitions.


He and I both remarked between the first and last quote that we thought the UUID of the partition would of had it recognized regardless of what we did with other partitions on the drive. Could someone kindly explain to us wherein the difficulties lie?
:-)~MIKE~(-:


---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss



--
James McPhee
jmcphe@gmail.com

---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss



---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss



--
James McPhee
jmcphe@gmail.com

---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss


---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss



--
James McPhee
jmcphe@gmail.com