4

On a new GPT initialized disk (second PC disk) I created a FAT32 partition using gparted. I want to use it as an EFI System Partition so I flagged it as boot. After that I checked the UUID using the gparted “partition information” option and it reported: 09B1-97A5. As far as I understand it should be C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

I also checked my running operative system disk (Ubuntu 14) and found that Gparted reports EB78-9AD2 for my actual boot partition UUID. What exactly is gparted reporting as UUID on my EFI system partition and why it doesn’t match with the expected C12A7328-F81F-11D2-BA4B-00A0C93EC93B ID?

artificer
  • 205

3 Answers3

13

You're confusing filesystem UUIDs with partition GUIDs. The former are stored within the filesystems and can be used in Linux's /etc/fstab file or by the mount command via the UUID= parameter. (Despite the "UUID" name, they aren't always true UUIDs. FAT doesn't use UUIDs, for instance, so for FAT, the serial number is used instead of a UUID.) These UUIDs should be unique for any given filesystem, although cloned filesystems might have duplicated UUIDs.

Partition GUIDs, by contrast, are available only on GPT disks. There are actually two GUIDs associated with a partition:

  • A type code GUID, which is what the C12A7328-F81F-11D2-BA4B-00A0C93EC93B figure is. That particular GUID identifies an EFI System Partition (ESP). This is equivalent to the one-byte partition type codes of an MBR disk.
  • A partition's unique GUID, which, like a filesystem UUID, should be unique to any particular partition. The EFI uses this GUID internally, and some versions of Linux utilities enable you to use it much like a filesystem UUID, but using the PARTUUID= label rather than UUID=.
Rod Smith
  • 45,120
  • 7
  • 66
  • 108
4

I found the solution. As suggested by a poster the UUIDs on GParted have nothing to do with GPT. I actually found the right GUID using: sudo gdisk /dev/sda. After that I used the option "i"

artificer
  • 205
0

Ahoy!

I can confirm this solution as it worked for me. I had been booting into emergency mode for quite a while. I would hit enter and type exit or ctrl-d , sometimes I had to do this several times but eventually it would usually work. I wanted to figure out what was wrong and boot into Ubuntu without emergency mode. Windows 10 came factory installed on my laptop which was booting fine. I removed windows 10 and installed a test copy of Ubuntu on /dev/sda1 and it was not booting into emergency mode, so then I was hopeful it was not a hardware error i.e. just broken. I read this solution

"Welcome to emergency mode!" Think it is a fsck problem

And thought maybe if I ran fsck -y /dev/sda6 it would solve the problem, unfortunately that did not work. Then I read this article and ran more /etc/fstab on both Ubuntu partitions. Even though I installed both Ubuntu partitions on the same laptop, there were two different UID values for /boot/efi in fstab.

The old Ubuntu install that was booting into emergency mode had this

UUID=BEAA-DA23  /boot/efi       vfat    defaults      0       1

The new blank Ubuntu test partition had this

/dev/disk/by-uuid/AB34-68EA /boot/efi vfat defaults 0 1

I ran blkid and it tells you the UUID's of the root partition and the swap partition, but not the /boot/efi partition which in hindsight was the one causing the problem. When I removed my windows partition, I had to create a new /boot/efi partition, and the UUID changed when I did this. The new Ubuntu install noticed this and configured correctly. But the old one, the one where I installed all my programs and had all my data, remained unchanged. If you want to find the UUID of your /boot/efi partition without installing a new copy of Ubuntu, you can run ls -l /dev/disk/by-uuid and the UUID of the /boot/efi partition should be there. It is also listed in gparted if you run sudo gparted and double click on the partition. Gparted also told me to install some packages via apt so it could properly read a vfat partition. I did this using apt via

sudo apt install dosfstools mtools

I ran sudo emacs /etc/fstab, on the old Ubuntu partition, commented out the old line like this

#UUID=BEAA-DA23  /boot/efi       vfat    defaults      0       1

And under it put the new /boot/efi information from the Ubuntu test partition.

/dev/disk/by-uuid/AB34-68EA /boot/efi vfat defaults 0 1

And so far that is working. I had a random reboot earlier that doesnt usually happen, but I think that might be something else. When I rebooted it again did not boot into emergency mode and booted straight into Ubuntu. Problem appears solved so far! Thanks for pointing me in the right direction hope that explanation can help someone else.

Good Luck!

update:

I am starting to think the UUID is another new partially broken replacement that wasnt as good as what we already had. For the /boot/efi partition, and all your other ones for that matter, I think you can avoid UUID's all together and just use the /dev/sda2 device which is traditionally what has worked and what Linux/Unix has always done. I think

/dev/sda2 /boot/efi vfat defaults 0 1

Will work just fine, and you can avoid UUID's altogether unless they have some other use I am not aware of. Google says it is good for if you are adding storage, but when the UUID changes, you have to manually fix fstab the same as when the /dev device changes. And when I add storage I normally leave the boot partition in place.

It seems they are creating many different aliases to reference the same thing again. Simply using the /dev name is how it has always been done, and is IMO better than some long meaningless random number that in some hidden way points to the /dev device.

user3408541
  • 141