Debian hangs during boot


This morning I came to work a hour earlier than usual. I started my work PC and waited for it to boot into Debian Jessie. And waited… waited… waited…

This sounds strange, doesn’t it? It generally boots rather quickly. In fact Debian hangs during boot with this message:

A start job is running for Create Volatile Files and Directories

Followed by a timer and no limit. You can leave it there, but it does not finish and just hangs there. So, let’s try understand the problem.


The problem

The problem here is quite obvious: in the previous session you updated systemd to version 215-5+b1. If you have a look at your system’s /tmp directory (you can’t do it now, but we’ll do it later for sake of knowledge), you find out that it’s bloated. Here’s the bug report.


As OdyX points out in the comments, the real problem has to do only with the /tmp directory and is caused by a bug in system-config-printer, and systemd is responsible only to expose the problem.


The solution

Thankfully, the solution is pretty straightforward. Reboot your computer with Ctrl+Alt+Del and wait for Grub to load, then press e to edit Debian’s entry. After the line with /boot/vmlinuz... add the following:

--add rw init=/bin/bash

And press F10 to boot. Debian will load as a shell with root permissions, so you can do whatever you want (but be careful, because you can cause big issues too!

Now it’s time to check your /tmp directory:

ls -l /tmp

You should wait some minutes until it finishes, and the output may scare you. It’s bloated, as I told you before. What can you do now? Just remove and recreate it.

rm -rf /tmp
mkdir /tmp
chmod 1777 /tmp

Now restart your PC and check it out: Debian will boot correctly!



Is systemd ready to go towards a Debian stable release? I don’t think so. The team has to work hard to accomplish this step. So, good luck guys, and please test it a little more next time!

See edit above.


Source: Debian User Forums

CC BY-SA 4.0 Debian hangs during boot by Mattia Migliorini is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.


Web Designer freelance, Ubuntu Member, Linux evangelist. Loves working on clear and minimal designs and wants to create beautiful things for different devices.

deshack wrote 83 posts

Post navigation


  • Günther Bayler

    Thank you very much for posting your solution! I had a similar problem while using Ubuntu 14.10, which I could finally solve using your solution (see here).

    Best regards,

  • Ben


    I had problems with some commands you put for editing the grub

    –add and rw are not recognized commands in debian I get this message cannot recognize –add and then continues in normal boot and stops in the same error line “A start job is running for dev-disk …..”

    Can you help me please?

    • deshack

      Did you put only one hyphen before “add”?

      • Ben

        I put double hyphen..and now I could do all the steps and and check my doesnt take too long to list them( was not bloated) and then used the final commands so it was removed and then reacreated a new TMP folder…but boot still hangs every time I power my lap on….

        IDK what else to do..pls help

  • Marius Gedminas

    I don’t have a system with sysvinit available (Ubuntu everywhere), but I’m curious why it didn’t have a problem with millions of files in /tmp. There was a job in /etc/init.d/ to clean /tmp on boot, wasn’t there? Was it simply more efficient?

  • Veritas Inc

    Good post! We are linking to this great article on our
    site. Keep up the great writing.

  • indra budiman

    nice post.thx

  • Jef Spaleta

    Okay so systemd exposes this because systemd-tmpfiles is configured to run and is interacting with the /tmp directory to remove and create subdirectories. the specifics of which are configurable.

    So for completeness, you as a local admin can take full control over how systemd-tmpfiles is being called during boot. You can also configure what directories its looking at and how its handling them. Highly configurable.

    Now the pathelogical situation produced by cups is a very interesting cornercase, seems like there might be room to use that pathelogical cacse enhance the tmpfiles helper’s efficiency.


  • Giulio Turetta

    Try, rescue… ensure 🙂

  • OdyX

    It would be more complete and factual to point that this problem is in fact a “full /tmp” problem, caused by in system-config-printer, not in systemd, which just exposes the problem.

    • deshack

      Thanks for pointing this out. I updated the post accordingly.

      • OdyX

        This has now been fixed both in cups and system-config-printer. Thanks for your edit!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>