timg11

I've studied this issues more. I use many boards, but I only see this here on this one. The problem seems to be limited to multi-line paste. If the pasted text has multiple lines, it is entirely ignored. if I break it into single lines, and paste them one by one, it will work. It doesn't seem to matter if the source file is DOS (CRLF) or UNIX (LF) line endings. Any newline, and the paste is ignored. Any ideas?

@JorgeB Has any progress been made on an updated guide to Snapshots for Unraid 7+? Where would I find it if it were posted? I'm still hoping to have @SimonF clarify the correct procedure for removing and merging unwanted snapshots back into the base IMG, based on my XML files posted.

There is a way to save days in the drive upgrade process without using the GUI? Tell me more!

virsh_dumpxml_Windows.txt

That pipe to xmllint doesn't seem to work as expected: # virsh dumpxml Debian | xmllint --xpath '//devices/disk' Usage : xmllint [options] XMLfiles ... I have attached the full output of virsh dumpxml VMName virsh_dumpxml_Debian.txt Debian VM is running

@SimonF The VM is running. I have attached the output of cat snapshots.db I've also attached Debian-snapshots.db, which is the status of the Debian VM that also has snapshots I want to clear. Debian Snapshots: Windows 11 Snapshots: snapshots.db Debian-snapshots.db

@snsn that looks like the card I have. I have attached the vbios ROM file I'm using. The VM settings have OVMF TPM for BIOS. matrox_g550.rom

My array is made of a mix of 2 ST24000NT002 and 3 ST16000NT001 drives. My plan has been to slowly replace the 16T drives with 24T drives as they are affordable. Currently it seems that "Black Friday" deals are for the 28T ST28000NT002, which is going for $50 less than the ST24000NT002. If I purchase two of these 28T drives I could do this: 1) replace Parity drive with 28T 2) wait two days for parity rebuild 3) replace a 16T array drive with new 28T drive 4) wait two days for parity restore 5) replace a 16T array drive with the removed 24T (formerly parity) drive 6) wait two days for parity restore. Net Gain 12T + 8T = 20T Is there a more efficient procedure? Can any of these steps be parallelized?

@SimonF Did the virsh dumpxml VMName | xmllint --xpath '//devices/disk' information clarify anything? Should I update to 7.2 now? Does it make any difference w.r.t. snapshot management? I'm just looking to remove these unnecessary snapshots in the safest and most efficient manner, without risking the state of the operational VMs. Block Commit on the oldest (top) snapshot? or Block Commit one by one starting with newest? Or something else?

@bmartino1 thanks for all the suggestions. The digitalocean.com article is helpful in highlighting the challenges with monitoring UDP, especially non-standard services. I'm hoping to figure out a way to just add the monitoring for the unifi Docker container to my script that is already monitoring all the services on Unraid running on a Pi. I thought maybe there is a way to determine if the container running from within Unraid. From the Unraid shell, I see this: root@T440:/mnt/user/appdata/unifi-controller-reborn/db# ls -ltr ----snip ----- -rw------- 1 nobody 104 1105 Nov 2 15:46 WiredTiger.turtle root@T440:/mnt/user/appdata/unifi-controller-reborn/db# The file WiredTiger.turtle is apparently updated every few seconds when unifi-controller-reborn is running. I'm not sure of the best way to determine that file's "freshness" from the Pi over the network. I suppose a user script on Unraid could check it, and then send something to the Pi. I like the Pi's script because it sends a single email when one or more services are not responding (listing them), and then an "all clear" email when all are restored.

😖Text Paste broken on this site again! CTRL-V, Paste, Paste Without Formatting all ignored. See attached file. virsh-dumpxlm-windows.txt Yes still on 7.0.1. - Need to update but my to-do list remains long..... At any of the vertices of the tree |__ I can click and get a submenu with choices 1) Revert Snapshot 2) Block Commit 3)Block Pull 4) Remove snapshot.

When I was having trouble with my VMs bring down Unraid, I got in the habit of turning off all the auto-starts whenever I restarted Unraid so I wouldn't get into a boot loop. I'd start Unraid, and then start the Dockers and VMs, verify they started OK, and then turn auto-start back on. As I think about it I've never had a Docker container bring Unraid down, so maybe it is safe to leave auto-start enabled for Docker. That will help if I'm forgetful, but not in the case of a container stopping due to a fault. w.r.t uptime kuma, that looks nice, and I might try it at some point. It says it can monitor "...uptime for HTTP(s) / TCP / HTTP(s) Keyword / HTTP(s) Json Query / Ping / DNS Record / Push / Steam Game Server / Docker Containers" . UDP notably missing. I'm curious how it can detect a running docker container over the network if the container offers ports only on UDP (it is unifi-controller-reborn). Is there some other "generic Docker API" that is available on all Docker instances, above and beyond what is shown on Unraid's Container Port? I already have a bash script running as a cron job on a Pi to monitor my Unraid server, its VMs and other devices using ping and nc. nc only supports verifying a port is open for TCP. I have been unable to find a simple way to determine the availability of a port with UDP. The complex way is to use tcpdump to monitor for UDP on the specific port and IP, identify an example of a real-world Unifi UDP packet exchange, and then duplicate that in a test application.

I have several Docker containers running now. When performing system maintenance, I have to stop them. Sometimes I forget to re-start them. Is there any app or script that could periodically monitor that my Docker containers are running? I already have a monitoring script from another host periodically polling Unraid itself and my VMs by testing with nc to see if port 22 is available. Unfortunately, some of my docker containers are UDP only, and I don't know of a way to detect if the container is running over the network when only UDP is offered. Maybe there is a plugin or way to monitor within the Unraid environment? I checked for "Docker Watchdog" in the app store, but didn't find anything. I looked at all the apps starting with "docker" and didn't see anything that looked appropriate. Does anyone have ideas on how to do this?

Thanks again for the tutorial - extremely helpful! I'll study up on these. I've only been using Linux for about 10 years (Raspian, Ubuntu, Debian, and now Unraid), so that makes me a beginner compared to true veterans like you. (I did use Solaris on a Sun workstation in the late 90s and early 2000s, but that was just for Verilog simulation, and I had a company sysadmin to take care of it) I already have the User Scripts plugin installed in Unraid so I can leverage that. I can see that things could go very badly if this type of script malfunctioned. Would the effects of the wrapper and "Inittab surgery" be limited to the tty/agetty that appear on the monitor? I.E. would SSH access and the web GUI be completely independent and unaffected if it became necessary to revert these changes? Or would recovery mean restoring my Unraid boot USB flash from a backup?

@bmartino1- Wow, I was expecting a minor tweak to my one-liner, but it takes a complex 72 line script! But I can see it is better that passively redirecting tail -f syslog to tty. It gives the syslog on the display, but then allows dropping to shell if I ever decide I need to hook up a keyboard to the server. (I'm not worried about physical access - the server is physically secure. I'm guessing the interactive shell after ^C is already logged in as root, rather than displaying the Login: prompt as it does now) I'll have to study this for a while. I don't yet understand the "wrapper" concept. I've never heard of c1, agetty, telinit, or "set -euo pipefail" before - will have to research.

Since I don't have a keyboard attached to the console, I tried to initiate the tail command from an SSH session as a persistent, background process like this: root@T440:~# nohup tail -f /var/log/syslog > /dev/tty1 2>&1 < /dev/null & On the SSH terminal it displays the process ID as expected. [1] 2090751 What happens is: 1) The console monitor (tty1) displays only this: "nohup: ignoring input and appending output to 'nohup.out'" 2) tail output goes into file /nohup.out, not the console display. AI says "it should redirect everything to /dev/tty1, the behavior you're seeing suggests that Unraid's shell or nohup implementation may be overriding or interfering with the redirection — possibly due to how pseudo-terminals and device permissions are handled." I'm learning to not trust AI advice regarding Unraid, so back to you to provide any insights on why this doesn't work as expected.

Sounds like a candidate for future enhancement of Unraid - although not critical since rebuild is hopefully an infrequent operation. Although upgrading a larger array could literally take weeks to accomplish one drive at a time.

