30

I am using Ubuntu 14.04.

I ran in terminal sudo apt-get update. Then I rebooted the system. And now I see: 

ALERT! /dev/disk/by-uuid/xxxxxxxxx does not exist. Dropping to a shell
initramfs:_

I can't boot up LIVE Ubuntu from USB flash drive. Yes, I double checked BIOS setup and the USB flash drive is OK and runs on another machine. Right now I am going to buy a DVD and burn a Live DVD from another laptop.

sudo blkid gives me: 

/dev/loop0: TYPE="squashfs"  
/dev/sda1: UUID="xxxx" TYPE="ext4"   
/dev/sr0: LABEL="Ubuntu 14.04.1 LTS i386" TYPE="iso960"

/etc/fstab has the same UUID="xxxx" and there is a line with: 

errors=remount-ro 0

I tried using boot-repair but I still can't log in to Ubuntu.

I don't want to reinstall Ubuntu, because I have a lot of data there.

Do you have any advice how this can be solved?

Anwar
  • 76,649
Marcin
  • 725
  • 1
  • 7
  • 13
  • 1
    Run sudo blkid from the terminal (from a live DVD if needed) and check the UUID's against what /etc/fstab has. Or post both results into your question please. How to run sudo blkid from a live DVD: Boot from Ubuntu live disk, click on Try Ubuntu option on startup. Open the terminal (Ctrl+Alt+T) and then run sudo blkid command in it. Finally, post its output in your question. – karel Aug 26 '14 at 11:06
  • 1
    ok @karel sudo blkid gives me

    `/dev/loop0: TYPE="squashfs"

    /dev/sda1: UUID="xxxx" TYPE="ext4"

    dev/sr0: LABEL="Ubuntu 14.04.1 LTS i386" TYPE="iso960"`

    /etc/fstab have the same UUID="xxxx"

    and there is line where is written errors=remount-ro 0 –

     – Marcin Aug 26 '14 at 13:12
  • 1
    I have this after run boot-repair Boot-repair log – Marcin Aug 26 '14 at 13:42
  • and then still I cant log in to ubuntu... – Marcin Aug 26 '14 at 13:50
  • sudo fsck /dev/sda1 fsck from util-linux 2.020.1 e2fsck 1.42.9 (4-Feb-2014) /dev/sda1:clean, 491701/19054592 files, 27163705/76189184 blocks – Marcin Aug 26 '14 at 15:11
  • I dont know how to write is these askubuntu add comment window, even when read lear more .... – Marcin Aug 26 '14 at 15:12
  • 3
    @MarcinGorski please add your solution as an answer and mark it accepted instead of editing the question. – muru Aug 26 '14 at 22:20
  • See https://www.youtube.com/watch?v=kilXfY-k_9A It solved me the problem – Gábor Lipták May 25 '18 at 21:19

2 Answers2

30

Solution was to perform these commands from liveDVD, it allows me to do things on my sda1 from that liveDVD(as far I understand)

sudo mount /dev/sda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt
update-initramfs -u
update-grub
reboot

A friend of mine from ubuntu pl forum helped me solve this problem.

He found out that there might be error in initramfs, which should be updated as part of the kernel update. If anything goes wrong during that update problems like mine could happen.

Henk Langeveld
  • 113
Marcin
  • 725
  • 1
  • 7
  • 13
  • 8
    Good post. I would like to add that Ubuntu isn't necessarily installed on sda1. To help determine where it is installed run sudo fdisk -l. Assuming you know what hard drive you installed Ubuntu to then that command should help you determine which sd* maps to that drive. – ubiquibacon Apr 29 '15 at 04:41
  • I tried this on Ubuntu MATE 17.04 (New Install), and it didn't help unfortunately... – Dominic Hayes Apr 16 '17 at 11:31
  • 3
    I was getting WARNING: missing /lib/modules/4.2.0-16-generic because LiveCD had different kernel version. So I've mounted tmp, lib and lib64 and then everything worked. – Max Malysh May 03 '17 at 22:57
  • 1
    I had to specify the filesystem to mount for an ext4 partition (mount -t ext4 /dev/sda1 /mnt), otherwise this worked great. – Shane Nov 02 '17 at 19:52
-1

People may frown on this if they want, but I have found that using "/dev/sdX" works more reliably for me than UUID for my personal systems. In an enterprise environment, I would put more effort into making it work with the UUID instead of the "/dev/" address, but you should be safe using /dev/sdaX in /etc/fstab instead of UUID reference, at least to be able to boot your system while you continue to search for the answer to why exactly the boot is failing in spite of having the correct UUID in /etc/fstab.

If you wish to go this route, use the following procedure:

  1. Boot into recovery shell or boot into a live USB drive or CD

  2. Mount your system partition that is failing to boot

  3. Edit the /etc/fstab file in the system partition mentioned in Step 2 as root and replace UUID=XXXXX with the corresponding /dev/sdX label in all of the relevant /etc/fstab entries.

Note: This procedure is known to me to be reliable for Ubuntu and Ubuntu-derived distributions (as of the writing of this article; this could easily change with any upcoming release). I know for a fact that it won't work reliably for some other distributions such as knoppix or Arch Linux (this is due to differences in the way that UDEV scans in devices and gives them names in the /dev filesystem). If you are using a non-Ubuntu-derived distribution, please do not use this method or else use it at your own risk.

Anwar
  • 76,649
MGodby
  • 1,162
  • Thanks for your help @MGodby but I already find solution. – Marcin Aug 26 '14 at 22:14
  • 6
    Your method is the old method, which was replaced for fairly good reasons, mainly that the drive numbering is not constant, and it's possible to boot from an unexpected drive. This is not possible with UUID. But I often use the "LABEL=___" format, just because it's clearer to see right away what's what. Example: LABEL=data_partition. – Marty Fried Aug 27 '14 at 00:42