Recent content by jw6677

Thanks, drives are moving around, and /dev naming is not persistent. Rest assured this error message was coming from within the proxmox GUI, so even if this were the issue, it would mean the GUI was allowing the selection of a device that doesn't exist. Here is the proper lsblk, sorry, wrong...

Just adding to this saga now that things are slowly inching towards recovery. I managed to restore a huge chunk of my backups from the tape library back to a datastore, which was exciting, but I immediately ran into the issue of missing the encryption key required to restore the backups. PBS...

Hey folks, The issue doens't appear to be related to old disk stuff on the drive, as i was sure to vgremove, pvremove, wipefs -a, and even had to gdisk+wipefs to create and remove a partition, then wipe the partition table, just to get the changes recognized by the os. I found a (janky)...

Whoops, nope, this is reappearing for a second node in the cluster. Unable to create OSDs: create OSD on /dev/nvme3n1 (bluestore) wiping block device /dev/nvme3n1 200+0 records in 200+0 records out 209715200 bytes (210 MB, 200 MiB) copied, 0.270562 s, 775 MB/s usage: ceph-volume lvm create [-h]...

Edit: Solved on one node with: apt install --reinstall ceph-volume Not sure what happened there, but seems to be good for that particular node. Previously thought totally resolved, but the saga continues

accessing through the web dashboard:8007, I am unable to create new OSDs at this time. Here's the output of the GUI task: create OSD on /dev/sdad (bluestore) creating block.db on '/dev/sdi' Physical volume "/dev/sdi" successfully created. Volume group...

However, this error prevents the tape's catalogue from being added back to PBS, and so, prevents the recovery of data in the tape library. I found a hack/workaround, of modifying the .tmp catalogue filename, but I doubt that it's the correct solution.

Man, I am having terrible luck with PBS and tape archiving this week. When trying to catalog tapes, any which were full prior to my need to restore everything from tape, are erroring out at the end of the tape: 2022-12-18T08:31:53-07:00: File 640: chunk archive for datastore 'store'...

Okay, put together a new library from parts of other dead tape libraries, and have this working. My apologies and best of luck to anyone else who comes across this issue!

This appears to be unrelated to the other issue I am experiencing, wherein empty tapes which are part of a media set cause the inventory command to fail and stop: 2022-12-17T11:58:33-07:00: inventorize media 'JW0129L8' with uuid '7e2637fb-5bc9-4af8-9f09-417e58a6d80c' 2022-12-17T11:58:33-07:00...

Okay, I am definitely at the end of my knowledge when it comes to trying to debug this. Can anyone shed any light on where I should be looking for more error messages or similar to try and figure this out?

Same on my end. Lastly, I've tried a couple of different cables, and a different HBA, to no luck.

root@hal-backup:~# proxmox-backup-manager versions --verbose proxmox-backup 2.3-1 running kernel: 5.15.74-1-pve proxmox-backup-server 2.3.1-1 running version: 2.3.1 pve-kernel-helper 7.3-1 pve-kernel-5.15...

Oh, I forgot to mention, I am not as fortunate as @jaff, my tape library only has one SAS port, and so I cannot use the two cable solution. And I am seeing the issue on read, not write, but it also only appears for larger data transfer tasks, all the smaller tasks of changing tapes, etc, work...

I am passing through an LSI adapter to a PBS VM. The only thing that looks relevant from the host dmesg is: [88947.269220] mpt2sas_cm1: log_info(0x31111000): originator(PL), code(0x11), sub_code(0x1000) [88949.519316] mpt2sas_cm1: log_info(0x31111000): originator(PL), code(0x11)...