Boot in emergency mode, incomplete /etc/fstab












0















I am trying to set up a multi-boot on my machine with Ubuntu (my original OS, on /dev/sda2), Kali Linux and Debian. However, I got stuck halfway through my installation of Debian, and since Ubuntu took a lot of time to boot, I followed the steps of this post to make the boot process faster. But when I rebooted my machine, Ubuntu would only boot in emergency mode... The only thing I was able to notice was that in my /etc/fstab the line associated with my Ubuntu partition was gone.



I would gladly post the contents of my fstab here but I don't know how to copy it from the emergency mode to here (I am using my Kali Linux on /dev/sda5 to write this post). Maybe there is a way to restore my fstab, to begin with?



Edit 1



Here is the content of my /etc/fstab:



# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# /boot/efi was on /dev/sda1 during installation
UUID=95B2-5AED /boot/efi vfat umask=0077 0 1
# /home was on /dev/sda3 during installation
UUID=69d6623e-0bcc-4cef-8b25-e46c98210d44 /home ext4 defaults 0 2
# swap was on /dev/sda4 during installation
UUID=a8ee0943-0cd9-4dba-b018-ca00fc450e5d none swap sw 0 0


And here is thd result of blkid | grep UUID:



/dev/sda1: UUID="95B2-5AED" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="f3ead83c-a7ca-453b-8317-a854080d37fc"
/dev/sda2: UUID="7d4d2f18-146c-4d56-b5f3-0dc605eeb9e0" TYPE="ext4" PARTLABEL="Ubuntu" PARTUUID="94d6c9bd-30da-4abf-a784-41e20992fdd4"
/dev/sda3: UUID="69d6623e-0bcc-4cef-8b25-e46c98210d44" TYPE="ext4" PARTLABEL="Home" PARTUUID="dd1299b6-adb1-45c0-99a6-94e922f4964b"
/dev/sda4: UUID="a8ee0943-0cd9-4dba-b018-ca00fc450e5d" TYPE="swap" PARTUUID="228fa2d0-8b0c-4562-bb5a-ebb73bb00f04"
/dev/sda5: UUID="489b70a2-db82-4b0c-bebd-cf19a403ade1" TYPE="ext4" PARTUUID="48ba997c-e595-45c1-93c0-b97e4f7ffbf5"
/dev/sda6: UUID="9068da24-6073-45dc-a18e-29634daa3910" TYPE="ext4" PARTUUID="9033f352-349f-4cee-94bf-c686f462adea"


Edit 2



I ran the e2fsck command on my Ubuntu, home and Debian partitions, and now instead of booting into emergency mode, Ubuntu starts to launch normally, but freezes after some time loading.










