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 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 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 wrote: > >> better yet could someone come explain it to us: >> >> http://www.bleepingcomputer.com/forums/t/561405/new-partition-scheme/page-2#entry3582631 >> >> :-)~MIKE~(-: >> >> On Tue, Dec 30, 2014 at 7:38 PM, Michael Havens 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 >