MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Resize_disks",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "1491": {
                "pageid": 1491,
                "ns": 0,
                "title": "Recover From Grub Failure",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "== General advice ==\n\nDuring to the upgrade from 3.x to 4.x, I found myself without a working grub and unable to boot. Monitor shows:\n*<code>grub rescue ></code>\n\nYou can use Proxmox installation ISO in verison 5.4 or newer, and select debug mode.\nOn the second prompt you'll have the full Linux tools, including LVM, ZFS, ..., available.\nIf you exit that prompt you will come to the installation screens, simply hit abort there.\n\nAlternatively, one can use a 64 bit version of Ubuntu or Debian Rescue CD.\n\nBoot Proxmox VE in debug mode, or the Ubuntu/Debian off the ISO.  We do not want to install Ubuntu/Debian, just run it live off the ISO/DVD.\n\nFirst We need to activate LVM and mount the the root partition that is inside the LVM container.\n*<code>sudo vgscan</code>\n*<code>sudo vgchange -ay</code>\n\nMount all the filesystems that are already there so we can upgrade/install grub. Your paths may vary depending on your drive configuration.\n*<code>sudo mkdir /media/RESCUE</code>\n*<code>sudo mount /dev/pve/root /media/RESCUE/</code>\n*<code>sudo mount /dev/sda1 /media/RESCUE/boot</code>\n*<code>sudo mount -t proc proc /media/RESCUE/proc</code>\n*<code>sudo mount -t sysfs sys /media/RESCUE/sys</code>\n*<code>sudo mount -o bind /dev /media/RESCUE/dev</code>\n*<code>sudo mount -o bind /run /media/RESCUE/run</code>\n\nChroot into your proxmox install.\n*<code>chroot /media/RESCUE</code>\n\nThen update grub and install it.\n*<code>update-grub</code>\n*<code>grub-install /dev/sda</code>\n\nIf there are no error messages, you should be able to reboot now.\n\nCredit: https://www.nerdoncoffee.com/operating-systems/re-install-grub-on-proxmox/\n\n== Recovering from grub \"disk not found\" error when booting from LVM ==\n\nThis section applies to the following setups:\n\n* PVE 7.4 (or earlier) hosts with their boot disk on LVM\n* PVE 8 hosts that have their boot disk on LVM, boot in UEFI mode and were upgraded from PVE 7\n\nIn these setups, the host might end up in a state in which grub fails to boot and prints an error <code>disk `lvmid/<vg uuid>/<lv uuid>` not found</code>. An example (of course, the UUIDs vary):\n\n <nowiki>\nWelcome to GRUB!\n\nerror: disk `lvmid/p3y5O2-jync-R2Ao-Gtlj-It3j-FZXE-ipEDYG/bApewq-qSRB-zYqT-mzvP-pGiV-VQaf-di4Rcz` not found.\ngrub rescue> </nowiki>\n\nThis error \"disk `...` not found\" error is originally [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987008 caused by a grub bug]. LVM metadata is stored on-disk in a ring buffer, so occasionally the current metadata will wrap around the end of the ring buffer. However, if there is a wraparound in the ring buffer, grub fails to parse the metadata and fails to boot with the above error.\n\nThe recommended steps differ between the PVE 7.4 and PVE 8.\n\n=== PVE 7.x ===\n\nThis subsection applies to PVE 7.4 (or earlier) hosts with their boot disk on LVM.\n\nPVE 7.4 ships <code>grub 2.06-3~deb11u5</code> which is affected by the [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987008 bug] (though earlier versions may also be affected). This was also reported multiple times in the forum already, see [https://forum.proxmox.com/threads/98761/ here] and [https://forum.proxmox.com/threads/123512/ here]. \n\n==== Temporary Workaround ====\n\nIn order to '''temporarily''' work around this bug and get the host to a bootable state again, it is sufficient to trigger an LVM metadata update. The updated metadata will reside in one contiguous section of the metadata ring buffer, so no wraparound occurs anymore. grub will then be able to parse the metadata correctly and boot again.\n\nOne simple way to trigger an LVM metadata update is to create a small logical volume:\n* Boot from a live USB/CD/DVD with LVM support, e.g. [https://grml.org/ grml]\n* Run <code>vgscan</code>\n* Create a 4MB logical volume named <code>grubtemp</code> in the <code>pve</code> volume group: <code>lvcreate -L 4M pve -n grubtemp</code>\n* Reboot. PVE should boot normally again.\n* You can now remove the <code>grubtemp</code> volume: <code>lvremove pve/grubtemp</code>\n\nNote that there are many other options for triggering a metadata update, e.g. using <code>lvchange</code> to extend an existing logical volume or add a tag to an existing logical volume.\n\nThe workaround is only temporary: If the host is (re)booted at a time when there is again a wraparound in the metadata ring buffer, grub will fail to boot again.\n\nOn a running PVE system, you can check whether there is a wraparound in the metadata ring buffer using the following command:\n\n <nowiki>\nvgscan -vvv 2>&1 | grep \"Reading metadata\" </nowiki>\n\nIf the output lines end with <code>(+0)</code>, there is no wraparound. If they end with <code>(+N)</code> for any other number <code>N</code>, there is a wraparound and the grub will most likely fail to boot after a reboot.\n\n==== Permanent Fix ====\n\nThe only '''permanent''' fix for PVE 7.x is:\n* Apply the temporary workaround to be able to boot PVE again\n* Upgrade to PVE 8 by following the [[Upgrade_from_7_to_8|upgrade guide]].\n\n=== PVE 8 ===\n\nThis subsection applies to PVE 8 hosts that have their boot disk on LVM, boot in UEFI mode and were upgraded from PVE 7.\n\nPVE 8 ships <code>grub 2.06-13</code> in which the [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987008 grub bug] is fixed. However, on hosts that boot in UEFI mode and were upgraded from PVE 7, it can happen that the updated grub 2.06-13 EFI binary is not installed to the EFI system partition (ESP) at <code>/boot/efi/EFI/proxmox/grubx64.efi</code>. As a result, when booting in UEFI mode, the host still runs the older <code>grub 2.06-3~deb11u5</code> binary that is affected by the grub bug. To find out whether this is the case, check its mtime using <code>ls -l /boot/efi/EFI/proxmox/grubx64.efi</code>. If it is older than the time of the upgrade from PVE 7 to 8, the host still runs the older grub binary when booting in UEFI mode.\n\n==== Temporary Workaround ====\n\nThe temporary workaround for PVE 8 to get the host in a bootable state [[#Temporary_Workaround|is the same as for PVE 7.x (see above)]].\n\n==== Permanent Fix ====\n\nThe issue can be fixed permanently on PVE 8 by installing the correct grub metapackage for UEFI and choosing the correct UEFI boot entry.\n\nFirst, apply the [[#Temporary_Workaround|temporary workaround]] to be able to boot into PVE 8 again. When booted into PVE 8, run the following command. It checks if the host is indeed booted in UEFI mode, and if yes, installs the correct grub metapackage for UEFI:\n\n <nowiki>\n[ -d /sys/firmware/efi ] && apt install grub-efi-amd64 </nowiki>\n\nThis will remove the <code>grub-pc</code> package, and update the binary on the ESP. You can verify that the mtime of <code>/boot/efi/EFI/proxmox/grubx64.efi</code> was updated.\n\nNote that this will not update the default EFI binary at <code>/boot/efi/EFI/BOOT/BOOTx64.EFI</code>, which might still be the grub binary that is affected by the bug. Consequently, make sure that you select the <code>proxmox</code> boot entry when booting in UEFI mode. If needed, you can adjust the boot order directly in the UEFI firmware or using the <code>efibootmgr</code> tool (see [https://manpages.debian.org/stable/efibootmgr/efibootmgr.8.en.html#Changing_the_boot_order its manpage])."
                    }
                ]
            },
            "1471": {
                "pageid": 1471,
                "ns": 0,
                "title": "Renaming a PVE node",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "== Introduction ==\n\nProxmox VE uses the ''hostname'' as a nodes name, so changing it works similar to changing the host name.\nThis must be done on a empty node.\n\n== Change Hostname ==\n\nRename a standalone PVE host, you '''need''' to edit the following files:\n* /etc/hosts\n* /etc/hostname\n\nYou can use pre-installed editor like <code>nano</code> (easy) or <code>vi</code> (advanced), for example:\n\n nano /etc/hosts\n\nIn the above files replace all occurrences of the ''old name'' with the '''new one'''. Ensure that <tt>/etc/hosts</tt> has an entry with the hostname mapped to the IP you want to use as main IP address for this node.\n\nThere are other files which you may want to edit, they are not important for the functions of Proxmox VE itself.\n* /etc/mailname\n* /etc/postfix/main.cf\n\nIf your node is in a '''cluster''', where it is not recommended changing its name, adapt <code>/etc/pve/corosync.conf</code> so that the nodes name is changed also there.\nSee https://pve.proxmox.com/pve-docs/chapter-pvecm.html#pvecm_edit_corosync_conf\n\n== Cleanup ==\n\nThe SSH keys don't need to be edited unless you really want to (and if you do, make sure you make the corresponding change on every other machine that SSH public key appears on).\n\nNow move the configuration files, as the ''pmxcfs'' has a few restrictions to ensure consistency you cannot rename non empty folders. Thus if you have VMs or Containers on the node, which is not recommended when changing a nodes name, you have to recreate the folder structure and copy files per folder level.\n\nAlso copy the contents of <tt>/var/lib/rrdcached/db/pve2-{node,storage}/''old-hostname''</tt> to <tt>/var/lib/rrdcached/db/pve2-{node,storage}/''new-hostname''</tt> and remove the old directory.\n\n== References ==\n\n* [https://forum.proxmox.com/threads/proxmox-node-name-change.14327/ Forum Post]\n\n[[Category: HOWTO]]"
                    }
                ]
            }
        }
    }
}