System no longer boots, gave up waiting for root device, (initramfs), /dev/mapper/gnome-root does not exist












10















After installing an update, my system no longer boots. I have full disk encryption (the one the installer sets up for you) enabled so it usually asks for the key only seconds after booting past GRUB. Now, it skips asking for the key, tries to load Gnome, and then goes to the screen pictured below. The system is a 64-bit System76 box running Ubuntu Gnome 13.04. This has happened to me once in the past however, on a Dell XPS 8300 64-bit running Ubuntu Gnome Remix 12.10. In that case I reinstalled the OS. However I want to actually fix the problem this time so I know how to handle it in the future. Also, it is extremely inconvenient to reinstall from scratch.



My suspicion is that something got screwed up in a config file in /boot such that it doesn't realize the disk is encrypted, but I didn't see anything when poking around in there. Do you have any ideas of how to fix it (besides reinstalling the OS)?



Gave up waiting for root device. Common problems:
— Boot args (cat /proc/cmdline)
— Check rootdelay= (did the system wait long enough?)
— Check root= (did the system wait for the right device?)
— Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/gnome-root does not exist.
Dropping to a shell!

BusyBox v.1.20.2 (Ubuntu 1:1.20.2-1ubuntu1) built-in shell (ash)
Enter 'help' for list of built-in commands.

(initramfs)









