similar to: CentOS 6 and luksOpen

Leon Fauster wrote: >> Am 20.06.2017 um 16:53 schrieb m.roth at 5-cent.us: >> >> Upgraded a RAID. Copied everything from backup. >> >> And then my manager said I had to encrypt the drive. >> >> I've done that, and made the filesystem, but I can't mount it. >> >> CentOS 6. >> I have the entry in /etc/crypttab, and a key in

> Am 20.06.2017 um 16:53 schrieb m.roth at 5-cent.us: > > Upgraded a RAID. Copied everything from backup. > > And then my manager said I had to encrypt the drive. > > I've done that, and made the filesystem, but I can't mount it. > > CentOS 6. > I have the entry in /etc/crypttab, and a key in /etc/crypt.pw, and the > luks UUID in /etc/fstab. I cannot

> Am 20.06.2017 um 17:12 schrieb m.roth at 5-cent.us: > > Leon Fauster wrote: >>> Am 20.06.2017 um 16:53 schrieb m.roth at 5-cent.us: >>> >>> Upgraded a RAID. Copied everything from backup. >>> >>> And then my manager said I had to encrypt the drive. >>> >>> I've done that, and made the filesystem, but I can't

Is there an easy way (cli) to enable a luks encrypted partition after reboot (a partition that was not enabled while booting, because not in the crypttab). I can execute the necessary command stack [1] but just wondering if there is an "enterprise/easy" way to do that ... [1] cryptsetup luksOpen $(blkid -t TYPE="crypto_LUKS" -o device) \ luks-$(cryptsetup luksUUID

Hi Chris, thanks for your answer. It is the first time I decided to encrypt my lvm. I choosed to encrypt the volume group, not every logical volume itself, because in case of doing lvm snapshots in that group they will be encrypted too? And how do I create a new encrypted volume group? Regards Tim Am 6. M?rz 2015 01:58:23 MEZ, schrieb Chris Murphy <lists at colorremedies.com>: >On

Got a HBS (y'know, Honkin' Big Server, one o' them technical terms), a Dell 720 with two Tesla GPUs. I updated the o/s, 6.5, and I cannot get the GPUs recognized. As a last resort, I d/l NVidia's proprietary driver/installer, 325, and it builds fine... I've yum removed the kmod-nvidia I had on the system, nouveau is blacklisted, and when I reboot, lsmod shows me nvidia loaded,

Hi everyone, I added a page under the HowTos for Encryption, and then added a guide for encrypting /tmp /swap and /home using cryptsetup and LUKS keys on LVM, when you already have partitions setup. http://wiki.centos.org/HowTos/EncryptTmpSwapHome Regards, Max

Folks, I have an issue: I've gotten that drive that I posted about the other day encrypted, and things were looking good... until there was a problem with another RAID attached to the box, and I wound up having to reboot. What had been /dev/sdb came up as /dev/sdc. So... is there any way other than using /dev/disk/by-uuid/<uUUID> as the second field in /etc/crypttab to deal with

Hello all, I posted the whole disk encryption instructions in the forum that has been briefly discussed on the list. I joined the list per Ned's post on the thread. http://www.centos.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=15923&forum=42 I have a couple of questions about the process of creating a wiki. 1. How does the peer-review process work? 2. Is there a place

On Mon, Sep 07, 2020 at 10:41:20AM +0100, Richard W.M. Jones wrote: >For BitLocker disks cryptsetup does not (yet? ever?) support reading >UUIDs and this function will fail. This does not matter here so just >ignore the error. > >Note there is no error message, cryptsetup simply returns with a bad >exit code: > >><rescue> cryptsetup luksUUID /dev/sda2

I'm sorry, but grep -i crypt /var/log/anaconda/anaconda.program.log returns nothing. But I have got an entry in /etc/crypttab. I only found this with grep -i luks /var/log/anaconda/anaconda.*: /var/log/anaconda/anaconda.storage.log:20:47:55,959 DEBUG blivet: LUKS.__init__: /var/log/anaconda/anaconda.storage.log:20:49:25,009 DEBUG storage.ui: LUKS.__init__:

For links to the original patch series, see: https://bugzilla.redhat.com/show_bug.cgi?id=1808977#c8 The original feedback was that ignoring errors from guestfs_luks_uuid would ignore legitimate errors from non-BitLocker disks, so I have modified this series so that errors are only ignored in the BitLocker case. As noted in the 4th patch there is no actual error in the BitLocker case, cryptsetup

On Tue, Oct 06, 2020 at 03:06:54PM +0100, Richard W.M. Jones wrote: >On Tue, Oct 06, 2020 at 03:25:20PM +0200, Martin Kletzander wrote: >> On Mon, Sep 07, 2020 at 10:41:20AM +0100, Richard W.M. Jones wrote: >> >For BitLocker disks cryptsetup does not (yet? ever?) support reading >> >UUIDs and this function will fail. This does not matter here so just >> >ignore

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I created a LUKS encrypted partition via a udev-triggered script on 6.6 using --key-file /tmp/foo. This worked fine, and I can decrypt the LUKS partition via script and manually using --key-file with luksOpen. The odd problem is that I can't decrypt the partition using the prompt. If I manually create a file with the passphrase in it

I'd like to edit the HowTo/EncryptedFilesystem page the note on how to create a valid keyfile. This is not a trivial action. Creating a plaintext file in vim does not qualify as a valid password. Instead, a valid keyfile is created by doing the following: echo -n "password" > keyfile.key which explicitly creates the file with password on the first line with an explicit

On 04/03/15 06:33 PM, Robert Nichols wrote: > On 03/04/2015 03:16 PM, Digimer wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi all, >> >> I created a LUKS encrypted partition via a udev-triggered script on >> 6.6 using --key-file /tmp/foo. This worked fine, and I can decrypt the >> LUKS partition via script and manually using

Just rebuilt a C6 box last week as C7. Four drives, and sda and sdb for root, with RAID-1 and luks encryption. Layout: lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ??sda1 8:1 0 200M 0 part /boot/efi ??sda2

Hi folks... check this out.. > GLU<-lme(gluc~rt*cd4+sex+age+rf+nadir+pharmac+factor(hcv)+factor(hbs)+ + haartd+hivdur+factor(arv), + random= ~rt|id, na.action=na.omit) > intervals(GLU)$fixed lower est. upper (Intercept) 67.3467070345 7.362307e+01 7.989944e+01 rt *0.0148050160* 6.249304e-02 1.101811e-01 cd4

https://gitlab.com/cryptsetup/cryptsetup/issues/488 This prevents virt-* tools from opening encrypted partitions automatically. Even 1024M isn't sufficient. I had to bump the memory up to 1400M to make it work, which is just too big for routine use. Even worse if the RAM size isn't quite large enough (eg 1200M) cryptsetup crashes. I'm not sure what to do about this now. The worst

On 03/05/2015 06:58 PM, Chris Murphy wrote: > On Thu, Mar 5, 2015 at 2:09 PM, Tim <lists at kiuni.de> wrote: >> Hello list, >> >> I bought a Thinkpad T420 and installed CentOS 7 recently. >> >> I choosed to use lvm encryption for the entire volume group. It works so far. >> >> But now I am planning to install a second hard disk. My thought is to