`cryptsetup luksOpen ` fails to set up the specified name mapping

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite
1












HardenedArray has a helpful archlinux-installation guide at Efficient Encrypted UEFI-Booting Arch Installation.



However, I encountered difficulty early in the installation process -- specifically, at the point of opening my LUKS partition.



The command cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3 completes without error, but after I enter the command cryptsetup luksOpen /dev/sda3 tsundoku, /dev/mapper/tsundoku does not become available.



ls /dev/mapper lists /dev/mapper/control alone, and not also /dev/mapper/tsundoku as I would expect.



The following error message appears upon cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug:



"Trying to read ... LUKS2 header at offset .... LUKS header read failed (-22). Command failed with code -1 (wrong or missing parameters)."



Could anyone offer any hints at to the cause of this error? My attempts at online research to this point haven't been fruitful.



Thanks much



--- EDIT ---



I've asked this question for help to achieve any of three goals: (1) to install arch-linux (in any manner) on a 6ish-year-old x86-64 Intel Core i5 2.50GHz ASUS; (2) more specifically, to install arch-linux securely with an encrypted partition; (3) to learn why, despite my expectations, cryptsetup luksOpen /dev/sda3 tsundoku does not create a tsundoku mapping entry in the path /dev/mapper.



I'm a newcomer to arch-linux, so although I'd prefer installing the OS with encryption, I'd settle for installing it in any way.



I haven't had much luck following the installation instructions in the official arch wiki in the past, so upon seeing HardenedArray's clearly delineated installation guide, I thought I'd give it a go -- worst case scenario being that I might encounter a problem like the one described above, whereby I might learn something new.



As for the issue, here are some more details:



As per HardenedArray's guide: I gdisk /dev/sda and create the following partitions:



  • /dev/sda1, default, 100M, EF00

  • /dev/sda2, default, 250M, 8300

  • /dev/sda3, default, default, 8300

Then I do the following:



mkfs.vfat -F 32 /dev/sda1



mkfs.ext2 /dev/sda2



At this point, I attempt to initialize a LUKS partition and set up a mapping.



> cryptsetup --verbose -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3



Command successful



> cryptsetup -v isLuks /dev/sda3



Command successful



> ls /dev/mapper



control



> cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug



 cryptsetup 2.0.0. processing "cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug"
Running command open.
Locking memory.
...
Trying to load any crypt type from device /dev/sda3.
Crypto backend ... initialized ...
Detected kernel Linux 4.14.9-1-ARCH x86_64.
...
Reading LUKS header of size 1024 from device /dev/sda3.
...
Activating volume tsundoku using token -1.
STDIN descriptor passphrase entry requested.
Activating volume tsundoku [keyslot -1] using passphrase.
...
Detected dm-ioctl version 4.37.0.
Device-mapper backend running with UDEV support enabled.
dm status tsundoku [ opencount flush ] [...] (...)
Trying to open key slot 0 [ACTIVE_LAST].
Reading key slot 0 area.
Using userspace crypto wrapper to access keyslot area.
Trying to open key slot 1 [INACTIVE].
# key slots 2-7 are also [INACTIVE]
Releasing crypt device /dev/sda3 context.
Releasing device-mapper backend.
Unlocking memory.
Command failed with code -2 (no permission or bad passphrase).


> ls /dev/mapper



control



> cryptsetup luksDump /dev/sda3



 LUKS header information for /dev/sda3
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha512
...
UUID: 56d8...
Key Slot 0: ENABLED
...
Key Slot 1: DISABLED
# Key Slots 2-7 are also DISABLED



Are the steps I've listed above inaccurate in any way? Perhaps there were alternatives I should have taken instead or intervening actions that I missed?



If not, is the command cryptsetup luksOpen /dev/sda volume supposed to create a volume mapping in the path /dev/mapper?



If so, do the details I've added above allow anyone to ascertain why the path /dev/sda3/tsundoku does not appear on my machine? And if not, is there any additional information that I could add to make the problem clearer?



Thanks much.







share|improve this question


















  • 1




    This is why you should use the community documentation, not random blog wiki.archlinux.org/index.php/Dm-crypt/…:
    – jasonwryan
    Jan 14 at 23:53










  • What is the exit code of luksFormat? What is the output of cryptsetup luksDump /dev/sda3?
    – Hauke Laging
    Jan 14 at 23:57










  • @HaukeLaging The exit code of luksFormat is 0. The output of cryptsetup luksDump /dev/sda3 states that Key Slot 0 is ENABLED but Key Slots 1-7 are DISABLED.
    – Polytope
    Jan 16 at 1:55










  • Any "dangerous" characters in the passphrase (from the keyboard layout perspective)? Does it work with foofoofoo or a keyfile instead?
    – Hauke Laging
    Jan 16 at 8:18














