Hi
If my email is TL;DR then the jist of my question/issue is:
On a headless machine, you are never presented with the prompt to set up a user or accept the license agreement. (initial-setup job/package). I do run VNC server, and had gone through the GNOME welcome wizard, as a standard user and as root. A systemd job keeps running on boot that's presumably outputting the initial-setup-text program to [somewhere] but there's no way (that I know of) to give it input to tell it to accept the agreement and continue. The initial-setup-text systemd job means systemd-analyze outputs "Bootup is not yet finished. Please try again later." Manually running initial-setup-text and accepting the license agreement didn't seem to affect any change. Running the program again just said the license agreement hadn't been accepted. I just removed the initial-setup package via yum. The systemd job went away and systemd-analyze now reports bootup in x seconds etc.
Are there any unforeseeable ramifications of doing this? At least my machine isn't spontaneously rebooting... Does the initial-setup package change/mark something somewhere that should perhaps be done manually?
---------- More detailed version:
Following a test upgrade from 6.5 to 7 on a headless server (worked fine btw) I ran into a bit of a SNAFU with systemd and services. I was trying to troubleshoot a couple of legacy init.d scripts for some programs that just wouldn't seem to start correctly via systemd using the chkconfig legacy compatibility 'thingy'.
The systemd-analyze tool kept saying that my machine hadn't finished booting up. I had performed the upgrade mid-September. The server has been rebooted a few times, but even after 3 days, I still got that message.
BS I said.
I've read the docs thoroughly on how to manage services, and, well, no services were really causing any problems (a couple were failing on start up, resolved most of those, still stuck on one but I could disable that) so I couldn't understand why systemd-analyze would keep reporting that my system hadn't "finished booting".
I then stumbled upon the "systemctl list-jobs". This listed - among a couple of other jobs - an initial-setup-text program running as a job that was "waiting" (from memory). Possibly waiting on input. I can't remember. Realizing what this was, I tried to run it manually from my ssh console. Press 2, accepting the license agreement, c, c ... the job wouldn't "go away". The license also was never accepted. I ran it again, accepted the agreement, c, went back again. Still no change.
So I killed the job...
[root@trixie bin]# systemctl status initial-setup-text initial-setup-text.service - Initial Setup configuration program (text mode) Loaded: loaded (/usr/lib/systemd/system/initial-setup-text.service; disabled) Active: active (exited) since Thu 2014-10-09 13:35:50 NZDT; 7min ago Main PID: 993 (code=killed, signal=TERM) CGroup: /system.slice/initial-setup-text.service
..... and re-booted.
It came back (the job that is). FFS. Still couldn't really use systemd-analyze to try and find out what's going on with my "legacy services" that aren't playing nice.
So I... yum remove initial-setup [reboot] ... and now the job has gone. YAY. Maybe I should have done something differently, Oh well.
My systemd-analyze now reports my system boots OK, and systemd list-jobs reports no jobs running.
So I guess my bug report would go something like....
The initial-setup-text systemd job keeps coming back after reboots. There's no way (easy way that I could find) to provide input to the initial-setup-text systemd job on a headless system. Short of redirecting output to a com port and ... yeah... too hard. systemd never reports a successful boot if you have a job that never completes (and that keeps coming back). Removing the initial-setup-text package was the only way I could think of to get rid of it. My system doesn't behave erratically after doing this. I would suggest (if possible) that the initial-setup-text gets run when you SSH into your machine for the first time for you to accept the license agreement etc. Maybe it's not even required. I did see a couple of bugzilla reports ( http://bugs.centos.org/view.php?id=7173) that maybe suggested that.
Cheers, Bert