Upgrading PVE Tries to Remove proxmox-ve package

I just did a apt update && apt upgrade and the issue is now resolved on my system.
 
Last edited:
I can confirm it is fixed. Doing refresh from GUI and then upgrade this is the result, all is well in the proxworld again :) Thanks for the quick fix!

Code: 
Starting system upgrade: apt-get dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  proxmox-kernel-6.8.8-1-pve-signed
The following packages will be upgraded:
  libnvpair3linux libpve-cluster-api-perl libpve-cluster-perl
  libpve-guest-common-perl libpve-notify-perl libpve-rs-perl libpve-storage-perl
  libuutil3linux libzfs4linux libzpool5linux proxmox-kernel-6.8 pve-cluster
  pve-container pve-esxi-import-tools pve-firmware pve-ha-manager pve-manager
  shim-signed shim-signed-common spl zfs-initramfs zfs-zed zfsutils-linux
23 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 244 MB of archives.
After this operation, 582 MB of additional disk space will be used.
Do you want to continue? [Y/n]
 
fabian said:
pve-no-subscription repository should be fixed again.

if you followed the advice here and have installed proxmox-backup-client 3.2.5-1 to work around the warning, please be aware that that version has opt-in experimental features that might not yet be ready for prime time. unless you explicitly invoke vzdump or proxmox-backup-client with parameters to enable those features, it should still be safe.
Click to expand...
Can confirm. Thank you and sorry about the game yesterday ;)
 
Thanks for the quick fix! And also sorry about the game yesterday, you guys did remarkably well! France had more luck than skill. ;)
 
Thanks to the PVE team for the quick fix !

Tested on 4 nodes on my side with 4 different workarounds applied before the currently fixed repo's and all seems well.

For those that used "test" repo in some way you should check some packages else you are not perfectly on track with normal "no-sub" state of packages :
- proxmox-backup-client still on 3.2.5-1 (3.2.3-1 was kept in the current "no-sub" repo) for all "test" repo (temp) users of any method AFAIK
- proxmox-backup-file-restore still on 3.2.5-1 (3.2.3-1 was kept in the current "no-sub" repo) for those that use update + dist-upgrade instead of solely wget + dpkg the proxmox-backup-client package on "test" repo
- pve-qemu-kvm version 9.0.0-3 instead of 8.1.5-6 if you used update + dist-upgrade method on "test" repo without holding this pacakge

Have a nice day,

EDIT: AFAIK a simple "apt install proxmox-backup-file-restore=3.2.3-1" and _similar_ commands for the other packages should put you back right on track ...
 
Last edited:
  • Like
Reactions: acasto
Previously run the update and got same message as everybody here. Updated moments ago and it looks fine.
1718700568440.png
 
fabian said:
if you followed the advice here and have installed proxmox-backup-cli
fabian said:
pve-no-subscription repository should be fixed again.

if you followed the advice here and have installed proxmox-backup-client 3.2.5-1 to work around the warning, please be aware that that version has opt-in experimental features that might not yet be ready for prime time. unless you explicitly invoke vzdump or proxmox-backup-client with parameters to enable those features, it should still be safe.
Click to expand...
Click to expand...
Thanks Fabi!
 
Bash: 
wget http://download.proxmox.com/debian/pve/dists/bookworm/pvetest/binary-amd64/proxmox-backup-client_3.2.5-1_amd64.deb
dpkg -i proxmox-backup-client_3.2.5-1_amd64.deb

Worked for me on a fresh install over debian 12.
 
kohly said:
workaround:

Bash: 
apt-mark hold proxmox-ve pve-manager
apt update
apt full-upgrade

when finaly fixed by staff:
Bash: 
apt-mark unhold proxmox-ve pve-manager

apt update

apt full-upgrade
Click to expand...

Hi all,

Thank you so much! This worked flawlessly!

It's elegant and shouldn't give any trouble in the future!

I've updated four nodes without issues.

Kind regards!
 
Hi all,

There is no official statement that it is fixed, is there? I don't want to offend: just a question to maybe improve things. I suppose you have automated regression tests. Why is repository integrity of a "fresh install" not integrated into automated regression tests? I think it would be worth it for the only two outward-facing repositories.

Thanks for some insight from staff.

Thanks,
lopiuh
 
AFAIK one can consider THIS POST as an official statement, at least when a non-prod, "no-sub" repo is concerned.

