MowMdown

I’ve had one MCE on my Ryzen based system recently on a 7beta however if it’s reoccurring you probably should evaluate your hardware. unfortunately with AMD it’s not possible to read the MCE log.

I have 4x 1TB SSDs and I am debating whether or not I should arrange them in a dual mirror vdev pool or raidz2 but I have some questions about how a dual mirror vdev pool distributes data and handles disk failure. Config Option #1: NAME STATE READ WRITE CKSUM cache ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 disk1 ONLINE 0 0 0 disk2 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 disk3 ONLINE 0 0 0 disk4 ONLINE 0 0 0 1. What happens if only a single disk is lost from only one of the mirror vdevs? 2. Can lose one mirror vdev and still have a functioning pool? 3. What if disk1 and disk3 are lost but disk2 and disk4 are fine? 4. At which point is this entire cache pool toast? Thanks.

Cold storage means the drives are not physically connected to the system. As in the drive is sitting unattached. If you wanted a “warm spare” you could just not assign it to any drive slots, and only mount it as an unassigned drive when you need it. alternatively you can assign the drive to a “pool” instead of the array and just set your shares to not use the pool. the drives don’t randomly spin up either.

Looks like my previous reply didn't come through. But yes. you should delete the postgres appdata folder as well. You will have to restart the Postgresql_immich and Immich dockers afterwards.

Click the little blue thumbdrive icon next to the drive name post the log

No that controller won’t cause issues. I have a similar one and it’s basically the same controller most motherboards use for extra sata ports

