| モード | init.d | systemd |
|---|---|---|
| システム停止 | 0 | systemctl isolate poweroff.target |
| シングルユーザモード | 1 | systemctl isolate rescue.target |
| マルチユーザモード | 3 | systemctl isolate multi-user.target |
| グラフィカルログイン | 5 | systemctl isolate graphical.target |
| OSの再起動 | 6 | systemctl isolate reboot.target |
| 緊急モード | - | systemctl isolate emergency.target |
・シングルユーザモードと緊急モードの違い
シングルユーザモードではネットワークが使えないが、緊急モードでは利用可能
・各モードがターゲット切替可能かどうかの確認方法
cd /usr/lib/systemd/system grep AllowIsolate 対象のターゲット
AllowIsolate=yes or noで表示される
CentOS8における主なリポジトリは、BaseOSとAppStreamです。
[BaseOS]
・従来のCentOS7までのベースリポジトリに相当する。
・従来通りCentOSのバージョン単位にrpmが用意されており、管理する必要がある。
[AppStream]
・従来のCentOSにおけるSoftware Collectionsリポジトリ、Extrasリポジトリで提供していたアプリケーションなどが含まれる。
・ストリームという呼称で新たに定義されている。これは、(開発元の提供形式に依存はするが)複数のOSバージョンに跨れ、またalternativesコマンドみたいな複数バージョンの切替が可能になる。
【症状】
・ある日電源立ち上げると画面がつかなくなった。
・デバイスマネージャーでディスプレイアダプタ(グラフィックボード)の箇所を確認するとビックリマークが付いており、「このデバイスが使用できる空きリソースが不足しています」というエラーメッセージが表示されていた。
・なお、以前認識しなくなった時が二度あり、一度目はグラボ自体が壊れたこと(ファンが不調だった事による熱故障)、二度目は原因不明だが二日ほどで勝手に治った経験があった。
【今回最終的にうまくいった対応方法】
・グラボを一度マザーボードから抜いてWindowsを起動
・その状態でマシンを一度終了し、グラボを再度取り付けてから起動
【調査過程及び施行内容】
(現状確認)
画面が何も見えない状態でありつつも、過去2度ほどグラボが駄目になったことある経験から、今回は確実にグラボが逝ってしまったと判断した。そのため、以前よりGoogleリモートデスクトップで別マシンから接続できる状態にしていたので、そちらからリモート接続をしたところ無事接続が行えた。そして、デバイスマネージャーで確認したところ、ディスプレイアダプタのとこがビックリマーク&上記に記載したメッセージが発生していた。この時点では、グラボ自体は認識している状態を確認できていた。筐体自体の中を開けたところ、グラボのファン自体も正常に動作していたことから、物理障害ではなく論理障害が発生しているという線で調査を進めることにした。
(対応内容)
・Windows Update
2020年3月版WIndows Updateの調子が悪いニュースは耳にはしていたが、こちらの影響の可能性はあるかなと思い、怖いながらもWindowsUpdateを実施したが何も変わらなかった。
・bcdedit
PCI Expressの認識が正しく行えていないという路線と考えていたので、以下の記事を参考に実施を行った。当ブログの記載されているとおり、WIndows7ではこの方法で良かったが、Windows10では公式なやりかたではないためか、このコマンドを投入して再起動を行うとグラボ自体も認識しなくなり、オンボード側のディスプレイアダプタが表示されるようになってしまった。。なお、ForceDisabled→Defaultにパラメータを元に戻したが認識されることはなかった。そのため、試す際には覚悟をもって(バックアップなどを取得してから)コマンドを投入する必要がある。
4CoreDual-VSTAでWindows 10：でっかいひとりごと：SSブログ
・HackFlags
同じくWIndows7などで使われていた手法でレジストリの値を書き換える対応というのが存在したが、何も変化は発生しなかった。
https://support.microsoft.com/ja-jp/help/942959/error-message-when-you-attach-a-pci-express-expansion-chassis-to-a-com
・グラフィックボードのドライバ更新(但し、実際は行わず)
もしかしたらこれをやればすぐ解決したのかもしれないが、Windows側でそもそもこのカードが刺さっている事自体を認識していなかったので、PCI Expressの差し込み部分が問題あると考え、対応を行わなかった。
・BIOS Update
購入してからそもそもどこのマザーボードからも把握していなかったので、以下のコマンドでマザーボードの型番を確認した。私の場合は、dxdiagでは確認は行えず、systeminfoでASUSのH110I-PLUSが使われている事が分かった。その後、BIOS Updateを実施したが、結果何も変化は無かった。なお、このタイミングより、Chromeリモートデスクトップ接続からオンボード表示(VGA)に切り替えた。
自分のPCのマザーボードの型番を確認する方法6選！ | Aprico
・BIOS設定見直し
確認を行った後にBIOS UpdateによってPCI Express関連の設定初期値が変わっている、設定項目が増えている可能性があると考え、以下サイトを参考に色々PCI Express周りの設定値を変えながら再起動を繰り返した。しかし、特に有用な設定は存在しなかった。但し、画像ディスプレイを優先的にPCI Expressを設定する値を設定しても、次確認するとAutoになっていた。ただ、これはPCI Expressが刺さっていないと誤認識されているため、自動で設定をAutoに戻されたのかと解釈した。
ASUSマザーのAdvanced Modeを徹底解説 ～Advancedメニュー詳細編～ - AKIBA PC Hotline!
この設定作業を行う前にキーボードの入力を受け付けなくてBIOSもといUEFI画面に入れないという事象に見舞われたが、通常Bluetooth版ThinkPadキーボードを使っていた事にはたと気がついた。進んでいるUEFIであればBluetooth接続を認識するかもしれないが、昔のBIOSであればPS/2しか認識しなかったし、現代においても有線USBでないと認識は行われない可能性が高い。当方は、有線版ThinkPadキーボードも保持しているので、そちらに切り替える事で設定を行えた。
・物理再接続
上記対応行っても一向に変化ないため、同じ構成で動いていた実績はあるので、壊れてない限りは物理レベルでは問題ない構成と考え、一度マシンから切り離して新しく付けた形で認識させるという方法にチャレンジしてみた。
結果は最初に記載通り、何事もなくうまく認識を行ってくれた。正直UEFI/Windows側でどの様にこの行為が解釈されたのか分からないが、特に新たなドライバを求められることもなく認識を行ってくれた。
【今回の事象に関係ありそうなマシン構成】
マザーボードとグラボの関係が一番関連しそう。
CPUは内部GPUの設定に影響与える場合もあるので参考程度に記載を行った。
Windowsの部分は、Windows10である事、Homeである事を示すために記載を行った。
ASUSTeK Intel H110搭載 マザーボード LGA1151対応 H110I-PLUS 【Mini-ITX】
ZOTAC Geforce GTX 1060 6GB Single Fan グラフィックスボード VD6096 ZTGTX1060-GD5STD/ZT-P10600A-10L
Intel CPU Core i7-7700K 4.2GHz 8Mキャッシュ 4コア/8スレッド LGA1151 BX80677I77700K 【BOX】【日本正規流通品】
【新パッケージ】Windows 10 Home 日本語版/May 2019 Update適用/パッケージ版
【対応する際に大事な事】
・こまめなバックアップ取得を心掛ける行う事
・リモートから操作できるように予め設定しておく事
・BIOS(UEFI)設定が行えるためのキーボードも抱えておく事
・負けない事、投げ出さない事、逃げ出さない事、信じ抜く事
【Amazon.co.jp 限定】Acronis True Image 2019 3台版
![DOS/V POWER REPORT (ドスブイパワーレポート) 2020年春号[雑誌]](https://m.media-amazon.com/images/I/51TCf2sTNQL._SL160_.jpg "DOS/V POWER REPORT (ドスブイパワーレポート) 2020年春号[雑誌]")
DOS/V POWER REPORT (ドスブイパワーレポート) 2020年春号[雑誌]
レノボ・ジャパン ThinkPad トラックポイント・キーボード - 日本語 0B47208
【事象】
ゲストOSからyumを実行しようとしても、yumが止まった状態になってしまい、アップデートが行われない。
なお、ホストOSからゲストOSに対して、SSHやゲストOS内に環境構築しているWebサーバーには問題なくアクセスできる。
(NATのポートフォワードの設定は正しく行えている)
【原因】
プロキシの設定が正しくなかった。
【環境】
ホストOS：Windows10
仮想環境：VirtualBox6
ゲストOS：CentOS7
ゲストOSのネットワークアダプター：NAT
その他：HTTPなど通信する際にプロキシが存在(会社)
【対応方法(の一例)】
１．VirtualBox自体のプロキシの設定変更
[ファイル] - [環境設定] より、"プロキシー"カテゴリを選択し、インターネットに直接接続を設定する。
２．ゲストOS内部のプロキシ設定
(CentOSで一時的に通信を行う場合)
以下を実行し、環境変数を宣言すれば通信を行える。
export HTTP_PROXY=http://<プロキシのユーザー名>:<プロキシのパスワード>@<プロキシのサーバー名>:<プロキシのポート番号>/ export HTTPS_PROXY=https://<プロキシのユーザー名>:<プロキシのパスワード>@<プロキシのサーバー名>:<プロキシのポート番号>/
【その他】
・VirtualBox6の環境であれば、ゲストOS→インターネット、ホストOS→ゲストOSの通信を実現したいのであれば、ネットワークアダプタはNATのみで問題ない。
・環境によっては、Windowsファイアーウォールや、ウイルスソフトに通信が止められている可能性があるので確認する必要がある。
【参考リンク】
社内Proxyに阻まれていろいろ捗らない人のためのTips - Qiita
CentOS 7で作るネットワークサーバ構築ガイド 1804対応 第2版 (Network Server Construction Guide S)
デフォルトではTomcatマネージャーはアクセスできない設定になっている。
そのため、tomcat-users.xmlを編集してあげる必要がある。
なお、tomcatのバージョンによって書式が違うことがあるので、注意が必要である。
http://www.lesstep.jp/step_on_board/tomcat/1285/www.lesstep.jp
昨今のtomcat脆弱性対応の対策など無くても8009は塞がれてる事が多いので、Apache HTTP Server経由などでアクセスするような構成となっていた場合、HTTPサーバーのポートフォワード指定がコンテキストパスなども含めている場合にmanagerが設定されていないと当然フォワードしてくれないのでアクセスエラーになる。
Apache HTTP Serverなどでは、httpd/conf.d/proxy_ajp.conf(環境によってはディレクトリ名やファイル名が異なる)などの設定を確認する必要がある。
weblabo.oscasierra.net
デフォルトではローカルホストからしかアクセスが許可されていない。
そのため、どのIPアドレスからであればアクセス可能かの設定を行ってあげる必要がある。
blog.enjoyxstudy.com
【事象】
GithubやGitlabなどリモートリポジトリ側で確認すると対象ブランチが存在するが、Forkクライアント側で確認すると対象ブランチが表示されない。
【理由】
クライアントの情報がリモートリポジトリ側と同期されていないだけ
【対応方法】
通常はFetch 'origin' Automaticallyがチェック付いているので困ることはないと思われる(過去困ったこと無かった)。
しかし、Fork 1.45.0.0を利用した際、うまく同期がされない事象に出くわした。
そのため、自分で上部のFetchアイコンを押して、対象をRemote:originを選択することで無事対象ブランチが表示された。
これが自身だけなのか、Fork側の問題かは不明であるが、備忘録がてらに記載しておく。
【行いたいこと】
コミットログの表示エリアはデフォルトでは対象リポジトリの全てのコミットの軌跡が表示される。
そのため、自身がコミットしているリポジトリの内容が埋もれて表示が見にくい時があるので、該当ブランチのコミットのみ表示させたい。
【方法】
BranchesやRemotes内の対象ブランチにマウスポインタを移動させると、右側に星マークとアンテナ0本みたいなアイコンが現れる。アンテナ0本側のアイコンをクリックすると、該当のブランチのみがフィルタされた状態でコミットログの内容が表示される。なお、複数ブランチを選択することで、選択したブランチのコミットログが表示された状態にすることも可能である。
コミットログの上部にClear filterというのが表示されるので、それをクリックすれば一括解除可能である。
