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:
>
>> 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@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@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
~MIKE~(-:%0A>%20%0A>%20On%20Tue,%20Dec%2030,%202014%20at%208:27%20PM,%20James%20Mcphee%20<jmcphe@gmail.com>%20wrote:%0A>%20%0A>%20>%20/boot/grub/device.map%20keeps%20things%20mapped%20by%20logical%20location%20and%20uuid.%0A>%20>%20%20if%20you%20created%20a%20new%20partition,%20even%20if%20it%20had%20the%20same%20UUID,%20it%20would%0A>%20>%20have%20a%20different%20logical%20address.%0A>%20>%0A>%20>%20On%20Tue,%20Dec%2030,%202014%20at%207:41%20PM,%20Michael%20Havens%20<bmike1@gmail.com>%20wrote:%0A>%20>%0A>%20>>%20better%20yet%20could%20someone%20come%20explain%20it%20to%20us:%0A>%20>>%0A>%20>>%20http://www.bleepingcomputer.com/forums/t/561405/new-partition-scheme/page-2#entry3582631%0A>%20>>%0A>%20>>%20:-)~MIKE~(-:%0A>%20>>%0A>%20>>%20On%20Tue,%20Dec%2030,%202014%20at%207:38%20PM,%20Michael%20Havens%20<bmike1@gmail.com>%20wrote:%0A>%20>>%0A>%20>>>%20I'm%20part%20of%20another%20discussion%20in%20which%20we%20are%20talking%20about%20UUIDs.%0A>%20>>>%20This%20is%20what%20one%20of%20the%20participants%20said:%0A>%20>>>%0A>%20>>>%20As%20pointed%20out%20earlier%20by%20bmike1%20in%20response%20to%20my%20comment%20about%20GRUB2%0A>%20>>>%20not%20being%20able%20to%20find%20the%20OS%20if%20you%20move%20the%20partitions,%20by%20default%20on%0A>%20>>>%20Linux%20Mint%20GRUB2%20will%20use%20UUIDs%20*(the%20id%20tag%20for%20your%20partitions)*%20instead%0A>%20>>>%20of%20partition%20numbers*(eg:%20sda1,%20sda2,%20etc)*,%20so%20I%20was%20incorrect%20when%20I%0A>%20>>>%20said%20GRUB2%20won't%20be%20able%20to%20find%20the%20boot%20partition.%20Linux%20Mint's%20fstab%20*(a%0A>%20>>>%20config%20file%20read%20at%20boot%20to%20tell%20Mint%20which%20partitions%20should%20be%0A>%20>>>%20automatically%20mounted)*%20also%20uses%20UUIDs%20by%20default%20so%20no%20issues%20there.%0A>%20>>>%20Therefore%20I%20do%20not%20see%20any%20reason%20why%20moving%20your%20installation%20would%20be%20an%0A>%20>>>%20issue%20*(keep%20reading)*,%20so%20I%20decided%20to%20test%20it%20in%20a%20virtual%20machine.%20I%0A>%20>>>%20installed%20Linux%20Mint%2017.1%20-%20Cinnamon%2064bit%20*(I've%20been%20wanting%20to%20try%0A>%20>>>%20Linux%20Mint%20for%20a%20while.%20I've%20been%20downloading%20a%20little%20bit%20of%20the%20ISO%20each%0A>%20>>>%20day)*%20with%20a%20partition%20layout%20similar%20to%20yours%20*(http://i.imgur.com/3qg0bSv.png%0A>%20>>>%20<http://i.imgur.com/3qg0bSv.png>%20)*.%20I%20wasn't%20able%20to%20move%20the%20extended%0A>%20>>>%20partition%20using%20Gparted,%20or%20create%20a%20new%20one.%20In%20the%20end%20I%20just%20created%203%0A>%20>>>%20new%20primary%20partitions%20and%20cloned%20the%20Linux%20Mint%20logical%20partitions%20to%20them%0A>%20>>>%20using%20dd%20*(dd%20is%20a%20sector%20based%20cloning%20tool%20that%20comes%20pre-installed%0A>%20>>>%20on%20most%20Linux%20operating%20systems.%20I%20used%20it%20because%20this%20way%20the%20new%0A>%20>>>%20partitions%20will%20have%20the%20same%20UUIDS%20as%20the%20Linux%20Mint%20ones%20did.%20This%20is%0A>%20>>>%20important%20since%20GRUB2%20is%20using%20UUIDS%20to%20identify%20the%20boot%20partition%20and%0A>%20>>>%20because%20the%20fstab%20uses%20UUIDs%20to%20identify%20your%20swap%20partition)*.%20Then%20I%0A>%20>>>%20deleted%20the%20old%20partitions%20*(%20http://i.imgur.com/hDBT5ns.png%0A>%20>>>%20<http://i.imgur.com/hDBT5ns.png>%20)*.%20The%20result%20was%20that%20GRUB2%20was%0A>%20>>>%20unable%20boot%20Linux%20Mint%20because%20it%20couldn't%20find%20the%20boot%20partition%20*(I%0A>%20>>>%20don't%20know%20why%20this%20is,%20but%20if%20I%20had%20to%20take%20a%20guess%20it%20would%20be%20that%20GRUB2%0A>%20>>>%20was%20probably%20storing%20part%20of%20itself%20on%20the%20extended%20partition's%20VBR%20which%0A>%20>>>%20no%20longer%20exists%20because%20I%20deleted%20the%20extended%20partition)*.%20So%20GRUB2%0A>%20>>>%20needed%20to%20be%20repaired.%20Using%20a%20Linux%20Mint%20Live-cd,%20I%20ran%20%22sudo%0A>%20>>>%20add-apt-repository%20ppa:yannubuntu/boot-repair%22*(this%20adds%20a%20third%20party%0A>%20>>>%20repo%20that%20has%20boot-repair%20in%20it,%20because%20it's%20not%20available%20in%20the%20default%0A>%20>>>%20Linux%20Mint%20repos)*,%20%22sudo%20apt-get%20update%22%20*(to%20update%20apts%20package%0A>%20>>>%20list)*,%20%22sudo%20apt-get%20install%20boot-repair%22%20*(to%20download%20and%20install%0A>%20>>>%20boot-repair)*,%20and%20then%20I%20ran%20boot-repair%20with%20its%20default%20settings%20*(be%0A>%20>>>%20warned%20by%20default%20boot-repair%20uploads%20information%20about%20your%20computer%0A>%20>>>%20online,%20you%20can%20disable%20this)*.%20This%20successfully%20fixed%20GRUB2,%20and%20I%0A>%20>>>%20was%20able%20to%20boot%20Linux%20Mint%20again%20*(http://i.imgur.com/ZJhXRbe.png%0A>%20>>>%20<http://i.imgur.com/ZJhXRbe.png>%20)*.%0A>%20>>>%0A>%20>>>%20I%20then%20said:%0A>%20>>>%0A>%20>>>%20I%20think%20I%20know%20why%20it%20needed%20repairing.%20The%20reason%20is%20that%20you%20created%0A>%20>>>%20new%20partitions%20(new%20UUIDs)%20and%20deleted%20the%20old%20partitions%20(the%20existing%0A>%20>>>%20UUIDs).%0A>%20>>>%0A>%20>>>%20to%20which%20he%20responded:%0A>%20>>>%0A>%20>>>%20The%20partitions%20were%20cloned%20with%20dd%20so%20that%20they%20would%20have%20the%20same%0A>%20>>>%20UUIDs.%20I%20also%20used%20%22sudo%20blkid%22%20to%20verify%20the%20uuids%20of%20the%20new%20primary%0A>%20>>>%20partitions%20matched%20before%20deleting%20the%20original%20logical%20partitions.%0A>%20>>>%0A>%20>>>%20He%20and%20I%20both%20remarked%20between%20the%20first%20and%20last%20quote%20that%20we%20thought%0A>%20>>>%20the%20UUID%20of%20the%20partition%20would%20of%20had%20it%20recognized%20regardless%20of%20what%20we%0A>%20>>>%20did%20with%20other%20partitions%20on%20the%20drive.%20Could%20someone%20kindly%20explain%20to%20us%0A>%20>>>%20wherein%20the%20difficulties%20lie?%0A>%20>>>%20:-)~MIKE~(-:%0A>%20>>>%0A>%20>>%0A>%20>>%0A>%20>>%20---------------------------------------------------%0A>%20>>%20PLUG-discuss%20mailing%20list%20-%20PLUG-discuss@lists.phxlinux.org%0A>%20>>%20To%20subscribe,%20unsubscribe,%20or%20to%20change%20your%20mail%20settings:%0A>%20>>%20http://lists.phxlinux.org/mailman/listinfo/plug-discuss%0A>%20>>%0A>%20>%0A>%20>%0A>%20>%0A>%20>%20--%0A>%20>%20James%20McPhee%0A>%20>%20jmcphe@gmail.com%0A>%20>%0A>%20>%20---------------------------------------------------%0A>%20>%20PLUG-discuss%20mailing%20list%20-%20PLUG-discuss@lists.phxlinux.org%0A>%20>%20To%20subscribe,%20unsubscribe,%20or%20to%20change%20your%20mail%20settings:%0A>%20>%20http://lists.phxlinux.org/mailman/listinfo/plug-discuss%0A>%20>%0A>%20---------------------------------------------------%0A>%20PLUG-discuss%20mailing%20list%20-%20PLUG-discuss@lists.phxlinux.org%0A>%20To%20subscribe,%20unsubscribe,%20or%20to%20change%20your%20mail%20settings:%0A>%20http://lists.phxlinux.org/mailman/listinfo/plug-discuss "Reply to this message")
(text/plain)
