search for: luksformat

...keyfile > (DAMHTDT) it would work from the terminal without "--hash -plain". Reviving a very old thread... I tried this (cryptsetup --hash plain luksOpen /dev/sdb1 sdb1) but it fails to recognize the passphrase at the command line still. When I tried to use '--hash plain' on luksFormat, I get: [root at dashboard1 ~]# echo YES | cryptsetup --hash plain luksFormat /dev/sdb1 /tmp/password Requested LUKS hash plain is not supported. I suspect I'm misunderstanding something. I've read "NOTES ON PASSWORD PROCESSING" and as best I can figure, the root of the problem...

...mapper/VolGroup_Share-LogVol_Share /share ext4 > rw,noatime,nodiratime,barrier=0,nobh,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user > 0 0 > > The ext4 volume sits on top of an lvm logical partion. That logical volume > ultimately sits on top of an encrypted disk using cryptsetup luksFormat: > > # lvscan > ACTIVE '/dev/VolGroup_Share/LogVol_Share' [4.48 TiB] inherit > > # pvscan > PV /dev/mapper/luks-7f865362-ee9f-40de-bc07-73701b4662f3 VG > VolGroup_Share lvm2 [4.48 TiB / 0 free] > > Is there something in my ext4 mount optio...

-----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

...2 encrypted partitions: /dev/sda2 and /dev/sdb1, which are used as LVM PVs. They both use the same encryption key, but the initramfs only prompts once, which is the behavior proposed by Rich. So, I pushed the test a little more and added 2 disks to the virtual machine and manually configured LUKS (luksFormat, etc...), with the same passphrase, but different from the one provided during the installation. I added the disks to /etc/crypttab and at boot I'm asked to provide 3 passphrases: 1 for the initial devices and 1 per additional disk. This is similar to Pino's fully deterministic approach. I...

On Fri, Oct 09, 2020 at 05:02:57PM +0200, Martin Kletzander wrote: > Basically what I did was create a small disk, create one partition > over the whole disk, then cryptsetup luksFormat the partition, open > it and format it with a filesystem (without any LVM). That is one > of the things you were adding support for, but it is not limited to > Windows Bitlocker setup, it can just as well be a custom setup when > installing any Linux distro. > > Even after quite...

...and clean-ups. So I'd say ACK from me (if that means anything), it's just one thing that I wanted to try out (and maybe you could create a test for it) and it did not work as expected. Basically what I did was create a small disk, create one partition over the whole disk, then cryptsetup luksFormat the partition, open it and format it with a filesystem (without any LVM). That is one of the things you were adding support for, but it is not limited to Windows Bitlocker setup, it can just as well be a custom setup when installing any Linux distro. Even after quite a bit of fighting, rebuilding...

...nd I would then mount it for remote access? If so, what would prevent the hosting company - which I presume is the root user - from also accessing it? That's that precisely, very easy. a) use dd to create a a file, eg.: dd if=/dev/zero of=gor.loop bs=1M count=2000 b) luks encrypt it: cryptsetup luksFormat gor.loop c) dev mapper mount it: cryptsetup luksOpen gor.loop luks-gor.loop d) fs it: mkfs.ext4 /dev/mapper/luks-gor.loop e) mount it:? mount /dev/mapper/luks-gor.loop $PWD/gor.rootfs.encrypted f) use it (to simplify I'd put cryptOpen + mount + unmount + luksClose into a script) g) remember!! s...

...mounts | grep share /dev/mapper/VolGroup_Share-LogVol_Share /share ext4 rw,noatime,nodiratime,barrier=0,nobh,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user 0 0 The ext4 volume sits on top of an lvm logical partion. That logical volume ultimately sits on top of an encrypted disk using cryptsetup luksFormat: # lvscan ACTIVE '/dev/VolGroup_Share/LogVol_Share' [4.48 TiB] inherit # pvscan PV /dev/mapper/luks-7f865362-ee9f-40de-bc07-73701b4662f3 VG VolGroup_Share lvm2 [4.48 TiB / 0 free] Is there something in my ext4 mount options that is incompatible with quota? Or maybe...

...f this user on the crypted partition. The problem looks strange for me and google has not helped.... This how I build the crypted partition (following a tutorial, just changing ext4 with xfs): lvcreate -L 30G -n lv_home vg_portable badblocks -s -w -t random -v /dev/vg_portable/lv_home cryptsetup luksFormat /dev/vg_portable/lv_home cryptsetup luksOpen /dev/vg_portable/lv_home c_home mkfs -t xfs -L /home /dev/mapper/c_home The blkid command shows: /dev/mapper/c_home: LABEL="/home" UUID="1118317e-cc5a-4183-a498-21418f82e982" TYPE="xfs" In /etc/fstab I add: UUID=1118317e-...

...> > This UUID being associated with the LUKS header indicates it is not a > partition UUID. > > A dd of this (or lvm snapshot) to another partition will keep the same UUID. Indeed. If your version of cryptsetup is new enough (supports the "--header" option), try doing the luksFormat operation with a detached header. Now you will find that your LUKS partition no longer has a UUID. > A partition UUID within a GPT table would not be persisted in this manner, > and msdos labeled disks have no concept of this to begin with. -- Bob Nichols "NOSPAM" is really...

On Fri, Oct 09, 2020 at 04:33:53PM +0100, Richard W.M. Jones wrote: >On Fri, Oct 09, 2020 at 05:02:57PM +0200, Martin Kletzander wrote: >> Basically what I did was create a small disk, create one partition >> over the whole disk, then cryptsetup luksFormat the partition, open >> it and format it with a filesystem (without any LVM). That is one >> of the things you were adding support for, but it is not limited to >> Windows Bitlocker setup, it can just as well be a custom setup when >> installing any Linux distro. >> &g...

On Tue, 2015-06-16 at 11:30 +0100, John Hodrien wrote: > On Tue, 16 Jun 2015, Always Learning wrote: > > > ON Centos 5, using GPARTED I created partitions for filing systems ext3 > > and ext4. 4 primary and unlimited (except by space) extended partitions. > > That suggests those partitions are not GPT but old fashioned M$DOS > > If it is old fashioned MSDOS, you can

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

On 02/17/2020 05:03 AM, lejeczek via CentOS wrote: > On 16/02/2020 15:18, H wrote: >> I wonder if it is possible to set up an encrypted "file container" on a CentOS VPS? I am the root user of the VPS but the hosting company also has access to the VPS and thus all files. Is it possible to create a LUKS-container on the VPS and those files only be accessible by me? IOW, most of

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__:

The changes since the previous patch: - safe ADD_ARG macro for adding arguments to a fixed size stack array - support for testing functions that return RHashtable, ie. tune2fs-l. - add tests that set (tune2fs) and get (tune2fs-l) various parameters. - only one 'intervalbetweenchecks' parameter (in seconds) Rich.

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

v1: https://www.redhat.com/archives/libguestfs/2019-November/msg00036.html

As discussed in the emails today, this is the third version addressing most points from the v1/v2 review. You will need to pair this with the changes in libguestfs-common from this series: https://www.redhat.com/archives/libguestfs/2020-September/msg00050.html Rich.