Proxmox Virtual Environment 9.0 released!

[scyto]

that usually doesn't mean that it hangs at that point, but that you don't get any of the rest of the output. you could try booting with "quiet" removed from the kernel cmdline (you can edit it for one boot in the Grub menu by hitting 'e'), that should display more messages. likely something delays or blocks the boot, like your suspicion that it's related to networking.. could you then open a new thread with the full journal output for a failed/hanging/slow boot?

hi @fabian

i found the root cuase on my machine (some debate from others if there are other causes)
in the thunderrbolt mesh guide (mine and others) some folks added scripts to `if-up.d` for `lo` and `en0x` interfaces.
these scripts restart frr.service
which never exits, so script never exits = hang
i suspect because frr.service is waiting on network.service lol (so race condition)

quick fix was to remove the script, i further validate and it is 100% the restart frr.service call as a status call in the script instead doesn't hang the system

if you are interested see here

https://gist.github.com/scyto/67fdc...malink_comment_id=5712111#gistcomment-5712111

does proxmox 9 restart frr (wether or not cofigured by hand or sdn) at evey interface up event? if so we no longer need these scripts people did.....

 

[shanreich]

hi @fabian

i found the root cuase on my machine (some debate from others if there are other causes)
in the thunderrbolt mesh guide (mine and others) some folks added scripts to `if-up.d` for `lo` and `en0x` interfaces.
these scripts restart frr.service
which never exits, so script never exits = hang
i suspect because frr.service is waiting on network.service lol (so race condition)

quick fix was to remove the script, i further validate and it is 100% the restart frr.service call as a status call in the script instead doesn't hang the system

if you are interested see here

https://gist.github.com/scyto/67fdc...malink_comment_id=5712111#gistcomment-5712111

does proxmox 9 restart frr (wether or not cofigured by hand or sdn) at evey interface up event? if so we no longer need these scripts people did.....

We added an After directive to the FRR service that waits for networking [1]. Does the full-mesh setup now work potentially without any ifup scripts, since FRR should only get started when networking has been set up?


[1] https://git.proxmox.com/?p=frr.git;a=commit;h=84509be6283fb93c638bab0e958f275cd57a7171

 

[JD2002]

Has anyone seen a situation where using the signed kernel results in system power off within 3-4 mins?

Had a bit of a palaver earlier in the week. I have two clusters running at home. A "homelab" and then one I'll called "production". The simpler explanation is that messing about with the lab cluster is no problem. Messing production can get me in a bit of trouble at the other end of the house.


When 9.0 dropped I went ahead and upgraded the lab cluster (a gaggle of NUCs) -- no problems encountered.

A few days later, I decided to go ahead with production cluster as I had a couple of hours I could use for it. Which is when the trouble started. I tried upgrade (no -- three-four mins later the hosts would power off). I tried fresh install of 9.0. Same behavior. The only way I could return some semblance of stability was by forcing an unsigned kernel. Previously these were running 8.4.x (currently 8.4.8) with the 8.14 bpo12 kernel series with perfect stability since original deployment (Bee-Link GTI13s several months old). Secure boot is disabled. TPM is disabled. Built in audio is disabled -- otherwise the EFI bios settings are stock (not an overclocker). Note that the lab NUC configuration is quite similar. Since I had such a short time window -- and having one's hardware simply power off on you is a bit disconcerting, I aborted the task and rolled the nodes back to 8.4.8 -- which is again -- running brilliantly.

I'll have some time this weekend to take a better-planned try at this -- but thought I'd ask here in event this was a known issue or something between-operator-and-keyboard.

Thanks.

 

[virtualfund]

Just upgraded one of my hosts and see the below warning after running 'pve8to9'. Should I install the 2 packages listed?

WARN: systemd-boot meta-package installed this will cause issues on upgrades of boot-related packages. Install 'systemd-boot-efi' and 'systemd-boot-tools' explicitly and remove 'systemd-boot

Edit: Per the upgrade guide - I installed both packages (already stated they were installed) and removed systemd-boot

 

[lukyjay]

I enabled ballooning on my debian VMs after upgrading and they both report only the minimum allocated amounts and never expanded causing them to crash. This happened on two seperate pve hosts. Both hosts had 50gb ram free.

 

[0xDEADC0DE]

Thanks for the great update.
I found a small bug with Machine Version selection.
The sort order is wrong.
When I updated PVE to 9.0, I thought that there will be a new machine version.
When I looked into the list, it was already at the latest version. (Only Windows needs to change the version. Linux is always latest)


I scrolled down the complete list to see what is the oldest version.


And there I found 10.0. The list should be sorted by number desc and not as string.