あなたはプロのキャラクターデザイナーです。 添付されたキャラクター画像を分析し、以下の条件に従ってキャラクターシート（四面図）を生成してください。 # 条件 - 視点: 正面、背面、左側面、右側面を正確に描画してください。 - デザインの一貫性: 髪型、服装、アクセサリー（特にリボンの位置、形状、大きさ）を含むすべてのデザイン要素を、元の画像に忠実に、かつすべての視点で矛盾なく再現してください。 - ポーズ: すべての視点で自然なAポーズにしてください。 - 出力形式: 4つのビューを1枚の画像内にグリッド状に配置し、背景は白で統一してください。
すげーーー
MariaDBサーバーをインストールして接続しようとすると、
ERROR 2026 (HY000): SSL connection error: unknown error number
が出て接続できない。SSLとか使ってないし無効化したい。
/etc/my.cnf もしくは /etc/mysql/mariadb.conf.d/99-disable-ssl.cnf などに以下追記
[mysqld] skip-ssl
skip-ssl は文字のごとくサーバーの TLS サポートを無効化して、すべて平文接続として扱うオプションである。
systemctl restart mysqlで再起動すれば設定が反映され、接続できるようになるはず。
ローカルから mysql -u root -p -h 127.0.0.1 でつなぐときに同じエラーが出る場合、クライアント側でも TLS を無効化する必要がある。
/etc/mysql/mariadb.conf.d/99-disable-ssl-client.cnfなど作成して以下追記
[client] skip-ssl disable-ssl-verify-server-cert
以下の記事がMariaDBの仕様変更についてよくまとまっている。
これを見ると11.4 LTSからSSLデフォルト有効の挙動になった模様。
とある件で systemd-analyze blame コマンドで起動時の各サービス実行時間見てたら fstrim.service も長かった。
❯ sudo systemd-analyze blame|head 1min 20.745s fstrim.service
SSDのトリムのサービスらしい。SSDのトリムについては以下
どうもこれが定期実行だけではなく起動時にも実行されてしまっているらしい。なんで？？？
確認してみる。実行頻度は確かに１週間に１回で問題なさそうだが、
❯ systemctl cat fstrim.timer # /usr/lib/systemd/system/fstrim.timer [Unit] Description=Discard unused filesystem blocks once a week Documentation=man:fstrim ConditionVirtualization=!container ConditionPathExists=!/etc/initrd-release [Timer] OnCalendar=weekly AccuracySec=1h Persistent=true RandomizedDelaySec=100min [Install] WantedBy=timers.target
Persistent=true
となっている。systemd で単に weekly と書くと、通常は 月曜日の午前0時0分 を指す。 もし月曜日の夜中にパソコンの電源を切っていて、実行タイミングを逃してしまったとしても、「次回起動した時にすぐに実行する」 となってしまう。いやそこまで必須じゃない。。。
ということで起動時必須を無効化したい。
sudo systemctl edit fstrim.timer
今回はタイマーの設定なので daemon-reload は不要。
❯ systemctl show fstrim.timer -p Persistent Persistent=no
❯ systemctl cat fstrim.timer # /usr/lib/systemd/system/fstrim.timer [Unit] Description=Discard unused filesystem blocks once a week Documentation=man:fstrim ConditionVirtualization=!container ConditionPathExists=!/etc/initrd-release [Timer] OnCalendar=weekly AccuracySec=1h Persistent=true RandomizedDelaySec=100min [Install] WantedBy=timers.target # /etc/systemd/system/fstrim.timer.d/override.conf [Timer] Persistent=false
これでよし
Ubuntuの起動がめっちゃ遅い。１０分以上かかる。 ディスクの障害かと思ってたけど起動後は普通に速い。
そこでsystemd-analyze blame コマンドで各サービスの起動にかかる時間調査したら systemd-tmpfiles-setup.service にめちゃくちゃ時間かかっていた。
systemd-tmpfiles-setupはOSが起動する時に一時的なファイルやディレクトリ」を作成・削除・管理する役割 を持っているサービス。起動時に/tmpが空っぽなのはこのサービスのおかげだったってわけ。 今回問題になったサーバーは/tmpにファイルが大量にあったため削除に時間がかかってしまったんだと思われる。
デフォルトタイムアウトが無制限なのでタイムアウトを設定する。
❯ sudo systemctl edit systemd-tmpfiles-setup.service
エディターが起動するので以下追記
[Service] TimeoutStartSec=120s
以下のように表示されればOK
Successfully installed edited file '/etc/systemd/system/systemd-tmpfiles-setup.service.d/override.conf'.
設定を反映
sudo systemctl daemon-reload
確認
❯ systemctl show systemd-tmpfiles-setup.service -p TimeoutStartUSec TimeoutStartUSec=2min
母艦がUbuntuで、VirtualBoxの起動に失敗してしまうようになってしまった。vagrant経由だが以下の様なログ
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'bento/ubuntu-24.04' version '202510.26.0' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
default: Adapter 2: bridged
==> default: Forwarding ports...
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Configuring storage mediums...
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["startvm", "2cac2f5a-f62b-4cc9-9799-5d3036899b40", "--type", "headless"]
Stderr: VBoxManage: error: VirtualBox can't operate in VMX root mode. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_VMX_IN_VMX_ROOT_MODE)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole
「VirtualBox can't operate in VMX root mode. Please disable the KVM kernel extension … (VERR_VMX_IN_VMX_ROOT_MODE)」が該当のエラーっぽい
「VirtualBox can't operate in VMX root mode. Please disable the KVM kernel extension … (VERR_VMX_IN_VMX_ROOT_MODE)」だが、 Linux側でKVMモジュールが先に VT-x/AMD‑V を占有している状態で VirtualBox を起動したときに出るエラーらしい。
Ubuntu 24.04 以降＋新しめのカーネルでは、KVM モジュールがロードされた時点で自動的に仮想化機能をつかみに行く仕様になっていて、VirtualBox と競合してしまった、というわけ。
KVM モジュールをアンロードして起動できるか確認
sudo rmmod kvm_intel
を実行して起動できればKVM モジュールが問題と言って間違いない。
とはいえ母艦起動時に毎回rmmodするわけにはいかないので恒久的な設定がしたい。
/etc/modprobe.d/VBox-NoKVM.confを新規作成して以下
# Prevent KVM from grabbing virtualization on load for VirtualBox options kvm enable_virt_at_load=0
initramfsを再生成
sudo update-initramfs -u
これで母艦を再起動すれば起動時にKVM が VT-x/AMD‑V を握らないようになって、VirtualBox が VMX root mode に入れるようになるはず。
kvm_intel / kvm_amd を完全ブラックリストにしてしまう例もあるけれど、 その場合 KVM/QEMU を使えなくなるから、まずはこの「enable_virt_at_load=0」方式のほうが無難
# /etc/modprobe.d/blacklist.conf blacklist kvm_intel
