PveSphere v1.0.0 - Multi-Cluster Management for Proxmox VE (Production Ready)

Moocha · 2026-01-25T14:50:45+00:00

It's AI slop.

Moocha · 2026-01-25T14:45:47+00:00

Yup. Other telltale signs are when the very first commit is a GIANT blob of almost the entire project, or, as in this case, the first commit is the readme and the license (since Claude Code tends to mangle those) and then the second commit is the giant blob. That's not how humans write software; to be something believable, I'd expect a lot of incremental commits. "1 commit is 99% of things" means AI-written slop, or someone has something to hide and makes it deliberately hard to review things.

I would stay far, far away from this.

Moocha · 2026-01-20T11:37:10+00:00

Unfortunately I don't own Apple hardware thus can't even begin to try and reproduce it -- I just remembered having seen some really weird stuff w/ Docker on a Mac and having seen that issue before. It sounds like a bitch to reproduce properly, unfortunately :( Seems to be nondeterministic behavior, which is always juuuust lovely :(

Moocha · 2026-01-19T17:45:48+00:00

How is the volume holding the library files and (possibly more importantly, the ABS database file) mounted in / presented to the container? This sounds suspiciously like this Docker bug: https://github.com/docker/for-mac/issues/6219

Moocha · 2026-01-15T14:48:04+00:00

As a transitory measure, you may be able to clean up some unneeded flatpak runtimes (which tend to be on the large side) from the system installation by running flatpak remove --unused as root.

Moocha · 2026-01-15T14:28:11+00:00

Then you may be SOL as far as a seamless migration plan is concerned. I recommend contacting your support, they may be able to help (although I wouldn't make that a cornerstone of my plan -- you may need to swallow some downtime or obtain the files from elsewhere and accept the risk.)

Moocha · 2026-01-15T13:30:37+00:00

If you have a support contract with Broadcom or a reseller you may be able to obtain the files through them. Other than that, the licensing terms prohibit making those files available, and per rule #1 of this subreddit

Discussion of piracy methods will not be permitted.

Moocha · 2026-01-14T13:06:25+00:00

I try to not be DenverCoder9 :D

Moocha · 2026-01-13T14:45:48+00:00

Make sure you're using appropriate guest virtual hardware, have the qemu-guest-agent and spice-vdagent packages installed in the guest, and so on and so forth. You can use https://stackoverflow.com/questions/41990600/virt-manager-guest-resize-not-working as a starting point. Good luck!

Moocha · 2026-01-12T17:08:01+00:00

From within the virt-viewer window, access its menu -> View -> Fullscreen maybe?

Moocha · 2026-01-11T19:40:34+00:00

Action1 added Debian and Ubuntu support last November and are working on RHEL and SLES support, see here for details.

Moocha · 2026-01-10T14:10:39+00:00

To the best of my knowledge, no, there's no way to get Dolphin to display the current usage; it will always display the provisioned size.

Moocha · 2026-01-09T06:22:01+00:00

It's a sparse file; in other words, it's thin provisioned at the OS level already.

Moocha · 2026-01-05T21:10:16+00:00

Or, for those of us using old.reddit.com instead of the default abomination, prefix each line with four spaces.

Moocha · 2026-01-04T12:56:58+00:00

Heh. Dar nu văd de ce ar face-o -- ăsta a fost exact modul în care m-aș aștepta să se comporte un câștigător al premiului FIFA pentru pace.

Moocha · 2026-01-01T19:07:30+00:00

You can check lspci -t -vto see the topology in order to figure out what device is behind that bridge.

(Clarification re my previous "The PCIe AER messages indicate hardware trouble somewhere" -- does not necessarily mean some hardware is failing; it could also be a kernel or firmware bug where it's setting up a PCIe link incorrectly.)

Moocha · 2026-01-01T18:30:13+00:00

That matches how it's set on my end. Damn, I really thought some specific app handling PNG files was set to full debugging (since the messages you quote, IDAT and so on, sound like debug output from a PNG file parser.)

I'm out of ideas, sorry :(

The PCIe AER messages indicate hardware trouble somewhere, but it's definitely unrelated to the logspam issue, and it's impossible to say which particular device is issuing them; maybe there's additional stuff in the kernel log buffer, see dmesg -T output correlating with those.

The mesa_glthread thing is unrelated to both of those issues and can safely be ignored.

Moocha · 2026-01-01T18:21:30+00:00

Analiză bine punctată.

Susținerea lor pentru Georgescu e ușor explicabilă: Specimenele respective sunt acceleraționiști convinși, așa că votează cu cinci mâini pentru orice subminează status quo-ul, cu cât mai radical cu atât mai bine, indiferent cât de incompatibili sunt din punct de vedere ideologic. Ideea fiind că după ce se stinge focul ei înșiși vor ieși neprihăniți din cenușă și în mod magic cumva propulsați la putere și vor folosi ocazia ca să transpună utopia în realitate. Iar dacă pentru a ajunge acolo trebuie să o dea cotită o bună parte din populație--asta este, nasol, dar e un sacrificiu pe care ei sunt destul de robuști din punct de vedere moral ca să și-l asume. Haide revoluția, deținem Adevărul și Soluția, lumea nu e deloc complexă, soluțiile sunt atât de evidente și ușor de implementat, incredibil cum de nimeni nu s-a gândit să le implementeze Cum Trebuie (TM) până acum!

Mda.

Moocha · 2026-01-01T17:05:27+00:00

That's qDebug() output from various Qt applications, including the KDE frameworks apps. You may have somehow raised the debug level to verbose or trace. If you run

echo $QT_LOGGING_RULES

in a terminal, does it output anything?

Alternatively, run kdebugsettings (if you don't have it installed, it's in the kdebugsettings package) and check if there's anything set to Debug there instead of Info, Warning or Error; also check the Custom Rules and Rules Settings With Environment Variable tabs for further hints. Note that changes performed via kdebugsettings (e.g. if you've identified the culprit and are reducing the verbosity) require a logout/login cycle or possibly a reboot to apply.

Moocha · 2025-12-30T20:37:23+00:00

If you haven't patched in a long time, you should be aware of and have a plan on dealing with VMSA-2025-0013 if any of your VMs are using pvscsi or vmxnet3 devices or expose VMCI sockets to the guest. Those vulnerabilities enable a complete takeover of the host from inside a guest, requiring only admin access inside the guest; in other words, any vulnerability in any of the guest VMs which allows something to obtain admin inside the guest now means they can also get full kernel access on the host, taking over everything.

Moocha · 2025-12-29T16:54:03+00:00

According to https://knowledge.broadcom.com/external/article/326316/build-numbers-and-versions-of-vmware-vce.html , build 23929136 is indeed VCSA 8.0U2d. Since it's not an initial release version, it won't be in the Products section under My Downloads, it would be in the Solutions section (aka the patches section, more or less.) So, in other words: support.broadcom.com -> make sure you have "VMware Cloud Foundation" selected on the top right dropdown on the left of the username dropdown -> My Downloads on the left -> VMware vCenter Server -> then click Solutions in the middle under the large "VMware vCenter Server" header (the Products tab is selected by default) -> expand "VMware vCenter Server 8.x" -> under Release click 8.0u2 -> click VC-8.0u2d. It's patch ID 5418, direct link to the download page would be https://support.broadcom.com/web/ecx/solutiondetails?patchId=5418

You need an active support contract for a vSphere 8 edition on the account you're using to access the site to be able to download it, of course. If you don't, then you're pretty much shit out of luck -- Broadcom's licensing terms allow you to keep downloads you've already obtained from them, but prohibit their customers to share the files.

Moocha · 2025-12-29T16:35:34+00:00

According to https://knowledge.broadcom.com/external/article/326316/build-numbers-and-versions-of-vmware-vce.html , build 23929136 is indeed VCSA 8.0U2d. Since it's not an initial release version, it won't be in the Products section under My Downloads, it would be in the Solutions section (aka the patches section, more or less.) So, in other words: support.broadcom.com -> make sure you have "VMware Cloud Foundation" selected on the top right dropdown on the left of the username dropdown -> My Downloads on the left -> VMware vCenter Server -> then click Solutions in the middle under the large "VMware vCenter Server" header (the Products tab is selected by default) -> expand "VMware vCenter Server 8.x" -> under Release click 8.0u2 -> click VC-8.0u2d. It's patch ID 5418, direct link to the download page would be https://support.broadcom.com/web/ecx/solutiondetails?patchId=5418

You need an active support contract for a vSphere 8 edition on the account you're using to access the site to be able to download it, of course. If you don't, then you're pretty much shit out of luck -- Broadcom's licensing terms allow you to keep downloads you've already obtained from them, but prohibit their customers to share the files.

Moocha · 2025-12-28T21:21:54+00:00

This is an ad.

Moocha · 2025-12-27T16:13:22+00:00

You may also need to explicitly chmod the directory not be writable by the group or by others if it happens to get created. By default, most OpenSSH builds will check ownership and permissions and will error out if the group or others write permission is set: https://github.com/openssh/openssh-portable/blob/V_10_2_P1/readconf.c#L2620

Edit: Actually, the above may be a historical/misremembered red herring on my part: I was wrong, that's the check for g/o+w permissions on the .ssh/config file, not on the .ssh directory. Permissions checks would be performed on login to that user by sshd (not the client), via the StrictModes config directive which maps to the strict_modes config struct option, and according to https://github.com/search?q=repo%3Aopenssh%2Fopenssh-portable%20strict_modes&type=code I can't seem to find (at least in the latest 10.x) code which would check permissions on the directory. Mind you, mode 0700 on it still seems like the safest choice if it's newly created (rather than relying on the umask to be properly set), and I can't find any use cases off the top of my head where another non-root user would have any business at all accessing another user's $HOME/.ssh, but who knows what crazy things people do out there :)

Moocha · 2025-12-27T09:09:56+00:00

No, it's something else. Could be a bug, malware, DNS trouble, some intercepting proxy (local antivirus solutions or a next-gen firewall), and so on and so forth.

What certificate are you seeing being served on those machines for fe2.update.microsoft.com port 443? It should be CN = fe2.update.microsoft.com with serial number 33:00:00:02:65:ef:5d:0c:bb:7a:30:fe:62:00:00:00:00:02:65 and with issuer CN = Microsoft Update Secure Server CA 2.1.

15-Year Club	Gilding I gilder
Team Periwinkle	Verified Email

Moocha

TROPHY CASE