"a start job is running for hold until boot process finishes up"

Hello there.
I’ve just finishing installing and configuring dietpi on raspberry, very happy.
Just noticed that sometimes it hangs during boot with the following msg:

“a start job is running for hold until boot process finishes up”

Should I look in var/log? Dont remember much about linux

I also can’t run Kodi (black screen) but I guess another topic should be opened?


I did a fresh reinstall and it works.

here we go again.
After trying to install some further packages and rebooting, the message appears again. Puzzled.

Just wondering…do you have an external HDD attached? This same problem just happened to me, I believe in relation to adding a 2TB external drive to my RPi. One fix I’ve seen is to try to comment out the drive in the fstab file. I’m going to try that as soon as I can figure out how to access my pi again… :smiley:

Here’s that other thread: https://dietpi.com/forum/t/rpi-a-start-job-is-running-for-hold/2892/1

Hello and thanls for the reply. :slight_smile:
Yes, I have an external HD connected, with some ntfs partitions that dietpi recognized correctly.
In the meantime I uninstalled all the packages that are under “remote desktop access” and then I have rebooted a couple of times without issues. I’m going to reinstall these one by one to see if they are the root cause. If the problems appears again I’ll comment out lines in fstab, but I need those :confused:

In the meantime I’m getting crazy because I can’t startx as non root user and so I cannot run vlc.
I didn’t remember linux conf was so complicated and funny :slight_smile:

I missed vi soooo much though. :slight_smile:

Hmm. Interesting. I hadn’t seen anything about remote accessing being a possible cause of the issue, but I do screen sharing over SSH to my Pi from the Remoter VNC app on my iPad. I wonder whether that’s causing issues.

I had two other drives, both SSDs, attached to my Pi before this trouble, and no issues with them. This WD drive is the first spinning drive I’ve tried.

I started the cp command via my iPad app last night and then closed the connection…maybe that futzed things up somehow. Thanks for this reply, and good luck! I’ll be interested to hear whether you discover anything new.

You probably already came across this, but I’m including it here for future searchers:


remote access apps are not the root cause, I had the problem again.
I have seen another thread mentioning plymouth, thank you for posting. will try to see if it is applicable. :slight_smile:

How are you even getting to a command prompt? Is your boot process completing, and then the issue starts after a period of time? Are you booting into safe mode?

gianpaolo nicheplayer
The issue is the plymouth package. This was not auto-removed during image creation since somehow on Raspbian Stretch repo the mountall is available and marked as “required”, so survives any auto-removal. On Debian Stretch this package is not even available: Debian -- Package Search Results -- mountall

This package also requires initramfs-tools, thus this is not auto-removed as well. So we finally have an initramfs implementation and a splash screen implementation on RPi that is not required, since RPi has it’s own implementation for both features… :frowning:

Simple fix:

G_AGP mountall && G_AGA
  • This purges the mountall packages and auto-removes all it’s dependencies including plymouth and initramfs-tools.

And if you already touch things, to resolve a potential service startup issue:

sed -i '/^After=/s/[[:blank:]]multi-user.target//' /etc/systemd/system/dietpi-postboot.service
systemctl daemon-reload

I also uploaded a new RPi image which resolves the issues. Please report back if you test it, so I can move it into official downloads:

This is great news! Thanks for the update, MichaIng . I ran the G_AGP code block but not the second, yet.