Here is something i found:

Ensure LUKS Drive is Configured
If the drive isn’t encrypted yet, you can encrypt it with LUKS:

bash
Copy
Edit
sudo cryptsetup luksFormat /dev/sdX
Replace /dev/sdX with the appropriate drive/partition. Be cautious—this step will erase all data on the drive.

Add the Drive to /etc/crypttab
Edit the /etc/crypttab file to configure the system to unlock the drive at boot.

Open the file:

bash
Copy
Edit
sudo nano /etc/crypttab
Add an entry for the encrypted drive:

bash
Copy
Edit
cryptname /dev/sdX none luks
cryptname: A name for the decrypted device (used later in /etc/fstab).
/dev/sdX: Path to the encrypted device.
none: Use none for a passphrase prompt at boot or specify a path to a key file.
luks: Indicates LUKS encryption.
Example:

bash
Copy
Edit
cryptdrive /dev/sdb1 none luks
3. Add the Decrypted Device to /etc/fstab
To automatically mount the decrypted drive after unlocking:

Edit /etc/fstab:

bash
Copy
Edit
sudo nano /etc/fstab
Add an entry for the decrypted drive:

bash
Copy
Edit
/dev/mapper/cryptname /mnt/mountpoint ext4 defaults 0 2
Replace:

/dev/mapper/cryptname with the mapped device from /etc/crypttab.
/mnt/mountpoint with your desired mount point.
ext4 with your file system type.
4. Generate an Initramfs
If the root file system or a critical drive is encrypted, you’ll need to update the initramfs to include decryption tools.

Update the initramfs:

bash
Copy
Edit
sudo update-initramfs -u
Verify that the cryptsetup package is installed in your initramfs configuration.

Test Boot Behavior
Reboot the system and observe the decryption process:

If you specified none in /etc/crypttab, you should be prompted for a passphrase at boot.
If a key file was used, the drive should decrypt automatically.
6. Using a Key File for Automatic Decryption
To avoid entering a passphrase at boot, use a key file:

Generate a key file:

bash
Copy
Edit
sudo dd if=/dev/urandom of=/root/luks-keyfile bs=4096 count=1
Set permissions:

bash
Copy
Edit
sudo chmod 600 /root/luks-keyfile
Add the key file to the LUKS header:

bash
Copy
Edit
sudo cryptsetup luksAddKey /dev/sdX /root/luks-keyfile
Update /etc/crypttab:

bash
Copy
Edit
cryptname /dev/sdX /root/luks-keyfile luks
Update the initramfs:

bash
Copy
Edit
sudo update-initramfs -u
Reboot to test automatic decryption.

Troubleshooting
Device not found during boot: Ensure the correct device path is used in /etc/crypttab.
Passphrase prompt not appearing: Verify cryptsetup is installed and included in initramfs.
Boot hangs or fails: Boot into a live session, comment out entries in /etc/fstab or /etc/crypttab, and investigate.

@Pete-S said in Blind swap / automatic rebuild on linux:

@DustinB3403 said in Blind swap / automatic rebuild on linux:

@Pete-S said in Blind swap / automatic rebuild on linux:

@travisdh1 said in Blind swap / automatic rebuild on linux:

@Pete-S said in Blind swap / automatic rebuild on linux:

@travisdh1 said in Blind swap / automatic rebuild on linux:

@Pete-S said in Blind swap / automatic rebuild on linux:

I often see that the argument for using hardware raid is to be able to initiate an automatic rebuild by just swapping a faulty drive for a new one.
A lot of people assume that software raid can't do that. But that's incorrect.

Software raid on linux (as in md managed by mdadm) can do the exact the same thing.

It's under policy and partition policy in mdadm.conf. You'll find on the man mdadm.conf page.
The spare-same-slot option would be the one that works the same way as hardware controllers usually do.

I haven't used it myself since I prefer to initiate the rebuild myself. But I wonder if you guys have used it?

I don't think blind swap is about automatic rebuild, that's a given no matter what software/hardware RAID is running. It's more about seeing the light is red instead of green on drive 6, so you know that is the one to replace.

The only example of not having that available, that I can think of, is https://www.45drives.com/

I don't know man.
A typical SMB would have no monitoring and any server would be stuck in a closet somewhere. Nobody would notice any red lights until several months later or until something breaks and then they'd have no clue what to do about it, wouldn't know who to call and wouldn't have any idea if the server even has warranty (it never has). A spare drive wouldn't be available unless it was an old discarded drive left on the shelf from the last time something was replaced.

While probably true, that doesn't really have anything to do with blind swap.

I'm just saying those that have their server park under control doesn't really need any LEDs. And those that really needs it, doesn't look at it.

But it would actually be a small thing to make a script that would indicate faulty drives. You look at /proc/mdstat and any drive showing a _ instead of U is lit up on the drive bay. It's controlled by SGPIO or SES. That's how the raid controller does it.

I thought MD was already capable of performing this. . .

I don't think so but I could be wrong.

I mean you could run raid 1 on a pair of sd cards. Since that md works on any type of block device or partition there is no guarantee that there are any drive bay lights or anything of that nature. But it's possible that there is an option for it.

Has a quick look and it looks like the ledmon package monitors md arrays and set LEDs accordingly.
So yes, software raid can indicate what drive has an error directly on the chassis with some additional software.

Here is a good example of why this is complex even for blind swap hardware RAID... it's not always clear what it is supposed to do.

https://mangolassi.it/topic/17314/replaced-drive-in-pe-t410-not-adding-to-virtual-disk/

Of interesting side note, the Linux md RAID system also implements Intel Matrix RAID and DDF (Disk Data Format) software RAID formats commonly used by consumer FakeRAID systems. Because of this, Linux md can sometimes convert FakeRAID into enterprise md RAID if you really know what you are doing 🙂

@Kelly said:

@scottalanmiller said:

Did it rebuild successfully?

I don't know. I ended up setting up the necessary VMs on other hosts and started rebuilding this one since it has been having stability issues in the last few weeks.

Ah okay, probably best but it is nice when you can figure out what happened, just to know what it was 😞

Just a guess..

For 6.5

sudo yum --enablerepo=base --disablerepo=citrix install postfix
http://xmodulo.com/how-to-install-additional-packages-in.html

For 7
http://discussions.citrix.com/topic/378880-xenserver-70-repositories/ post #5