The disk drive for /tmp is not ready yet or not present

Bug #1091792 reported by Sworddragon on 2012-12-18
226
This bug affects 48 people
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)
Undecided
Unassigned
Precise
Low
Unassigned
Quantal
Low
Unassigned
Trusty
Low
Unassigned

Bug Description

I'm using Ubuntu 13.04 dev with mountall 2.46 and on booting I'm getting the message "The disk drive for /tmp is not ready yet or not present". But it seems that this message doesn't make any troubles. I'm able to use /tmp without any problems. Maybe something is trying to mount /tmp too early.

Steve Langasek (vorlon) wrote :

Thanks for the report. I've heard this issue reported informally on IRC, but have not reproduced it myself.

Can you attach the /etc/fstab and /etc/mtab from the affected system?

Changed in mountall (Ubuntu):
status: New → Incomplete
Sworddragon (sworddragon) wrote :
Sworddragon (sworddragon) wrote :
Changed in mountall (Ubuntu):
status: Incomplete → New
Steve Langasek (vorlon) wrote :

Thanks. Could you please install the attached file as /etc/init/mountall.conf on your system (not as mountall-debug.conf - you'll have to rename it), reboot until you reproduce the problem, and then attach the resulting /run/mountall.log to this bug?

Sworddragon (sworddragon) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mountall (Ubuntu):
status: New → Confirmed
Sworddragon (sworddragon) wrote :

Sometimes I'm seeing this message with /dev/mapper/cryptswap1 too.

Steve Langasek (vorlon) wrote :

So one thing that's happening here (per private duplicate bug #1122910) is that the time spent running /etc/init/mounted-tmp.conf is being counted against the idle timer for devices not showing up. It really shouldn't, since the device is obviously present by that point and it's just waiting for a device to finish before freeing up the 'mounted' event. Will look at fixing this.

Changed in mountall (Ubuntu):
status: Confirmed → Triaged
Pedro Dias (pedro-dias-77) wrote :

I'm using Xubuntu 12.04.2 LTS with mountall 2.36.4 and I'm affected by this bug too. It is causing the boot to take up a few minutes when before the update to mountall it took about 30 seconds. I worked up a temporary solution by changing fstab to include a line for /tmp as shown below. This resolved the long boot time and returned the boot time to about 30 seconds again.

___________________________________________________________________________________________________________________

# /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>
proc /proc proc nodev,noexec,nosuid 0 0
tmpfs /tmp tmpfs optional,nodev,noexec,nosuid 0 0
# / was on /dev/sda5 during installation
UUID=e1d5a19a-38eb-4764-94fb-aa207425bb05 / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=bf18614c-9c65-438f-8d3b-42e05d38dc94 /boot ext4 defaults 0 2
# swap was on /dev/sda2 during installation
UUID=4763d205-0f07-4307-aa84-92a2e08dbd79 none swap sw 0 0

___________________________________________________________________________________________________________________

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mountall - 2.48

---------------
mountall (2.48) unstable; urgency=low

  [ Steve Langasek ]
  * Make sure we don't show the error message claiming a device is not
    ready when we're actually already handling it but are just waiting for
    related upstart jobs that are blocking the mount to finish.
    LP: #1091792.

  [ Stéphane Graber ]
  * Mount a tmpfs on /sys/fs/cgroup if it exists.

 -- Steve Langasek <email address hidden> Sat, 09 Mar 2013 00:36:22 +0000

Changed in mountall (Ubuntu):
status: Triaged → Fix Released
Zsombor (gzsombor) wrote :

Will it be included in quantal?

Sworddragon (sworddragon) wrote :

I have tested this with mountall 2.48 but I have still get this message about /dev/mapper/cryptswap1 on booting.

Steve Langasek (vorlon) wrote :

Yes, the message about /dev/mapper/cryptswap1 has a different cause that we have not yet isolated. I thought there was a separate bug report open about cryptswap1, but I'm not finding it now. Would you mind opening a separate bug report for that?

Aequiternus (aequiternus) wrote :

same problem
workaround mounting /tmp to tmpfs, using fstab, works fine
tmpfs /tmp tmpfs defaults 0 0
...waiting for new version of mountall in updates

Montblanc (montblanc) wrote :

I'm still experiencing this on 13.04 x64 with up-to-date mountall. The only difference is that /tmp is bound to another partition as specified in fstab. If I press S to skip mounting it and continue booting and then CTRL+ALT+F1 to access the tty and do a 'sudo mountall', the tmp partition gets mounted correctly and the system is perfectly usable. Funny is that once in a while it just works. My system is on the SSD, while tmp and var on HDD, so I thought this could be a matter of my / on ssd loading too early than /tmp (my 2 cents). nobootwait as fstab option didn't do the trick. Should I file another bug?

Steve Langasek (vorlon) wrote :

Yes, please file a separate bug. Having /tmp as a real filesystem on a separate partition is an unusual configuration; I'm not sure why it would behave wrongly but we should figure that out.

Montblanc (montblanc) wrote :

Dear Steve,
It came out that this was just a consequence of a bug in e2fsck hanging up the boot process when the external journal for / is on another partition. I filed bug #1186331 which also contains a patch.

how to solve this problem?

Zsombor (gzsombor) wrote :

It still happens with 2.48build1

Aritchie (aritchie) wrote :

Okay this is getting silly really, after the last round of updates it fixed this issue on my 12.04.3 Desktop system. I thought "Cool". Well after another round of updates; and all I am doing is using the Update Manager for this, this message is back on boot up. The download and install finishes just fine. Is there a log somewhere where I can check to see what was in those round of updates? I think there 25 in this round.

Ubuntu Desktop 12.04.3
linux-generic-lts-raring 3.8.0.31.31

Brahim Salem (brsl) wrote :

This bug affects me too on Ubuntu 12.04.3 and even after updates it persists! I have being using Linux Mint 13 (which based on Ubuntu 12.4) and never had any issues like that and my hardware is not defective!

Dan Chay (danchay) wrote :

I have this bug this morning. Ubuntu desktop 12.04 LTS, GNU/Linux 3.8.0-32-generic.

I can confirm this bug on Ubuntu 12.04.2, 3.5.0-42-generic #65~precise1-Ubuntu, running on a macbook pro

catarinac (catarinavclemente) wrote :

I also have this bug on Ubuntu 12.04 (Precise) 3.8.0-33-generic.

ale (anh-le91) wrote :

The bug is marked as "Fix released", but I'm still seing this problem on Ubuntu 12.04, mountall version 2.36.4?

Dimitri John Ledkov (xnox) wrote :

Correct, this is fix released in 2.48, thus Ubuntu 13.04 and up.

Changed in mountall (Ubuntu Precise):
status: New → Triaged
Changed in mountall (Ubuntu Quantal):
status: New → Triaged
Changed in mountall (Ubuntu Precise):
importance: Undecided → Low
Changed in mountall (Ubuntu Quantal):
importance: Undecided → Low
Dimitri John Ledkov (xnox) wrote :

I have added series tasks, to clearly reflect that this is fixed in Ubuntu 13.04. In practice this message is shown at times too early, when /tmp is still being cleared from files generated at previous boot. Thus one can ignore and wait for it to go away.

RichardE (richard-east-yahoo) wrote :

I've got this also - on 12.04, does the latest mountall fix it? And, while I'm here what does triaged mean on this package?

Changed in mountall (Ubuntu Quantal):
assignee: nobody → Scott W Gleason (lilwes1973)
assignee: Scott W Gleason (lilwes1973) → nobody
Ben Howard (utlemming) wrote :

Also seeing this on Trusty in the Cloud Images:

 * Stopping log initial device creation [74G[ OK ]
 * Starting configure network device [74G[ OK ]
 * Stopping Mount network filesystems[ OK ]

The disk drive for /tmp is not ready yet or not present.
keys:Continue to wait, or Press S to skip mounting or M for manual recovery

 * Starting userspace bootsplash [74G[ OK ]

Changed in mountall (Ubuntu):
status: Fix Released → Confirmed
Rolf Leggewie (r0lf) wrote :

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".

Changed in mountall (Ubuntu Quantal):
status: Triaged → Won't Fix
LutHer (vucicl) wrote :

I have a few partitions on my machine. I can remove them, but would rather not. Anyone know if removing them will elivate this bug?

RichardE (richard-east-yahoo) wrote :

"I have a few partitions on my machine. I can remove them, but would rather not. Anyone know if removing them will elivate this bug?"

To be honest I don't think this will make any difference, so I wouldn't try it.
I only have the usual set of /boot, /root and /home and the system sets up a /tmp on boot and deletes it when I shut down (I think?)

It just waits a few seconds on boot while it sorts its life out, and then carries on normally -- so no big deal (at least for me!!)

But to be fair I am running a fairly old dist. (12.04)

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1091792

tags: added: iso-testing
Mario (q-mario) wrote :

I am experiencing this too on Trusty!

Dimitri John Ledkov (xnox) wrote :

Note xenial no longer uses mountall.
Trusty is the last affected and supported release.

Changed in mountall (Ubuntu):
status: Confirmed → Won't Fix
Changed in mountall (Ubuntu Trusty):
status: New → Triaged
importance: Undecided → Low
Mario (q-mario) wrote :

Is there any workaround for this on on trusty in the meantime ?

gengjichao (gengjichao) wrote :

I also encountered this problem, I used the following version

mountall 2.49
Linux version 4.4.0-46-genric(root@quorm)(gcc version 4.8.4(Ubuntu 4.8.4-2ubuntu1~14.04.3)) #67 SMP Fri Dec 23 14:57:30 CST 2016

Fake Name (lemuix-2) wrote :

I'm pretty sure I'm still seeing the on a up-to-date trusty install as well. This is in a rented dedicated server too, so it's extra spectacularly annoying, because I have to wait for someone to go press a key on the keyboard to fix it.

mountall -v says "mountall 2.49"

Fake Name (lemuix-2) wrote :

Manually adding
tmpfs /tmp tmpfs defaults 0 0
to fstab does seem to be a functional workaround.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers