doron

This is not a stable state. I wouldn't declare victory just yet. Now, the SIGHUP messages come from the Preclear Disk plugin (not UD), which I presume you have installed. It seems to be signalling itself whenever it sees a change in the mounted partitions table, or when it times out at 3 sec accessing disk info. Seems like it does the latter, and I can only guess it somehow doesn't get along with one of your USB drives (either the boot drive or the "license" drive). What happens if you disable the Preclear Disk plugin (just for testing)? Does everything quiet down or do the UD messages keep popping out every 3 seconds?

Yeah that won't work. I just tried it on my prod system (shudder). It seems to be doing the right thing (on the right disk...) although it does spit out one error message re unmounting - I believe this is a bug in the original script, has nothing to do with this exercise - but it does seem to work; I have not tried to boot from it (as I said, my main system), may try later. If you're in for the game, you may want to try it - the process will be more streamlined. It has to do with the UD plugin. Can't be good that it gets a SIGHUP every 3 seconds - not sure why that'd happen. What if you click on the disk in the UD section in the main UI page (the little plus sign near the hdd icon), and set its mount point to be /boot rather than BOOTDISK ? Does the log flood quiet down?

Great news! Happy to hear it worked for you. Just out of curiosity - can you share what happened when you tried to run make_bootable_linux after doing both "sed" edits?

Correct. Thanks for clarifying.

Yes, so much for just reading the code and not testing... The "make bootable" process has changed since those instructions were written, so that some more adjustments are in order. Try this, in addition to previous edit (again, just offhand looking at code, no time to test right now): sed "s|UNRAID|BOOTDISK|g" -i /mnt/unraid_disk/syslinux/make_bootable_linux.sh Then run make_bootable_linux again. BTW, you mention "target USB" - I assume you mean target HDD, or else I'm not sure I understand what you are trying to do.

You may wanna try mkfs.fat for that. The original make_bootable_linux script will try to make the disk with label UNRAID, bootable. So if it's the original flash, it will act unto it. The proposed process from @thohell appears to have a slight bug, which might account for what you're seeing here. The editing of the "make_bootable_linux" script should probably be: sed -e "s|UNRAID|BOOTDISK|g" -i /mnt/unraid_disk/make_bootable_linux instead of what's proposed (note the little "g" in the sed command). I have not tested this on a live system - just reading the code - but you may want to try this, and then run make_bootable_linux again. Are you sure you used "/dev/sdX1" - emphasis on the "1" - or just "/dev/sdX"? See above - try mkfs.fat.

Yes that's the way to do it (I was thinking of the old, more manual way of creating the boot drive) but your screenshot show a WD Passport drive - you did install it on the USB thumb drive, right? (the Ultra Fit). Just making sure.

@joyson, is your USB drive bootable? Have you gone through the "make_bootable" step of the Unraid installation?

Thanks for reporting, @b0n3v. Glad it worked for you. Stay safe and healthy.

Do you have something in your go script that might write there?

There's 6.3G showing up there on your du above. How about du -xh /root ?

Can you check what's under /root? This might be the culprit.

Thanks for reporting! This is good to hear.

Have you looked at the Cooler Master case I pointed to on eBay in the previous post? You might find it interesting (and they still have a few available as I write this). (Curiously, I also have a CM590 which is what I plan to be moving away from... Tight.)

Like the rest of you of this thread, I have also been searching for the thing - a tower with 5.25" bays top to bottom(*). I've bumped on this on eBay and grabbed one. They seem to still have a few left. They are NIB. This one has 9 5.25" bays, all exposed. You can fill them with 5-in-3 or 3-in-2 of your fancy, to get a nice 15 or 12 hotswap 3.5" drives. It's a bit of a beast (full tower, deep, tons of cooling options). It supports E-ATX mobos, though unfortunately does not fit boards like X9DR3-LN4F (which is EE-ATX by spec) - the I/O plate and PCI/E slots do not align. It does take ATX (and smaller FF) boards happily. Thought some of you might find this interesting. (*) I was looking at using a CSE846 but dropped it due to its sound signature - too noisy for its designated location.

Uneventful upgrade from rc8 here. A thing of beauty. Thanks.