share|improve this question





























    0















    I am trying to set up a multi-boot on my machine with Ubuntu (my original OS, on /dev/sda2), Kali Linux and Debian. However, I got stuck halfway through my installation of Debian, and since Ubuntu took a lot of time to boot, I followed the steps of this post to make the boot process faster. But when I rebooted my machine, Ubuntu would only boot in emergency mode... The only thing I was able to notice was that in my /etc/fstab the line associated with my Ubuntu partition was gone.



    I would gladly post the contents of my fstab here but I don't know how to copy it from the emergency mode to here (I am using my Kali Linux on /dev/sda5 to write this post). Maybe there is a way to restore my fstab, to begin with?



    Edit 1



    Here is the content of my /etc/fstab:



    # /etc/fstab: static file system information.
    #
    # Use 'blkid' to print the universally unique identifier for a
    # device; this may be used with UUID= as a more robust way to name devices
    # that works even if disks are added and removed. See fstab(5).
    #
    # <file system> <mount point> <type> <options> <dump> <pass>
    # /boot/efi was on /dev/sda1 during installation
    UUID=95B2-5AED /boot/efi vfat umask=0077 0 1
    # /home was on /dev/sda3 during installation
    UUID=69d6623e-0bcc-4cef-8b25-e46c98210d44 /home ext4 defaults 0 2
    # swap was on /dev/sda4 during installation
    UUID=a8ee0943-0cd9-4dba-b018-ca00fc450e5d none swap sw 0 0


    And here is thd result of blkid | grep UUID:



    /dev/sda1: UUID="95B2-5AED" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="f3ead83c-a7ca-453b-8317-a854080d37fc"
    /dev/sda2: UUID="7d4d2f18-146c-4d56-b5f3-0dc605eeb9e0" TYPE="ext4" PARTLABEL="Ubuntu" PARTUUID="94d6c9bd-30da-4abf-a784-41e20992fdd4"
    /dev/sda3: UUID="69d6623e-0bcc-4cef-8b25-e46c98210d44" TYPE="ext4" PARTLABEL="Home" PARTUUID="dd1299b6-adb1-45c0-99a6-94e922f4964b"
    /dev/sda4: UUID="a8ee0943-0cd9-4dba-b018-ca00fc450e5d" TYPE="swap" PARTUUID="228fa2d0-8b0c-4562-bb5a-ebb73bb00f04"
    /dev/sda5: UUID="489b70a2-db82-4b0c-bebd-cf19a403ade1" TYPE="ext4" PARTUUID="48ba997c-e595-45c1-93c0-b97e4f7ffbf5"
    /dev/sda6: UUID="9068da24-6073-45dc-a18e-29634daa3910" TYPE="ext4" PARTUUID="9033f352-349f-4cee-94bf-c686f462adea"


    Edit 2



    I ran the e2fsck command on my Ubuntu, home and Debian partitions, and now instead of booting into emergency mode, Ubuntu starts to launch normally, but freezes after some time loading.










    share|improve this question



























      0












      0








      0








      I am trying to set up a multi-boot on my machine with Ubuntu (my original OS, on /dev/sda2), Kali Linux and Debian. However, I got stuck halfway through my installation of Debian, and since Ubuntu took a lot of time to boot, I followed the steps of this post to make the boot process faster. But when I rebooted my machine, Ubuntu would only boot in emergency mode... The only thing I was able to notice was that in my /etc/fstab the line associated with my Ubuntu partition was gone.



      I would gladly post the contents of my fstab here but I don't know how to copy it from the emergency mode to here (I am using my Kali Linux on /dev/sda5 to write this post). Maybe there is a way to restore my fstab, to begin with?



      Edit 1



      Here is the content of my /etc/fstab:



      # /etc/fstab: static file system information.
      #
      # Use 'blkid' to print the universally unique identifier for a
      # device; this may be used with UUID= as a more robust way to name devices
      # that works even if disks are added and removed. See fstab(5).
      #
      # <file system> <mount point> <type> <options> <dump> <pass>
      # /boot/efi was on /dev/sda1 during installation
      UUID=95B2-5AED /boot/efi vfat umask=0077 0 1
      # /home was on /dev/sda3 during installation
      UUID=69d6623e-0bcc-4cef-8b25-e46c98210d44 /home ext4 defaults 0 2
      # swap was on /dev/sda4 during installation
      UUID=a8ee0943-0cd9-4dba-b018-ca00fc450e5d none swap sw 0 0


      And here is thd result of blkid | grep UUID:



      /dev/sda1: UUID="95B2-5AED" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="f3ead83c-a7ca-453b-8317-a854080d37fc"
      /dev/sda2: UUID="7d4d2f18-146c-4d56-b5f3-0dc605eeb9e0" TYPE="ext4" PARTLABEL="Ubuntu" PARTUUID="94d6c9bd-30da-4abf-a784-41e20992fdd4"
      /dev/sda3: UUID="69d6623e-0bcc-4cef-8b25-e46c98210d44" TYPE="ext4" PARTLABEL="Home" PARTUUID="dd1299b6-adb1-45c0-99a6-94e922f4964b"
      /dev/sda4: UUID="a8ee0943-0cd9-4dba-b018-ca00fc450e5d" TYPE="swap" PARTUUID="228fa2d0-8b0c-4562-bb5a-ebb73bb00f04"
      /dev/sda5: UUID="489b70a2-db82-4b0c-bebd-cf19a403ade1" TYPE="ext4" PARTUUID="48ba997c-e595-45c1-93c0-b97e4f7ffbf5"
      /dev/sda6: UUID="9068da24-6073-45dc-a18e-29634daa3910" TYPE="ext4" PARTUUID="9033f352-349f-4cee-94bf-c686f462adea"


      Edit 2



      I ran the e2fsck command on my Ubuntu, home and Debian partitions, and now instead of booting into emergency mode, Ubuntu starts to launch normally, but freezes after some time loading.










      share|improve this question
















      I am trying to set up a multi-boot on my machine with Ubuntu (my original OS, on /dev/sda2), Kali Linux and Debian. However, I got stuck halfway through my installation of Debian, and since Ubuntu took a lot of time to boot, I followed the steps of this post to make the boot process faster. But when I rebooted my machine, Ubuntu would only boot in emergency mode... The only thing I was able to notice was that in my /etc/fstab the line associated with my Ubuntu partition was gone.



      I would gladly post the contents of my fstab here but I don't know how to copy it from the emergency mode to here (I am using my Kali Linux on /dev/sda5 to write this post). Maybe there is a way to restore my fstab, to begin with?



      Edit 1



      Here is the content of my /etc/fstab:



      # /etc/fstab: static file system information.
      #
      # Use 'blkid' to print the universally unique identifier for a
      # device; this may be used with UUID= as a more robust way to name devices
      # that works even if disks are added and removed. See fstab(5).
      #
      # <file system> <mount point> <type> <options> <dump> <pass>
      # /boot/efi was on /dev/sda1 during installation
      UUID=95B2-5AED /boot/efi vfat umask=0077 0 1
      # /home was on /dev/sda3 during installation
      UUID=69d6623e-0bcc-4cef-8b25-e46c98210d44 /home ext4 defaults 0 2
      # swap was on /dev/sda4 during installation
      UUID=a8ee0943-0cd9-4dba-b018-ca00fc450e5d none swap sw 0 0


      And here is thd result of blkid | grep UUID:



      /dev/sda1: UUID="95B2-5AED" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="f3ead83c-a7ca-453b-8317-a854080d37fc"
      /dev/sda2: UUID="7d4d2f18-146c-4d56-b5f3-0dc605eeb9e0" TYPE="ext4" PARTLABEL="Ubuntu" PARTUUID="94d6c9bd-30da-4abf-a784-41e20992fdd4"
      /dev/sda3: UUID="69d6623e-0bcc-4cef-8b25-e46c98210d44" TYPE="ext4" PARTLABEL="Home" PARTUUID="dd1299b6-adb1-45c0-99a6-94e922f4964b"
      /dev/sda4: UUID="a8ee0943-0cd9-4dba-b018-ca00fc450e5d" TYPE="swap" PARTUUID="228fa2d0-8b0c-4562-bb5a-ebb73bb00f04"
      /dev/sda5: UUID="489b70a2-db82-4b0c-bebd-cf19a403ade1" TYPE="ext4" PARTUUID="48ba997c-e595-45c1-93c0-b97e4f7ffbf5"
      /dev/sda6: UUID="9068da24-6073-45dc-a18e-29634daa3910" TYPE="ext4" PARTUUID="9033f352-349f-4cee-94bf-c686f462adea"


      Edit 2



      I ran the e2fsck command on my Ubuntu, home and Debian partitions, and now instead of booting into emergency mode, Ubuntu starts to launch normally, but freezes after some time loading.







      boot fstab






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 30 at 10:27







      Ul Tome

















      asked Jan 29 at 11:15









      Ul TomeUl Tome

      305




      305






















          1 Answer
          1






          active

          oldest

          votes


















          4














          Since your Kali installation is working, you can use it to access your Ubuntu installation in a chroot. To do this, run the following commands as root:



          mkdir /ubunturoot
          mount /dev/sda2 /ubunturoot
          mount -o bind /dev /ubunturoot/dev
          mount -o bind /dev/pts /ubunturoot/dev/pts
          mount -o bind /proc /ubunturoot/proc
          mount -o bind /sys /ubunturoot/sys
          chroot /ubunturoot


          Now your command prompt window (note: this particular shell only!) should be accessing your Ubuntu root filesystem just as if you had logged onto Ubuntu and become root in Ubuntu. Take a look and ensure everything is as it should be.



          If your Ubuntu /etc/fstab is in error, now you can edit it.



          Once that is fixed, first make sure the /boot/efi filesystem is mounted in your Ubuntu chroot:



          mount /boot/efi


          Then run ls /lib/modules to see one or more directories named with kernel version numbers. Use update-initramfs -u -k <kernel version number> to update the initramfs file of the respective Ubuntu kernel. (Since you are now really running Kali's kernel, you must explicitly specify the version number of Ubuntu's kernel: trying to update the default kernel would result in an error message since Ubuntu's and Kali's kernel versions are unlikely to match.)



          Then check /etc/default/grub for boot options mentioning filesystem UUIDs or other things that may have changed on your OS installations. Fix as necessary, then run update-grub to update the configuration file of Ubuntu's GRUB bootloader.



          Once you've fixed all the problems you've found, undo the temporary chroot environment manually:



          umount /boot/efi
          exit # out of the chroot environment, back to Kali native view of the filesystem
          umount /ubunturoot/sys
          umount /ubunturoot/proc
          umount /ubunturoot/dev/pts
          umount /ubunturoot/dev
          umount /ubunturoot
          rmdir /ubunturoot





          share|improve this answer
























          • Thanks, but: 1) I don't know how to fix my fstab, that's what I'm asking; 2) ls /lib/modules shows two kernel numbers, how do I know which one is Ubuntu's? 3) There is no UUID mentioned in /etc/default/grub...

            – Ul Tome
            Jan 29 at 18:59











          • 1) now you should be able to at least show us your current Ubuntu fstab, which would make it a lot easier for us to help you, 2) if you followed the chroot instructions, they are both Ubuntu's: the latest kernel update and the previous one for backup, 3) good, that's one potential source of problems eliminated then.

            – telcoM
            Jan 29 at 19:55











          • Ok, thanks a lot; I have been able to fix my fstab now thanks to this post, and now I can boot on Ubuntu. The only problem left is that my machine seems to be trying to load something (a partition?) at boot and takes a lot of time before starting to launch Ubuntu...

            – Ul Tome
            Jan 30 at 18:29











          • Your /etc/fstab now seems to have all the correct UUIDs. Note that Ubuntu's boot splash screen allows you to press Esc to see what is going on during the boot process. But you said "takes a lot of time before starting to launch Ubuntu": is it before or after the first display of GRUB appears? If it's before, run efibootmgr -v and add the output to your question, please: you might have a stale UEFI boot entry or two in there. They should be easy to remove using the efibootmgr command with the appropriate options, but I'd like to take a look first, to perhaps give you the exact commands.

            – telcoM
            Jan 31 at 11:30











          • And if the slowdown/hang happens after GRUB, you can press Esc in the Ubuntu boot splash screen to see a diagnostic display. That might help in getting more information about what exactly is causing the start-up hang/slowdown.

            – telcoM
            Jan 31 at 17:33











          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',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          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%2funix.stackexchange.com%2fquestions%2f497426%2fboot-in-emergency-mode-incomplete-etc-fstab%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          4














          Since your Kali installation is working, you can use it to access your Ubuntu installation in a chroot. To do this, run the following commands as root:



          mkdir /ubunturoot
          mount /dev/sda2 /ubunturoot
          mount -o bind /dev /ubunturoot/dev
          mount -o bind /dev/pts /ubunturoot/dev/pts
          mount -o bind /proc /ubunturoot/proc
          mount -o bind /sys /ubunturoot/sys
          chroot /ubunturoot


          Now your command prompt window (note: this particular shell only!) should be accessing your Ubuntu root filesystem just as if you had logged onto Ubuntu and become root in Ubuntu. Take a look and ensure everything is as it should be.



          If your Ubuntu /etc/fstab is in error, now you can edit it.



          Once that is fixed, first make sure the /boot/efi filesystem is mounted in your Ubuntu chroot:



          mount /boot/efi


          Then run ls /lib/modules to see one or more directories named with kernel version numbers. Use update-initramfs -u -k <kernel version number> to update the initramfs file of the respective Ubuntu kernel. (Since you are now really running Kali's kernel, you must explicitly specify the version number of Ubuntu's kernel: trying to update the default kernel would result in an error message since Ubuntu's and Kali's kernel versions are unlikely to match.)



          Then check /etc/default/grub for boot options mentioning filesystem UUIDs or other things that may have changed on your OS installations. Fix as necessary, then run update-grub to update the configuration file of Ubuntu's GRUB bootloader.



          Once you've fixed all the problems you've found, undo the temporary chroot environment manually:



          umount /boot/efi
          exit # out of the chroot environment, back to Kali native view of the filesystem
          umount /ubunturoot/sys
          umount /ubunturoot/proc
          umount /ubunturoot/dev/pts
          umount /ubunturoot/dev
          umount /ubunturoot
          rmdir /ubunturoot





          share|improve this answer
























          • Thanks, but: 1) I don't know how to fix my fstab, that's what I'm asking; 2) ls /lib/modules shows two kernel numbers, how do I know which one is Ubuntu's? 3) There is no UUID mentioned in /etc/default/grub...

            – Ul Tome
            Jan 29 at 18:59











          • 1) now you should be able to at least show us your current Ubuntu fstab, which would make it a lot easier for us to help you, 2) if you followed the chroot instructions, they are both Ubuntu's: the latest kernel update and the previous one for backup, 3) good, that's one potential source of problems eliminated then.

            – telcoM
            Jan 29 at 19:55











          • Ok, thanks a lot; I have been able to fix my fstab now thanks to this post, and now I can boot on Ubuntu. The only problem left is that my machine seems to be trying to load something (a partition?) at boot and takes a lot of time before starting to launch Ubuntu...

            – Ul Tome
            Jan 30 at 18:29











          • Your /etc/fstab now seems to have all the correct UUIDs. Note that Ubuntu's boot splash screen allows you to press Esc to see what is going on during the boot process. But you said "takes a lot of time before starting to launch Ubuntu": is it before or after the first display of GRUB appears? If it's before, run efibootmgr -v and add the output to your question, please: you might have a stale UEFI boot entry or two in there. They should be easy to remove using the efibootmgr command with the appropriate options, but I'd like to take a look first, to perhaps give you the exact commands.

            – telcoM
            Jan 31 at 11:30











          • And if the slowdown/hang happens after GRUB, you can press Esc in the Ubuntu boot splash screen to see a diagnostic display. That might help in getting more information about what exactly is causing the start-up hang/slowdown.

            – telcoM
            Jan 31 at 17:33
















          4














          Since your Kali installation is working, you can use it to access your Ubuntu installation in a chroot. To do this, run the following commands as root:



          mkdir /ubunturoot
          mount /dev/sda2 /ubunturoot
          mount -o bind /dev /ubunturoot/dev
          mount -o bind /dev/pts /ubunturoot/dev/pts
          mount -o bind /proc /ubunturoot/proc
          mount -o bind /sys /ubunturoot/sys
          chroot /ubunturoot


          Now your command prompt window (note: this particular shell only!) should be accessing your Ubuntu root filesystem just as if you had logged onto Ubuntu and become root in Ubuntu. Take a look and ensure everything is as it should be.



          If your Ubuntu /etc/fstab is in error, now you can edit it.



          Once that is fixed, first make sure the /boot/efi filesystem is mounted in your Ubuntu chroot:



          mount /boot/efi


          Then run ls /lib/modules to see one or more directories named with kernel version numbers. Use update-initramfs -u -k <kernel version number> to update the initramfs file of the respective Ubuntu kernel. (Since you are now really running Kali's kernel, you must explicitly specify the version number of Ubuntu's kernel: trying to update the default kernel would result in an error message since Ubuntu's and Kali's kernel versions are unlikely to match.)



          Then check /etc/default/grub for boot options mentioning filesystem UUIDs or other things that may have changed on your OS installations. Fix as necessary, then run update-grub to update the configuration file of Ubuntu's GRUB bootloader.



          Once you've fixed all the problems you've found, undo the temporary chroot environment manually:



          umount /boot/efi
          exit # out of the chroot environment, back to Kali native view of the filesystem
          umount /ubunturoot/sys
          umount /ubunturoot/proc
          umount /ubunturoot/dev/pts
          umount /ubunturoot/dev
          umount /ubunturoot
          rmdir /ubunturoot





          share|improve this answer
























          • Thanks, but: 1) I don't know how to fix my fstab, that's what I'm asking; 2) ls /lib/modules shows two kernel numbers, how do I know which one is Ubuntu's? 3) There is no UUID mentioned in /etc/default/grub...

            – Ul Tome
            Jan 29 at 18:59











          • 1) now you should be able to at least show us your current Ubuntu fstab, which would make it a lot easier for us to help you, 2) if you followed the chroot instructions, they are both Ubuntu's: the latest kernel update and the previous one for backup, 3) good, that's one potential source of problems eliminated then.

            – telcoM
            Jan 29 at 19:55











          • Ok, thanks a lot; I have been able to fix my fstab now thanks to this post, and now I can boot on Ubuntu. The only problem left is that my machine seems to be trying to load something (a partition?) at boot and takes a lot of time before starting to launch Ubuntu...

            – Ul Tome
            Jan 30 at 18:29











          • Your /etc/fstab now seems to have all the correct UUIDs. Note that Ubuntu's boot splash screen allows you to press Esc to see what is going on during the boot process. But you said "takes a lot of time before starting to launch Ubuntu": is it before or after the first display of GRUB appears? If it's before, run efibootmgr -v and add the output to your question, please: you might have a stale UEFI boot entry or two in there. They should be easy to remove using the efibootmgr command with the appropriate options, but I'd like to take a look first, to perhaps give you the exact commands.

            – telcoM
            Jan 31 at 11:30











          • And if the slowdown/hang happens after GRUB, you can press Esc in the Ubuntu boot splash screen to see a diagnostic display. That might help in getting more information about what exactly is causing the start-up hang/slowdown.

            – telcoM
            Jan 31 at 17:33














          4












          4








          4







          Since your Kali installation is working, you can use it to access your Ubuntu installation in a chroot. To do this, run the following commands as root:



          mkdir /ubunturoot
          mount /dev/sda2 /ubunturoot
          mount -o bind /dev /ubunturoot/dev
          mount -o bind /dev/pts /ubunturoot/dev/pts
          mount -o bind /proc /ubunturoot/proc
          mount -o bind /sys /ubunturoot/sys
          chroot /ubunturoot


          Now your command prompt window (note: this particular shell only!) should be accessing your Ubuntu root filesystem just as if you had logged onto Ubuntu and become root in Ubuntu. Take a look and ensure everything is as it should be.



          If your Ubuntu /etc/fstab is in error, now you can edit it.



          Once that is fixed, first make sure the /boot/efi filesystem is mounted in your Ubuntu chroot:



          mount /boot/efi


          Then run ls /lib/modules to see one or more directories named with kernel version numbers. Use update-initramfs -u -k <kernel version number> to update the initramfs file of the respective Ubuntu kernel. (Since you are now really running Kali's kernel, you must explicitly specify the version number of Ubuntu's kernel: trying to update the default kernel would result in an error message since Ubuntu's and Kali's kernel versions are unlikely to match.)



          Then check /etc/default/grub for boot options mentioning filesystem UUIDs or other things that may have changed on your OS installations. Fix as necessary, then run update-grub to update the configuration file of Ubuntu's GRUB bootloader.



          Once you've fixed all the problems you've found, undo the temporary chroot environment manually:



          umount /boot/efi
          exit # out of the chroot environment, back to Kali native view of the filesystem
          umount /ubunturoot/sys
          umount /ubunturoot/proc
          umount /ubunturoot/dev/pts
          umount /ubunturoot/dev
          umount /ubunturoot
          rmdir /ubunturoot





          share|improve this answer













          Since your Kali installation is working, you can use it to access your Ubuntu installation in a chroot. To do this, run the following commands as root:



          mkdir /ubunturoot
          mount /dev/sda2 /ubunturoot
          mount -o bind /dev /ubunturoot/dev
          mount -o bind /dev/pts /ubunturoot/dev/pts
          mount -o bind /proc /ubunturoot/proc
          mount -o bind /sys /ubunturoot/sys
          chroot /ubunturoot


          Now your command prompt window (note: this particular shell only!) should be accessing your Ubuntu root filesystem just as if you had logged onto Ubuntu and become root in Ubuntu. Take a look and ensure everything is as it should be.



          If your Ubuntu /etc/fstab is in error, now you can edit it.



          Once that is fixed, first make sure the /boot/efi filesystem is mounted in your Ubuntu chroot:



          mount /boot/efi


          Then run ls /lib/modules to see one or more directories named with kernel version numbers. Use update-initramfs -u -k <kernel version number> to update the initramfs file of the respective Ubuntu kernel. (Since you are now really running Kali's kernel, you must explicitly specify the version number of Ubuntu's kernel: trying to update the default kernel would result in an error message since Ubuntu's and Kali's kernel versions are unlikely to match.)



          Then check /etc/default/grub for boot options mentioning filesystem UUIDs or other things that may have changed on your OS installations. Fix as necessary, then run update-grub to update the configuration file of Ubuntu's GRUB bootloader.



          Once you've fixed all the problems you've found, undo the temporary chroot environment manually:



          umount /boot/efi
          exit # out of the chroot environment, back to Kali native view of the filesystem
          umount /ubunturoot/sys
          umount /ubunturoot/proc
          umount /ubunturoot/dev/pts
          umount /ubunturoot/dev
          umount /ubunturoot
          rmdir /ubunturoot






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 29 at 12:12









          telcoMtelcoM

          17.2k12347




          17.2k12347













          • Thanks, but: 1) I don't know how to fix my fstab, that's what I'm asking; 2) ls /lib/modules shows two kernel numbers, how do I know which one is Ubuntu's? 3) There is no UUID mentioned in /etc/default/grub...

            – Ul Tome
            Jan 29 at 18:59











          • 1) now you should be able to at least show us your current Ubuntu fstab, which would make it a lot easier for us to help you, 2) if you followed the chroot instructions, they are both Ubuntu's: the latest kernel update and the previous one for backup, 3) good, that's one potential source of problems eliminated then.

            – telcoM
            Jan 29 at 19:55











          • Ok, thanks a lot; I have been able to fix my fstab now thanks to this post, and now I can boot on Ubuntu. The only problem left is that my machine seems to be trying to load something (a partition?) at boot and takes a lot of time before starting to launch Ubuntu...

            – Ul Tome
            Jan 30 at 18:29











          • Your /etc/fstab now seems to have all the correct UUIDs. Note that Ubuntu's boot splash screen allows you to press Esc to see what is going on during the boot process. But you said "takes a lot of time before starting to launch Ubuntu": is it before or after the first display of GRUB appears? If it's before, run efibootmgr -v and add the output to your question, please: you might have a stale UEFI boot entry or two in there. They should be easy to remove using the efibootmgr command with the appropriate options, but I'd like to take a look first, to perhaps give you the exact commands.

            – telcoM
            Jan 31 at 11:30











          • And if the slowdown/hang happens after GRUB, you can press Esc in the Ubuntu boot splash screen to see a diagnostic display. That might help in getting more information about what exactly is causing the start-up hang/slowdown.

            – telcoM
            Jan 31 at 17:33



















          • Thanks, but: 1) I don't know how to fix my fstab, that's what I'm asking; 2) ls /lib/modules shows two kernel numbers, how do I know which one is Ubuntu's? 3) There is no UUID mentioned in /etc/default/grub...

            – Ul Tome
            Jan 29 at 18:59











          • 1) now you should be able to at least show us your current Ubuntu fstab, which would make it a lot easier for us to help you, 2) if you followed the chroot instructions, they are both Ubuntu's: the latest kernel update and the previous one for backup, 3) good, that's one potential source of problems eliminated then.

            – telcoM
            Jan 29 at 19:55











          • Ok, thanks a lot; I have been able to fix my fstab now thanks to this post, and now I can boot on Ubuntu. The only problem left is that my machine seems to be trying to load something (a partition?) at boot and takes a lot of time before starting to launch Ubuntu...

            – Ul Tome
            Jan 30 at 18:29











          • Your /etc/fstab now seems to have all the correct UUIDs. Note that Ubuntu's boot splash screen allows you to press Esc to see what is going on during the boot process. But you said "takes a lot of time before starting to launch Ubuntu": is it before or after the first display of GRUB appears? If it's before, run efibootmgr -v and add the output to your question, please: you might have a stale UEFI boot entry or two in there. They should be easy to remove using the efibootmgr command with the appropriate options, but I'd like to take a look first, to perhaps give you the exact commands.

            – telcoM
            Jan 31 at 11:30











          • And if the slowdown/hang happens after GRUB, you can press Esc in the Ubuntu boot splash screen to see a diagnostic display. That might help in getting more information about what exactly is causing the start-up hang/slowdown.

            – telcoM
            Jan 31 at 17:33

















          Thanks, but: 1) I don't know how to fix my fstab, that's what I'm asking; 2) ls /lib/modules shows two kernel numbers, how do I know which one is Ubuntu's? 3) There is no UUID mentioned in /etc/default/grub...

          – Ul Tome
          Jan 29 at 18:59





          Thanks, but: 1) I don't know how to fix my fstab, that's what I'm asking; 2) ls /lib/modules shows two kernel numbers, how do I know which one is Ubuntu's? 3) There is no UUID mentioned in /etc/default/grub...

          – Ul Tome
          Jan 29 at 18:59













          1) now you should be able to at least show us your current Ubuntu fstab, which would make it a lot easier for us to help you, 2) if you followed the chroot instructions, they are both Ubuntu's: the latest kernel update and the previous one for backup, 3) good, that's one potential source of problems eliminated then.

          – telcoM
          Jan 29 at 19:55





          1) now you should be able to at least show us your current Ubuntu fstab, which would make it a lot easier for us to help you, 2) if you followed the chroot instructions, they are both Ubuntu's: the latest kernel update and the previous one for backup, 3) good, that's one potential source of problems eliminated then.

          – telcoM
          Jan 29 at 19:55













          Ok, thanks a lot; I have been able to fix my fstab now thanks to this post, and now I can boot on Ubuntu. The only problem left is that my machine seems to be trying to load something (a partition?) at boot and takes a lot of time before starting to launch Ubuntu...

          – Ul Tome
          Jan 30 at 18:29





          Ok, thanks a lot; I have been able to fix my fstab now thanks to this post, and now I can boot on Ubuntu. The only problem left is that my machine seems to be trying to load something (a partition?) at boot and takes a lot of time before starting to launch Ubuntu...

          – Ul Tome
          Jan 30 at 18:29













          Your /etc/fstab now seems to have all the correct UUIDs. Note that Ubuntu's boot splash screen allows you to press Esc to see what is going on during the boot process. But you said "takes a lot of time before starting to launch Ubuntu": is it before or after the first display of GRUB appears? If it's before, run efibootmgr -v and add the output to your question, please: you might have a stale UEFI boot entry or two in there. They should be easy to remove using the efibootmgr command with the appropriate options, but I'd like to take a look first, to perhaps give you the exact commands.

          – telcoM
          Jan 31 at 11:30





          Your /etc/fstab now seems to have all the correct UUIDs. Note that Ubuntu's boot splash screen allows you to press Esc to see what is going on during the boot process. But you said "takes a lot of time before starting to launch Ubuntu": is it before or after the first display of GRUB appears? If it's before, run efibootmgr -v and add the output to your question, please: you might have a stale UEFI boot entry or two in there. They should be easy to remove using the efibootmgr command with the appropriate options, but I'd like to take a look first, to perhaps give you the exact commands.

          – telcoM
          Jan 31 at 11:30













          And if the slowdown/hang happens after GRUB, you can press Esc in the Ubuntu boot splash screen to see a diagnostic display. That might help in getting more information about what exactly is causing the start-up hang/slowdown.

          – telcoM
          Jan 31 at 17:33





          And if the slowdown/hang happens after GRUB, you can press Esc in the Ubuntu boot splash screen to see a diagnostic display. That might help in getting more information about what exactly is causing the start-up hang/slowdown.

          – telcoM
          Jan 31 at 17:33


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • 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%2funix.stackexchange.com%2fquestions%2f497426%2fboot-in-emergency-mode-incomplete-etc-fstab%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

          How to reconfigure Docker Trusted Registry 2.x.x to use CEPH FS mount instead of NFS and other traditional...

          is 'sed' thread safe

          How to make a Squid Proxy server?