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. https://www.gnu.org/software/grub/manual/html_node/Device-map.html On Tue, Dec 30, 2014 at 9:13 PM, Michael Havens wrote: > I suppose not..... so where are UUID and logical addresses kept? > > :-)~MIKE~(-: > > On Tue, Dec 30, 2014 at 9:04 PM, Michael Havens 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 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 >>> >> >> > > --------------------------------------------------- > 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