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?

Improve this question
1
  • 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. Commented Sep 13, 2014 at 14:57

2 Answers 2

Reset to default
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.

Improve this answer
1
  • 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 Commented Nov 22, 2016 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

Improve this answer
3
  • 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. Commented Sep 13, 2014 at 9: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). Commented Sep 13, 2014 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? Commented Sep 14, 2014 at 11:46

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.