Sponsored Content
Operating Systems Linux Red Hat Cryptsetup compains not a valid device Post 302997591 by ashis12ka4 on Wednesday 17th of May 2017 04:30:28 AM
Old 05-17-2017
Cryptsetup compains not a valid device

Hi,

We have a disk say /dev/sdx which is encrypted as whole disk (no partition)

Now after extending the disk and resizing the file system the cryptsetup comamnd compains that /dev/sdx is not a vaild LUKS device.

[xxxxxxxxxxxxxx]# cryptsetup luksOpen /dev/sdx sdxEncrypted
Device /dev/sdx is not a valid LUKS device.

Do I need to change anything with fdisk?

Quick Help is much appreciated.
 

5 More Discussions You Might Find Interesting

1. AIX

"rmt0" is not a valid backing device - VIO

hello to all, i am trying to assing a tape drive to a virtual partition through VIO but i get the message "rmt0" is not a valid backing device. the oslevel of my VIO is AIX 6.1.3.0. when i run the command lsdev |grep rmt i get the following result: rmt0 Available 08-08-00-0,0 ... (6 Replies)
Discussion started by: omonoiatis9
6 Replies

2. Red Hat

Unable To Activate Ethernet Network Device in RHEL 5.5 - e100 device eth0 does not seem to be presen

Hi All, Could anyone please help to resolve the below problem. I installed RHEL5.5 in my desktop.But when i try to activate the ethernet connection then it gives me the error. I spent 2 days for the above and go through with several suggestion found by googling. But no luck. ... (0 Replies)
Discussion started by: Tanmoy
0 Replies

3. HP-UX

Failed to open tape device /dev/rmt/0mn:Device busy (errno = 16)

Hi, Unable to make tape backup, please help. /opt/ignite/bin/make_tape_recovery -a /dev/rmt/?mn -I -v -m tar -x inc_entire=vg00 * Creating local directories for configuration files and archive. ======= 04/25/16 16:28:08 IST Started /opt/ignite/bin/make_tape_recovery. (Mon... (4 Replies)
Discussion started by: anuragr
4 Replies

4. Linux

Systemd cryptsetup fails to map drive during reboot

I have created an encrypted disk using the following command: # cryptsetup create testcui /dev/sdb --key-file= /etc/keys --verify-passphrase plain This created the correctly mapped device /dev/mapper/testcui I have create the crypttab file with the following: # # test disk #... (0 Replies)
Discussion started by: jlowry
0 Replies

5. Debian

Problems with cryptsetup keyfile encrypted root partition under Debian 9, i386

Hello, i'm trying to set up a machine with an encrypted filesystem. It's a Debian 9/i386. The partition table on /dev/sda 1. 1 MiB BIOS BOOT (04) N/A N/A 2. 256 MiB Linux (83) ext4 /boot 3. 2304 MiB Linux (83) ext4 / 4. 1 MiB MINIX (81) N/A N/A 5. 510 MiB Linux... (7 Replies)
Discussion started by: tyuxar
7 Replies
SYSTEMD-CRYPTSETUP-GENERATOR(8) 			   systemd-cryptsetup-generator 			   SYSTEMD-CRYPTSETUP-GENERATOR(8)

NAME
systemd-cryptsetup-generator - Unit generator for /etc/crypttab SYNOPSIS
/lib/systemd/system-generators/systemd-cryptsetup-generator DESCRIPTION
systemd-cryptsetup-generator is a generator that translates /etc/crypttab into native systemd units early at boot and when configuration of the system manager is reloaded. This will create systemd-cryptsetup@.service(8) units as necessary. systemd-cryptsetup-generator implements systemd.generator(7). KERNEL COMMAND LINE
systemd-cryptsetup-generator understands the following kernel command line parameters: luks=, rd.luks= Takes a boolean argument. Defaults to "yes". If "no", disables the generator entirely. rd.luks= is honored only by initial RAM disk (initrd) while luks= is honored by both the main system and the initrd. luks.crypttab=, rd.luks.crypttab= Takes a boolean argument. Defaults to "yes". If "no", causes the generator to ignore any devices configured in /etc/crypttab (luks.uuid= will still work however). rd.luks.crypttab= is honored only by initial RAM disk (initrd) while luks.crypttab= is honored by both the main system and the initrd. luks.uuid=, rd.luks.uuid= Takes a LUKS superblock UUID as argument. This will activate the specified device as part of the boot process as if it was listed in /etc/crypttab. This option may be specified more than once in order to set up multiple devices. rd.luks.uuid= is honored only by initial RAM disk (initrd) while luks.uuid= is honored by both the main system and the initrd. If /etc/crypttab contains entries with the same UUID, then the name, keyfile and options specified there will be used. Otherwise, the device will have the name "luks-UUID". If /etc/crypttab exists, only those UUIDs specified on the kernel command line will be activated in the initrd or the real root. luks.name=, rd.luks.name= Takes a LUKS super block UUID followed by an "=" and a name. This implies rd.luks.uuid= or luks.uuid= and will additionally make the LUKS device given by the UUID appear under the provided name. rd.luks.name= is honored only by initial RAM disk (initrd) while luks.name= is honored by both the main system and the initrd. luks.options=, rd.luks.options= Takes a LUKS super block UUID followed by an "=" and a string of options separated by commas as argument. This will override the options for the given UUID. If only a list of options, without an UUID, is specified, they apply to any UUIDs not specified elsewhere, and without an entry in /etc/crypttab. rd.luks.options= is honored only by initial RAM disk (initrd) while luks.options= is honored by both the main system and the initrd. luks.key=, rd.luks.key= Takes a password file name as argument or a LUKS super block UUID followed by a "=" and a password file name. For those entries specified with rd.luks.uuid= or luks.uuid=, the password file will be set to the one specified by rd.luks.key= or luks.key= of the corresponding UUID, or the password file that was specified without a UUID. rd.luks.key= is honored only by initial RAM disk (initrd) while luks.key= is honored by both the main system and the initrd. SEE ALSO
systemd(1), crypttab(5), systemd-cryptsetup@.service(8), cryptsetup(8), systemd-fstab-generator(8) systemd 237 SYSTEMD-CRYPTSETUP-GENERATOR(8)
All times are GMT -4. The time now is 11:20 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy