I ran in circles for three days before I found a solution to this. It seems to be a unique problem that, lucky me, I created myself.
Symptom
When I resized /dev/mapper/pve-root onto a second local drive and restarted the server, GRUB would throw and error that it couldn't "find 'lvmid/<PVUUID/VGUUID>'" where PVUUID and VGUUID were presented accordingly. It immediately dropped to a grub-rescue prompt.
Cause
I was adding a physical volume /dev/sdb with a Disklabel type: dos and extending the volume group, and subsequently pve/root, onto it.
Resolution
I had to change the Disklabel type to gpt to match /dev/sda using parted as 'fdisk' does not seem to be able to change the Disklabel, only the partition type.
Details
DISCLAIMER: This might not be the correct/sanctioned (or only) way to do this, but it worked for me. I pieced together some information I found scattered about, but mostly from the Proxmox forums and comparing my server's twin, which was running just fine.
Since this was a new install from the beginning, I had the luxury of reinstalling Proxmox (over and over and over...) without losing anything. If you do not have this luxury, you can boot from a LiveCD of your flavor of Linux to run the LVM commands to undo what you've done. These instructions assume you know how to do that and get to a terminal. I used Ubuntu 17.10 and I ran sudo su before starting for expediency.
First, you'll want to reduce pve/root back to its original size in order to free the additional storage from use. Start by finding the allocated physical extents (PE) of the physical volume (pv) you added, in this case sdb1:
:~# pvdisplay /dev/sdb1
--- Physical volume ---
PV Name /dev/sdb1
VG Name pve
PV Size 232.88 GiB / not usable 2.16 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 59618
Free PE 0
Allocated PE 59618
PV UUID pZMzLR-EIrN-NHBn-qFQ1-AkRz-1BSS-L4WsaB
Continue by reducing the extents and filesystem of the logical volume (lv), pve/root:
:~# lvresize -l -PE -r pve/root
where -l is the extents switch, -PE is the negative Allocated PE identified in pvdisplay, and -r resizes the filesystem in the same operation, saving you from having to run an fs2resize.
Next, reduce the volume group (vg), pve:
:~# vgreduce pve /dev/sdb1
and then remove the physical volume (pv) from the volume group (vg) to free it:
:~# pvremove /dev/sdb1
Second, you'll need change the Disklabel type of /dev/sdb to match that of your primary storage, usually /dev/sda. In my case, sda was gpt and sdb was dos. Begin by installing parted which can handle this, unlike fdisk:
:~# apt install parted
and run parted on your second storage and change the Disklabel type, called Partition Table, with mktable:
:~# parted /dev/sdb
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mktable gpt
Finally, quit parted:
(parted) quit
Lastly, you can re-add your physical volume to your volume group and extend /dev/pve/root as described elsewhere. Your server should then reboot as expected without getting tripped up on the disparate Disklabel types.
I hope this saves someone from a lot of frustration.
Symptom
When I resized /dev/mapper/pve-root onto a second local drive and restarted the server, GRUB would throw and error that it couldn't "find 'lvmid/<PVUUID/VGUUID>'" where PVUUID and VGUUID were presented accordingly. It immediately dropped to a grub-rescue prompt.
Cause
I was adding a physical volume /dev/sdb with a Disklabel type: dos and extending the volume group, and subsequently pve/root, onto it.
Resolution
I had to change the Disklabel type to gpt to match /dev/sda using parted as 'fdisk' does not seem to be able to change the Disklabel, only the partition type.
Details
DISCLAIMER: This might not be the correct/sanctioned (or only) way to do this, but it worked for me. I pieced together some information I found scattered about, but mostly from the Proxmox forums and comparing my server's twin, which was running just fine.
Since this was a new install from the beginning, I had the luxury of reinstalling Proxmox (over and over and over...) without losing anything. If you do not have this luxury, you can boot from a LiveCD of your flavor of Linux to run the LVM commands to undo what you've done. These instructions assume you know how to do that and get to a terminal. I used Ubuntu 17.10 and I ran sudo su before starting for expediency.
First, you'll want to reduce pve/root back to its original size in order to free the additional storage from use. Start by finding the allocated physical extents (PE) of the physical volume (pv) you added, in this case sdb1:
:~# pvdisplay /dev/sdb1
--- Physical volume ---
PV Name /dev/sdb1
VG Name pve
PV Size 232.88 GiB / not usable 2.16 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 59618
Free PE 0
Allocated PE 59618
PV UUID pZMzLR-EIrN-NHBn-qFQ1-AkRz-1BSS-L4WsaB
Continue by reducing the extents and filesystem of the logical volume (lv), pve/root:
:~# lvresize -l -PE -r pve/root
where -l is the extents switch, -PE is the negative Allocated PE identified in pvdisplay, and -r resizes the filesystem in the same operation, saving you from having to run an fs2resize.
Next, reduce the volume group (vg), pve:
:~# vgreduce pve /dev/sdb1
and then remove the physical volume (pv) from the volume group (vg) to free it:
:~# pvremove /dev/sdb1
Second, you'll need change the Disklabel type of /dev/sdb to match that of your primary storage, usually /dev/sda. In my case, sda was gpt and sdb was dos. Begin by installing parted which can handle this, unlike fdisk:
:~# apt install parted
and run parted on your second storage and change the Disklabel type, called Partition Table, with mktable:
:~# parted /dev/sdb
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mktable gpt
Finally, quit parted:
(parted) quit
Lastly, you can re-add your physical volume to your volume group and extend /dev/pve/root as described elsewhere. Your server should then reboot as expected without getting tripped up on the disparate Disklabel types.
I hope this saves someone from a lot of frustration.