Very good to know, i didnt know that. I swear by device by label for ZFS, makes it easier to readily identify and keep track of. But yeah, its a bit more painful but by-id is another proper way. Using device letters/names will get you into big trouble after reboot often, its never worth it IMO.

So, you create a label for each disk using something like

e2label /dev/sdx <label>

and then use these labels to define the pool?

This is probably a smart thing to do, as you likely make the labels locational identifiers in your chassis so that it's easy to find and replace failed disks. I'm still not sure what procedure I will use to find failed disks. Hopefully the Supermicro chassis will give me a red light indicator, or something, similar to the way the LSI RAID controllers work.

]]>https://bbs.archlinux.org/profile.php?id=796822016-11-29T11:12:59Zhttps://bbs.archlinux.org/viewtopic.php?id=213556&action=newi think thatif the target hard disk is smaller than the source hard disk ,at first shtink the source hard disk by gparted then do either partclene or dd .------regards]]>https://bbs.archlinux.org/profile.php?id=870082016-11-15T05:18:32Zhttps://bbs.archlinux.org/viewtopic.php?id=216874&action=newusing dm-cache/lvmcache (a sort of bcache enhancement with device mapper) here since months with write cache enabled under an HDD mirror mdadm raid.officially mainlined too, no problem at all so far even on brutal system halt.]]>https://bbs.archlinux.org/profile.php?id=168572016-11-12T09:16:43Zhttps://bbs.archlinux.org/viewtopic.php?id=218160&action=newFrom 'man systemd':

]]>https://bbs.archlinux.org/profile.php?id=95552016-11-09T09:58:07Zhttps://bbs.archlinux.org/viewtopic.php?id=208650&action=newShort update to this thread:I got the problem fixed! It was a bug at upstream libvirt.

]]>https://bbs.archlinux.org/profile.php?id=685412016-11-04T00:50:27Zhttps://bbs.archlinux.org/viewtopic.php?id=216941&action=newHi spookyKid. I didn't get notified about your reply, sorry for the delay in getting back to you.

I'd be happy to help you set this up on your own system, Would you like a tutorial on adding custom hooks, or on using a passphrase to unlock a keyfile? Because if its the latter you seek, it'd be easier to setup and more secure if you put luks on a usb stick and installed grub to that.

Please not that the above configuration of the files should be just a point to start.For your own convenience I recommend not using them on a productive system.This solution is not secure and not efficent.

For myself I am currently in process of building some service to automatically lock & unlock devices based on some popup with help of sshpass.Additionally you should think of a way to keep track of removed devices, too.On my own solution I am writing some kind of "status file" keeping track of every unlocked device and check with help of "dislocker-find" if device was removed or added.

Hope this helps some other to build cool ways of bitlocker unlock on unix

EDIT:Ah something I forgot.Seems like dislocker-fuse needs some seconds to unlock your drive.This causes "mount" command to fail sometimes (since "dislocker-file" does not exist).simply creating a loop that checks if your dislocker-file already exists should resolve the problem.

]]>https://bbs.archlinux.org/profile.php?id=380912016-10-31T11:43:14Zhttps://bbs.archlinux.org/viewtopic.php?id=168013&action=newFolks at qemu-devel mailing list pointed out that there's a bug in Windows 7 that does not allow UEFI (OVMF) + Windows 7 + HyperV features combination.https://lists.nongnu.org/archive/html/q … 02845.html]]>https://bbs.archlinux.org/profile.php?id=474202016-10-21T12:45:45Zhttps://bbs.archlinux.org/viewtopic.php?id=217521&action=newThis was an experiment to create a specific board where more competent and experienced users could post questions and issues that were more complex and challenging.

Unfortunately, almost no-one bothered to read the sticky and so many of the posts here were obviously guided by the thought, "well, this is about administering my system, so I'll put it here..."

Consequently, the staff (mindful of people who susbscribe to particular fora) spent a lot of time and energy moving posts to more appropriate fora. The corollary to this was an uptick in indignant posts/emails of the "why did you move my post to Newbie Corner?" flavour; (the answer, as it almost always is, "because if you haven't read the stickies or the Code of Conduct you are either a newbie or an idiot: which would you prefer us to use?").

So, this board is being locked to new posts. You can still answer any of the existing posts here, but the average user will not be able to open new threads. Developers, TUs, Fellows and staff can open new threads; but as those people rarely do, the experiment is over and the board is effectively shuttered.

]]>https://bbs.archlinux.org/profile.php?id=255792016-10-14T05:46:15Zhttps://bbs.archlinux.org/viewtopic.php?id=218234&action=newHi, I'd like to know if the output I get from lsblk after decrypting container sec is normal.This happens with a local disk and NAS, output = the same.All my containers are created with tcplay.It don't matter if I use a script or single tcplay commands with THIS specific container.

As you can see, there a 3 block devices set to open the initial container 'sec', and 1 on 'sec1'After unmounting,1 block device is removed, which is the way it should be, but, 2 block devices are not being removed.I am able to get the problem out of the way, but, I guess this not how it's supposed to be.My question is, how could this have happened?

]]>https://bbs.archlinux.org/profile.php?id=611852016-10-13T14:13:05Zhttps://bbs.archlinux.org/viewtopic.php?id=218196&action=newI don't seem to be able to get gluster native access with libvirt.Does anyone know if libvirt is compiled with libgfapi support? I can't figure out how to display compile/configure options for libvirt?It seems to be lot of overhead to use filesystem pool with gluster and go through the fuse layer.

]]>https://bbs.archlinux.org/profile.php?id=264052016-10-11T00:13:44Zhttps://bbs.archlinux.org/viewtopic.php?id=218074&action=newThere are a lot of misconceptions being thrown around on this thread. Everything is encrypted on your system except for the BIOS boot partition (the small section at the beginning of the disk that loads GRUB itself). Having a key embedded in the initramfs is fine, because it, with the kernel, is on the encrypted /boot which is not decrypted until GRUB decrypts it. Yes, GRUB really can decrypt a LUKS-encrypted partition to get to the initramfs and kernel. When the system is off, the key is in on the encrypted section of the disk and is secure.]]>https://bbs.archlinux.org/profile.php?id=883522016-10-10T16:51:00Zhttps://bbs.archlinux.org/viewtopic.php?id=218004&action=newI'm trying to learn a bit about the kernel keyring (as background for using ecryptfs). Does the kernel keyring store anything on disk, or is it a strictly an in-memory mechanism? I've looked through some of the documentation, but this isn't claer to me. If it does save things to disk, where are the file written?

BIOS is configured to use S3 (Suspend to RAM), and Resume by USB devices (I tried various keyboards, both wired and non-wired but the system stays asleep), PS2 devices (I don't have any and adaptors didn't allow USB devices to wake the system up) are enabled, see http://www.produktinfo.conrad.com/daten … _S_2_0.pdf