A preliminary note: I'm the author of GPT fdisk (gdisk), so I understand what it does pretty well.
First, when doing any sort of maintenance at this level, backups are critical! Before you do anything else, you should create backups that will enable you to re-create your system if things go phenomenally badly, because in some cases, things do go phenomenally badly. Keeping backups is a good idea in general, and it's imperative if you're about to do something risky.
Second, your question doesn't specify why you want to do this. The answer to that question is important. As the saying goes, "if it ain't broke, don't fix it." If it simply offends your sensibility that you're booting from an MBR disk, then it's probably not worth the risk. Even with an adequate backup, restoring everything if things go wrong will be much more of a hassle than learning to live with your sensibility being offended. OTOH, if you're having problems of some sort, then it's possible that converting your MBR disk to a GPT disk will fix the problems; but without knowing what problems you're experiencing, I can't offer any opinion on whether this will actually help, or if there might be an easier way to fix the problem.
Third, the gdisk command will do the actual MBR-to-GPT conversion; see its documentation on this type of conversion for details. Since you're already booting in EFI mode, the boot loaders on your /dev/sdb1 will be unchanged; however:
- The NVRAM-resident boot loader definitions that point to those boot loaders are likely to need to change, so the system might stop booting until you change them. OTOH, if you have the Linux fallback loader installed as
EFI\BOOT\bootx64.efi, then recovery may be automatic, depending on how the EFI responds. On the other-other hand, you may need to be prepared with a Boot Repair disk, rEFInd on a USB flash drive, or some other emergency recovery plan.
- Depending on how you have
/etc/fstab and your boot loader configured, you may need to adjust configurations. The filesystem names and UUIDs will remain unchanged from this shift, but the partition names and GUIDs will change. (Technically, MBR doesn't support either partition names or partition GUIDs, but some tools try to create stand-ins for these values.) AFAIK, Ubuntu sets up /etc/fstab in ways that shouldn't need changing by default, but I don't know about the GRUB configuration; that might need fixing post-change. Also, of course, if you've made any non-standard changes to /etc/fstab or your boot loader, there may be changes required as as result.
- The type code for your
/dev/sdb1 is currently 0x0b, which gdisk will translate to its 0700. This is technically incorrect for an ESP, so you may want to change it to EF00. (For that matter, 0x0b is incorrect for an ESP on an MBR disk. In theory, it should be changed to 0xef if you leave the disk using MBR. In fact, depending on why you want to make the change to GPT, changing the type code on /dev/sdb1 might be all you need to do.)
Fourth, I see you've got a big Windows NTFS partition on /dev/sdb. If you're currently booting Windows from a partition on a GPT /dev/sda, then I'm guessing that the NTFS partition on /dev/sdb is a data partition. If so, then it should continue working in Windows after this change. Windows normally ties its partition table type to its boot mode, though, so if you're doing something else -- like if you're booting Windows in BIOS/CSM/legacy mode from /dev/sdb2 -- then changing /dev/sdb from MBR to GPT could render Windows unbootable.