Update after I thought more about this issue for a couple of days.... I told Gemini that 1) The Matrox installer did not recognize the card and refused to run; and 2) when I manually installed extracted drivers from Device Manager Update Driver, it sort of worked but the image was compressed in the upper half of the display. Gemini thought those symptoms meant the QEMU was not properly initializing the Matrox, and went off on a rabbit trail of VBIOS, and various other attempts, finally leading to suggesting kernel changes for Unraid. At that point I realized it was off track and stopped. I thought I'd go back to the manually installed drivers and do some testing with different DisplayPort to HDMI adapters on the two DIsplayPort outputs of the G550. I re-installed the drivers, and the G550 was recognized and looked normal in Device Manager. Still had the 1/2 display on the HDMI monitor. The only other monitor I had in reach was a VGA analog. I had an adapter, so I plugged it in to the other port. Perfect video. I moved it to the first port. Perfect video. Then I borrowed another HDMI monitor and plugged it in the adapter and port I'd been testing with. Perfect video. So the 1/2 screen issue was a compatibility issue with a specific monitor. So that HDMI incompatibility is still a mystery, but the Matrox card pass through into the Windows VM is solved.

Follow up question - Now that I've got the console monitor staying on, I'm thinking "what can I do with it"? Is it possible to configure the system to copy the system log to the console? I might as well have some visibility on what is happening. Now it just sits at the login prompt.

So you're saying get another flash drive, install Unraid on it, and boot, and then try the Reboot from the GUI. If it hangs for 10+ minutes, then it's something about the server? If I can know Unraid is shutting down OK first, it's not a big deal to do the warm boot from in IDRAC. I don't have to do it that often. Next time I need to reboot, I'll video the Unraid console monitor as it rapidly scrolls text then immediately blacks out. Maybe I can see the "last message" of Unraid is that it has completed shutdown.

Thanks for your help. Last week I added a 24TB drive to the array as Parity2. Once the parity was rebuilt, I unassigned the 16T parity drive. I performed a Parity check, which took the amount of time to read a 24T drive, even though the Parity drive was the only drive with more than 16T capacity . Today, I took the next step and completed the upgrade process with one 24 TB data drive. I followed these steps 1. Stop the Array: Stop the array via the WebGUI. 2. Unassign Old Drive (Logical Slot): Navigate to Main à Array Devices. For Disk 4 (the logical slot you are replacing), change the assigned device to "No Device". 3. Physical Removal: Remove the old drive from Physical Slot 4. (This is safe since the array is stopped, even with a hot-swap server). 4. Assign New Drive (Logical Slot): Return to Main --> Array Devices. The entry for Disk 4 will show as "Not installed." Use the drop-down menu for the Disk 4 logical slot and select the 24TB drive that is currently physically installed in Physical Slot 8 and showing up as an Unassigned Device. 5. Start the Rebuild: Click Start to begin the array rebuild process. Unraid will copy all the data that was on the old Disk 1 (which it is now emulating from parity) onto the new 24TB drive you assigned to the Disk 1 logical slot. The physical slot location of the new drive (Slot 8) does not matter for the rebuild, only that you assign the correct drive to the correct logical slot (Disk 4) in the GUI. Now the rebuild is underway I selected Disk 4 because it had the least content on it. So now the rebuild process is going. Will it take the amount of time to copy and rebuild the 3.49 TB of data, or the amount of time to copy 24T of mostly empty drive? As I have the opportunity, I will purchase additional 24 T drives and repeat the process for Disk 1 to 3.