I’m unaware of any files on the USB which have human readable drive assignments. With that said, you should not expect drive assignment issues with that M.2 -> SATA adapter. Im pretty confident your drives will be detected and properly assigned by unraid as long as the BIOS can see all of them. in the future though, definitely take note of your drive assignments (the slot and serial#) if you change hardware like a motherboard or HBA/RAID card.

for starters remove the entire “Immich” folder and its contents. then it sounds like you have docker volumes which need to be removed. These are “hidden” and will need to be removed via cmdline. -> See help here also use “docker volume ls” to view them

How were your HDDs connected to your old mainboard? Directly via SATA ports or through an HBA or some other adapter/splitter? if they were directly connected to the boards SATA ports you shouldn’t have issues with unraid detecting and reassigning the drives to the correct slots.

The only nothing thing I’d do is just take a photo/screenshot of your drive assignments just in case you need to manually reassign them on the new system. The most important one is knowing which disk(s) is parity so you don’t end up with assigning a data drive in the parity slot(s). That would be the only way you’d lose data.

You have to remove the Immich config files from the appdata share. Either that or you need to delete the hidden docker volumes through cmdline.

Use the file activity plugin to see what’s going on

Yes they should. Even if they don’t there isn’t any data loss you may (1% chance) just need to recreate the docker images using the existing template.

Do you even have a cache drive setup in a pool? you won’t have the option to set the primary storage pool to cache if you don’t have a cache drive. if you do, navigate to your shares tab, click on the appdata share, set primary storage to cache and secondary storage to array. Set the mover option so the arrow points TO cache. ”Array -> Cache” Stop the entire docker service and also the VM service from the settings page. run mover and it should move the appdata share.

Dec 19 21:24:48 kernel: ------------[ cut here ]------------ Dec 19 21:24:48 kernel: Can't encode file handler for inotify: 255 Dec 19 21:24:48 kernel: WARNING: CPU: 2 PID: 600657 at fs/notify/fdinfo.c:55 show_mark_fhandle+0x77/0xe6 Dec 19 21:24:48 kernel: Modules linked in: af_packet vhci_hcd usbip_host usbip_core xt_nat veth xt_CHECKSUM ipt_REJECT nf_reject_ipv4 ip6table_mangle iptable_mangle vhost_net vhost vhost_iotlb tap xt_conntrack nf_conntrack_netlink xfrm_user xfrm_algo xt_addrtype br_netfilter iscsi_target_mod target_core_user target_core_pscsi target_core_file target_core_iblock md_mod xt_MASQUERADE xt_tcpudp xt_mark tun nf_tables nfnetlink ip6table_nat iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ntfs3 tcp_diag inet_diag nct6683 ip6table_filter ip6_tables iptable_filter ip_tables x_tables efivarfs bridge stp llc mei_hdcp mei_pxp mei_gsc mei_me mei zfs(PO) i915 edac_mce_amd edac_core intel_rapl_common kvm_amd spl(O) iosf_mbi drm_buddy kvm ttm video i2c_algo_bit drm_display_helper drm_kms_helper crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel drm sha512_ssse3 sha256_ssse3 sr_mod sha1_ssse3 btusb cdrom btrtl btbcm aesni_intel btintel backlight crypto_simd wmi_bmof cryptd intel_gtt bluetooth rapl cp210x agpgart Dec 19 21:24:48 kernel: i2c_piix4 r8169 acpi_cpufreq usbserial k10temp i2c_core ccp ecdh_generic ahci joydev cdc_acm ecc realtek tpm_crb libahci tpm_tis tpm_tis_core tpm wmi button Dec 19 21:24:48 kernel: CPU: 2 PID: 600657 Comm: lsof Tainted: P O 6.6.66-Unraid #1 Dec 19 21:24:48 kernel: Hardware name: Micro-Star International Co., Ltd. MS-7C95/PRO B550M-VC WIFI (MS-7C95), BIOS H.B0 03/14/2024 Dec 19 21:24:48 kernel: RIP: 0010:show_mark_fhandle+0x77/0xe6 Dec 19 21:24:48 kernel: Code: ff 00 00 00 89 c1 74 04 85 c0 79 22 80 3d 32 b0 2c 01 00 75 5e 89 ce 48 c7 c7 06 03 26 82 c6 05 20 b0 2c 01 01 e8 f6 77 d8 ff <0f> 0b eb 45 89 44 24 0c 8b 44 24 04 48 89 ef 31 db 48 c7 c6 44 03 Dec 19 21:24:48 kernel: RSP: 0018:ffffc900165f7c10 EFLAGS: 00010286 Dec 19 21:24:48 kernel: RAX: 0000000000000000 RBX: ffff8881054e8b00 RCX: 0000000000000027 Dec 19 21:24:48 kernel: RDX: 0000000082c1dcb0 RSI: ffffffff82245218 RDI: 00000000ffffffff Dec 19 21:24:48 kernel: RBP: ffff8881045e61e0 R08: 0000000000000000 R09: ffffffff82c1dcb0 Dec 19 21:24:48 kernel: R10: 00003fffffffffff R11: 0000000000000032 R12: ffff8881045e61e0 Dec 19 21:24:48 kernel: R13: ffff8881045e61e0 R14: ffffffff812ecf4b R15: ffff888106dab478 Dec 19 21:24:48 kernel: FS: 000014ebb2773f00(0000) GS:ffff8887fe880000(0000) knlGS:0000000000000000 Dec 19 21:24:48 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Dec 19 21:24:48 kernel: CR2: 00000000004a6000 CR3: 000000014a0ac000 CR4: 0000000000750ee0 Dec 19 21:24:48 kernel: PKRU: 55555554 Dec 19 21:24:48 kernel: Call Trace: Dec 19 21:24:48 kernel: <TASK> Dec 19 21:24:48 kernel: ? __warn+0x99/0x11a Dec 19 21:24:48 kernel: ? report_bug+0xd9/0x153 Dec 19 21:24:48 kernel: ? show_mark_fhandle+0x77/0xe6 Dec 19 21:24:48 kernel: ? handle_bug+0x53/0x7c Dec 19 21:24:48 kernel: ? exc_invalid_op+0x13/0x60 Dec 19 21:24:48 kernel: ? asm_exc_invalid_op+0x16/0x20 Dec 19 21:24:48 kernel: ? __pfx_inotify_fdinfo+0x10/0x10 Dec 19 21:24:48 kernel: ? show_mark_fhandle+0x77/0xe6 Dec 19 21:24:48 kernel: ? __pfx_inotify_fdinfo+0x10/0x10 Dec 19 21:24:48 kernel: ? seq_vprintf+0x2d/0x49 Dec 19 21:24:48 kernel: ? seq_printf+0x53/0x6e Dec 19 21:24:48 kernel: ? preempt_latency_start+0x2b/0x46 Dec 19 21:24:48 kernel: inotify_fdinfo+0x83/0xaa Dec 19 21:24:48 kernel: show_fdinfo.isra.0+0x63/0xab Dec 19 21:24:48 kernel: seq_show+0x152/0x173 Dec 19 21:24:48 kernel: seq_read_iter+0x16e/0x353 Dec 19 21:24:48 kernel: seq_read+0x91/0xbb Dec 19 21:24:48 kernel: vfs_read+0xa4/0x1d1 Dec 19 21:24:48 kernel: ? __do_sys_newfstat+0x34/0x5c Dec 19 21:24:48 kernel: ksys_read+0x74/0xc0 Dec 19 21:24:48 kernel: do_syscall_64+0x57/0x7b Dec 19 21:24:48 kernel: entry_SYSCALL_64_after_hwframe+0x78/0xe2 Dec 19 21:24:48 kernel: RIP: 0033:0x14ebb2a0b6ed Dec 19 21:24:48 kernel: Code: 21 87 0e 00 f7 d8 64 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 80 3d 59 0b 0f 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec Dec 19 21:24:48 kernel: RSP: 002b:00007ffdc1fc07c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 Dec 19 21:24:48 kernel: RAX: ffffffffffffffda RBX: 000000000043f600 RCX: 000014ebb2a0b6ed Dec 19 21:24:48 kernel: RDX: 0000000000000400 RSI: 000000000046bc30 RDI: 0000000000000007 Dec 19 21:24:48 kernel: RBP: 000014ebb2af31f0 R08: 0000000000000001 R09: 0000000000000000 Dec 19 21:24:48 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 000014ebb2af30a0 Dec 19 21:24:48 kernel: R13: 0000000000000000 R14: 0000000000001000 R15: 000000000043f600 Dec 19 21:24:48 kernel: </TASK> Dec 19 21:24:48 kernel: ---[ end trace 0000000000000000 ]--- Happens to all of us

Parity is updated on the fly. As soon as a file is deleted, parity is updated, when a file is written, parity updates again.

So i'm not crazy! It was there during beta and was removed.

For Jellyfin, you need to not only pass the extra paramters through to the container but in the transcoder settings for jellyfin, you need to specify "/dev/dri/renderD128" in the text field. (as the sub-text explains) After that you need to actually transcode something for it to register anything in the intel top.

I know this thread is old but if anyone is having issues, one thing to check is to make sure REBAR is set to YES/ENABLED in the BIOS. I have had an ARC A310 working since 7.0 Beta 1

Replacing the cables and/or making sure they're properly seated is the first thing to check.

I actually think it's infuse that pulls most of the content into the RAM/Flash Storage on the AppleTV. If you watched it via the Plex app you probably won't see the same behavior. Edit: When starting a film, watch the network graphs on unraid's dashboard, you will see a large portion get sent to the appletv. Mine will saturate the entire 1Gig bandwidth. Plex does not do this.

You can also just add it here like this: Both ways work just fine.

I looked into it, Vaultwarden will not work over HTTP with the Bitwarden browser plugin due to Crypto APIs requiring HTTPS. source

I see, yeah after looking into it further, it seems it's a requirement between Vaultwarden and modern browsers. I'm not sure you have a way out then if that's the case. You'll have to generate certs with LetsEncrypt and copy the certs every 90 days. That will allow you to use it offline in between.

You should be able to... I think that's why we're all confused because that's how it is supposed to work. No SSL needed, no internet required.