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

Bug #1091792 reported by Removed by request
226
This bug affects 48 people
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)
Won't Fix
Undecided
Unassigned
Precise
Won't Fix
Low
Unassigned
Quantal
Won't Fix
Low
Unassigned
Trusty
Fix Released
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.

Tags: iso-testing
Revision history for this message
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
Revision history for this message
Removed by request (removed3425744) wrote :
Revision history for this message
Removed by request (removed3425744) wrote :
Changed in mountall (Ubuntu):
status: Incomplete → New
Revision history for this message
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?

Revision history for this message
Removed by request (removed3425744) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in mountall (Ubuntu):
status: New → Confirmed
Revision history for this message
Removed by request (removed3425744) wrote :

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

Revision history for this message
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
Revision history for this message
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

___________________________________________________________________________________________________________________

Revision history for this message
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
Revision history for this message
Zsombor (gzsombor) wrote :

Will it be included in quantal?

Revision history for this message
Removed by request (removed3425744) wrote :

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

Revision history for this message
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?

Revision history for this message
Removed by request (removed3425744) wrote :
Revision history for this message
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

Revision history for this message
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?

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
lepidas blades rompolos (lepidas) wrote :

how to solve this problem?

Revision history for this message
Zsombor (gzsombor) wrote :

It still happens with 2.48build1

Revision history for this message
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

Revision history for this message
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!

Revision history for this message
Dan Chay (danchay) wrote :

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

Revision history for this message
Francesco Chiechi (francesco-chiechi) wrote :

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

Revision history for this message
catarinac (catarinavclemente) wrote :

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

Revision history for this message
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?

Revision history for this message
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
Revision history for this message
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.

Revision history for this message
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
Revision history for this message
Ben Howard (darkmuggle-deactivatedaccount) 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
Revision history for this message
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
Revision history for this message
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?

Revision history for this message
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)

Revision history for this message
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
Revision history for this message
Mario (q-mario) wrote :

I am experiencing this too on Trusty!

Revision history for this message
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
Revision history for this message
Mario (q-mario) wrote :

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

Revision history for this message
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

Revision history for this message
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"

Revision history for this message
Fake Name (lemuix-2) wrote :

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

Revision history for this message
Sapa Holliday (saparonia) wrote :

I bought a second hand hdd from ebay that had previously been in a sky box. I gave it a good formatting and then installed elementary freya on it and ran update. My old hdd is still in but is full, so I have dual boot same opsys. I am getting this exact bug. I have a fat32 partition on the old hdd for storage/ backup and never had any problems before but now it's a real hassle to boot into the second hard drive because of this bug.
update grub gives me this mess

[sudo] password for sapa:
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-4.4.0-93-generic
Found initrd image: /boot/initrd.img-4.4.0-93-generic
Found linux image: /boot/vmlinuz-4.4.0-92-generic
Found initrd image: /boot/initrd.img-4.4.0-92-generic
Found linux image: /boot/vmlinuz-3.19.0-80-generic
Found initrd image: /boot/initrd.img-3.19.0-80-generic
Found linux image: /boot/vmlinuz-3.19.0-26-generic
Found initrd image: /boot/initrd.img-3.19.0-26-generic
Found elementary OS Freya (0.3.2) on /dev/sda1
done
sda is the old drive, the new one is sdb1 with some linux swap space.
It tries to mount a non-existing /tmp on every boot into the new drive, is completely ok when booting into the old drive.

Changed in mountall (Ubuntu Trusty):
status: Triaged → Fix Released
Revision history for this message
Steve Langasek (vorlon) wrote :

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release

Changed in mountall (Ubuntu Precise):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.