I need a video output from my server to be controlled by a Windows VM for a dedicated display. I first started by attempting to pass-through the embedded VGA in this T440 server to the Windows VM. That turned out to be unstable, and would crash Unraid when starting or stopping the VM. I have only a PCIe-1X slot, so I'm limited on choices to add a physical display card. I found an NVidia NVS300 which fit mechanically. I worked for weeks trying to get it to work, but eventually gave up. Apparently Nvidia blocks virtualization of that card for some reason so the driver will never load. Now I have a Matrox G550 with a PCIe-1X interface. Again, it turns out to be quite a challenge. I've been working for days trying to get it work. The passthrough is working. It is seen by Windows as a Basic Display Adapter. I can't install the drivers from the Matrox installer (with control panel) because the Matrox installer says there is no Matrox hardware present. I can install the drivers by extracting the installer archive, and using the Device Manger Update Driver to point to the extracted drivers. They install and seem to be working, but the display compresses the screen into the upper half of the display. The lower half is blank. Gemini says this is due to improper initialization, and sent me on a long path of attempted fixes. The card is initialized and displays the Unraid boot logo (mirrored to what is seen on the QXL video with VNC. The spinning white circle appears only on the QXL VNC display. The Unraid logo remains on the Matrox display, and a desktop is never shown. In Windows, Display Settings shows an 800x600 secondary display is present, but it is not driving the monitor on the Matrox, which only shows the Unraid boot logo. With guidance from Gemini, I've adjusted the XML for the Matrox like this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x18' slot='0x00' function='0x0'/> </source> <alias name='hostdev1'/> <rom file='/mnt/user/isos/vbios/matrox_g550.rom'/> <property name='x-vga' value='off'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0' boot='off'/></hostdev> </hostdev> That doesn't help. Skipping a lot of mucking with the VGA BIOS and other suggestions, the latest suggestion was this: Stop the VM. SSH into your Unraid host and modify the vfio-pci module options. Use the G550's specific Device ID (2527) to avoid affecting the onboard G200eW (0536): Bash nano /etc/modprobe.d/vfio.conf # Add this line: options vfio-pci ids=102b:2527 disable_vga=1 After rebooting Unraid, that setting did not take effect. root@T440:~# cat /sys/module/vfio_pci/parameters/disable_vga N root@T440:~# Believing "Unraid doesn't use the standard update-initramfs -u command" , Gemini recommended the following to apply the new configuration: modprobe -r vfio_pci modprobe vfio_pci That resulted in : modprobe: FATAL: Module vfio_pci is builtin. Now it's telling me to make changes to /boot/syslinux/syslinux.cfg. This is typical for AI to go down rabbit holes when there might have been a wrong turn a while back. It seems that Gemini can be helpful with Windows, but it has very limited understanding of Unraid, so I'm hesitant to getting into boot configurations and such. I've attached the entire saga with Gemini if anyone is interested. Matrox G550 - PCI passthrough in a KVM.docx Before proceeding any further, I wanted to check here with knowledgeable humans to see if any of this makes sense or if there are other suggestions. PS @PUNGGOKERS suggested Claude as better than Gemini, but Claude told me "Unfortunately, Claude is not available to new users right now. We’re working hard to expand our availability soon."

Here's a detailed log of what happens when I reboot Unraid from the GUI. Note I stop all Docker, VMs, and the array before initializing the reboot. Reboot Timeline 2025-10-26 12:27:18 Confirm Reboot from Unraid GUI (array already stopped) 2025-10-26 12:27:46 Monitor shows Unraid shutdown and then blanks 2025-10-26 12:30:39 T440 Fans speed up to max - monitor still blank 2025-10-26 12:40:48 10 minutes with no change 2025-10-26 12:41:05 Using Dell T440 IDRAC reset system (warm boot) 2025-10-26 12:41:20 Dell BIOS POST screen appears on monitor 2025-10-26 12:41:48 BIOS screen blanks 2025-10-26 12:42:56 Unraid Boot terminal output on screen 2025-10-26 12:43:45 Unraid boot complete - login prompt on terminal screen 2025-10-26 12:44:15 Log in from web GUI 2025-10-26 12:44:34 T440 fans slow down to normal My question is - should I even use the Unraid GUI to boot, or just start from IDRAC?

Thank you! It even un-blanked the console on my running system when I set to disabled. I'm trying to figure out why it takes something like 10 minutes to reboot Unraid so I want to know what's going on - if it is in Unraid, or the T440 POST.

@JorgeB you said "click the last snapshot and then "block commit," I interpreted "last" as being the most recent, or in the tree structure, the bottom one dated 2025-09-27. If doing a Block Commit on the oldest (top) snapshot will merge all the later ones into the primary image (deleting the snapshots, or making it safe to delete them), that is what I'd like to do. Doing in one step would be preferable, since doing the Block Commit on only the most recent took quite a while. @SimonF please confirm the correct procedure.