4

I have a server running Ubuntu 14.04, with one hard disk partitioned like:

sda
 sda1 -> /
 sda2 -> /var
 sda3 -> (swap)
 sda4 -> /home

Whenever I boot, I get the message The disk drive for /var is not ready yet or not present. Press S to skip, Continue to wait or M to fix manually. I get this message thrice for the mountpoints /tmp and /home as well. The big problem is that, I actually can't even press a key when it asks me to enter a key. It just goes ahead with the boot process anyways and then gets stuck at the following step:

Starting system logging daemon

Which I am assuming is because I am guessing the system logging daemon is trying to get a lock on /var/log/messages, but can't because /var isn't mounted. The problem is I can't check anything because I don't have any access to so much as a command line. I however, can get into a root prompt from the recovery mode. Which logs should I be checking for for further information and how should I basically go ahead with this?

Andrew Schulman
  • 8,811
  • 21
  • 32
  • 47
Rohan Prabhu
  • 143
  • 1
  • 6
  • The `not ready yet` message doesn't necessarily indicate a problem. And that `Starting system logging daemon` is the last message you see doesn't necessarily mean there is a problem with the logging daemon. It might be the next thing it is doing after that, which fails. Can you mount all the file systems from recovery mode? For example try `mount -a` in the root shell. If that succeeds type `ls -lart /var/log` next. – kasperd Sep 13 '14 at 14:57

2 Answers2

5

I had the same exact problem and thanks to your comment about it only happening after enabling LDAP, I was able to find out why it was happening for me. In the /etc/nsswitch.conf file, I had the following:

passwd:         ldap compat
group:          ldap compat
shadow:         ldap compat

I changed it to this and it fixed the problem: 

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap

I hope this solves the issue for you as well.

Renan
  • 356
  • 1
  • 9
  • In our case this fix allowed us to boot far enough to find that networking config was broken. This was due to having swapped the motherboard. A quick `rm /etc/udev/rules.d/70-persistent-net.rules` and a reboot got us back online. In our case we were already `files ldap` but we were stuck until removing files entirely. 14.04 – dannyman Nov 22 '16 at 19:58
3

This sounds like for some reason Ubuntu is not aware of which disk it should really mount. Your best bet would be to find out the UUID of disk sda. You should be able to do this by running sudo blkid , which should print all disks and then check your etc/fstab to see if the UUID matches.

An example output of sudo blkid:

/dev/sda1: UUID="052f54e5-383f-4743-b3ba-fad1f0ed4ce1" TYPE="ext4" 
/dev/sdb1: UUID="18f2c5a3-0992-4c4c-a693-debd4a5b206a" TYPE="ext4" 
/dev/sdc1: UUID="0da04cdb-8307-4455-854a-2da2c4bf334e" TYPE="ext4" 
/dev/sdd1: UUID="ac5b8715-7bd4-4e1c-bd0b-82fe5383dc05" TYPE="ext4"

Now that you have found out the UUID of sda partitions (in your case there are 4) just open fstab with your favourite editor:

sudo nano /etc/fstab

and add the corresponding entries or fix them if all are present but are showing wrong UUIDs

Vix
  • 31
  • 4
  • In a recovery shell there is no need for using `sudo` since you would already be `root`. Additionally if the file system is read-only, one would have to type `mount -o remount,rw /` before editing any files, and `mount -o remount,ro /` once you are done. – kasperd Sep 13 '14 at 09:40
  • I did run a blkid to get the UUIDs for the 4 disks. Then I cross verified it with the contents of `/etc/fstab` and they are correct (including the UUIDs and the mount points). – Rohan Prabhu Sep 13 '14 at 12:24
  • So after multiple attempts to fix this problem, I just reinstalled the system completely and hoped that it would work. Everything was fine, but I faced the issue again when I enabled LDAP authentication. I have around 3-4 people using multiple boxes hosted across networks, so I have to use LDAP for central authentication. The system was running fine and rebooting properly, but once I installed and enabled LDAP authentication (libpam-ldap), I started getting this problem again. Can this indicate something towards the solution? – Rohan Prabhu Sep 14 '14 at 11:46