UUID

[Michael Havens]

I suppose not..... so where are UUID and  logical addresses kept?

:-)~MIKE~(-:

On Tue, Dec 30, 2014 at 9:04 PM, Michael Havens <bmike1 at 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 at 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 at gmail.com> 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 <bmike1 at 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
>>>> <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
>>>> <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
>>>> <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 at lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>
>>
>>
>>
>> --
>> James McPhee
>> jmcphe at gmail.com
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20141230/bb0462ed/attachment.html>