At least Kamil and I have been seeing this throughout Fedora 19 testing, but never got around to filing a bug on it.
When you finish installation there's a button to reboot. Often, when you click it, the system delays, sitting at a console with some irrelevant info on it, for about a minute (for me) before restarting. (For a long time I just thought it was broken, and forced shutdown on my test VMs at that point). I don't know if it's 1 minute or longer for Kamil. I think other testers have mentioned seeing this too.
bcl thinks this is probably a systemd thing, at least as a first guess. We'll try and provide some more detailed info later, I just wanted to get the bug filed before I forgot about it again.

Created attachment 761139[details]
journal when waiting for reboot (DVD or netinst)
Before I gather any better information, here's some basic one:
I tested LiveCD >5 times and it doesn't happen for them. Neither if you reboot right after startup, nor if you reboot after installation is finished. Everything is quick. It seems to affect just Anaconda-only environment (DVD, netinst, PXE), both bare metal and VM.
I managed to quickly save journal during waiting for reboot once, it is attached. I'll try to provide better logs. From a quick look, it seems like NetworkManager could cause the problem:
Jun 12 10:21:05 localhost.localdomain NetworkManager[677]: <error> [1371032465.581113] [nm-dbus-manager.c:278] nm_dbus_manager_init_bus(): Could not get the system bus. Make sure the message bus daemon is running! Message: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused

(In reply to Kamil Páral from comment #4)
> 4 times it took about 1:30 min.
Ctrl+Alt+Del doesn't speed up the process. However, shell on tty2 still works during this time.
I tried to follow http://www.freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 (I created a secondary disk for that in VM), however for some reason either debug.sh was not executed, or something else failed and the log was not written.
So I at least booted with systemd debug and saved the journal the same way as before, during the reboot timeout period. Attached.

So my guess here is that the boot-up never finished. You end up in a weird mix of starting things and stopping things there I guess. There's probably a service still in the process of starting up, which we need to wait for to fail before we can then immediately shut it down again to bring the system down again.
Can you enable systemd-debug-shell.service (which will give you an unconditional debug shell on tty9. Then, when this is stuck again, please type "systemctl list-jobs" and paste the output here, thanks.

If I kill (systemctl kill) anaconda.service during the reboot delay, the machine reboots _immediately_. And I mean immediately, I wonder whether it at least unmounts the drives. The reboot is instant.
In the journal I see following messages concerning anaconda after reboot is triggered:
Jun 21 12:24:42 localhost.localdomain systemd-journal[559]: Suppressed 287 messages from /system/anaconda.service
Jun 21 12:24:42 localhost.localdomain anaconda[746]: Problems running the window manager: 1
Have the journal missed 287 messages? Why?
Maybe anaconda is erroneously trying to start another window manager, during reboot? Brian, can you check?

(In reply to Kamil Páral from comment #9)
> This is the output of "systemctl list-jobs" during the reboot delay:
[...]
> 512 anaconda.service stop running
[...]
So this is the problem. anaconda is slow at shutting down, and everything else waits for that. Reassigning to anaconda.

(In reply to Kamil Páral from comment #10)
> If I kill (systemctl kill) anaconda.service during the reboot delay, the
> machine reboots _immediately_. And I mean immediately, I wonder whether it
> at least unmounts the drives. The reboot is instant.
Hmm, if you have the suspicion that things are too fast here, and something reboots forcibly too early, then you could drop in a script in /usr/lib/systemd/system-shutdown/. Make it execute "sleep 10" or so, mark it executable. All executables from that directory are executed immediately before issuing the kernel reboot() syscall. Hence, if this change will cause your reboot to wait for 10 more seconds, then everything should be OK. Note that we in fact are pretty fast these days in shutting down. What is slow is mostly the disk syncs. But this might be a non-issue with install media?
> In the journal I see following messages concerning anaconda after reboot is
> triggered:
>
> Jun 21 12:24:42 localhost.localdomain systemd-journal[559]: Suppressed 287
> messages from /system/anaconda.service
> Jun 21 12:24:42 localhost.localdomain anaconda[746]: Problems running the
> window manager: 1
>
> Have the journal missed 287 messages? Why?
Seems anaconda is writing a ton of messages in a very short time. journald will rate limit per-service, so that one service cannot cause everybody else's logs to be flushed out. You can increase this limit in /etc/systemd/journald.conf using
RateLimitInterval=10s
RateLimitBurst=200
(this is the default of a per-service limit of 200 msgs per 10s, feel free to bump this to any values you like. You can also turn off the limiting by setting it to 0. See journald.conf(5) for more info).

(In reply to Lennart Poettering from comment #13)
> Hence, if this change will cause
> your reboot to wait for 10 more seconds, then everything should be OK.
I tried it and it really waits 10 seconds before rebooting. So it should be fine. I'm quite impressed with the shutdown speed.
> Seems anaconda is writing a ton of messages in a very short time. journald
> will rate limit per-service, so that one service cannot cause everybody
> else's logs to be flushed out. You can increase this limit in
> /etc/systemd/journald.conf using
>
> RateLimitInterval=10s
> RateLimitBurst=200
I relaxed those to 0, and the "Suppressed XXX messages" line is no longer in journal. But there are no extra messages from anaconda either, the journal looks almost the same as in comment 11.

I can't reproduce this often enough to debug it.
I did see (via pstree -p) that anaconda and Xorg were still running and lsof -p <anaconda pid> showed a bunch of files still open.
So, if you can reproduce this I'd like to see:
1. What happens if you kill -9 <xorg>
Is Xorg what's holding onto things?
2. strace -p <anaconda>
3. strace -p <xorg>
At the point where anaconda calls systemctl --no-wall reboot there is nothing else for it to do, it should just exit.
Also, if you can reproduce this reliably, does it also happen in text?
What I did to get information off the system was to run netcat on another system like so:
nc -kl <local ip> 8000
And on the install you can do:
lsof -p XXX > /dev/tcp/<other ip>/8000
to send things to the other system.

I can't reproduce entirely *reliably*, but it happens to me quite often, so I'll try and remember to check back in this tab next time it happens and provided the requested info. I'm sure Kamil will do the same.

(In reply to Brian C. Lane from comment #16)
> Also, if you can reproduce this reliably, does it also happen in text?
Yes it does. Again, just killing the anaconda thread (i.e. not the whole process, just the thread) is enough to make the computer reboot.

(In reply to Kamil Páral from comment #9)
> I tried to start systemd-debug-shell.service, but there is no such service
> on F19 TC6 DVD.
The service has changed names: it's just debug-shell.service now.
~]$ rpm -ql systemd | grep debug
/usr/lib/systemd/system/debug-shell.service
...

[Copied from Bug 994188, Comment 1]
Brian C. Lane 2013-08-06 17:03:11 UTC
Found the problem, patch posted to anaconda-patches. Amount to not using os.system to call systemctl for shutdown since it blocks.

(In reply to Steve Tyler from comment #40)
...
> The "4m[terminated]" message is displayed for about 7 seconds.
...
Just to be clear, that message looks unpolished at best and corrupt at worst.
Users shouldn't be seeing it all ...
As reported in Comment 24, the message appears to be coming from tmux.