VMware Converterで変換したCentOS 7が「error can't find command ':'」で起動しない

ESXi上にある仮想マシンCentOS 7)をVMware ConverterでV2Vしたら、エラーで起動しない問題に遭遇したのでメモ。


【環境】
VMware vCenter Converter Standalone 6.3.0
CentOS 7.9


V2Vした仮想マシンを起動したところ、次のようなエラーでOSが起動しない。

error can't find command ':'



「MORE」と表示されているので、moreコマンドの状態?と思い、
コンソールで「q」を押すとエラー表示をスキップしてGRUBの画面に移行してOSが起動することが分かった。

が、OSを再起動すると同じエラーが発生する。
これでは毎回コンソールでエラーをスキップする必要があって困る。


メッセージにある「コロン(:)」が起動時のファイルに記述されており、エラーが出ていると予想。
OS起動時のことなので、GRUBの設定ファイルを確認。
 ・/etc/default/grub
 ・/boot/grub2/grub.cfg

1つ目のファイルは特に変わった様子はなかったが、2つ目にそれらしい箇所があった。

# cat /boot/grub2/grub.cfg
・・・略
### BEGIN /etc/grub.d/10_linux ###
: # (removed by Converter) menuentry 'CentOS Linux (3.10.0-1160.81.1.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted menuentry_id_option 'gnulinux-3.10.0-327.el7.x86_64-advanced-1d47488d-d712-46a0-9923-cc069790491d' {
: # (removed by Converter)      load_video
: # (removed by Converter)      set gfxpayload=keep
: # (removed by Converter)      insmod gzio
・・・略

先頭に「: # (removed by Converter) 」と記載された行が原因と思われる。

GRUB2は、
 1./etc/default/grub で設定を変更する
 2.grub2-mkconfig コマンドで grub.cfg を生成
という手順で行う。

/etc/default/grub の方はV2V前の状態と変わっていないので、特に設定は変更せずgrub.cfg を再生成するだけ。
※以下のコマンドを実行前に、念のため /boot/grub2/grub.cfg のバックアップを取っておく。

# grub2-mkconfig -o /boot/grub2/grub.cfg

UEFIマシンの場合は、/boot/efi/EFI/redhat/grub.cfg


生成された /boot/grub2/grub.cfg を確認すると、問題の行が消えている。
OSを再起動して、正常に起動することを確認。

「: # (removed by Converter) 」が入ってしまう理由は、Converterの仕様なのかバグなのか不明。


<参考>
第26章 GRUB 2 での作業 Red Hat Enterprise Linux 7 | Red Hat Customer Portal

【 grub2-mkconfig/grub-mkconfig 】コマンド――GRUB 2の起動メニューを生成する:Linux基本コマンドTips(278) - @IT

RedHatにも、それらしい情報があるが有償サブスクリプションが無いと閲覧できない領域にある。(内容は未確認)
System will not boot after p2v conversion : error can't find command ':' - Red Hat Customer Portal

VMware vCenter Converter Standalone 6.3 がリリースされていた

以前、VMware vCenter Converter Standalone がダウンロードできなくなっていて困った記事を書いた。

shobon.hatenablog.com


もう先月の事だけど、ついに、新しい VMware vCenter Converter Standalone がリリースされていた。

リリースノートはこちら。
docs.vmware.com


対応プラットフォームも変わっているので、要チェック。

SourceTree(Windows版)3.4.9で自動更新に失敗する

SourceTree(Windows版)3.4.9で更新通知が出ていたのでアップデートを試みたら、エラー発生。

エラーメッセージは以下の通り。

メソッドが見つかりません: 'Void
SharpCompress.Readers.IReaderExtensions.WriteEntryToFile(SharpCompress.Readers.IReader, System.String, SharpCompress.Readers.ExtractionOptions)'

環境としては、3.4.9→3.4.10への更新時にエラーになっている。

更新に失敗したせいか、SourceTreeを終了した後は、起動しなくなってしまった。
公式サイトから、SourceTreeSetup-3.4.9.exe を入手して再インストールすると、正常に起動した。(いったんアンインストールはしていない)

以下のフォーラムでも話題になっているが、
sourcetree app can't update


3.4.8では発生せず、3.4.9の自動更新時の問題っぽい。
Atlassian Teamの方から、3.4.10の直リンクが紹介されているので、それをインストールすれば良さげ。

公式サイトトップの「Download for Windows」のリンクは3.4.9のままで、何気に気持ち悪い。
(バージョンを3.4.10 に変えると、フォーラムにある直リンクURLと同じになる)

なお、3.4.10のリリースノート
SourceTree Release Notes

「Fixed: Sourcetree failed to update from 3.4.9 to latest version」と今回のエラーの修正も記載されている。


