CentOS9 でKernel起動失敗 bad shim signature.
CentOS Stream 9において, kernel 5.14.0-171.el9.x86-_64 をインストールした際に、
error: ../../grub-core/kern/efi/sb.c:183:bad shim signature. error: ../../grub-core/loader/i386/efi/linux.c:259:you need to load the kernel first. Press any key to continue...
と表示されて起動しなくなりました。
Bootメニューで1つ前のカーネルを指定すれば起動しますが自動起動しなくなるので大変です。
原因はわかりませんがKernelを元に戻す方法を調べました。
上記を参考にしていますが、
まずは1つ前のカーネルで起動します。以下rootで操作しています。
# grubby --info=ALL | grep kernel kernel="/boot/vmlinuz-5.14.0-171.el9.x86_64" kernel="/boot/vmlinuz-5.14.0-168.el9.x86_64" kernel="/boot/vmlinuz-0-rescue-1549a6774d694c8db1fba3a18bab70eb"
171が起動しないカーネル。168が一つ前のカーネル（起動中）
168にデフォルトを変更します。
# grubby --set-default "/boot/vmlinuz-5.14.0-168.el9.x86_64" The default is /boot/loader/entries/1549a6774d694c8db1fba3a18bab70eb-5.14.0-168.el9.x86_64.conf with index 1 and kernel /boot/vmlinuz-5.14.0-168.el9.x86_64
問題のカーネル(-171)を消すためにインストール済みのリストを取得
この場合は、一番下の kernel-5.14.0-171.el9.x86_64 がそうですね。
# rpm -qa | grep kernel kernel-core-5.14.0-168.el9.x86_64 kernel-modules-5.14.0-168.el9.x86_64 kernel-5.14.0-168.el9.x86_64 kernel-tools-libs-5.14.0-171.el9.x86_64 kernel-tools-5.14.0-171.el9.x86_64 kernel-core-5.14.0-171.el9.x86_64 kernel-modules-5.14.0-171.el9.x86_64 kernel-5.14.0-171.el9.x86_64
問題のカーネルを消します。（171とつくcoreとmodulesも全部消すのが正しいかと。toolsは168がないので消さない方が良いのかな？とにかく復旧ならkernerlだけ消しとけばOK！問題の先送り！）
# dnf remove kernel-5.14.0-171.el9.x86_64
再起動すれば古いカーネルで正しく起動しました。
原因は不明ですが、再度インストールしても同じエラーがでたのでCentOS側の修正を待つか次のカーネルを待った方が良いと思います。
強いて言えば、今回は試しにCockpit経由で更新作業をしました。その後はコンソール側からdnf updateを行いましたが同じエラーが出ます。
自動アップデートにしてると再度インストールされてしまうので、カーネル(171)を消さない方がいいかもしれません。
(修正済) Geometry関数を利用する場合MariaDBを最新版にしてはいけない！
MariaDB 10.5.10 / 10.4.19 / 10.3.29 / 10.2.38 において
ST_DISTANCE_SPHERE 関数が追加されましたが
この関数が原因だと思われるバグが発生しています。
具体的には、ST_Contains / ST_Within の挙動がおかしくなっています。結構致命的です。
アップデートした途端に計算結果が異なったので調べたところ
SPATIAL indexのバグが再発しているのではないかとのことです。
10.5.9にすると正しい結果を返すようになりましたので10.5.10は避けた方が無難です。
こちらで同じ症状が報告されています。
[MDEV-13467] Feature request: Support for ST_Distance_Sphere() - Jira
再発したと思われるバグ（追記：これじゃないと思われる）
[MDEV-12462] SPATIAL index fails to work with CONTAINS - Jira
（追記）
私の環境で発生したのは、 WHERE ST_Contains(@point, @polygon) で、本来なら４件ヒットするはずが２件しかヒットしないという症状でした。
これは推測でしかないのですが、@polygonのデータ(ポイント数)が大きなデータにヒットしていない感じでしたので、そのあたりにバグが発生しているのではないかと思われます。@polygonはテキストエディタに貼り付けるだけでも大変なことになる大きさなので詳細検証はやっていません！
当初、計算が劇的に速くなったので感激していたのですが間違っていたら元も子もないです・・・。
(2021-07-20追記)
最新バージョンで修正されたようです。（未確認）
修正されたバージョン： MariaDB 10.6.2, 10.2.39, 10.3.30, 10.4.20, 10.5.11
予想通り大きなGeometryの場合にspatial indexに不具合が生じていたようです。
[MDEV-25758] InnoDB spatial indexes miss large geometry fields after MDEV-25459 - Jira
CentOS LVMをSSMで100%容量拡張する
いつも便利なSSM。
（以前の記事） CentOS7でLVM管理 SSM (System Storage Manager) - かぼちゃ日記
Volumeの容量が足りなくなってきた場合、HDDを追加してLVMで容量拡張をします。
容量を追加するときにsizeオプションで追加するのですが+300Gとしてもサイズが大きすぎます！
と毎回怒られて+299G追加して+20M追加して・・・とちまちまやっていたのですがいい加減面倒なので全部使い切る方法を調べました。（man ssm しただけ・・・）
CentOS 8だと以前のように認識をさせないでも起動中に自動的に新しいHDDを認識しました。（偶然かも知れない）
Vmware仮想マシンにおいて再起動せずにHDDを追加する - かぼちゃ日記
あと、下の例は記録を取ってなかったので容量表示は適当です。（実際は299.98Gとか表示される）
HDDを追加した後、現状を確認（rootになるかsudoつけて実行してね）
$ssm list ---------------------------------------------------------------- Device Free Used Total Pool Mount point ---------------------------------------------------------------- /dev/sda 16.00 GB PARTITIONED /dev/sda1 600.00 MB /boot/efi /dev/sda2 1.00 GB /boot /dev/sda3 0.00 KB 14.41 GB 14.41 GB cl_centos8 /dev/sdb 0.00 KB 300.00 GB 300.00 GB datapool /dev/sdc 0.00 KB 300.00 GB 300.00 GB datapool <= 追加されたHDD ---------------------------------------------------------------- --------------------------------------------------------- Pool Type Devices Free Used Total --------------------------------------------------------- cl_centos8 lvm 1 0.00 KB 14.41 GB 14.41 GB datapool lvm 2 0.00KB 300.00 GB 300.00 GB --------------------------------------------------------- ----------------------------------------------------------------------------------------------- Volume Pool Volume size FS FS size Free Type Mount point ----------------------------------------------------------------------------------------------- /dev/cl_centos8/root cl_centos8 12.81 GB xfs 12.80 GB 4.77 GB linear / /dev/cl_centos8/swap cl_centos8 1.60 GB linear /dev/datapool/data datapool 300.00 GB xfs 300.00 GB 63.51 GB linear /var/lib/mysql /dev/sda1 600.00 MB vfat part /boot/efi /dev/sda2 1.00 GB ext4 1.00 GB 780.77 MB part /boot -----------------------------------------------------------------------------------------------
HDDが追加されていることを確認したらPoolにHDDを追加します
$ssm add -p datapool /dev/sdc $ssm list ---------------------------------------------------------------- Device Free Used Total Pool Mount point ---------------------------------------------------------------- /dev/sda 16.00 GB PARTITIONED /dev/sda1 600.00 MB /boot/efi /dev/sda2 1.00 GB /boot /dev/sda3 0.00 KB 14.41 GB 14.41 GB cl_centos8 /dev/sdb 0.00 KB 300.00 GB 300.00 GB datapool /dev/sdc 0.00 KB 300.00 GB 300.00 GB datapool ---------------------------------------------------------------- --------------------------------------------------------- Pool Type Devices Free Used Total --------------------------------------------------------- cl_centos8 lvm 1 0.00 KB 14.41 GB 14.41 GB datapool lvm 2 300.00GB 300.00 GB 600.00 GB <= 使える容量が増えている --------------------------------------------------------- ----------------------------------------------------------------------------------------------- Volume Pool Volume size FS FS size Free Type Mount point ----------------------------------------------------------------------------------------------- /dev/cl_centos8/root cl_centos8 12.81 GB xfs 12.80 GB 4.77 GB linear / /dev/cl_centos8/swap cl_centos8 1.60 GB linear /dev/datapool/data datapool 300.00 GB xfs 300.00 GB 63.51 GB linear /var/lib/mysql /dev/sda1 600.00 MB vfat part /boot/efi /dev/sda2 1.00 GB ext4 1.00 GB 780.77 MB part /boot -----------------------------------------------------------------------------------------------
Poolの使える容量が増えていることを確認したらVolumeに容量を全部追加します
$ssm resize -s+100%USED /dev/datapool/data $ssm list ---------------------------------------------------------------- Device Free Used Total Pool Mount point ---------------------------------------------------------------- /dev/sda 16.00 GB PARTITIONED /dev/sda1 600.00 MB /boot/efi /dev/sda2 1.00 GB /boot /dev/sda3 0.00 KB 14.41 GB 14.41 GB cl_db1-11 /dev/sdb 0.00 KB 300.00 GB 300.00 GB datapool /dev/sdc 0.00 KB 300.00 GB 300.00 GB datapool ---------------------------------------------------------------- --------------------------------------------------------- Pool Type Devices Free Used Total --------------------------------------------------------- cl_centos8 lvm 1 0.00 KB 14.41 GB 14.41 GB datapool lvm 2 0.00 KB 599.99 GB 599.99 GB --------------------------------------------------------- ----------------------------------------------------------------------------------------------- Volume Pool Volume size FS FS size Free Type Mount point ----------------------------------------------------------------------------------------------- /dev/cl_centos8/root cl_centos8 12.81 GB xfs 12.80 GB 4.77 GB linear / /dev/cl_centos8/swap cl_centos8 1.60 GB linear /dev/datapool/data datapool 599.99 GB xfs 599.85 GB 363.51 GB linear /var/lib/mysql /dev/sda1 600.00 MB vfat part /boot/efi /dev/sda2 1.00 GB ext4 1.00 GB 780.77 MB part /boot -----------------------------------------------------------------------------------------------
これで容量が追加されました。
resizeの-sオプションには、下記が使えます（この備忘録はこれが言いたかっただけ）
-s100G //容量を100Gにする
-s+100G //容量を100G増やす
-s-100G //容量を100G減らす（いろいろ制限有り）
-s+80%USED //容量を80％使う
-s+20%FREE //容量を20%残す
もう-s+100%USEDしか使わないと思う。
CentOS 8 / esxi環境 で画面解像度が保存されないのをどうにかする
VMware esxi 7 (および6）においてCentOS8をインストールすると画面解像度が保存されません。
再起動すると800x600になってしまうのでかなり面倒です。
正しい解決方法は結局見つからなかったので対処療法ですが記録しておきます。
~~【問題点1】 CentOS8からX Window SystemがX.orgからWaylandにデフォルトが変更になった。
そもそもの元凶がこれだと思われます・・・。まだ人類には早すぎた（違）
解像度が保存されない原因は不明ですが、対処に利用したい解像度変更のxrandrコマンドがWaylandでは動きません。
~~【解決策1】Waylandを止める！
/etc/gdm/custom.conf
を編集します。コメントアウトだけで大丈夫のハズ
WaylandEnable=false
再起動したら、xrandrコマンドが動くか確認しましょう
# xrandr --output Virtual-1 --mode 1680x1050
xrandrを引数無しで実行すると認識している解像度一覧が出ます。
outputで指定しているVirtual-1（モニタ識別子）も表示されますので確認してください。（Virtual1だったりします）
このあたりはxrandrでぐぐればたくさん事例があると思います。
あとはこれを起動時に実行するだけですが・・・
/etc/gdm/Init/Default で実行するのが一番だと思います。
ログイン画面（GDM）の画面解像度 - つるながの綴り方
他にもいろいろ方法がありますが、/etc/profile.d/ にスクリプトを入れる方法は時間差がありすぎてダメでした。
~~【問題点2】/etc/gdm/Init/Default が実行されない！
これもWaylandがデフォルトになっている影響だと邪推しています。（Waylandではこれを使わないようなので）
正しく設定されているかどうかは、Defaultを直接実行してみれば判ります。解像度が正しく変更されれば大丈夫です。
これはバグのような気がするので直るのを待つのがいいのですが・・・
~~【解決策2】/etc/xdg/autostart/ で無理矢理実行する
解決策というか一時回避策です。
Gnomeの起動時に実行するように設定します。
[Desktop Entry] Type=Application Name=GNOME run Default Exec=/etc/gdm/Init/Default OnlyShowIn=GNOME; NoDisplay=true;
ファイル名は最後に.desktopが付いていれば何でも良いです。 gnome.run.default.desktop とか。
これを /etc/xdg/autostart/ に置きます。ユーザー個別にしたいときはそれぞれで設定して下さい（省略）
これでログイン時にDefaultが実行されて解像度が変更されました。
ログイン画面はDefaultが正しく実行されないので800x600のままです。
もしバグ修正が行われれば、ログイン画面から指定解像度になると思います。そのときは.desktopを消せば良いかと。
また、Waylandがまともに動くようになればそちらに移行するのが一番かと思います。
Windows Server 2019 (ハードウェアRAID vs 記憶域プール)
Domain Controllerのリプレースを計画中です。
Windows Server 2012R2 から Windows Server 2019 へ移行予定です。
普段Windows Serverを利用しないので新機能についていけずいろいろ調べた結果の備忘録です。
第2回目は、ストレージについてです。
結論としては、現状ではケースバイケースです。
風潮的にハードウェアRAIDは、消えていく存在なのかもしれません。
まずこれは、Domain Controllerではなく、ファイルサーバを兼任する場合の前提です。
以前も書きましたが、Windows Serverの記憶域プールは、ハードウェアRAIDだと設定できません。（認識しない）
HBAモードをサポートするRAIDカード等が必要となります。
DELLのサーバだと13世代（PowerEdge 430等）以降のRAIDカード(Perc H330 / H730等)からサポートされます。
H730だと、カード全体をHBAモードにしたり、ドライブ毎にRAID/HBAを切り替えることもできます。
なお余談ですが、12世代(H710等)で存在したCachecade機能は廃止されました。広く利用されず、混乱を生んだためとDELLの返答がありますね。
Solved: ssd cashe on h730p - Dell Community
この機能はRAIDカード単体で、SSDをHDDのキャッシュとして利用するものでした。この機能が残っていればハードウェアRAIDを採用したんですが。
このCachecadeと同じ様な機能を記憶域プールが持っているので、そちらを利用しましょうということらしいです。
ここで、同じ様なと書いたのは類似機能が２つあるためです。
- 階層記憶域
- 記憶域スペース ダイレクト （S2D）
Cachecadeと同じキャッシュ機能を考えた場合、S2Dが必要となりますが、この機能はWindows Server 2019 Datacenterのみで利用可能です。Standardでは利用できません。
機能的にも、ハイパーコンバージドを構築するもので高機能です。ただのDCにここまで費用はかけられません。
記憶域スペース ダイレクトの概要 | Microsoft Docs
階層記憶域は、厳密にはキャッシュ機能ではなくファイル配置を最適化する機能です。
標準で1GB（コマンド設定で推奨最大16GB）をWriteCacheとしてSSD層に確保しますのでこの部分はキャッシュ機能といえます。
Windows Server 2012 R2 の記憶域スペースは、Write-Back Cache と 記憶域階層 をサポート
階層記憶域の挙動としてはSSD層に書き込んでいき、いっぱいになったらHDD層に書き込み、1日1回SSD層とHDD層の整理をするといった挙動のようです。
Windowsの記憶域階層の挙動（SSD層が優先的に使われるよ） [クソゲ〜製作所]
しかし、同じ方がSSD層がいっぱいになった際にパフォーマンスが大幅低下するとも報告されています。（私は確かめてません）
Windowsの記憶域階層な共有フォルダがプチフリする謎現象 [クソゲ〜製作所]
さらに、記憶域プールのParityは書き込みが非常に遅いようです。階層記憶域を利用するか、別途SSDをJournalディスクとして追加すると改善されるようですが、HDDだけで運用する場合は注意が必要です。H730であればハードウェアRAIDにするべきでしょう。
小容量SSDは、記憶域プールのJournalディスク（パリティ利用時）にしてしまおう
階層記憶域の作り方
SSDとHDDで階層記憶域を構築し、安価で高速なストレージを構築する | しょぼんブログ
補足：GUIでも単純なものは作れますがParityは選択肢にでませんでした。
また、Windwos Server 2019だとコマンドは同一ですが、New-StorageTierコマンドの結果が異なりました。
PS C:\WINDOWS\system32> Get-StoragePool StoragePool | New-StorageTier -FriendlyName CacheTier -MediaType SSD FriendlyName Usage TierClass MediaType ResiliencySettingName PhysicalDiskRedundancy Size FootprintOnPool StorageEfficiency ------------ ----- --------- --------- --------------------- ---------------------- ---- --------------- ----------------- CacheTier Data Unknown SSD Mirror 1 0 B 0 B
また、いろいろと作成実験をしていますが、ハードウェアRAIDと比べてディスク追加やモード切替（MirrorからParity等）が後で行えないものが多いようです。
ハードウェアRAIDの方が、RAIDモード切替やディスク追加、障害時復旧等が楽だと思います。
逆に、SSDの寿命を確認するために専用ソフト等を利用する場合は、ハードウェアRAIDを通すとSMARTデータが取得できないので苦労します。（DELLの純正SSDだと管理画面で確認できます。高すぎて手が出ませんが）
まだ最終結論に至っていないのですが、HDDはハードウェアRAIDでRAID5/6、SSDはHBA/NVMeで直接接続、場合によってはそれらのディスクを記憶域プールでまとめてもいいですが、SSDも安くなってきたので個別ドライブで運用を工夫するのが現状での最適かもしれません。
Windows Server 2019 (NTFS vs ReFS)
Domain Controllerのリプレースを計画中です。
Windows Server 2012R2 から Windows Server 2019 へ移行予定です。
普段Windows Serverを利用しないので新機能についていけずいろいろ調べた結果の備忘録です。
まずは題名にあるNTFSとReFSのどちらを採用するべきか！
私の環境では、結論から言うと「NTFS」でした。
ReFSは耐障害性が高く新しいフォーマットなので利用したくなりますが、バックアップ周りでサポートされていないことが多いと感じました。
今回は、「Azure Backup」を利用する予定ですが、まさに「ReFS」はサポート外です。
nasunoblog.blogspot.com
詳細は上記サイトを見ていただくとして、2014年の記事でWindows Server 2012R2の時代なので、そろそろサポートされているだろうと試してみましたが、2019と現状のAzureでもやはりサポート外のようです。記事にあるサポート情報のリンクは既に利用できず、詳細をAzureやネットで調べても明記されている場所を見つけられないんですけどね。
CentOS 7 (GRUB2) でKernel Parameterを変更
CentOS 7をコンソールで利用していると、画面がブランクになったり、解像度が気に入らなかったり、不便なことが多いので変更しましょうという話
CentOS 7の場合、/boot/grub2/grub.cfg を変更するとKernel Parameterを変更できます。
ただし、このままだとKernelがUpdateされたときに元に戻ってしまうのかな？
/etc/default/grub を編集するのが正しいらしいです。
GRUB_CMDLINE_LINUX="ここにパラメータ(スペース区切り)"
- 画面サイズ vga=771 または video=800x600 (後者が最新手法？)
- ブランクにしない consoleblank=0
- 起動時に詳細表示 quiet を削る
編集が終わったら
grub2-mkconfig -o /boot/grub2/grub.cfg
