Hi again, we've seen this fingerprint issue recur for the first time (in the last week) since it was fixed in PVE 8.0 (we run PMG this way).
https://forum.proxmox.com/threads/fingerprint-error.126816/#post-593864 (to show the history/changelog/etc we're talking about)
Quite strange, as we'd...
Your browser cache being stale/irrelevant sounds most likely.
Odds are the content was expired by the time you revisited, so was re-fetched properly. Just a guess.
For what it's worth, I've just upgraded from 8.0.11 to 8.1.2 (GUI reflected version, PMG is 8.1.0) - and both hosts report OK!
pmg-api (8.1.2) over (8.0.11) ...
proxmox-mailgateway (8.1.0) over (8.0.1)...
:)
Hi all,
Just looking for views of SAS vs NVMe for guest storage in current times, to get an idea of what makes the most sense with a potential system build:
This is the compatibility matrix we've been sent about the options. SAS 24G @ 15.36TB per drive seems wise to me.
From there, another...
Ah hah, though what are your thoughts on my screenshots showing that even the GUI cannot discern some actions' success/error state?
Thanks, this is the normal process for us. These power actions seem different, and there are enough discrepancies to query it further!
I'm working in PHP, not Bash? Using a class to fire API calls. JSON replies.
Status makes sense and we use this already, but this is about determining whether a call failed to execute properly, even if syntactically OK.
That's where it seems the UPID is returned regardless, but via JSON if we...
Hi there,
Just comparing the attached realities of what is reflected for an OK action and then a not-OK action, there are a few things I'm curious about:
Rather than just firing and hoping that if the request went through OK, that it is actually OK, we need to know the error/status.
Comparing...
Thank you, however for 8.0 the latest installer is dated months before our latest update in late October. We haven't missed much.
The update was done then intentionally to make sure we were ahead of 8.1 but equally up and away from 7.4. Timed up well.
Hi there,
Just checking the best way to "pin" a Proxmox VE version before running an upgrade, so as to update to the latest "dot" releases of the previous sub-major.
Now that v8.1 is released, we'd like to get everything up to latest v8.0 minor/patch - is this easily doable? I'd imagine so via...
Hi there,
Looking at your forum in dark mode, it's gorgeous with the orange outlines used cleverly in a primary/secondary context against the black/dark.
Whereas in the Proxmox software packages, this isn't the case - orange is hardly used. Could this be expanded in PVE 8.1?
I would say that...
Thanks, that makes sense. Did this and removed it afterwards. Couldn't see any wraparound during any check-point.
Both reboots went well, nothing to report. Thanks very much for your help with this, glad to know it's already covered.
Thanks, have done that now...
I'd say this segment only could benefit from being more clear about legacy mode, as it currently sounds like it is OK (bug does not apply).
https://pve.proxmox.com/wiki/Upgrade_from_7_to_8#GRUB_Might_Fail_To_Boot_From_LVM_in_UEFI_Mode
Thanks again for all of your work on this. 1 in 120-250...
Okay great, thanks for the additional clarity!
Remove the grubtemp LV at which stage - after 1st reboot to PVE 7.4-latest? Then check vgscan before 2nd reboot?
Also, did you see my comment about orange outlines on forum vs GUIs, and that the software would benefit from it?
Thank you, I've done that to the impacted machine and it reports no wraparound now.
However, as we need to reboot into latest 7.4.x and then into 8.0.x (ie. 2x, not 1x, reboots), should we do anything abnormal re: PVE 7 up to 8?
Just to be sure we don't end up stuck with an un-bootable machine...
Thank you for this. However, the updated wiki page seems to imply that legacy-booting systems are not impacted - but we have 1 that is?
https://forum.proxmox.com/threads/pve-7-4-x-to-7-4-latest-grub-failed-to-write-to-dev-sda-then-grub-install-real-gives-disk-not-found-i.135235/
I sent over...
Thank you both, this gives a new perspective - we have exact series configured per-guest right now, this seems wise so will retain it.
We are leveraging some of the flags available, and each cluster only has nodes with the same silicon model exactly, so no issue there.
Hi,
I'm curious about this - with the new update to the default CPU type when creating via GUI, and the note about performance efficiency, should we be changing over from using the most-closest-matching one from the list, instead to using x86-64-v2-AES to reap these rewards?
Or are there...
OMG Friedrich, I knew you lauched dark mode to the softwares, but come on - I had no idea about the forum!
It's fantastic with the orange. You should consider using orange outlines in the GUIs more? Love your stuff. :)
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.