Recent content by BriBriBri

Yes, you can install the drivers manually. Both during Windows setup and from within Windows. But if you're wanting all the drivers and services to be installed and functioning, the inability of the MSI-based installer to install everything is a bit of an issue.

Confirmed. Glad to see this thread. I have experienced the same. Neither an upgrade of an existing VM with previous install of virtio-win nor a fresh install of virtio-win-0.1.262 on a newly built Windows 11 VM succeeds.

Hello! Thank you for the replies! Yes, this is a PVE-managed Ceph cluster. pveversion output follows. . . root@pve1:~# pveversion -v proxmox-ve: 8.2.0 (running kernel: 6.8.4-3-pve) pve-manager: 8.2.2 (running version: 8.2.2/9355359cd7afbae4) proxmox-kernel-helper: 8.1.0 pve-kernel-5.15...

Located another corrupt ISO today. It was uploaded Feb 17, 2024. Can't say when the corruption occurred. But, given the findings above, I have no reason not to suspect that it happened after the file was uploaded and its checksum verified, like the other two. Having found this, I've now...

We uploaded two ISOs on June 11 via the proxmox GUI and made use of the checksum matching feature while doing so. root@pve1:/var/log/pve/tasks# pvenode task list --type imgcopy...

Thank you, dcsapak. setuid bit set as you described. Tape backup job is now running.

Hello dcsapak, As requested: root@pbs2:~# ls -lh /usr/lib/x86_64-linux-gnu/proxmox-backup/* -rwxr-xr-x 1 root root 27M Jun 5 07:23 /usr/lib/x86_64-linux-gnu/proxmox-backup/proxmox-backup-api -rwxr-xr-x 1 root root 427K Jun 5 07:23...

can't even load a tape and format it. Get same "Error: this program needs to be run with setuid root" as above.

Tape backup jobs now fail since upgrading to pbs 3.2-4 last week: 2024-06-22T14:00:00-07:00: waiting for drive lock... 2024-06-22T14:00:00-07:00: Starting tape backup job 'pbs2-primary-140tb:pve-tapes:lto8:weekly-tape-backup' 2024-06-22T14:00:00-07:00: task triggered by schedule 'sat 14:00'...

Our first tape job since updating pbs last week is showing same: 2024-06-22T14:00:00-07:00: waiting for drive lock... 2024-06-22T14:00:00-07:00: Starting tape backup job 'pbs2-primary-140tb:pve-tapes:lto8:weekly-tape-backup' 2024-06-22T14:00:00-07:00: task triggered by schedule 'sat 14:00'...

Thank you! All is understood now!

Thanks. Yes, I should have been more explicit. It's clearly the verify job conflicting. I'm just surprised that a snapshot that has already been synced across the previous night (and is now being verified) is being re-opened by the current sync job prior to syncing across the newer snapshot...

Hi All, Is this expected behavior? PBS1 is our older pbs server that was removed to a remote site. Its sole function is to nightly reach out to our newer (PBS2) server and sync its datastore to itself. PBS1 then also runs its own verify jobs on the datastore it then holds. PBS1's sync log...

Well, I think we can call this a fluke or a test that went awry (perhaps due to the HBA issue that threw my processes (etc.) askew). I repeated my test scenario just now, using the last three weekends of written tapes as well as the original tape from the weekend where the catalog wasn't found...

One note: We had an hba that proved untrustworthy early on when we first imported the encryption key and did the intitial inventory. With the info provided above (thanks!) I now find myself focusing on this (which I had forgotten about). I now suspect things got into an odd state (the content...