up vote
2
down vote

favorite
1












HardenedArray has a helpful archlinux-installation guide at Efficient Encrypted UEFI-Booting Arch Installation.



However, I encountered difficulty early in the installation process -- specifically, at the point of opening my LUKS partition.



The command cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3 completes without error, but after I enter the command cryptsetup luksOpen /dev/sda3 tsundoku, /dev/mapper/tsundoku does not become available.



ls /dev/mapper lists /dev/mapper/control alone, and not also /dev/mapper/tsundoku as I would expect.



The following error message appears upon cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug:



"Trying to read ... LUKS2 header at offset .... LUKS header read failed (-22). Command failed with code -1 (wrong or missing parameters)."



Could anyone offer any hints at to the cause of this error? My attempts at online research to this point haven't been fruitful.



Thanks much



--- EDIT ---



I've asked this question for help to achieve any of three goals: (1) to install arch-linux (in any manner) on a 6ish-year-old x86-64 Intel Core i5 2.50GHz ASUS; (2) more specifically, to install arch-linux securely with an encrypted partition; (3) to learn why, despite my expectations, cryptsetup luksOpen /dev/sda3 tsundoku does not create a tsundoku mapping entry in the path /dev/mapper.



I'm a newcomer to arch-linux, so although I'd prefer installing the OS with encryption, I'd settle for installing it in any way.



I haven't had much luck following the installation instructions in the official arch wiki in the past, so upon seeing HardenedArray's clearly delineated installation guide, I thought I'd give it a go -- worst case scenario being that I might encounter a problem like the one described above, whereby I might learn something new.



As for the issue, here are some more details:



As per HardenedArray's guide: I gdisk /dev/sda and create the following partitions:



  • /dev/sda1, default, 100M, EF00

  • /dev/sda2, default, 250M, 8300

  • /dev/sda3, default, default, 8300

Then I do the following:



mkfs.vfat -F 32 /dev/sda1



mkfs.ext2 /dev/sda2



At this point, I attempt to initialize a LUKS partition and set up a mapping.



> cryptsetup --verbose -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3



Command successful



> cryptsetup -v isLuks /dev/sda3



Command successful



> ls /dev/mapper



control



> cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug



 cryptsetup 2.0.0. processing "cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug"
Running command open.
Locking memory.
...
Trying to load any crypt type from device /dev/sda3.
Crypto backend ... initialized ...
Detected kernel Linux 4.14.9-1-ARCH x86_64.
...
Reading LUKS header of size 1024 from device /dev/sda3.
...
Activating volume tsundoku using token -1.
STDIN descriptor passphrase entry requested.
Activating volume tsundoku [keyslot -1] using passphrase.
...
Detected dm-ioctl version 4.37.0.
Device-mapper backend running with UDEV support enabled.
dm status tsundoku [ opencount flush ] [...] (...)
Trying to open key slot 0 [ACTIVE_LAST].
Reading key slot 0 area.
Using userspace crypto wrapper to access keyslot area.
Trying to open key slot 1 [INACTIVE].
# key slots 2-7 are also [INACTIVE]
Releasing crypt device /dev/sda3 context.
Releasing device-mapper backend.
Unlocking memory.
Command failed with code -2 (no permission or bad passphrase).


> ls /dev/mapper



control



> cryptsetup luksDump /dev/sda3



 LUKS header information for /dev/sda3
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha512
...
UUID: 56d8...
Key Slot 0: ENABLED
...
Key Slot 1: DISABLED
# Key Slots 2-7 are also DISABLED



Are the steps I've listed above inaccurate in any way? Perhaps there were alternatives I should have taken instead or intervening actions that I missed?



If not, is the command cryptsetup luksOpen /dev/sda volume supposed to create a volume mapping in the path /dev/mapper?



If so, do the details I've added above allow anyone to ascertain why the path /dev/sda3/tsundoku does not appear on my machine? And if not, is there any additional information that I could add to make the problem clearer?



Thanks much.







share|improve this question


















  • 1




    This is why you should use the community documentation, not random blog wiki.archlinux.org/index.php/Dm-crypt/…:
    – jasonwryan
    Jan 14 at 23:53










  • What is the exit code of luksFormat? What is the output of cryptsetup luksDump /dev/sda3?
    – Hauke Laging
    Jan 14 at 23:57










  • @HaukeLaging The exit code of luksFormat is 0. The output of cryptsetup luksDump /dev/sda3 states that Key Slot 0 is ENABLED but Key Slots 1-7 are DISABLED.
    – Polytope
    Jan 16 at 1:55










  • Any "dangerous" characters in the passphrase (from the keyboard layout perspective)? Does it work with foofoofoo or a keyfile instead?
    – Hauke Laging
    Jan 16 at 8:18












