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
*%20instead%20of%0A>%20partition%20numbers*(eg:%20sda1,%20sda2,%20etc)*,%20so%20I%20was%20incorrect%20when%20I%20said%0A>%20GRUB2%20won't%20be%20able%20to%20find%20the%20boot%20partition.%20Linux%20Mint's%20fstab%20*(a%0A>%20config%20file%20read%20at%20boot%20to%20tell%20Mint%20which%20partitions%20should%20be%0A>%20automatically%20mounted)*%20also%20uses%20UUIDs%20by%20default%20so%20no%20issues%20there.%0A>%20Therefore%20I%20do%20not%20see%20any%20reason%20why%20moving%20your%20installation%20would%20be%20an%0A>%20issue%20*(keep%20reading)*,%20so%20I%20decided%20to%20test%20it%20in%20a%20virtual%20machine.%20I%0A>%20installed%20Linux%20Mint%2017.1%20-%20Cinnamon%2064bit%20*(I've%20been%20wanting%20to%20try%20Linux%0A>%20Mint%20for%20a%20while.%20I've%20been%20downloading%20a%20little%20bit%20of%20the%20ISO%20each%20day)*%20with%0A>%20a%20partition%20layout%20similar%20to%20yours%20*(http://i.imgur.com/3qg0bSv.png%0A>%20<http://i.imgur.com/3qg0bSv.png>%20)*.%20I%20wasn't%20able%20to%20move%20the%20extended%0A>%20partition%20using%20Gparted,%20or%20create%20a%20new%20one.%20In%20the%20end%20I%20just%20created%203%0A>%20new%20primary%20partitions%20and%20cloned%20the%20Linux%20Mint%20logical%20partitions%20to%20them%0A>%20using%20dd%20*(dd%20is%20a%20sector%20based%20cloning%20tool%20that%20comes%20pre-installed%20on%0A>%20most%20Linux%20operating%20systems.%20I%20used%20it%20because%20this%20way%20the%20new%20partitions%0A>%20will%20have%20the%20same%20UUIDS%20as%20the%20Linux%20Mint%20ones%20did.%20This%20is%20important%0A>%20since%20GRUB2%20is%20using%20UUIDS%20to%20identify%20the%20boot%20partition%20and%20because%20the%0A>%20fstab%20uses%20UUIDs%20to%20identify%20your%20swap%20partition)*.%20Then%20I%20deleted%20the%20old%0A>%20partitions%20*(%20http://i.imgur.com/hDBT5ns.png%0A>%20<http://i.imgur.com/hDBT5ns.png>%20)*.%20The%20result%20was%20that%20GRUB2%20was%20unable%0A>%20boot%20Linux%20Mint%20because%20it%20couldn't%20find%20the%20boot%20partition%20*(I%20don't%20know%0A>%20why%20this%20is,%20but%20if%20I%20had%20to%20take%20a%20guess%20it%20would%20be%20that%20GRUB2%20was%0A>%20probably%20storing%20part%20of%20itself%20on%20the%20extended%20partition's%20VBR%20which%20no%0A>%20longer%20exists%20because%20I%20deleted%20the%20extended%20partition)*.%20So%20GRUB2%20needed%0A>%20to%20be%20repaired.%20Using%20a%20Linux%20Mint%20Live-cd,%20I%20ran%20%22sudo%20add-apt-repository%0A>%20ppa:yannubuntu/boot-repair%22*(this%20adds%20a%20third%20party%20repo%20that%20has%0A>%20boot-repair%20in%20it,%20because%20it's%20not%20available%20in%20the%20default%20Linux%20Mint%0A>%20repos)*,%20%22sudo%20apt-get%20update%22%20*(to%20update%20apts%20package%20list)*,%20%22sudo%0A>%20apt-get%20install%20boot-repair%22%20*(to%20download%20and%20install%20boot-repair)*,%20and%0A>%20then%20I%20ran%20boot-repair%20with%20its%20default%20settings%20*(be%20warned%20by%20default%0A>%20boot-repair%20uploads%20information%20about%20your%20computer%20online,%20you%20can%20disable%0A>%20this)*.%20This%20successfully%20fixed%20GRUB2,%20and%20I%20was%20able%20to%20boot%20Linux%20Mint%0A>%20again%20*(http://i.imgur.com/ZJhXRbe.png%20<http://i.imgur.com/ZJhXRbe.png>%20)*.%0A>%20%0A>%20I%20then%20said:%0A>%20%0A>%20I%20think%20I%20know%20why%20it%20needed%20repairing.%20The%20reason%20is%20that%20you%20created%20new%0A>%20partitions%20(new%20UUIDs)%20and%20deleted%20the%20old%20partitions%20(the%20existing%20UUIDs).%0A>%20%0A>%20to%20which%20he%20responded:%0A>%20%0A>%20The%20partitions%20were%20cloned%20with%20dd%20so%20that%20they%20would%20have%20the%20same%20UUIDs.%0A>%20I%20also%20used%20%22sudo%20blkid%22%20to%20verify%20the%20uuids%20of%20the%20new%20primary%20partitions%0A>%20matched%20before%20deleting%20the%20original%20logical%20partitions.%0A>%20%0A>%20He%20and%20I%20both%20remarked%20between%20the%20first%20and%20last%20quote%20that%20we%20thought%20the%0A>%20UUID%20of%20the%20partition%20would%20of%20had%20it%20recognized%20regardless%20of%20what%20we%20did%0A>%20with%20other%20partitions%20on%20the%20drive.%20Could%20someone%20kindly%20explain%20to%20us%0A>%20wherein%20the%20difficulties%20lie?%0A>%20:-)~MIKE~(-:%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)
