RHEL 7以降で推奨されるパーティション設定スキーム

ちょっと大きめのメモリ構成にOSをインストールする機会があり、RHEL9のドキュメントを見た。
それより前と違いがあるか気になったのでメモ。

結論としては、推奨されるswapサイズは長らく変わっていない。
推奨されるパーティションサイズも、7～9までは同等で、6以前は異なる。

RHEL7以降（～現行は9まで）

/boot

• 最小限 1 GiB を推奨
• /boot/efi は、200MiB以上を推奨（BIOSシステムでは、EFIパーティションは不要）
• LVM ボリュームを /boot に使用できない。/ とは別にする必要あり。

/（ルート）

10GiB 以上を推奨

/home

最小限1GiB

swap

最小限1GiB

＜ハイバネートを許可しない場合の推奨swapサイズ計算式（単位：GB）＞
If RAM < 2
　Swap = RAM * 2
Else If 2 <= RAM < 8
　Swap = RAM
Else If 8 <= RAM < 64
　Swap = 4～RAM/2
Else If 64 <= RAM
　Swap = ワークロードによる（最小4GB）

＜計算例＞
物理メモリ[GB]    Swapサイズ[GB]
1                2
2                2
4                4
8                4
16               4 ～ 8
24               4 ～ 12
32               4 ～ 16
64               4 ～？

RHEL6

/boot

• 最小限 250MB を推奨
• /boot/efi は、50-150MB以上を推奨

/（ルート）

3-5GB 以上を推奨

/home

最小限100MB

swap

最小限256MB
ハイバネートを許可しない場合の推奨swapサイズ計算式は、RHEL 7以降と同じ。

参考

B.4. 推奨されるパーティション設定スキーム Red Hat Enterprise Linux 9 | Red Hat Customer Portal

E.4. 推奨されるパーティション設定スキーム Red Hat Enterprise Linux 8 | Red Hat Customer Portal

8.14. インストール先 Red Hat Enterprise Linux 7 | Red Hat Customer Portal

9.15.5. 推奨されるパーティション設定スキーム Red Hat Enterprise Linux 6 | Red Hat Customer Portal

AlmaLinux9 でcifsモジュールが無かったためマウントエラーになった

【環境】
$ cat /etc/redhat-release
AlmaLinux release 9.1 (Lime Lynx)

AlmaLinux9から、NASをCIFSマウントしようとしたら、エラーになった。

# mount -t cifs -o username=USER_NAME //192.168.1.20/hoge /mnt/path
Password for USER_NAME@//192.168.1.20/hoge:
mount error: cifs filesystem not supported by the system
mount error(19): No such device
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

cifs関連のパッケージを入れ忘れたかと思い確認すると、cifs-utilsパッケージはインストール済み。

# rpm -qa | grep cifs
cifs-utils-6.14-1.el9.x86_64

cifsモジュールの状況を確認すると、存在しなかった。

# lsmod | grep cifs
（何も表示されない）

# modinfo cifs
modinfo: ERROR: Module cifs not found.

カーネル周りで不足があると思い、AlmaLinux8 の方でパッケージを確認。
まずはkernelと名前のつくパッケージをリストアップ。

$ rpm -qa | grep kernel | grep $(uname -r)
kernel-core-4.18.0-372.19.1.el8_6.x86_64
kernel-modules-4.18.0-372.19.1.el8_6.x86_64
kernel-4.18.0-372.19.1.el8_6.x86_64

上記のパッケージにて、cifsというキーワードが含まれているものを確認。

$ rpm -ql kernel-core-4.18.0-372.19.1.el8_6.x86_64 | grep cifs
/lib/modules/4.18.0-372.19.1.el8_6.x86_64/kernel/fs/cifs

$ rpm -ql kernel-modules-4.18.0-372.19.1.el8_6.x86_64 | grep cifs
/lib/modules/4.18.0-372.19.1.el8_6.x86_64/kernel/fs/cifs/cifs.ko.xz　←これが欲しかったもの

$ rpm -ql kernel-4.18.0-372.19.1.el8_6.x86_64 | grep cifs
（何も表示されない）

AlmaLinux9 にて、kernel-modules パッケージが入っていなかったので追加。

# dnf install kernel-modules

AlmaLinux9でも、このパッケージにcifsモジュールが含まれている事を確認

# rpm -ql kernel-modules-5.14.0-162.18.1.el9_1.x86_64 | grep cifs
/lib/modules/5.14.0-162.18.1.el9_1.x86_64/kernel/fs/cifs/cifs.ko.xz

モジュールの詳細を確認

# modinfo cifs
・・・省略（詳細が表示）

これでcifsマウントできるようになった。

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は、
　１．/etc/default/grub で設定を変更する
　２．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

となる。