「システムランレベルの変更に関するアップデートUTMPの開始」で起動が停止する-ヘッドレスサーバー... Xなし
午前8時27分です。私は寝ていません。疲れました。これをここに置いて寝ます。後で確認します。私がまとまりの少し南にいる場合はご容赦ください。
VPSで実行されているUbuntu 16.04.3 LTSサーバー。同じホストマシンであるCentOS6に別のVPSをインストールしました。 CentOSのvpsはまだ動き続けています。 Ubuntu vpsが起動しません。最後の変更は、Virtualmin "仮想サーバー"を追加することでした（実際には、いくつかのデーモンに対する特権を持つ別のユーザーのみ）。そして、いくつかはpostfixをいじっています。私がオンラインで読んだことはすべて、グラフィックスドライバーを取り除いて再インストールすることです。まあ、グラフィックスドライバーがないので、グラフィックスがありません。 Xはありません。ウィンドウマネージャーはありません。 X向けのIntelまたはnvidiaグラフィックスドライバーではありません。
これまでで最も健全な解決策に至ったのは、これまでにArch Linuxに関する半古代のフォーラム投稿です。/var/runから/ runへのシンボリックリンクがないために発生する同じ問題。まあ、私はそのシンボリックリンクを持っています。だからそれはおそらくそれではない。そして、上記の途方もなく役に立たないメッセージ以外に、何が悪いのかを示すものは何もありません。
シルバーライニング... vpsには、ハイパーバイザーに組み込まれた独立したVNC機能があります...そのため、ターミナルアクセスはまだ可能です。そして私はできる CTRL+ALT+F2 起動メッセージがまだtty1でスタックしている場合でも、tty2でログインプロンプトを取得するにはただし、ネットワーク接続はありません。 systemdサービス/ユニットのかなりのチャンクが起動していません。複数回再起動しても意味のある変更はありません。
それはすべてが爆破する直前に「到達したターゲットグラフィカルインターフェース」について話しますdoes。しかし、再びXはありません。そして、はい、実際にxorg/x11が依存関係として何らかの形で取り込まれていないことを確認しました。下のスクリーンショット。
Ubuntu 16.04サーバーは、インストールしていない場合でもXで起動するように事前構成されています。どうして？ 「猫だから」と思う。どうやら、少なくともsystemdでの前提は、graphical.targetユニット（Xorgなど）に依存するものが何もない場合、デフォルトのターゲットとして構成されていても、起動中に実行されないことです。そのような場合は、代わりにsystemd "targets" multi-user.targetを使用してください。私の場合、graphicd.targetに依存する何かが引き込まれ、systemdがブートシーケンスを並べ替えました。これにより、ブートシーケンスの最後に「システムランレベルの変更に関するUTMPの更新を開始」が追加されました。それは赤いニシンであることがわかりました（申し訳ありません。私はsystemdを初めて使用したので、作業するための多くのことを正確には提供していませんでした）。
デフォルトのターゲットをmulti-user.target（Sudo systemctl set-default multi-user.target）、これが機能していることを確認しました。そうです。また、コメントに記載されている個別のShorewallの問題も解決しました（ブートシーケンスの早い段階でipsetが作成されていなかったため、独自のsystemdサービスユニットを作成し、Shorewallに依存させて修正しました）。 multi-user.targetに切り替えると、起動しなかった他のサービスが解決されたようです（依存関係ツリーは、代わりに、graphical.targetを起動することで間違っていたため、サービスは実行されず、エラーも発生しませんでした）。
問題の一部がまだ残っています。systemdは、tty1がmulti-user.targetに到達してもtty1を解放していません。サーバーの運用に悪影響を与えないように見えるため、これは世界の終わりではありません。しかし、それは何がそれを引き起こしているのか、それが後でお尻を噛むかもしれないのかどうか、私の心に疑問を投げかけます。そのため、私はこの答えを受け入れません。他の誰かがそれを修正する方法を知っている場合は、共有してください。
gnomeを削除します。
Sudo apt-get autoremove gnome-core gnome-Shell gnome-session
それを再インストールします：
Sudo apt-get install gnome-core gnome-Shell gnome-session
あなたが持っている場合
「問題を修正できません。壊れたパッケージを保持しています」
Sudo apt-get install aptitude
未解決の依存関係に関する最初の質問には「いいえ」、古いパケットをインストールするには「はい」と答えます。その後
Sudo aptitude install gnome-core gnome-Shell gnome-session