Hi, I have a small weird problem, wondering if anyone has seen this. Proxmox 6.x host running on a stock template install on OVH environment (SW raid 2x2tb config which OVH provide and I've used many times before without issue).
Normally when I do updates on such an environment, I do
then all is good and happy days.
(I find some other forum posts that suggest now one should not do apt-get upgrade at all? but only dist-upgrade?)
However, this time - it seems to be getting stuck, right now here:
and then, nothing. I've left it overnight in a 'screen' session and it just won't push past this. I am not sure what it is waiting for.
I googled and found a similar discussion in the forum, and it had suggested a few things to validate grub and md / disk grub setup, approx hints below are shown:
So. Right now I am pretty sure if I reboot this box, it will not come back up, which would be a drama/hassle I prefer to avoid.
I'm not sure how to force it to fix itself up. I've tried to remove and reinstall the kernel package but that didn't go so well.
Clearly it is grumpy trying to generate the new initrd boot image file but having some problem.
Sigh.
Any hints are greatly appreciated.
Otherwise plan B, which arguably is not impossible, just feels stupid.
-- make backup of VMs on the box. Make backup of config (really not all that much ...)
-- blow it away using template OVH proxmox install, re-do from scratch onto the bare metal setup.
-- update to latest proxmox, before doing anything further.
-- restore config and VM, and happy days. Just an hour or two of outage for some fun admin work. Whee.
-- but I am happier if I don't have to go that route since ?it is more work, and more gross? and ideally this sort of problem is one that I would prefer to know how to actually fix instead of work-around.
Thanks,
Tim
Normally when I do updates on such an environment, I do
Code:
apt-get update
(wait / proceed)
apt-get upgrade
(wait / proceed)
then
apt-get dist-upgrade
(wait/proceed)(I find some other forum posts that suggest now one should not do apt-get upgrade at all? but only dist-upgrade?)
However, this time - it seems to be getting stuck, right now here:
Code:
... lots of output from updates...
then...
Setting up pve-kernel-5.4.41-1-pve (5.4.41-1) ...
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.4.41-1-pve /boot/vmlinuz-5.4.41-1-pve
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.4.41-1-pve /boot/vmlinuz-5.4.41-1-pve
update-initramfs: Generating /boot/initrd.img-5.4.41-1-pveand then, nothing. I've left it overnight in a 'screen' session and it just won't push past this. I am not sure what it is waiting for.
I googled and found a similar discussion in the forum, and it had suggested a few things to validate grub and md / disk grub setup, approx hints below are shown:
Code:
root@proxmox6:~# grub-probe --target=device /
/dev/md2
root@proxmox6:~# grub-probe --target=device /boot
/dev/md2
root@proxmox6:~# grub-probe --device /dev/md2 --target=fs_uuid
6fb5fb9e-188e-457d-8310-f9985659e25d
root@proxmox6:~# cat /etc/default/grub
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
# openstack-debian-images disables OS prober to avoid
# loopback detection which breaks booting
GRUB_DISABLE_OS_PROBER=true
GRUB_DEVICE=UUID=6fb5fb9e-188e-457d-8310-f9985659e25d
root@proxmox6:~#
SO, HERE WE ARE:
root@proxmox6:~# apt-get dist-upgrade
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
(other update did not exit cleanly so locks were still in place - remove them manually).
root@proxmox6:~# rm /var/lib/dpkg/lock-frontend
root@proxmox6:~# rm /var/lib/dpkg/lock
Then try to kick it along again:
root@proxmox6:~# apt-get dist-upgrade
E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
OK, fine, we do it your way:
root@proxmox6:~# dpkg --configure -a
Setting up pve-kernel-5.4.41-1-pve (5.4.41-1) ...
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.4.41-1-pve /boot/vmlinuz-5.4.41-1-pve
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.4.41-1-pve /boot/vmlinuz-5.4.41-1-pve
update-initramfs: Generating /boot/initrd.img-5.4.41-1-pve
(wait forever, have a nice day)So. Right now I am pretty sure if I reboot this box, it will not come back up, which would be a drama/hassle I prefer to avoid.
I'm not sure how to force it to fix itself up. I've tried to remove and reinstall the kernel package but that didn't go so well.
Clearly it is grumpy trying to generate the new initrd boot image file but having some problem.
Sigh.
Any hints are greatly appreciated.
Otherwise plan B, which arguably is not impossible, just feels stupid.
-- make backup of VMs on the box. Make backup of config (really not all that much ...)
-- blow it away using template OVH proxmox install, re-do from scratch onto the bare metal setup.
-- update to latest proxmox, before doing anything further.
-- restore config and VM, and happy days. Just an hour or two of outage for some fun admin work. Whee.
-- but I am happier if I don't have to go that route since ?it is more work, and more gross? and ideally this sort of problem is one that I would prefer to know how to actually fix instead of work-around.
Thanks,
Tim