急ぎの場合は、フォーラムにあるよう直リンクから3.4.10を入手すると良い。
急ぎでないなら、SourceTreeの公式サイト・トップページのリンクが3.4.10以降になるのを待つべし。


【11/9追記】
11/9の夕方時点で、SourceTreeの公式サイト・トップページのリンク「Download for Windows」がバージョン3.4.10になっていた。
(いつから3.4.10に切り替わっていたかは不明)
自動更新で失敗する場合は、これをダウンロードしてインストールすれば解決すると思われる。

vCenter Converter のダウンロードは停止している

vCenter Converterのダウンロード情報を求めて検索すると当BlogもHITするようで、
過去に書いた下記の記事がHITする模様。
shobon.hatenablog.com



が、残念ながら、今年の2月に次のようなアナウンスがされており、ダウンロードが停止しています。
blogs.vmware.com


最後の一文を見ると、タイムラインは決まっていないものの、新しいバージョンに取り組んでいるようなので、暫く待つしかなさそう。

2022/11/22追記

VMware vCenter Converter Standalone 6.3 がリリースされています。

shobon.hatenablog.com

エラーページでJettyのバージョンを非表示にする

【環境】
・Jetty 9.4/10.0
ソースコード版(dnf 等でインストールするものではない)
Apacheのmod_proxyでJettyと連携


Jettyを扱う機会があった際、エラーページのバージョン表示が気になった。

404なページへアクセスした際、次のような画面が表示される。

下部に「Powered By」でバージョンが表示されるので、これを非表示にする方法を調べた。

Jetty 9.4の場合

${JETTY_HOME}/etc/jetty.xml を次のように修正する。

<Set name="sendServerVersion"><Property name="jetty.httpConfig.sendServerVersion" deprecated="jetty.send.server.version" default="true" /></Set>
   ↓
<Set name="sendServerVersion"><Property name="jetty.httpConfig.sendServerVersion" deprecated="jetty.send.server.version" default="false" /></Set>

Jetty 10.0の場合

${JETTY_HOME}/etc/jetty.xml を次のように修正する。

<Set name="sendServerVersion" property="jetty.httpConfig.sendServerVersion"/>
   ↓
<Set name="sendServerVersion"><Property name="jetty.httpConfig.sendServerVersion" default="false"/></Set>

10.0の場合は、9.4より設定が面倒。
近くにある 「jetty.httpConfig.sendDateHeader」の設定を参考に、「Property」を追加する。


いずれの場合も、設定変更後はサービスを再起動する。
(※systemctl で制御できる場合のコマンド例)

# systemctl restart jetty.service


なお、上記を変更すると、HTMLタグに表示されていたバージョンのほか、httpdヘッダに出力されていた

Server: Jetty(10.0.11)

の情報も出力されなくなる。


Jettyのバージョンは消えるが、標準では以下のようなヘッダが出力される(AlmaLinux、httpsの場合)。

Server: Apache/2.4.37 (AlmaLinux) OpenSSL/1.1.1k

こちらは、httpdの設定で「ServerTokens Prod」を指定すれば、バージョン情報等は削除され、

Server: Apache

となる。

SourceTreeでGitを更新したらエラーになった

Windows版のSourceTreeでGitのバージョンを更新したら、Gitのエラーが出た。


'git log' がコード128で終了しました: fatal; unsafe repository
(xxxxxxxxx is owned by someone else)

To add an exception for this directory, call:

git config --global --add safe.directory

エラーの最後の部分には、NASのパスが書いてあった。

これは、git 2.35.2から実装されたセキュリティ対策が影響しているらしく、
NAS上のGitリポジトリは「unsafe repository」ということらしい。

LANにある自分専用のNASなので、許可ディレクトリに追加して対処。

WindowsのSourceTreeなので、%UserProfile%\.gitconfig へ以下を追記した。

[safe]
        directory = 許可したいpath

Firefox98以降でPDF等をダウンロードせず開いた場合の挙動を従来に戻す

少し前の話になるけど、Firefox98でファイル(PDF等)を開いた場合の挙動が変わっていた話。
PDFをFirefoxの内部ビューワではなく、Acrobatなどで開いていると影響を受ける。


Firefox 97までは、
ファイルを開く場合はテンポラリフォルダに保存され、Firefoxを終了したらファイルが削除されていた。

Firefox 98からは、
ファイルを開く場合もダウンロードフォルダにファイルが保存されるようになった。


動作が変わった事を知らず、FirefoxでPDFへアクセスしてダウンロードではなく「開く」を選択していると、ダウンロードフォルダに大量のPDFが発生する。

従来の挙動に戻すには、about:config にて

browser.download.improvements_to_download_panel=false

に設定する。


参考
Firefox バージョン 98 におけるダウンロード処理方法の変更 | Firefox ヘルプ