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?

8
  • 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, 2014 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, 2014 at 13:12
  • 1
    I have this after run boot-repair Boot-repair log
    – Marcin
    Aug 26, 2014 at 13:42
  • and then still I cant log in to ubuntu...
    – Marcin
    Aug 26, 2014 at 13:50
  • 3
    @MarcinGorski please add your solution as an answer and mark it accepted instead of editing the question.
    – muru
    Aug 26, 2014 at 22:20

2 Answers 2

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.

4
  • 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. Apr 29, 2015 at 4:41
  • I tried this on Ubuntu MATE 17.04 (New Install), and it didn't help unfortunately... Apr 16, 2017 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 3, 2017 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 2, 2017 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.

2
  • Thanks for your help @MGodby but I already find solution.
    – Marcin
    Aug 26, 2014 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. Aug 27, 2014 at 0:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .