Broken Debian boot when trying to auto-mount an encrypted partition

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











up vote
0
down vote

favorite












I've made a quite thoroughly encrypted, balanced and well functioning filesystem with dm-crypt/LUKS/cryptsetup, but I made the mistake of leaving the home folder unencrypted when first installing Debian (jessie).



Since this has grown into a highly organized and very streamlined system that took weeks to build, I wanted to encrypt the home folder with minimum change to the system. I already had a large encrypted partition on a seperate drive for user created documents and projects, so I thought: Why not just move the home folder data over there, and point Debian to it instead?



This would obviously entail auto-mounting the encrypted partion I want to use on every boot. At present it is only mounted when needed, using a script that calls "cryptsetup luksOpen" and "mount". So before typing "usermod -d" and editing "HOME=" in "/etc/default/useradd", the first order of business was to auto-mount an existing, working encrypted partition. Simple, right?



Well, I messed up somehow, because now the system won't boot...



Here's what I did:



After carefully reading up on the subject to make sure I wasn't overlooking something, I edited "/etc/crypttab" and "/etc/fstab", in that order.



My crypttab was simple: It contained two lines. These were both added by the Debian installer when the system was new, and I never had any problems with them:




sda2_fsroot UUID=deadbeef-dead-beef-dead-beefdeadbeef none luks



sda3_swappart UUID=beefdead-beef-dead-beef-deadbeefdead none luks,swap