Drive encryption is one of Unraid's many good features. When you encrypt part or all of your array and cache, at some point you might end up wanting to change your unlock key. Just how often, would depend on your threat model (and on your level of paranoia). At this time (6.8), Unraid does not have a UI for changing the unlock key. Here is a small tool that will let you change your unlock key. Each of the current and new unlock keys can either be a text password / passphrase, or a binary key file if you're into those (I am). Your array must be started to use this tool. Essentially, the script validates the provided current key against your drives, and on all drives that can be unlocked with the current key, replaces it with the new one (in fact, it adds the new key to all of them, and upon success, removes the old key from all of them). Important: The tool does not save the provided new (replacement) key on permanent storage. Make very sure you have it backed up, either in memory (...) or on some permanent storage (not on the encrypted array 😜 ). If you misplace the new key, your data is hosed. Currently this script needs to be run from the command line. I may turn it into a plugin if there's enough interest (and time) - although I'm pretty sure Limetech has this feature on their radar for some upcoming version. Usage: unraid-newenckey [current-key-file] [new-key-file] Both positional arguments are optional and may be omitted. If provided, each of them is either the name of a file (containing a passphrase or a binary key), or a single dash (-). For each of the arguments, if it is either omitted or specified as a dash, the respective key will be prompted for interactively. Note: if you provide a key file with a passphrase you later intend to use interactively when starting the array (the typical use case on Unraid), make sure the file does not contain an ending newline. One good way to do that is to use "echo -n", e.g.: echo -n "My Good PassPhrase" > /tmp/mykeyfile This code has been tested, but no warranty is expressed or implied. Use at your own risk. With the above out of the way, please report any issues. EDIT 2022-06-07: The recommended way to install this is to use the plugin - look for "New Unlock Key for Encrypted Drives" on Community Apps. I'm leaving the script attached here for now, but updates will be provided via the plugin (currently at version 0.9). EDIT 2021-08-16: Posted an updated version for Unraid 6.10. The 6.10 OS includes an updated "lsblk" command which is not backwards compatible.

Thanks @Hurubaw! ... and there goes my hypothesis. The WD40EFRX certainly is not a 4Kn (*), which is what I thought might be a common theme. That is for the author to answer authoritatively. (*) 4k native sector size, as opposed to 512e or 512, which both present 512 size sectors, either emulated or native.

Could you post the specific model of the HDDs - both the ones failing and the ones completing successfully? ("WD Red" or "WD Black" are marketing names and can point to a bunch of different drive models). You can find the model name as the left part of the "identification" col on the GUI - examples could be WDC_WD4000F9YZ or WDC-WD60EDAZ or HUH721212AL4200. Do not post the serial number, which is typically the rightmost part and should be considered private information). Trying to compare it to my case and perhaps suggest a common theme to the failing drives vs. succeeding ones.

Wizardry huh. More like rustiness. In fact, even that filter was kinda heavy-handed - a better version would have been lsblk | grep "crypt" | sed -r 's/[^[:alnum:]]*([[:alnum:]]*) .*/\1/' At any rate, I did hack up that script. You can find it here. EDIT: Moved the script to its own thread.

Umm, apparently the logs are not being stored on permanent storage, and the server has been restarted since then... So what I have does now not cover the relevant time. Sorry about that.

Isn't it?... 🙂 All it does is take lsblk output lines that contain "crypt", and extract the first alphanum token out of them. Run the line on your server and see what you get. Might be a good idea to write a script to do a key change amass. If I get some spare time later today I might hack up something.

Yep, that could come really handy, even allowing you to script the whole process, if you pass it via a simple filter, e.g. lsblk | grep " crypt " | sed -r 's/[^a-z]*// ; s/([a-z0-9]*) .*/\1/' Welcome aboard! 🙂

@Derek_, glad it worked well for you. Just for other readers of this thread - note that for the array disk you must use the /dev/mdX devices (not /dev/sdX), whereas for the encrypted cache drive you need to find the actual device name /dev/sdX and then use it adding "1" for first (only) partition on that disk. You do not do this for parity drives - they are not LUKS devices. You're very welcome. Great question. You do have 7 left. What technically happened is that for each drive, you added a key into slot #1 (second slot), then restarted and tested, and then removed the key from slot #0, marking it "disabled". The next time you do the same exercise (assuming no fiddling in between, I'm simplifying this a bit), you will add a key into the first free slot - which will now be #0. So if I understand your underlying question, you can repeat this process an infinite number of times - as long as you remove the old keys. The eight slots can keep up to eight keys simultaneously.

I don't see a reason to stop anything. The key slots are fixed and are manipulated in place. Your data is not affected during the process. Just do the full set of luksAddKey, stop/start when convenient to see that the new key works, then a set of luksRemoveKey.