[Solved]after update jessie hangs during boot, "start job is

[woodnymph]

This maybe related to systemd-tmpfiles-setup.service, though I can't say I understand.

After my most recent update, the boot sequence hangs at:
"a start job is running for Create Volatile files and directories" with a timer and no limit .. I let it go for 12 minutes, but nothing.
It seems as long as this sequence remains, the boot process does not finish and just hangs here.

I haven't been able to find anything specific to this. I currently cannot boot into this machine, though do have access to files via dual boot.
Any ideas for a workaround here?

[Ardouos]

After doing a bit of research from what I can see it is to do with either your /tmp or swap partitions. Can you check to see if they are mounted properly in the fstab?

[woodnymph]

After doing a bit of research from what I can see it is to do with either your /tmp or swap partitions. Can you check to see if they are mounted properly in the fstab?

This is kind of where it all started .. I edited /etc/fstab for swap to /dev/sda2, but later commented it out entirely after reading a post saying systemd would auto mount the swap & other partitions. Not sure about /tmp.

When I first booted after the upgrade, neither the main hdd nor the swap were being recognized and I was getting fatal depends errors. Editing fstab fixed these but left me with the current problem. I wonder if there is a config somewhere I can at least set a timeout? I also had the exact same problem on a different machine, though editing fstab got it back proper.

[anthonyfok]

I ran into the same problem after doing a "apt-get dist-upgrade" where systemd was upgraded from version 208-8 to 215-5+b1.
Upon reboot, "a start job is running for Create Volatile files and directories" appears to run forever, though I must admit I had only waited a few minutes before pressing "Ctrl-Alt-Del" to reboot, which, thankfully, worked.

I have Ubuntu 14.04 installed on another partition, so I was able to boot into Ubuntu diagnose the problem on my Debian partition.
I am very glad to have found your posts, which gave me an idea where to start looking.

After learning more about systemd-tmpfiles, I checked out each of the "volatile" directories, and when I tried to do a "ls -l /Debian/tmp", it kind of got stuck.
I managed to pkill the "ls" process from another console, then proceeded to umount the Debian partition and ran e2fsck on it. Came out clean.

Eventually, I tried to use debugfs to list that /tmp directory, and also let "ls -l tmp" run for almost an hour and got some output. It turns out that my /tmp directory was filled with some 628,000 symlinks to /etc/cups/ppd/Xerox_WorkCentre_6015NI.ppd . I recalled that I was in a hurry to print some music sheets, and Debian all of a sudden just wouldn't print to my printer after my "apt-get dist-upgrade" run, so I had to reboot into Ubuntu to do the printing.

So, after collecting output from "ls" and "debugfs", I finally went ahead to remove the old bloated /tmp directory and create it anew:

Code: Select all

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

I am about to reboot to see if it solves my problem.

Perhaps something did go wrong during that "apt-get dist-upgrade". /tmp is normally mounted as a tmpfs, right? All those symlinks should have resided in tmpfs, i.e. in RAM, but somehow they ended up in my ext4 filesystem, so perhaps /tmp got umount'ed during the system upgrade, perhaps even during the systemd 208-8 to 215-5+b1 upgrade? (Or maybe not? Perhaps I didn't have /tmp mounted as tmpfs, which is the case in my Ubuntu installation). Oh well, I will find out when I reboot.

Hope this helps!

Anthony

P.S. Hurray! It worked! I am back in Debian now.
P.P.S. As for my printing problem, it turns out that my /etc/cups/ppd/Xerox_WorkCentre_6015NI.ppd permission got changed by something a few days ago:

-rw-r----- 1 root lp 21519 Oct 8 18:07 Xerox_WorkCentre_6015NI.ppd
-rw-r--r-- 1 root root 21275 Jul 27 02:49 Xerox_WorkCentre_6015NI.ppd.O

Hmm... I wondered what happened. My /var/log/dpkg.log shows that some cups packages was being configured around 18:07 on Oct 8...

[woodnymph]

So, after collecting output from "ls" and "debugfs", I finally went ahead to remove the old bloated /tmp directory and create it anew:

Code: Select all

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

I am about to reboot to see if it solves my problem.

Good catch Anthony. Definitely a problem with my /tmp folder, won't even display in the file browser after running for 5 minutes. On deleting it, there were some 200,000 files (60+MB) to deal with .. I remember now too, after the dist-upgrade it did not shut down normally and I think I eventually just powered it off. I'll try a reboot here when it's done to see if it works for me & maybe should do this on my other machine as well (same problem).

[Update] Hey! that worked. I am able to boot into my Debian machine again .. though now I.m getting a failed LSB message - ahh, onto other things. I can't believe this crap(systemd) is being pushed out like it is - BS in my opinion, please stop breaking my installs. /endrant.

[Ardouos]

I can't believe this crap(systemd) is being pushed out like it is - BS in my opinion, please stop breaking my installs. /endrant.

Yer, I do not understand why it is being pushed so hard. I do not feel like it is polished/ mature enough to just be forced onto people.

[ludwig]

I have a very simlilar problem here. I installed a printer yesterday and have also version 215-5+b1 of systemd.
The system hangs during boot with the same error message.

The only way I could get it to restart was to the following procedure

-add rw init=/bin/bash in order to get a root shell before the system hangs
-move the folder /usr/lib/tmpfiles.d to /usr/lib/oldtmpfiles.d

Then I could log in normally during the next reboot and the tmpfiles.d was recreated during an upgrade.
Unfortunately the problem just comes back for the next reboot.

The problem seems to be the /tmp directory, which has 976M. I cannot ls or remove it.
When I run ls it gives memory exhausted as an output and when I run rm -rf it just runs for a long time and the size of the directory does not appear to change.

Is there a way to delete the /tmp directory?

[Ardouos]

I have a very simlilar problem here. I installed a printer yesterday and have also version 215-5+b1 of systemd.
The system hangs during boot with the same error message.

The only way I could get it to restart was to the following procedure

-add rw init=/bin/bash in order to get a root shell before the system hangs
-move the folder /usr/lib/tmpfiles.d to /usr/lib/oldtmpfiles.d

Then I could log in normally during the next reboot and the tmpfiles.d was recreated during an upgrade.
Unfortunately the problem just comes back for the next reboot.

The problem seems to be the /tmp directory, which has 976M. I cannot ls or remove it.
When I run ls it gives memory exhausted as an output and when I run rm -rf it just runs for a long time and the size of the directory does not appear to change.

Is there a way to delete the /tmp directory?

The answer on how the person sorted out their issue is in the post. I must advise to backup before doing anything potentially dangerous to your system.

[kurtmeln]

Actually the reboot finally succeed though it took a long time (~ 2 - 3 min).
I have edited the /etc/fstab before, just now I added "noatime" to my added line and it seems speedup.

I have similar problem. When reboot Jessie, the display has gone to sleep, but the PC is still runing, keyboard and mouse LED don't turn off. I have to turn off the power mamually and then boot;
My version is "debian-live-8.0.0-amd64-xfce-desktop", DELL (bought in 2013): i5 CPU, 1T hdd, 16G RAM;
The system are debian8.0 + win8.1, with grub as boot loader, same problem never occured when the system are debian7 + win8.1