Linux / Unix / Interix」カテゴリーアーカイブ

Hyper-V の第2世代で Linux の起動ログを追いかける

どうも、みむらです。

Hyper-V 上で Linux を動かすかとやっていたのですが
内部で起動がコケてしまって、その追跡にとても時間が掛かったのでそのメモです。

1.COM ポートを生やす

PowerShell で “Set-VMComPort” コマンドを使うことで生やせます。

Set-VMComPort (Hyper-V) | Microsoft Learn
https://learn.microsoft.com/en-us/powershell/module/hyper-v/set-vmcomport

Set-VMComPort -VMName "Gentoo Linux" -Number 1 -Path \.\pipe\vm_debugcom

-VMName は VM 名、 -Number は 1を最小値として ttyS0 に当たっていきます。

2. COM を見る

手っ取り早いのが PuTTY です。
管理者権限で起動した PuTTY で、名前付きパイプの文字列をそのまま入力すると繋いでくれます。

その後、起動オプションに CONSOLE の設定を入れて起動します。
サンプルとしては下記のような感じです:

linux /vmlinuz-6.5.4-gentoo console=ttyS0,9600
boot

3.ログを眺める

コンソールの内容が PuTTY 側に流れてきます。

今回の場合はどうやら “noxsave” を入れれば治るらしいのですが、
気持ち悪いので原因調査をしてみます。


“XSAVE has to be disabled as it is not supported by this module” ということで、
これで検索を掛けて見ると、下記のパッチが見つかります。

https://lwn.net/ml/linux-kernel/1678386957-18016-3-git-send-email-ssengar@linux.microsoft.com/

コードを抜粋するとまさにこんな感じ。

+++ b/arch/x86/hyperv/hv_vtl.c

+static int __init hv_vtl_early_init(void)
+{
+	/*
+	 * `boot_cpu_has` returns the runtime feature support,
+	 * and here is the earliest it can be used.
+	 */
+	if (cpu_feature_enabled(X86_FEATURE_XSAVE))
+		panic("XSAVE has to be disabled as it is not supported by this module.\n"
+			  "Please add 'noxsave' to the kernel command line.\n");
+
+	real_mode_header = &hv_vtl_real_mode_header;
+	apic->wakeup_secondary_cpu_64 = hv_vtl_wakeup_secondary_cpu;
+
+	return 0;
+}

調べてみると、 “Enable Linux to boot in VTL context” という項目を発見。

切ってみたところ、正常に起動しました。


というわけで、第2世代でコンソールを生やして中身を追いかける話・・でした!
エラーメッセージを見れば一撃なんですけど、ここにたどり着くまでに数時間溶かしてしまったので、まだまだ精進します、、、💦

ElasticSearch OSS / OpenSearch の Beats が “runtime/cgo: pthread_create failed: operation not permitted” で落ちるのを直す

どうも、みむらです。