Good question for the automated regression tests !
 
lopiuh said:
Hi all,

There is no official statement that it is fixed, is there? I don't want to offend: just a question to maybe improve things. I suppose you have automated regression tests. Why is repository integrity of a "fresh install" not integrated into automated regression tests? I think it would be worth it for the only two outward-facing repositories.

Thanks for some insight from staff.

Thanks,
lopiuh
Click to expand...

see reply by @Spaneta (and my linked earlier reply, in case you missed it).

such checks exist, they didn't cover a specific (rarely used) manual process that was the cause of yesterday's issue, they now (or soon will, the change is not yet deployed) cover that as well. and yes, an additional test that checks this from the outside would be a good addition as well.
 
  • Like
Reactions: Omaha2002 and gfngfn256
fabian said:
see reply by @Spaneta (and my linked earlier reply, in case you missed it).

such checks exist, they didn't cover a specific (rarely used) manual process that was the cause of yesterday's issue, they now (or soon will, the change is not yet deployed) cover that as well. and yes, an additional test that checks this from the outside would be a good addition as well.
Click to expand...

Thank you very much for this positive information.

Yours
lopiuh
 
The new kernel seems to have some sort of issue with Thunderbolt or at least my QNAP QNA-T310G1S on my Intel NUC 13 . With 6.8.4-3-pve it works fine:

[ 1.740375] atlantic 0000:2e:00.0: enabling device (0000 -> 0002)
[ 2.148198] atlantic 0000:2e:00.0 enp46s0: renamed from eth0
[ 5.815641] atlantic 0000:2e:00.0 enp46s0: entered allmulticast mode
[ 8.189958] atlantic 0000:2e:00.0 enp46s0: atlantic: link change old 0 new 10000
[ 17.399990] atlantic 0000:2e:00.0 enp46s0: entered promiscuous mode

And it is alive and well too, with valid firmware:

root@pve-3:~# ethtool -i enp46s0
driver: atlantic
version: 6.8.4-3-pve
firmware-version: 3.1.57
expansion-rom-version:
bus-info: 0000:2e:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: yes
root@pve-3:~#

But with 6.8.8 it fails: (keeping all other packages on the latest build as above - flipping the kernel versions for boot only)

[ 1.725221] atlantic 0000:2e:00.0: enabling device (0000 -> 0002)
[ 2.010209] atlantic: Bad FW version detected: ffffffff
[ 2.010379] atlantic: probe of 0000:2e:00.0 failed with error -95

No more network. Still trying to determine if this is an atlantic driver problem (given the .ko module file is the same size on both versions) or Thunderbird related. Any ideas/hints welcome!
 
I try to upgrade i am getting this error:

~# apt full-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
pve-kernel-5.15.30-2-pve
The following packages will be upgraded:
pve-container
1 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
2 not fully installed or removed.
Need to get 0 B/139 kB of archives.
After this operation, 377 MB disk space will be freed.
Do you want to continue? [Y/n] y
Reading changelogs... Done
(Reading database ... 73713 files and directories currently installed.)
Removing pve-kernel-5.15.30-2-pve (5.15.30-3) ...
Examining /etc/kernel/postrm.d.
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 5.15.30-2-pve /boot/vmlinuz-5.15.30-2-pve
update-initramfs: Deleting /boot/initrd.img-5.15.30-2-pve
run-parts: executing /etc/kernel/postrm.d/proxmox-auto-removal 5.15.30-2-pve /boot/vmlinuz-5.15.30-2-pve
/etc/kernel/postrm.d/proxmox-auto-removal: 4: .: cannot open /usr/share/proxmox-kernel-helper/scripts/functions: No such
file
run-parts: /etc/kernel/postrm.d/proxmox-auto-removal exited with return code 2
Failed to process /etc/kernel/postrm.d at /var/lib/dpkg/info/pve-kernel-5.15.30-2-pve.postrm line 14.
dpkg: error processing package pve-kernel-5.15.30-2-pve (--remove):
installed pve-kernel-5.15.30-2-pve package post-removal script subprocess returned error exit status 1
dpkg: too many errors, stopping
Errors were encountered while processing:
pve-kernel-5.15.30-2-pve
Processing was halted because there were too many errors.
E: Sub-process /usr/bin/dpkg returned an error code (1)
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back