up vote
2
down vote

favorite
1









up vote
2
down vote

favorite
1






1





HardenedArray has a helpful archlinux-installation guide at Efficient Encrypted UEFI-Booting Arch Installation.



However, I encountered difficulty early in the installation process -- specifically, at the point of opening my LUKS partition.



The command cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3 completes without error, but after I enter the command cryptsetup luksOpen /dev/sda3 tsundoku, /dev/mapper/tsundoku does not become available.



ls /dev/mapper lists /dev/mapper/control alone, and not also /dev/mapper/tsundoku as I would expect.



The following error message appears upon cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug:



"Trying to read ... LUKS2 header at offset .... LUKS header read failed (-22). Command failed with code -1 (wrong or missing parameters)."



Could anyone offer any hints at to the cause of this error? My attempts at online research to this point haven't been fruitful.



Thanks much



--- EDIT ---



I've asked this question for help to achieve any of three goals: (1) to install arch-linux (in any manner) on a 6ish-year-old x86-64 Intel Core i5 2.50GHz ASUS; (2) more specifically, to install arch-linux securely with an encrypted partition; (3) to learn why, despite my expectations, cryptsetup luksOpen /dev/sda3 tsundoku does not create a tsundoku mapping entry in the path /dev/mapper.



I'm a newcomer to arch-linux, so although I'd prefer installing the OS with encryption, I'd settle for installing it in any way.



I haven't had much luck following the installation instructions in the official arch wiki in the past, so upon seeing HardenedArray's clearly delineated installation guide, I thought I'd give it a go -- worst case scenario being that I might encounter a problem like the one described above, whereby I might learn something new.



As for the issue, here are some more details:



As per HardenedArray's guide: I gdisk /dev/sda and create the following partitions:



  • /dev/sda1, default, 100M, EF00

  • /dev/sda2, default, 250M, 8300

  • /dev/sda3, default, default, 8300

Then I do the following:



mkfs.vfat -F 32 /dev/sda1



mkfs.ext2 /dev/sda2



At this point, I attempt to initialize a LUKS partition and set up a mapping.



> cryptsetup --verbose -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3



Command successful



> cryptsetup -v isLuks /dev/sda3



Command successful



> ls /dev/mapper



control



> cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug



 cryptsetup 2.0.0. processing "cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug"
Running command open.
Locking memory.
...
Trying to load any crypt type from device /dev/sda3.
Crypto backend ... initialized ...
Detected kernel Linux 4.14.9-1-ARCH x86_64.
...
Reading LUKS header of size 1024 from device /dev/sda3.
...
Activating volume tsundoku using token -1.
STDIN descriptor passphrase entry requested.
Activating volume tsundoku [keyslot -1] using passphrase.
...
Detected dm-ioctl version 4.37.0.
Device-mapper backend running with UDEV support enabled.
dm status tsundoku [ opencount flush ] [...] (...)
Trying to open key slot 0 [ACTIVE_LAST].
Reading key slot 0 area.
Using userspace crypto wrapper to access keyslot area.
Trying to open key slot 1 [INACTIVE].
# key slots 2-7 are also [INACTIVE]
Releasing crypt device /dev/sda3 context.
Releasing device-mapper backend.
Unlocking memory.
Command failed with code -2 (no permission or bad passphrase).


> ls /dev/mapper



control



> cryptsetup luksDump /dev/sda3



 LUKS header information for /dev/sda3
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha512
...
UUID: 56d8...
Key Slot 0: ENABLED
...
Key Slot 1: DISABLED
# Key Slots 2-7 are also DISABLED



Are the steps I've listed above inaccurate in any way? Perhaps there were alternatives I should have taken instead or intervening actions that I missed?



If not, is the command cryptsetup luksOpen /dev/sda volume supposed to create a volume mapping in the path /dev/mapper?



If so, do the details I've added above allow anyone to ascertain why the path /dev/sda3/tsundoku does not appear on my machine? And if not, is there any additional information that I could add to make the problem clearer?



Thanks much.







share|improve this question














HardenedArray has a helpful archlinux-installation guide at Efficient Encrypted UEFI-Booting Arch Installation.



However, I encountered difficulty early in the installation process -- specifically, at the point of opening my LUKS partition.



