rykr

vault-diagnostics-20250402-1355.zipHere are the diags. Not sure it will show anything as it's rebuilding parity now.

what do you mean diagnostics? I pulled it out of its drive caddy thinking that the caddy might be the problem. So far it's working ok and a parity sync is happening. Once the parity sync finishes, I'm going to try it in a different slot in the caddy to see if that slot was the problem. Stay tuned!

got a parity drive that is disabled. I have 2 so still good so far. Looking at attributes the only line that is brown (highlighted) is UDMA CRC error count. This is normally a cable issue. So I power down, swap cables. Take the array offline and remove the drive. Start array, Then stop the array again and add the parity drive back in. It says it will erase all data on the drive which is expected. I start the array and that drive is immediately disabled again. Is there any additional deducing I can do to try and see what the problem is?

So how does br0 and br1 relate to host and bridge when picking a network for a docker container?

I have 3 NICs in my box and one of them is connected to a port on my switch that is hard linked to a given subnet. I see eth1 as a network when I do `docker network ls`. I also see a br1 listed even though I have no idea what that is or why it's there. What I assumed is that eth1 would get an ip address in my IOT subnet and I would use port forwarding when assigning docker containers to it. However, this doesn't seem to be working like I thought. What am I doing wrong?

Have no idea what. could be causing this. Not much in the logs. Restarting helps for a few days. Still looking for clues

Here is sit looking at a dialog from installing an update to unassigned devices plugin. The last lines in the dialog say: plugin: unassigned.devices.plg updated Executing hook script: post_plugin_checks Is it done? who knows... Is it so hard to simply say 'do not close this window until it says installation done' and then print the line 'installation done' when it's done. Would save a lot of questions.

So recently I had an xfs drive that would not mount. I ran xfs_repair multiple times before I realized it kept dying because of OOM. I finally adjusted the options to the point that it ran to completion but now I have tons of files in lost+found. These are not backed up so I'm going to try and save what I can out of it. But I'm trying to understand how it is structured. All the files just have a numeric name. I'm assuming this is something like sector numbers. There are big chunks of files that have sequential numbers and all the files in these chunks are generally all the same size. I took one of the files and read it with the file command and it was a jpg. I copied it out to a new folder with a .jpg extension and it loaded up as an image. The thing I don't understand is that I can take the next file (same name as the first one but the number is +1) and it appears to be the _same_ image. So I'm trying to answer the following questions: 1. Can there be multiple files in a single file in lost+found (multiple files in a single sector) 2. why would two files in lost+found that appears to have come from two different sectors be actually the same file (in this case the same image) Any linux filesystem experts give me an insight into this? Thanks!

I have an SAS controller that currently has 4 SATA drives hanging off of it. They work well. As I replace drives I'm wondering if it makes sense to replace them with SAS drives. They seem to be faster, more doable, and cost a bit less. I'm seeing 14TB SAS seagate drives brand new for like $175. Would it make sense to go that route?

ok, dmesg shows me that xfs_repair is running out of memory going to try again with -m option

yeah, I just don't understand why it doesn't finish with either a success or error. could the xfs_repair program be being killed? I just ran it again like this: xfs_repair -vP /dev/md5p1 it produced this output: Phase 1 - find and verify superblock... - block cache size set to 1402128 entries Phase 2 - using internal log - zero log... zero_log: head block 2 tail block 2 - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata badly aligned inobt rec (starting inode = 10879599959) ir_freecount/free mismatch, inode chunk 5/142181719, freecount 255 nfree 0 invalid inode count, inode chunk 5/142181719, count 255 ninodes 48 agi_count 34401952, counted 34402143 in ag 5 agi_freecount 68, counted 323 in ag 5 sb_icount 266868928, counted 267733823 sb_ifree 244, counted 505 sb_fdblocks 159628764, counted 167451433 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... found inodes not in the inode allocation tree found inodes not in the inode allocation tree - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 no error, success, or nothing. just stops. I'm on 6.12.4 and I confirmed that 6.12.5 doesn't update the xfs progs

why is that? If I tell it to rebuild that drive from parity will it just rebuild it corrupted?

what about rebuilding the drive from parity? Would that be an option?

relocated sector count is 127 but extended self test completed without error. Safe to readd the drive as a second parity or should I replace it?

xfs_repair just keeps quitting. This is now 3 times it has run for *hours* and then finished with this: found inodes not in the inode allocation tree Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 when. I try to Brin the array back online it still says the drive has no recognizable filesystem. Seems like a bug that is causing xfs_repair to just quit. Trying to mount just gives this: mount: /tmp/mnt: mount(2) system call failed: Structure needs cleaning. dmesg(1) may have more information after failed mount system call.

ok, I ran it with -L. it *seemed* to finish even though it never reported being done. here is what is in the UI. After many "correcting imap" lines we see this: found inodes not in the inode allocation tree Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 when trying to mount it now it says structure needs cleaning. ps aux | grep xfs_repair shows xfs_repair is no longer running.

running xfs_repair -L

not sure but I might have tried to mount it incorrectly.

trying to mount the filesystem gives me this: root@Vault:/tmp# mount -t xfs /dev/sdg1 mnt mount: /tmp/mnt: can't read superblock on /dev/sdg1. dmesg(1) may have more information after failed mount system call.

I got this. should I follow these instructions: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.

My disk 5 reported as unmountable. It's XFS. So I stop the array and start it in maintenance mode. I then go to the GUI and do a check disk (xfs_repair -n). It ran *forever* but didn't finish in a way that I expected. The last few lines of the output are: Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 The check disk button is active again. No options were given for running xfs_repair again. Got lots of output like: imap claims in-use inode 11906112941 is free, would correct imap. Lots and lots of lines like this. Any idea what I should do now?

Two times in the past 2-3 months I've come home to find my server hung up. not responding. Both times all I needed to do was put the flash drive in a different USB port and it booted right up. But each time I tried to boot without moving the flash drive the system would go straight to the BIOS and act like it couldn't see anything. I have a hard time believing my USB ports are just dying one by one. Can the flash drive dying behave like this? You would think if the flash drive was dead it wouldn't work in a different port but it does. Stumped.

I've got fireguard setup on my unraid server to give me remote access to a couple of containers and vms. That all seems to work ok but occasionally I have no internet access on my phone at all. And when I turn off the wire guard on my phone it all comes back. So I think I have something setup wrong on my wireguard tunnel. Also, does anyone know if there is a way to direct only traffic intended for a given url over the tunnel?

I seem to have got it worked out.

yeah, I did that. it said that there was important stuff in the log and I needed to try and mount the drive and then unmount it. I was unable to do t hat so now I'm doing a xfs_repair -L. This is finding lots of errors but hopefully will leave me with a good drive. Thankfully this is a new drive and there was nearly nothing on it. However, one thing that is weird. Right before this happened I had kernel panic on 6.12. I am wondering if the kernel panic caused the corruption though I don't think a kernel panic would cause this *much* corruption. xfs_repair is reporting *lots * of data fork in ino xxxxxx messages.