(Obviously I changed the UUID's for this post)



(Yes, I am aware I could just use urandom as keyfile for the swap. I wanna fix this first)



I was unsure which UUID to add on the extra line I was going to put there, because blkid showed both a "UUID" and a "PARTUUID" for the partition I was trying to auto-mount (it is a GPT partition). I had a hard time finding concrete answers about this, so I decided to just play it safe and follow the manual, entering the UUID like so:




documents UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none luks




(Here the x are the UUID, not the PARTUUID, of the partition I wanted to mount. My source was blkid, and I copypasted to make sure I got it right)



(This was added as a new line directly below the existing two lines in crypttab)



Then I saved crypttab, and opened fstab. In fstab I simply added the following line directly below the bottom one (which was the DVD drive):




/dev/mapper/documents /storage/documents ext4 defaults 0 2




(Here "/storage/documents" is the folder and mountpoint I have always used for this partition)



The options "ext4", "defaults", "0" and "2" should all be correct according to what I've read and done, and just to guard myself against silly errors like using tab instead of space I actually copypasted these options from the existing, working line for sda2_fsroot (to be clear: sda2_fsroot is mounted as / ).



Then, after some extra websearching and reading, I reluctantly (since this feels like doing heart surgery) ran, as root:




update-initramfs -u




Then I rebooted. And it doesn't work...



I get prompted for the password for the fsroot, and for the swappart. I enter both passwords, and get a message that the blocks on fsroot look ok. And then nothing. I am never asked for the password for documents. Boot never proceeds.



Rebooting into rescue mode doesn't help. It too freezes in the boot process.



Since I wanted to take my precautions however simple this might seem, I had actually made a backup of the four files in "/boot/" (vmlinuz, initramfs and two others), from right before I made the changes to crypttab and fstab and ran update-initramfs.



So after not finding any answers to this online, I booted up a Debian live DVD, confirmed that all my encrypted drives were still intact and mountable as usual, and tried to restore the four files in "/boot/" to their previous state, as I suspect initramfs to be the culprit (maybe something to do with Debian moving to stretch?).



To be extra safe I didn't DELETE the four files in /boot/ and replace them: I figure this folder/partition is so special that it might rely on the files occupying special sectors on the drive. So just to be sure, I renamed all four updated files with a ".bak" extension, and then copied the old versions with the "correct" filename to "/boot/", leaving both versions in the folder.



The result?



Now I am not even asked to enter a password... When I boot I get a black screen with a blinking underscore, that just sits there like the CPU was halted.



What do I do now?



I simply don't know the low level details of initramfs, fstab and so on well enough, and I am really surprised at how easily this stuff breaks, even when I try to prepare and be careful!



Any help would be greatly appreciated!







share|improve this question
























    up vote
    0
    down vote

    favorite












    I've made a quite thoroughly encrypted, balanced and well functioning filesystem with dm-crypt/LUKS/cryptsetup, but I made the mistake of leaving the home folder unencrypted when first installing Debian (jessie).



    Since this has grown into a highly organized and very streamlined system that took weeks to build, I wanted to encrypt the home folder with minimum change to the system. I already had a large encrypted partition on a seperate drive for user created documents and projects, so I thought: Why not just move the home folder data over there, and point Debian to it instead?



    This would obviously entail auto-mounting the encrypted partion I want to use on every boot. At present it is only mounted when needed, using a script that calls "cryptsetup luksOpen" and "mount". So before typing "usermod -d" and editing "HOME=" in "/etc/default/useradd", the first order of business was to auto-mount an existing, working encrypted partition. Simple, right?



    Well, I messed up somehow, because now the system won't boot...



    Here's what I did:



    After carefully reading up on the subject to make sure I wasn't overlooking something, I edited "/etc/crypttab" and "/etc/fstab", in that order.



    My crypttab was simple: It contained two lines. These were both added by the Debian installer when the system was new, and I never had any problems with them:




    sda2_fsroot UUID=deadbeef-dead-beef-dead-beefdeadbeef none luks



    sda3_swappart UUID=beefdead-beef-dead-beef-deadbeefdead none luks,swap




    (Obviously I changed the UUID's for this post)



    (Yes, I am aware I could just use urandom as keyfile for the swap. I wanna fix this first)



    I was unsure which UUID to add on the extra line I was going to put there, because blkid showed both a "UUID" and a "PARTUUID" for the partition I was trying to auto-mount (it is a GPT partition). I had a hard time finding concrete answers about this, so I decided to just play it safe and follow the manual, entering the UUID like so:




    documents UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none luks




    (Here the x are the UUID, not the PARTUUID, of the partition I wanted to mount. My source was blkid, and I copypasted to make sure I got it right)



    (This was added as a new line directly below the existing two lines in crypttab)



    Then I saved crypttab, and opened fstab. In fstab I simply added the following line directly below the bottom one (which was the DVD drive):




    /dev/mapper/documents /storage/documents ext4 defaults 0 2




    (Here "/storage/documents" is the folder and mountpoint I have always used for this partition)



    The options "ext4", "defaults", "0" and "2" should all be correct according to what I've read and done, and just to guard myself against silly errors like using tab instead of space I actually copypasted these options from the existing, working line for sda2_fsroot (to be clear: sda2_fsroot is mounted as / ).



    Then, after some extra websearching and reading, I reluctantly (since this feels like doing heart surgery) ran, as root:




    update-initramfs -u




    Then I rebooted. And it doesn't work...



    I get prompted for the password for the fsroot, and for the swappart. I enter both passwords, and get a message that the blocks on fsroot look ok. And then nothing. I am never asked for the password for documents. Boot never proceeds.



    Rebooting into rescue mode doesn't help. It too freezes in the boot process.



    Since I wanted to take my precautions however simple this might seem, I had actually made a backup of the four files in "/boot/" (vmlinuz, initramfs and two others), from right before I made the changes to crypttab and fstab and ran update-initramfs.



    So after not finding any answers to this online, I booted up a Debian live DVD, confirmed that all my encrypted drives were still intact and mountable as usual, and tried to restore the four files in "/boot/" to their previous state, as I suspect initramfs to be the culprit (maybe something to do with Debian moving to stretch?).



    To be extra safe I didn't DELETE the four files in /boot/ and replace them: I figure this folder/partition is so special that it might rely on the files occupying special sectors on the drive. So just to be sure, I renamed all four updated files with a ".bak" extension, and then copied the old versions with the "correct" filename to "/boot/", leaving both versions in the folder.



    The result?



    Now I am not even asked to enter a password... When I boot I get a black screen with a blinking underscore, that just sits there like the CPU was halted.



    What do I do now?



    I simply don't know the low level details of initramfs, fstab and so on well enough, and I am really surprised at how easily this stuff breaks, even when I try to prepare and be careful!



    Any help would be greatly appreciated!







    share|improve this question






















      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I've made a quite thoroughly encrypted, balanced and well functioning filesystem with dm-crypt/LUKS/cryptsetup, but I made the mistake of leaving the home folder unencrypted when first installing Debian (jessie).



      Since this has grown into a highly organized and very streamlined system that took weeks to build, I wanted to encrypt the home folder with minimum change to the system. I already had a large encrypted partition on a seperate drive for user created documents and projects, so I thought: Why not just move the home folder data over there, and point Debian to it instead?



      This would obviously entail auto-mounting the encrypted partion I want to use on every boot. At present it is only mounted when needed, using a script that calls "cryptsetup luksOpen" and "mount". So before typing "usermod -d" and editing "HOME=" in "/etc/default/useradd", the first order of business was to auto-mount an existing, working encrypted partition. Simple, right?



      Well, I messed up somehow, because now the system won't boot...



      Here's what I did:



      After carefully reading up on the subject to make sure I wasn't overlooking something, I edited "/etc/crypttab" and "/etc/fstab", in that order.



      My crypttab was simple: It contained two lines. These were both added by the Debian installer when the system was new, and I never had any problems with them:




      sda2_fsroot UUID=deadbeef-dead-beef-dead-beefdeadbeef none luks



      sda3_swappart UUID=beefdead-beef-dead-beef-deadbeefdead none luks,swap




      (Obviously I changed the UUID's for this post)



      (Yes, I am aware I could just use urandom as keyfile for the swap. I wanna fix this first)



      I was unsure which UUID to add on the extra line I was going to put there, because blkid showed both a "UUID" and a "PARTUUID" for the partition I was trying to auto-mount (it is a GPT partition). I had a hard time finding concrete answers about this, so I decided to just play it safe and follow the manual, entering the UUID like so:




      documents UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none luks




      (Here the x are the UUID, not the PARTUUID, of the partition I wanted to mount. My source was blkid, and I copypasted to make sure I got it right)



      (This was added as a new line directly below the existing two lines in crypttab)



      Then I saved crypttab, and opened fstab. In fstab I simply added the following line directly below the bottom one (which was the DVD drive):




      /dev/mapper/documents /storage/documents ext4 defaults 0 2




      (Here "/storage/documents" is the folder and mountpoint I have always used for this partition)



      The options "ext4", "defaults", "0" and "2" should all be correct according to what I've read and done, and just to guard myself against silly errors like using tab instead of space I actually copypasted these options from the existing, working line for sda2_fsroot (to be clear: sda2_fsroot is mounted as / ).



      Then, after some extra websearching and reading, I reluctantly (since this feels like doing heart surgery) ran, as root:




      update-initramfs -u




      Then I rebooted. And it doesn't work...



      I get prompted for the password for the fsroot, and for the swappart. I enter both passwords, and get a message that the blocks on fsroot look ok. And then nothing. I am never asked for the password for documents. Boot never proceeds.



      Rebooting into rescue mode doesn't help. It too freezes in the boot process.



      Since I wanted to take my precautions however simple this might seem, I had actually made a backup of the four files in "/boot/" (vmlinuz, initramfs and two others), from right before I made the changes to crypttab and fstab and ran update-initramfs.



      So after not finding any answers to this online, I booted up a Debian live DVD, confirmed that all my encrypted drives were still intact and mountable as usual, and tried to restore the four files in "/boot/" to their previous state, as I suspect initramfs to be the culprit (maybe something to do with Debian moving to stretch?).



      To be extra safe I didn't DELETE the four files in /boot/ and replace them: I figure this folder/partition is so special that it might rely on the files occupying special sectors on the drive. So just to be sure, I renamed all four updated files with a ".bak" extension, and then copied the old versions with the "correct" filename to "/boot/", leaving both versions in the folder.



      The result?



      Now I am not even asked to enter a password... When I boot I get a black screen with a blinking underscore, that just sits there like the CPU was halted.



      What do I do now?



      I simply don't know the low level details of initramfs, fstab and so on well enough, and I am really surprised at how easily this stuff breaks, even when I try to prepare and be careful!



      Any help would be greatly appreciated!







      share|improve this question












      I've made a quite thoroughly encrypted, balanced and well functioning filesystem with dm-crypt/LUKS/cryptsetup, but I made the mistake of leaving the home folder unencrypted when first installing Debian (jessie).



      Since this has grown into a highly organized and very streamlined system that took weeks to build, I wanted to encrypt the home folder with minimum change to the system. I already had a large encrypted partition on a seperate drive for user created documents and projects, so I thought: Why not just move the home folder data over there, and point Debian to it instead?



      This would obviously entail auto-mounting the encrypted partion I want to use on every boot. At present it is only mounted when needed, using a script that calls "cryptsetup luksOpen" and "mount". So before typing "usermod -d" and editing "HOME=" in "/etc/default/useradd", the first order of business was to auto-mount an existing, working encrypted partition. Simple, right?



      Well, I messed up somehow, because now the system won't boot...



      Here's what I did:



      After carefully reading up on the subject to make sure I wasn't overlooking something, I edited "/etc/crypttab" and "/etc/fstab", in that order.



      My crypttab was simple: It contained two lines. These were both added by the Debian installer when the system was new, and I never had any problems with them:




      sda2_fsroot UUID=deadbeef-dead-beef-dead-beefdeadbeef none luks



      sda3_swappart UUID=beefdead-beef-dead-beef-deadbeefdead none luks,swap




      (Obviously I changed the UUID's for this post)



      (Yes, I am aware I could just use urandom as keyfile for the swap. I wanna fix this first)



      I was unsure which UUID to add on the extra line I was going to put there, because blkid showed both a "UUID" and a "PARTUUID" for the partition I was trying to auto-mount (it is a GPT partition). I had a hard time finding concrete answers about this, so I decided to just play it safe and follow the manual, entering the UUID like so:




      documents UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none luks




      (Here the x are the UUID, not the PARTUUID, of the partition I wanted to mount. My source was blkid, and I copypasted to make sure I got it right)



      (This was added as a new line directly below the existing two lines in crypttab)



      Then I saved crypttab, and opened fstab. In fstab I simply added the following line directly below the bottom one (which was the DVD drive):




      /dev/mapper/documents /storage/documents ext4 defaults 0 2




      (Here "/storage/documents" is the folder and mountpoint I have always used for this partition)



      The options "ext4", "defaults", "0" and "2" should all be correct according to what I've read and done, and just to guard myself against silly errors like using tab instead of space I actually copypasted these options from the existing, working line for sda2_fsroot (to be clear: sda2_fsroot is mounted as / ).



      Then, after some extra websearching and reading, I reluctantly (since this feels like doing heart surgery) ran, as root:




      update-initramfs -u




      Then I rebooted. And it doesn't work...



      I get prompted for the password for the fsroot, and for the swappart. I enter both passwords, and get a message that the blocks on fsroot look ok. And then nothing. I am never asked for the password for documents. Boot never proceeds.



      Rebooting into rescue mode doesn't help. It too freezes in the boot process.



      Since I wanted to take my precautions however simple this might seem, I had actually made a backup of the four files in "/boot/" (vmlinuz, initramfs and two others), from right before I made the changes to crypttab and fstab and ran update-initramfs.



      So after not finding any answers to this online, I booted up a Debian live DVD, confirmed that all my encrypted drives were still intact and mountable as usual, and tried to restore the four files in "/boot/" to their previous state, as I suspect initramfs to be the culprit (maybe something to do with Debian moving to stretch?).



      To be extra safe I didn't DELETE the four files in /boot/ and replace them: I figure this folder/partition is so special that it might rely on the files occupying special sectors on the drive. So just to be sure, I renamed all four updated files with a ".bak" extension, and then copied the old versions with the "correct" filename to "/boot/", leaving both versions in the folder.



      The result?



      Now I am not even asked to enter a password... When I boot I get a black screen with a blinking underscore, that just sits there like the CPU was halted.



      What do I do now?



      I simply don't know the low level details of initramfs, fstab and so on well enough, and I am really surprised at how easily this stuff breaks, even when I try to prepare and be careful!



      Any help would be greatly appreciated!









      share|improve this question











      share|improve this question




      share|improve this question










      asked Feb 17 at 19:35









      Alex Malkovich

      12




      12

























          active

          oldest

          votes











          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%2f424850%2fbroken-debian-boot-when-trying-to-auto-mount-an-encrypted-partition%23new-answer', 'question_page');

          );

          Post as a guest



































          active

          oldest

          votes













          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes










           

          draft saved


          draft discarded


























           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f424850%2fbroken-debian-boot-when-trying-to-auto-mount-an-encrypted-partition%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?