The command cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3 completes without error, but after I enter the command cryptsetup luksOpen /dev/sda3 tsundoku, /dev/mapper/tsundoku does not become available.



ls /dev/mapper lists /dev/mapper/control alone, and not also /dev/mapper/tsundoku as I would expect.



The following error message appears upon cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug:



"Trying to read ... LUKS2 header at offset .... LUKS header read failed (-22). Command failed with code -1 (wrong or missing parameters)."



Could anyone offer any hints at to the cause of this error? My attempts at online research to this point haven't been fruitful.



Thanks much



--- EDIT ---



I've asked this question for help to achieve any of three goals: (1) to install arch-linux (in any manner) on a 6ish-year-old x86-64 Intel Core i5 2.50GHz ASUS; (2) more specifically, to install arch-linux securely with an encrypted partition; (3) to learn why, despite my expectations, cryptsetup luksOpen /dev/sda3 tsundoku does not create a tsundoku mapping entry in the path /dev/mapper.



I'm a newcomer to arch-linux, so although I'd prefer installing the OS with encryption, I'd settle for installing it in any way.



I haven't had much luck following the installation instructions in the official arch wiki in the past, so upon seeing HardenedArray's clearly delineated installation guide, I thought I'd give it a go -- worst case scenario being that I might encounter a problem like the one described above, whereby I might learn something new.



As for the issue, here are some more details:



As per HardenedArray's guide: I gdisk /dev/sda and create the following partitions:



  • /dev/sda1, default, 100M, EF00

  • /dev/sda2, default, 250M, 8300

  • /dev/sda3, default, default, 8300

Then I do the following:



mkfs.vfat -F 32 /dev/sda1



mkfs.ext2 /dev/sda2



At this point, I attempt to initialize a LUKS partition and set up a mapping.



> cryptsetup --verbose -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3



Command successful



> cryptsetup -v isLuks /dev/sda3



Command successful



> ls /dev/mapper



control



> cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug



 cryptsetup 2.0.0. processing "cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug"
Running command open.
Locking memory.
...
Trying to load any crypt type from device /dev/sda3.
Crypto backend ... initialized ...
Detected kernel Linux 4.14.9-1-ARCH x86_64.
...
Reading LUKS header of size 1024 from device /dev/sda3.
...
Activating volume tsundoku using token -1.
STDIN descriptor passphrase entry requested.
Activating volume tsundoku [keyslot -1] using passphrase.
...
Detected dm-ioctl version 4.37.0.
Device-mapper backend running with UDEV support enabled.
dm status tsundoku [ opencount flush ] [...] (...)
Trying to open key slot 0 [ACTIVE_LAST].
Reading key slot 0 area.
Using userspace crypto wrapper to access keyslot area.
Trying to open key slot 1 [INACTIVE].
# key slots 2-7 are also [INACTIVE]
Releasing crypt device /dev/sda3 context.
Releasing device-mapper backend.
Unlocking memory.
Command failed with code -2 (no permission or bad passphrase).


> ls /dev/mapper



control



> cryptsetup luksDump /dev/sda3



 LUKS header information for /dev/sda3
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha512
...
UUID: 56d8...
Key Slot 0: ENABLED
...
Key Slot 1: DISABLED
# Key Slots 2-7 are also DISABLED



Are the steps I've listed above inaccurate in any way? Perhaps there were alternatives I should have taken instead or intervening actions that I missed?



If not, is the command cryptsetup luksOpen /dev/sda volume supposed to create a volume mapping in the path /dev/mapper?



If so, do the details I've added above allow anyone to ascertain why the path /dev/sda3/tsundoku does not appear on my machine? And if not, is there any additional information that I could add to make the problem clearer?



Thanks much.









share|improve this question













share|improve this question




share|improve this question








edited Jan 16 at 3:06

























asked Jan 14 at 23:25









Polytope

113