share|improve this question





























    10















    After installing an update, my system no longer boots. I have full disk encryption (the one the installer sets up for you) enabled so it usually asks for the key only seconds after booting past GRUB. Now, it skips asking for the key, tries to load Gnome, and then goes to the screen pictured below. The system is a 64-bit System76 box running Ubuntu Gnome 13.04. This has happened to me once in the past however, on a Dell XPS 8300 64-bit running Ubuntu Gnome Remix 12.10. In that case I reinstalled the OS. However I want to actually fix the problem this time so I know how to handle it in the future. Also, it is extremely inconvenient to reinstall from scratch.



    My suspicion is that something got screwed up in a config file in /boot such that it doesn't realize the disk is encrypted, but I didn't see anything when poking around in there. Do you have any ideas of how to fix it (besides reinstalling the OS)?



    Gave up waiting for root device. Common problems:
    — Boot args (cat /proc/cmdline)
    — Check rootdelay= (did the system wait long enough?)
    — Check root= (did the system wait for the right device?)
    — Missing modules (cat /proc/modules; ls /dev)
    ALERT! /dev/mapper/gnome-root does not exist.
    Dropping to a shell!

    BusyBox v.1.20.2 (Ubuntu 1:1.20.2-1ubuntu1) built-in shell (ash)
    Enter 'help' for list of built-in commands.

    (initramfs)









    share|improve this question



























      10












      10








      10


      2






      After installing an update, my system no longer boots. I have full disk encryption (the one the installer sets up for you) enabled so it usually asks for the key only seconds after booting past GRUB. Now, it skips asking for the key, tries to load Gnome, and then goes to the screen pictured below. The system is a 64-bit System76 box running Ubuntu Gnome 13.04. This has happened to me once in the past however, on a Dell XPS 8300 64-bit running Ubuntu Gnome Remix 12.10. In that case I reinstalled the OS. However I want to actually fix the problem this time so I know how to handle it in the future. Also, it is extremely inconvenient to reinstall from scratch.



      My suspicion is that something got screwed up in a config file in /boot such that it doesn't realize the disk is encrypted, but I didn't see anything when poking around in there. Do you have any ideas of how to fix it (besides reinstalling the OS)?



      Gave up waiting for root device. Common problems:
      — Boot args (cat /proc/cmdline)
      — Check rootdelay= (did the system wait long enough?)
      — Check root= (did the system wait for the right device?)
      — Missing modules (cat /proc/modules; ls /dev)
      ALERT! /dev/mapper/gnome-root does not exist.
      Dropping to a shell!

      BusyBox v.1.20.2 (Ubuntu 1:1.20.2-1ubuntu1) built-in shell (ash)
      Enter 'help' for list of built-in commands.

      (initramfs)









      share|improve this question
















      After installing an update, my system no longer boots. I have full disk encryption (the one the installer sets up for you) enabled so it usually asks for the key only seconds after booting past GRUB. Now, it skips asking for the key, tries to load Gnome, and then goes to the screen pictured below. The system is a 64-bit System76 box running Ubuntu Gnome 13.04. This has happened to me once in the past however, on a Dell XPS 8300 64-bit running Ubuntu Gnome Remix 12.10. In that case I reinstalled the OS. However I want to actually fix the problem this time so I know how to handle it in the future. Also, it is extremely inconvenient to reinstall from scratch.



      My suspicion is that something got screwed up in a config file in /boot such that it doesn't realize the disk is encrypted, but I didn't see anything when poking around in there. Do you have any ideas of how to fix it (besides reinstalling the OS)?



      Gave up waiting for root device. Common problems:
      — Boot args (cat /proc/cmdline)
      — Check rootdelay= (did the system wait long enough?)
      — Check root= (did the system wait for the right device?)
      — Missing modules (cat /proc/modules; ls /dev)
      ALERT! /dev/mapper/gnome-root does not exist.
      Dropping to a shell!

      BusyBox v.1.20.2 (Ubuntu 1:1.20.2-1ubuntu1) built-in shell (ash)
      Enter 'help' for list of built-in commands.

      (initramfs)






      boot gnome grub2 updates






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Sep 4 '16 at 15:16









      karel

      59.2k13128151




      59.2k13128151










      asked Apr 26 '13 at 23:37









      Freedom_BenFreedom_Ben

      5,17762132




      5,17762132






















          4 Answers
          4






          active

          oldest

          votes


















          9














          I got it fixed!!! For future generations so you don't have to go through the agonizing days and endless hours that I did:



          Firstly, I was able to get the system to boot from the (initramfs) prompt by typing the following (I used this forum page as a crutch):



          cryptsetup luksOpen /dev/sda5 sda5_crypt
          lvm vgchange -a y
          exit


          This got my system to boot properly. Once booted, I modified /etc/crypttab to point to a different UUID than before. I picked the UUID from my /etc/fstab. Save the original UUID value. You will need it in a few steps. I then ran (from a terminal):



          update-initramfs -k all -c


          If you get a warning that looks like this or something similar:



          WARNING: invalid line in /etc/crypttab


          then go back to the beginning and instead of sda5_crypt, use what is in your crypttab.



          I then rebooted. This time I got the prompt for the passphrase! But don't get too excited, because it didn't work. I entered the right password about 7 times and it rejected them all. It then went back to the (initramfs) prompt after about 90 seconds.



          I repeated step one and got it booted again. I then restored the original UUID value to the crypttab, and reran step two. I then rebooted, and SUCCESS!






          share|improve this answer































            5














            With full-disk encryption being an option in Ubuntu 14.04, I just wanted to point out how I solved this problem, since my initramfs terminal didn't allow me to use cryptsetup:




            1. Boot from a Live DVD/USB (USB will be a lot faster).



            2. Open a Terminal and type the following:



              sudo -i
              cryptsetup luksOpen /dev/sda5 sda5_crypt
              # (do any lvm management you need here, I didn't need any.)
              mkdir /mnt/system
              mount /dev/mapper/ubuntu--vg-root /mnt/system
              mount /dev/sda2 /mnt/system/boot
              mount /dev/sda1 /mnt/system/boot/efi (May or may not be needed.)
              for i in /dev/pts /dev /proc /sys; do mount -B $i /mnt/system$i; done
              chroot /mnt/system
              update-initramfs -k all -c
              exit
              for i in /dev/pts /dev /proc /sys; do umount /mnt/system$i; done
              umount /mnt/system/boot/efi # (If you have UEFI.)
              umount /mnt/system/boot
              umount /mnt/system


            3. Reboot and hope it works.







            share|improve this answer


























            • I liked this solution better, because I didn't have to figure out how to get an initramfs prompt or do more than one reboot. In my case, I had upgraded from Ubuntu 15.04 to 15.10 and was no longer able to unlock my drive during boot. One addition is that I found that the mapping name provided on line 2 (e.g. sda5_crypt) needs to match your crypttab file.

              – Der Wolf
              Oct 30 '15 at 0:59






            • 1





              The above only works if you have an entry in /etc/crypttab. After entering the chroot per the steps above, but before running update-initramfs, run nano /etc/crypttab, and make sure there is a line there with the name of the mapper and the drive UUID. If the file does not exist or is empty, update-initramfs will not fix the issue! Add the crypttab line while in the chroot environment. This answer should be edited to reflect this. Also, I think that cryptsetup only exists on the initramfs prompt if /etc/crypttab exists and has entries when initramfs is updated.

              – Nick
              May 13 '16 at 13:12





















            0














            Fix your grub via booting through a live-cd/live-usb. Refer this page for details of the process. Refer the section "via the LiveCD terminal" on the page.



            Fixing the grub should fix any malformed file that you might have in grub configuration.






            share|improve this answer
























            • Thanks for the tip. I tried all that you suggested but to no avail. I did just get it figured out though. It's pretty crazy...

              – Freedom_Ben
              Apr 27 '13 at 4:04



















            0














            Check if you have cryptsetup installed on your system, it might have been removed by running apt-get autoremove. More info.






            share|improve this answer























              Your Answer








              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "89"
              };
              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',
              autoActivateHeartbeat: false,
              convertImagesToLinks: true,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: 10,
              bindNavPrevention: true,
              postfix: "",
              imageUploader: {
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              },
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f286284%2fsystem-no-longer-boots-gave-up-waiting-for-root-device-initramfs-dev-mappe%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              4 Answers
              4






              active

              oldest

              votes








              4 Answers
              4






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              9














              I got it fixed!!! For future generations so you don't have to go through the agonizing days and endless hours that I did:



              Firstly, I was able to get the system to boot from the (initramfs) prompt by typing the following (I used this forum page as a crutch):



              cryptsetup luksOpen /dev/sda5 sda5_crypt
              lvm vgchange -a y
              exit


              This got my system to boot properly. Once booted, I modified /etc/crypttab to point to a different UUID than before. I picked the UUID from my /etc/fstab. Save the original UUID value. You will need it in a few steps. I then ran (from a terminal):



              update-initramfs -k all -c


              If you get a warning that looks like this or something similar:



              WARNING: invalid line in /etc/crypttab


              then go back to the beginning and instead of sda5_crypt, use what is in your crypttab.



              I then rebooted. This time I got the prompt for the passphrase! But don't get too excited, because it didn't work. I entered the right password about 7 times and it rejected them all. It then went back to the (initramfs) prompt after about 90 seconds.



              I repeated step one and got it booted again. I then restored the original UUID value to the crypttab, and reran step two. I then rebooted, and SUCCESS!






              share|improve this answer




























                9














                I got it fixed!!! For future generations so you don't have to go through the agonizing days and endless hours that I did:



                Firstly, I was able to get the system to boot from the (initramfs) prompt by typing the following (I used this forum page as a crutch):



                cryptsetup luksOpen /dev/sda5 sda5_crypt
                lvm vgchange -a y
                exit


                This got my system to boot properly. Once booted, I modified /etc/crypttab to point to a different UUID than before. I picked the UUID from my /etc/fstab. Save the original UUID value. You will need it in a few steps. I then ran (from a terminal):



                update-initramfs -k all -c


                If you get a warning that looks like this or something similar:



                WARNING: invalid line in /etc/crypttab


                then go back to the beginning and instead of sda5_crypt, use what is in your crypttab.



                I then rebooted. This time I got the prompt for the passphrase! But don't get too excited, because it didn't work. I entered the right password about 7 times and it rejected them all. It then went back to the (initramfs) prompt after about 90 seconds.



                I repeated step one and got it booted again. I then restored the original UUID value to the crypttab, and reran step two. I then rebooted, and SUCCESS!






                share|improve this answer


























                  9












                  9








                  9







                  I got it fixed!!! For future generations so you don't have to go through the agonizing days and endless hours that I did:



                  Firstly, I was able to get the system to boot from the (initramfs) prompt by typing the following (I used this forum page as a crutch):



                  cryptsetup luksOpen /dev/sda5 sda5_crypt
                  lvm vgchange -a y
                  exit


                  This got my system to boot properly. Once booted, I modified /etc/crypttab to point to a different UUID than before. I picked the UUID from my /etc/fstab. Save the original UUID value. You will need it in a few steps. I then ran (from a terminal):



                  update-initramfs -k all -c


                  If you get a warning that looks like this or something similar:



                  WARNING: invalid line in /etc/crypttab


                  then go back to the beginning and instead of sda5_crypt, use what is in your crypttab.



                  I then rebooted. This time I got the prompt for the passphrase! But don't get too excited, because it didn't work. I entered the right password about 7 times and it rejected them all. It then went back to the (initramfs) prompt after about 90 seconds.



                  I repeated step one and got it booted again. I then restored the original UUID value to the crypttab, and reran step two. I then rebooted, and SUCCESS!






                  share|improve this answer













                  I got it fixed!!! For future generations so you don't have to go through the agonizing days and endless hours that I did:



                  Firstly, I was able to get the system to boot from the (initramfs) prompt by typing the following (I used this forum page as a crutch):



                  cryptsetup luksOpen /dev/sda5 sda5_crypt
                  lvm vgchange -a y
                  exit


                  This got my system to boot properly. Once booted, I modified /etc/crypttab to point to a different UUID than before. I picked the UUID from my /etc/fstab. Save the original UUID value. You will need it in a few steps. I then ran (from a terminal):



                  update-initramfs -k all -c


                  If you get a warning that looks like this or something similar:



                  WARNING: invalid line in /etc/crypttab


                  then go back to the beginning and instead of sda5_crypt, use what is in your crypttab.



                  I then rebooted. This time I got the prompt for the passphrase! But don't get too excited, because it didn't work. I entered the right password about 7 times and it rejected them all. It then went back to the (initramfs) prompt after about 90 seconds.



                  I repeated step one and got it booted again. I then restored the original UUID value to the crypttab, and reran step two. I then rebooted, and SUCCESS!







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Apr 27 '13 at 4:23









                  Freedom_BenFreedom_Ben

                  5,17762132




                  5,17762132

























                      5














                      With full-disk encryption being an option in Ubuntu 14.04, I just wanted to point out how I solved this problem, since my initramfs terminal didn't allow me to use cryptsetup:




                      1. Boot from a Live DVD/USB (USB will be a lot faster).



                      2. Open a Terminal and type the following:



                        sudo -i
                        cryptsetup luksOpen /dev/sda5 sda5_crypt
                        # (do any lvm management you need here, I didn't need any.)
                        mkdir /mnt/system
                        mount /dev/mapper/ubuntu--vg-root /mnt/system
                        mount /dev/sda2 /mnt/system/boot
                        mount /dev/sda1 /mnt/system/boot/efi (May or may not be needed.)
                        for i in /dev/pts /dev /proc /sys; do mount -B $i /mnt/system$i; done
                        chroot /mnt/system
                        update-initramfs -k all -c
                        exit
                        for i in /dev/pts /dev /proc /sys; do umount /mnt/system$i; done
                        umount /mnt/system/boot/efi # (If you have UEFI.)
                        umount /mnt/system/boot
                        umount /mnt/system


                      3. Reboot and hope it works.







                      share|improve this answer


























                      • I liked this solution better, because I didn't have to figure out how to get an initramfs prompt or do more than one reboot. In my case, I had upgraded from Ubuntu 15.04 to 15.10 and was no longer able to unlock my drive during boot. One addition is that I found that the mapping name provided on line 2 (e.g. sda5_crypt) needs to match your crypttab file.

                        – Der Wolf
                        Oct 30 '15 at 0:59






                      • 1





                        The above only works if you have an entry in /etc/crypttab. After entering the chroot per the steps above, but before running update-initramfs, run nano /etc/crypttab, and make sure there is a line there with the name of the mapper and the drive UUID. If the file does not exist or is empty, update-initramfs will not fix the issue! Add the crypttab line while in the chroot environment. This answer should be edited to reflect this. Also, I think that cryptsetup only exists on the initramfs prompt if /etc/crypttab exists and has entries when initramfs is updated.

                        – Nick
                        May 13 '16 at 13:12


















                      5














                      With full-disk encryption being an option in Ubuntu 14.04, I just wanted to point out how I solved this problem, since my initramfs terminal didn't allow me to use cryptsetup:




                      1. Boot from a Live DVD/USB (USB will be a lot faster).



                      2. Open a Terminal and type the following:



                        sudo -i
                        cryptsetup luksOpen /dev/sda5 sda5_crypt
                        # (do any lvm management you need here, I didn't need any.)
                        mkdir /mnt/system
                        mount /dev/mapper/ubuntu--vg-root /mnt/system
                        mount /dev/sda2 /mnt/system/boot
                        mount /dev/sda1 /mnt/system/boot/efi (May or may not be needed.)
                        for i in /dev/pts /dev /proc /sys; do mount -B $i /mnt/system$i; done
                        chroot /mnt/system
                        update-initramfs -k all -c
                        exit
                        for i in /dev/pts /dev /proc /sys; do umount /mnt/system$i; done
                        umount /mnt/system/boot/efi # (If you have UEFI.)
                        umount /mnt/system/boot
                        umount /mnt/system


                      3. Reboot and hope it works.







                      share|improve this answer


























                      • I liked this solution better, because I didn't have to figure out how to get an initramfs prompt or do more than one reboot. In my case, I had upgraded from Ubuntu 15.04 to 15.10 and was no longer able to unlock my drive during boot. One addition is that I found that the mapping name provided on line 2 (e.g. sda5_crypt) needs to match your crypttab file.

                        – Der Wolf
                        Oct 30 '15 at 0:59






                      • 1





                        The above only works if you have an entry in /etc/crypttab. After entering the chroot per the steps above, but before running update-initramfs, run nano /etc/crypttab, and make sure there is a line there with the name of the mapper and the drive UUID. If the file does not exist or is empty, update-initramfs will not fix the issue! Add the crypttab line while in the chroot environment. This answer should be edited to reflect this. Also, I think that cryptsetup only exists on the initramfs prompt if /etc/crypttab exists and has entries when initramfs is updated.

                        – Nick
                        May 13 '16 at 13:12
















                      5












                      5








                      5







                      With full-disk encryption being an option in Ubuntu 14.04, I just wanted to point out how I solved this problem, since my initramfs terminal didn't allow me to use cryptsetup:




                      1. Boot from a Live DVD/USB (USB will be a lot faster).



                      2. Open a Terminal and type the following:



                        sudo -i
                        cryptsetup luksOpen /dev/sda5 sda5_crypt
                        # (do any lvm management you need here, I didn't need any.)
                        mkdir /mnt/system
                        mount /dev/mapper/ubuntu--vg-root /mnt/system
                        mount /dev/sda2 /mnt/system/boot
                        mount /dev/sda1 /mnt/system/boot/efi (May or may not be needed.)
                        for i in /dev/pts /dev /proc /sys; do mount -B $i /mnt/system$i; done
                        chroot /mnt/system
                        update-initramfs -k all -c
                        exit
                        for i in /dev/pts /dev /proc /sys; do umount /mnt/system$i; done
                        umount /mnt/system/boot/efi # (If you have UEFI.)
                        umount /mnt/system/boot
                        umount /mnt/system


                      3. Reboot and hope it works.







                      share|improve this answer















                      With full-disk encryption being an option in Ubuntu 14.04, I just wanted to point out how I solved this problem, since my initramfs terminal didn't allow me to use cryptsetup:




                      1. Boot from a Live DVD/USB (USB will be a lot faster).



                      2. Open a Terminal and type the following:



                        sudo -i
                        cryptsetup luksOpen /dev/sda5 sda5_crypt
                        # (do any lvm management you need here, I didn't need any.)
                        mkdir /mnt/system
                        mount /dev/mapper/ubuntu--vg-root /mnt/system
                        mount /dev/sda2 /mnt/system/boot
                        mount /dev/sda1 /mnt/system/boot/efi (May or may not be needed.)
                        for i in /dev/pts /dev /proc /sys; do mount -B $i /mnt/system$i; done
                        chroot /mnt/system
                        update-initramfs -k all -c
                        exit
                        for i in /dev/pts /dev /proc /sys; do umount /mnt/system$i; done
                        umount /mnt/system/boot/efi # (If you have UEFI.)
                        umount /mnt/system/boot
                        umount /mnt/system


                      3. Reboot and hope it works.








                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      edited Apr 16 '15 at 4:21









                      Eliah Kagan

                      82.2k21227366




                      82.2k21227366










                      answered May 27 '14 at 4:52









                      k0ryfik0ryfi

                      9614




                      9614













                      • I liked this solution better, because I didn't have to figure out how to get an initramfs prompt or do more than one reboot. In my case, I had upgraded from Ubuntu 15.04 to 15.10 and was no longer able to unlock my drive during boot. One addition is that I found that the mapping name provided on line 2 (e.g. sda5_crypt) needs to match your crypttab file.

                        – Der Wolf
                        Oct 30 '15 at 0:59






                      • 1





                        The above only works if you have an entry in /etc/crypttab. After entering the chroot per the steps above, but before running update-initramfs, run nano /etc/crypttab, and make sure there is a line there with the name of the mapper and the drive UUID. If the file does not exist or is empty, update-initramfs will not fix the issue! Add the crypttab line while in the chroot environment. This answer should be edited to reflect this. Also, I think that cryptsetup only exists on the initramfs prompt if /etc/crypttab exists and has entries when initramfs is updated.

                        – Nick
                        May 13 '16 at 13:12





















                      • I liked this solution better, because I didn't have to figure out how to get an initramfs prompt or do more than one reboot. In my case, I had upgraded from Ubuntu 15.04 to 15.10 and was no longer able to unlock my drive during boot. One addition is that I found that the mapping name provided on line 2 (e.g. sda5_crypt) needs to match your crypttab file.

                        – Der Wolf
                        Oct 30 '15 at 0:59






                      • 1





                        The above only works if you have an entry in /etc/crypttab. After entering the chroot per the steps above, but before running update-initramfs, run nano /etc/crypttab, and make sure there is a line there with the name of the mapper and the drive UUID. If the file does not exist or is empty, update-initramfs will not fix the issue! Add the crypttab line while in the chroot environment. This answer should be edited to reflect this. Also, I think that cryptsetup only exists on the initramfs prompt if /etc/crypttab exists and has entries when initramfs is updated.

                        – Nick
                        May 13 '16 at 13:12



















                      I liked this solution better, because I didn't have to figure out how to get an initramfs prompt or do more than one reboot. In my case, I had upgraded from Ubuntu 15.04 to 15.10 and was no longer able to unlock my drive during boot. One addition is that I found that the mapping name provided on line 2 (e.g. sda5_crypt) needs to match your crypttab file.

                      – Der Wolf
                      Oct 30 '15 at 0:59





                      I liked this solution better, because I didn't have to figure out how to get an initramfs prompt or do more than one reboot. In my case, I had upgraded from Ubuntu 15.04 to 15.10 and was no longer able to unlock my drive during boot. One addition is that I found that the mapping name provided on line 2 (e.g. sda5_crypt) needs to match your crypttab file.

                      – Der Wolf
                      Oct 30 '15 at 0:59




                      1




                      1





                      The above only works if you have an entry in /etc/crypttab. After entering the chroot per the steps above, but before running update-initramfs, run nano /etc/crypttab, and make sure there is a line there with the name of the mapper and the drive UUID. If the file does not exist or is empty, update-initramfs will not fix the issue! Add the crypttab line while in the chroot environment. This answer should be edited to reflect this. Also, I think that cryptsetup only exists on the initramfs prompt if /etc/crypttab exists and has entries when initramfs is updated.

                      – Nick
                      May 13 '16 at 13:12







                      The above only works if you have an entry in /etc/crypttab. After entering the chroot per the steps above, but before running update-initramfs, run nano /etc/crypttab, and make sure there is a line there with the name of the mapper and the drive UUID. If the file does not exist or is empty, update-initramfs will not fix the issue! Add the crypttab line while in the chroot environment. This answer should be edited to reflect this. Also, I think that cryptsetup only exists on the initramfs prompt if /etc/crypttab exists and has entries when initramfs is updated.

                      – Nick
                      May 13 '16 at 13:12













                      0














                      Fix your grub via booting through a live-cd/live-usb. Refer this page for details of the process. Refer the section "via the LiveCD terminal" on the page.



                      Fixing the grub should fix any malformed file that you might have in grub configuration.






                      share|improve this answer
























                      • Thanks for the tip. I tried all that you suggested but to no avail. I did just get it figured out though. It's pretty crazy...

                        – Freedom_Ben
                        Apr 27 '13 at 4:04
















                      0














                      Fix your grub via booting through a live-cd/live-usb. Refer this page for details of the process. Refer the section "via the LiveCD terminal" on the page.



                      Fixing the grub should fix any malformed file that you might have in grub configuration.






                      share|improve this answer
























                      • Thanks for the tip. I tried all that you suggested but to no avail. I did just get it figured out though. It's pretty crazy...

                        – Freedom_Ben
                        Apr 27 '13 at 4:04














                      0












                      0








                      0







                      Fix your grub via booting through a live-cd/live-usb. Refer this page for details of the process. Refer the section "via the LiveCD terminal" on the page.



                      Fixing the grub should fix any malformed file that you might have in grub configuration.






                      share|improve this answer













                      Fix your grub via booting through a live-cd/live-usb. Refer this page for details of the process. Refer the section "via the LiveCD terminal" on the page.



                      Fixing the grub should fix any malformed file that you might have in grub configuration.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Apr 27 '13 at 0:27









                      Bhavin DoshiBhavin Doshi

                      1,8181733




                      1,8181733













                      • Thanks for the tip. I tried all that you suggested but to no avail. I did just get it figured out though. It's pretty crazy...

                        – Freedom_Ben
                        Apr 27 '13 at 4:04



















                      • Thanks for the tip. I tried all that you suggested but to no avail. I did just get it figured out though. It's pretty crazy...

                        – Freedom_Ben
                        Apr 27 '13 at 4:04

















                      Thanks for the tip. I tried all that you suggested but to no avail. I did just get it figured out though. It's pretty crazy...

                      – Freedom_Ben
                      Apr 27 '13 at 4:04





                      Thanks for the tip. I tried all that you suggested but to no avail. I did just get it figured out though. It's pretty crazy...

                      – Freedom_Ben
                      Apr 27 '13 at 4:04











                      0














                      Check if you have cryptsetup installed on your system, it might have been removed by running apt-get autoremove. More info.






                      share|improve this answer




























                        0














                        Check if you have cryptsetup installed on your system, it might have been removed by running apt-get autoremove. More info.






                        share|improve this answer


























                          0












                          0








                          0







                          Check if you have cryptsetup installed on your system, it might have been removed by running apt-get autoremove. More info.






                          share|improve this answer













                          Check if you have cryptsetup installed on your system, it might have been removed by running apt-get autoremove. More info.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Jan 22 at 12:21









                          ArsenyArseny

                          1033




                          1033






























                              draft saved

                              draft discarded




















































                              Thanks for contributing an answer to Ask Ubuntu!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f286284%2fsystem-no-longer-boots-gave-up-waiting-for-root-device-initramfs-dev-mappe%23new-answer', 'question_page');
                              }
                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

                              Mangá

                               ⁒  ․,‪⁊‑⁙ ⁖, ⁇‒※‌, †,⁖‗‌⁝    ‾‸⁘,‖⁔⁣,⁂‾
”‑,‥–,‬ ,⁀‹⁋‴⁑ ‒ ,‴⁋”‼ ⁨,‷⁔„ ‰′,‐‚ ‥‡‎“‷⁃⁨⁅⁣,⁔
⁇‘⁔⁡⁏⁌⁡‿‶‏⁨ ⁣⁕⁖⁨⁩⁥‽⁀  ‴‬⁜‟ ⁃‣‧⁕‮ …‍⁨‴ ⁩,⁚⁖‫ ,‵ ⁀,‮⁝‣‣ ⁑  ⁂– ․, ‾‽ ‏⁁“⁗‸ ‾… ‹‡⁌⁎‸‘ ‡⁏⁌‪ ‵⁛ ‎⁨ ―⁦⁤⁄⁕