某所の監視に Wazuh ( https://wazuh.com/ )をよく使っているのですが
内部的に ElasticSearch OSS 7.10.2 を使っているため、新しすぎる OS 上で動かそうとすると filebeat が下記のように落ちてしまうことがあります

runtime/cgo: pthread_create failed: Operation not permitted

もちろん、この問題は新しいバージョンの Beats では解決されているのですが
他方で 7.13 以降の Beats は OpenSearch 1.x や Elasticsearch OSS などで使えないという問題があります。

https://opensearch.org/docs/latest/clients/agents-and-ingestion-tools/index/

この問題については、下記のコメントにあるように elasticsearch 側もアップデートすることが推奨されていますので、公式に解決される可能性は低そうです。

https://github.com/elastic/beats/pull/26305#issuecomment-863472649

枯れたものを使え、公式でサポートしていないディストリビューションを使うな、というのは一理あるのですが、その方法で回避するのは面白くないですので、修正含めてやってみました。

(wazuh のサポートで解決している例が見当たらなかったこともあり、最初だけ英語で併記します。)

注意:

修正は自己責任でお願いします。本番用環境に対して独自ビルドを行ったものを適用したことにより問題が発生しても当方では責任を負えません。


落ちる原因 (Cause):

“clone3” のシステムコールが seccomp の許可リストに登録されていないため。
en : The systemcall “clone3” is not allowed by seccomp.

glibc 2.34 以降において、 pthread_create() を呼び出す際に clone3 システムコールが用いられるようになったことが原因となっています。

修正方法 (Solution):

libbeat/common/seccomp 以下の “policy_linux_386.go” と “policy_linux_amd64.go” に “clone3” を追記する
en: Add “clone3” to policy_linux_386.go and policy_linux_amd64.go under libbeat/common/seccomp.

具体的な追加内容については、まさしく当該する patch がありますのでこれに従います。
https://github.com/elastic/beats/commit/82507fda20bee46cee4808d388a0c809dd01ff13

また glibc 2.35 以降では “rseq” システムコールも用いるそうですので
こちらも併せて対応しておくとよいと思います。
en: It is a recommend to also add “rseq” to policy_linux_386.go and policy_linux_amd64.go under libbeat/common/seccomp, due to the syscall is used glibc >= 2.35.

https://github.com/elastic/beats/commit/f02fa32e0a37d6529983e2181b80bf62e4a16b41


実際にやってみる

実際に上記のパッチを当てて問題が解決するか確認してみました。

確認環境 : Fedora 36 x86_64

続きを読む

CentOS から Fedora に直接アップグレードしてみる

どうも、みむらです。

気がついたら 2022 年になっていましたし、オリンピックも終わっていました。
年が進むのは早いものですね。

同じく年が早いと気づかされたものとして、CentOS Linux 8 のサポート切れがあります。

CentOS Stream 8 にアップグレードしましょう、という話もありますが、
“Stream” は RHEL の “Nightly” の立ち位置になっていますし、
今までのRHEL 互換を求めるなら、Alma Linux Rocky Linux に切替えていくのが正しいように見えます。

Fedora/CentOS Stream/CentOS/RHELの関係性 – 赤帽エンジニアリングブログ
https://rheb.hatenablog.com/entry/202007-fedora-distribution

GitHub の CentOS などから Alma Linux に移行するためのツール (Almalinux-deploy):
https://github.com/AlmaLinux/almalinux-deploy

上記の移行ツールの使用について日本語で書かれた記事:
https://www.server-memo.net/memo/centos8_to_almalinux.html

他方、 CentOS Stream 9 からミラーが変わるようで、
執筆時点 (2022/01/17) では日本のサーバがなく寂しい所でもあります。

CentOS Stream 9 Mirror list:
https://admin.fedoraproject.org/mirrormanager/mirrors/CentOS

今実験用に稼働させているサーバのひとつが CentOS なのですが、
実験用ですし CentOS Stream が “Nightly” の立場に変わるのであれば、
更に上流の Fedora にアップグレード出来るのではないか・・と試してみました。


注意:
下記の手法を試したことにより生じた損害や被害などは当方では全く関知しません。
また、公式ではない方法かつ危険が伴う可能性もあるため、バックアップ等を取り、リスクを取ることが出来る環境でのみお試しください。


続きを読む

Ubuntu 19.10 で Hyper-V の Enhanced Mode を有効にする (Enable the Enhanced Mode with Ubuntu 19.10)

どうもみむらです。

Ubuntu を Hyper-V で使用していると、
起動時に高確率で GUI 起動待ちになって何も操作できなくなったり
( Ctrl + Alt + Function Key での切り替えしてもログイン画面が出てこない )
そもそも Enhanced Mode が使えなくて色々と不便でしたので、
有効にするスクリプトを作成しました。


Hi I’m Mimura.

I make a script to enable the “Enhanced Mode” on Hyper-V with “Ubuntu 19.10”.
Also, it fix an issue that to fail to start X.


Script:

下記からダウンロードできます。 / you can download from this link:
https://gist.github.com/mimura1133/a6aebf4945b6688d1a5aedffdfa9368c


How does it works / どういう仕組みか:

このスクリプトは、
Microsoft が提供している Enhanced Mode を有効にするスクリプトを元に
作成されています。

https://github.com/microsoft/linux-vm-tools/tree/master/ubuntu/18.04

最近の Ubuntu では Wayland を最初に使用しようと試みます。

上記のスクリプトでは、 Xorg を使うようにできているため、
Wayland を利用しないようにする処理を追加し、
Enhanced Mode を Xorg 経由で使えるようにしました。

# Stop to use wayland.
sed -i_orig -e 's/#WaylandEnable=false/WaylandEnable=false/g' /etc/gdm3/custom.conf

また、どうやら Ubuntu に入っている Wayland と Hyper-V が相性が悪いらしく
時々起動に失敗する(コンソール経由のログインも受け付けない状態になる)のですが
Wayland を無効にすることで、確実に起動できるようにもなります。

(Arch Linux に入れたときには上手く動いていたので、 Ubuntu の問題だと個人的には思ってます..)


this script based on Microsoft’s.
https://github.com/microsoft/linux-vm-tools/tree/master/ubuntu/18.04

Recent versions of ubuntu are try to use a Wayland before using Xorg.
So, I added a code to disable to use Wayland.

# Stop to use wayland.
sed -i_orig -e 's/#WaylandEnable=false/WaylandEnable=false/g' /etc/gdm3/custom.conf

In addition, the Wayland and Hyper-V seem to be incompatible, sometimes fail to boot,
but the issue is fixed at the same time by disabling wayland.


Ubuntu の最新版が Enhanced Mode でサクサク動いて、コピペも出来るようになりますし、
同じように Kal Linux でも Enhanced Mode が使えるようにするものも公開していますので
Linux を Hyper-V で使っている方は、是非お試しくださいませー。

I have also released another versions for Kali Linux.
Please feel free to use the script if you’re using Linux on Hyper-V.

Git Repository (Forked from Microsoft):
https://github.com/mimura1133/linux-vm-tools

Windows と Linux の和暦対応

どうも、みむらです。
しばらく記事を書かない間に、新暦が発表され、
そして私も会社が変わってしまいました。
 
最近はアプリ診断員にジョブチェンジしました。
IDA さんが友達です。

特に最近は iOS アプリを見ているので、
フォレンジックネタとか iOS に関するセキュリティ診断ネタであれば、
凄く話に乗れると思います。

それ以外には、Unity のアプリとか (lib2cpp の読み解きとか)
Windows ならユーザランドからカーネルランドまで。お話まってます。


閑話休題。

新暦と言えば、やはり新暦対応でしょう。
私も新暦が発表された直後から「なんとしても対応しよう」と遊んでました。

画像
(from : https://twitter.com/mimura1133/status/1112566297135480838/ )

などなど。
 
今回は、もし「令和じゃない元号にします」と発表があった際に
素早く手持ちの環境を自己責任において対応させられるように
(要出典)
Windows と Linux の対応の仕組みを見ておこう
、とそういうテーマです。

 


Windows 側での対応

Windows の場合はレジストリキーを追加します。

(注:本修正を実施した事によりご利用中のプログラムに不具合が発生しても本サイトは責任を負いかねますと共に、くれぐれもプログラムの製造元へ連絡されませんようお願い致します)

 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras 以下に
年号情報が詰まっていますので

REG_SZ 型にて
キー名:”<開始年> <開始月> <開始日>”
値:”<フル読み>_<代表する一文字>_<英語表記>_<英語短縮表記>”

のフォーマットにてキーを生成すれば OK のようです。

 

この値を設定すると、
この値を参照しているプログラムの処理系であれば
基本的に新年号に対応出来るようになります。

画像

 


Linux (glibc) での対応

Linux の場合は locale ファイルを修正します。

(注:本修正を実施した事によりご利用中のプログラムに不具合が発生しても本サイトは責任を負いかねますと共に、くれぐれもプログラムの製造元へ連絡されませんようお願い致します)
 

locales ファイルは下記のパスに保存されています。
(Arch Linux, CentOS 7 にて確認)

/usr/share/i18n/locales/ja_JP

 
修正するのは、”era” の部分。

「○○元年」(+1 で始まるレコード)と「○○年」(+2 で始まるレコード)
を用いて年号の変換を行います。

そして年号は UTF-16BE の順番で書いていきます。

リトルエンディアンでの「令和」のバイト列

できあがった例は次の通り

新しい年号に対応させた ja_JP ファイル.

1つめの “+:1:2019//05//01:2019//12//31:<U4EE4><U548C>:%EC<U5143><U5E74> は
2019年5月1日~2019年12月31日までを「令和(<4EE4><548C>) 元年(<5143><5E74>)」

表記するというもの。

2つめの “+:1:2020//01//01:+*:<U4EE4><U548C>:%EC%Ey<U5E74> は
2020年1月1日以降を「令和(<4EE4><548C>) %Ey(+2)年(<5E74>)」

表記するというものになります。

ですので上記のような ja_JP ファイルを作成し、locale-gen をすると
下記のように新暦に対応することができます。

新暦対応後の図

 


最後に。

Windows や Linux のシステムがかなり柔軟に新暦対応させられる作りになっていることはおわかりいただけたかと思います。
 
ただ、これは一人のソフトウェア作者としてのコメントではありますが
全てのプラットフォームが上記で挙げたような簡単な方法で
すぐ対応出来るようになっているわけではありません。

 
また、上記のようなレジストリキーやファイルを参照するものであっても
(平成)31年から(令和)1年へ変わるわけですので
エラーが発生するシステムも十二分に考えられます。
 
ですので上記の方法で対応ができ、
ご利用のソフトウェアで問題なく稼働した場合でも
これは運が良かったという程度にお考えいただき、
ベンダーの正式対応を基本的にはお待ちいただくようにしてください。
 
上記のリスクにご理解いただけるかたで、新しいものに楽しみを感じるかたは
ぜひ自己責任において新暦対応を一足お先にお試しくださいませ。
なお、それによりデータ破損等が発生しても当方では責任を負いかねます。

・・というわけで。であであー。