113







  • 1




    This is why you should use the community documentation, not random blog wiki.archlinux.org/index.php/Dm-crypt/…:
    – jasonwryan
    Jan 14 at 23:53










  • What is the exit code of luksFormat? What is the output of cryptsetup luksDump /dev/sda3?
    – Hauke Laging
    Jan 14 at 23:57










  • @HaukeLaging The exit code of luksFormat is 0. The output of cryptsetup luksDump /dev/sda3 states that Key Slot 0 is ENABLED but Key Slots 1-7 are DISABLED.
    – Polytope
    Jan 16 at 1:55










  • Any "dangerous" characters in the passphrase (from the keyboard layout perspective)? Does it work with foofoofoo or a keyfile instead?
    – Hauke Laging
    Jan 16 at 8:18












  • 1




    This is why you should use the community documentation, not random blog wiki.archlinux.org/index.php/Dm-crypt/…:
    – jasonwryan
    Jan 14 at 23:53










  • What is the exit code of luksFormat? What is the output of cryptsetup luksDump /dev/sda3?
    – Hauke Laging
    Jan 14 at 23:57










  • @HaukeLaging The exit code of luksFormat is 0. The output of cryptsetup luksDump /dev/sda3 states that Key Slot 0 is ENABLED but Key Slots 1-7 are DISABLED.
    – Polytope
    Jan 16 at 1:55










  • Any "dangerous" characters in the passphrase (from the keyboard layout perspective)? Does it work with foofoofoo or a keyfile instead?
    – Hauke Laging
    Jan 16 at 8:18







1




1




This is why you should use the community documentation, not random blog wiki.archlinux.org/index.php/Dm-crypt/…:
– jasonwryan
Jan 14 at 23:53




This is why you should use the community documentation, not random blog wiki.archlinux.org/index.php/Dm-crypt/…:
– jasonwryan
Jan 14 at 23:53












What is the exit code of luksFormat? What is the output of cryptsetup luksDump /dev/sda3?
– Hauke Laging
Jan 14 at 23:57




What is the exit code of luksFormat? What is the output of cryptsetup luksDump /dev/sda3?
– Hauke Laging
Jan 14 at 23:57












@HaukeLaging The exit code of luksFormat is 0. The output of cryptsetup luksDump /dev/sda3 states that Key Slot 0 is ENABLED but Key Slots 1-7 are DISABLED.
– Polytope
Jan 16 at 1:55




@HaukeLaging The exit code of luksFormat is 0. The output of cryptsetup luksDump /dev/sda3 states that Key Slot 0 is ENABLED but Key Slots 1-7 are DISABLED.
– Polytope
Jan 16 at 1:55












Any "dangerous" characters in the passphrase (from the keyboard layout perspective)? Does it work with foofoofoo or a keyfile instead?
– Hauke Laging
Jan 16 at 8:18




Any "dangerous" characters in the passphrase (from the keyboard layout perspective)? Does it work with foofoofoo or a keyfile instead?
– Hauke Laging
Jan 16 at 8:18










1 Answer
1






active

oldest

votes

















up vote
0
down vote













You're using the wrong command instead use the following command until you complete install and boot into your new Arch OS:



# cryptsetup --type luks open /dev/sdaX plain1 #change **plain1** to your map location 


After you boot into your new OS then you can use the other one. Don't forget DuckDuckGo, Qwant, Google and so on are your friends. Carry on from there, good luck.






share|improve this answer






















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f417135%2fcryptsetup-luksopen-device-name-fails-to-set-up-the-specified-name-mapping%23new-answer', 'question_page');

    );

    Post as a guest






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote













    You're using the wrong command instead use the following command until you complete install and boot into your new Arch OS:



    # cryptsetup --type luks open /dev/sdaX plain1 #change **plain1** to your map location 


    After you boot into your new OS then you can use the other one. Don't forget DuckDuckGo, Qwant, Google and so on are your friends. Carry on from there, good luck.






    share|improve this answer


























      up vote
      0
      down vote













      You're using the wrong command instead use the following command until you complete install and boot into your new Arch OS:



      # cryptsetup --type luks open /dev/sdaX plain1 #change **plain1** to your map location 


      After you boot into your new OS then you can use the other one. Don't forget DuckDuckGo, Qwant, Google and so on are your friends. Carry on from there, good luck.






      share|improve this answer
























        up vote
        0
        down vote










        up vote
        0
        down vote









        You're using the wrong command instead use the following command until you complete install and boot into your new Arch OS:



        # cryptsetup --type luks open /dev/sdaX plain1 #change **plain1** to your map location 


        After you boot into your new OS then you can use the other one. Don't forget DuckDuckGo, Qwant, Google and so on are your friends. Carry on from there, good luck.






        share|improve this answer














        You're using the wrong command instead use the following command until you complete install and boot into your new Arch OS:



        # cryptsetup --type luks open /dev/sdaX plain1 #change **plain1** to your map location 


        After you boot into your new OS then you can use the other one. Don't forget DuckDuckGo, Qwant, Google and so on are your friends. Carry on from there, good luck.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 15 at 6:45









        yeti

        2,36611223




        2,36611223










        answered Mar 15 at 4:43









        gettywig

        11




        11






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f417135%2fcryptsetup-luksopen-device-name-fails-to-set-up-the-specified-name-mapping%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?