はじまりの「は」

ServerA（バックアップ元）からServerB（バックアップ先）へ、SSH鍵認証を用いたrsyncバックアップを行う手順を解説します。

手順1：ServerAでSSH鍵ペアを作成する 

まず、ServerAで認証に使用するための「秘密鍵」と「公開鍵」を作成します。バックアップを自動化（cronなど）する場合は、パスフレーズを空にして作成するのが一般的です。 

bash

# ServerA で実行
ssh-keygen -t ed25519 -f ~/.ssh/id_rsync_backup

• -t ed25519: 現在最も推奨される高速かつ安全なアルゴリズムです。
• -f: 鍵の名前を指定します。 

手順2：ServerAの公開鍵をServerBに登録する

ServerAで作成した「公開鍵（.pub）」の内容を、ServerBの authorized_keys ファイルに追記します。 

bash

# ServerA から ServerB へ公開鍵を転送（パスワードが一度聞かれます）
ssh-copy-id -i ~/.ssh/id_rsync_backup.pub ユーザー名@ServerBのIP

手順3：rsyncコマンドでバックアップを実行する

rsync実行時に、手順1で作成した秘密鍵を指定して実行します。 

bash

# ServerA で実行
rsync -avz -e "ssh -i ~/.ssh/id_rsync_backup" /コピー元/ディレクトリ/ ユーザー名@ServerBのIP:/コピー先/パス/

• -a: アーカイブモード（権限やタイムスタンプを維持）。
• -v: 進行状況を表示。
• -z: データを圧縮して転送。
• -e "ssh -i ...": 使用する秘密鍵を明示的に指定します。 

注意点

• パーミッション: .ssh ディレクトリは 700、authorized_keys ファイルは 600 である必要があります。不適切だと認証に失敗します。
• –dry-run: 本番実行の前に --dry-run オプションを付けて、どのファイルが転送されるか確認することをお勧めします。 

このバックアップを定期的に自動実行させたい場合は、crontab に上記のrsyncコマンドを登録してください。 

次は、特定の時間帯に自動実行するための cron設定 について詳しく説明しましょうか？

Raspbian Busterは2024年6月末に長期サポート(LTS)が終了し、公式リポジトリからReleaseファイルが削除されたため、通常のアップデートは実行できません。セキュリティリスクを避けるため、最新のRaspberry Pi OSへクリーンインストールして移行することが強く推奨されます。どうしても現在の環境を維持する必要がある場合は、リポジトリの設定をアーカイブ用(legacy.raspbian.org)へ書き換えることで対処できます。

macOS標準のコマンド sips を使用したシェルスクリプトで、ご要望の動作を自動化できます。 

以下のスクリプトは、1920px（または1080px）を超える画像のみをフルHDにリサイズし、元の大きなファイルは originals フォルダへ移動します。 

サンプルスクリプト

デスクトップなどに resize_images.sh という名前で保存して使用してください。 

bash

#!/bin/bash

# 元ファイルを退避するフォルダ名
ORIGINAL_DIR="originals"
mkdir -p "$ORIGINAL_DIR"

# フォルダ内のjpgファイルをループ処理
for file in *.jpg *.JPG *.jpeg; do
    # ファイルが存在しない場合はスキップ
    [ -e "$file" ] || continue

    # 画像の幅と高さを取得
    width=$(sips -g pixelWidth "$file" | awk '/pixelWidth/ {print $2}')
    height=$(sips -g pixelHeight "$file" | awk '/pixelHeight/ {print $2}')

    # 幅が1920より大きい、または高さが1080より大きいか判定
    if [ "$width" -gt 1920 ] || [ "$height" -gt 1080 ]; then
        echo "Processing: $file (${width}x${height})"
        
        # 元ファイルをoriginalsフォルダに移動（バックアップ）
        mv "$file" "$ORIGINAL_DIR/"
        
        # originalsフォルダに移動した元ファイルを元に、フルHDサイズ(長辺1920)でリサイズ
        # -Z はアスペクト比を維持して指定ピクセル内に収めるオプション
        sips -Z 1920 "$ORIGINAL_DIR/$file" --out "$file"
    else
        echo "Skipped (Small enough): $file (${width}x${height})"
    fi
done

echo "完了しました。"

使い方

1. ターミナルを起動します。
2. 対象の画像が入っているフォルダに移動します。
   • cd /path/to/your/folder （フォルダをターミナルにドラッグ＆ドロップするとパスが入力されます）
3. 上記のスクリプトをコピーして実行するか、保存したファイルを実行します。
   • 直接実行する場合：上記コードをコピーしてターミナルに貼り付け、Enterキーを押します。
   • ファイルとして実行する場合：sh resize_images.sh と入力します。 

ポイント

• sipsコマンド: macOS標準搭載のため、追加インストールは不要です。
• アスペクト比維持: -Z 1920 を使うことで、横長なら幅1920px、縦長なら高さ1920pxに収まるよう自動調整されます。
• 安全設計: 最初に mv で元ファイルを別フォルダに移してからリサイズを実行するため、上書きミスを防げます。 

処理したいファイルの拡張子（.JPGや.jpegなど）が混在している場合でも、スクリプト内のループ対象に含まれているため一括で処理可能です。 

このスクリプトを特定のフォルダ名に合わせて調整したり、リサイズ後の画質を指定したりしますか？

画質調整は不要ですが、フォルダ名を変えて実行したいです。

フォルダ名をスクリプトの冒頭で簡単に変更できるように書き換えました。

SAVE_DIR の値を好きな名前に変えて実行してください。

修正版スクリプト

bash

#!/bin/bash

# --- 設定：元ファイルを移動させるフォルダ名 ---
SAVE_DIR="バックアップ用フォルダ"
# ------------------------------------------

mkdir -p "$SAVE_DIR"

for file in *.jpg *.JPG *.jpeg; do
    [ -e "$file" ] || continue

    # 画像のサイズを取得
    width=$(sips -g pixelWidth "$file" | awk '/pixelWidth/ {print $2}')
    height=$(sips -g pixelHeight "$file" | awk '/pixelHeight/ {print $2}')

    # フルHD（1920x1080）を超えているか判定
    if [ "$width" -gt 1920 ] || [ "$height" -gt 1080 ]; then
        echo "リサイズ中: $file"
        
        # 1. 元ファイルを指定のフォルダへ移動
        mv "$file" "$SAVE_DIR/"
        
        # 2. 移動した元ファイルを読み込み、現在の場所にリサイズ版を出力
        # -Z 1920 は長辺を1920pxに合わせます
        sips -Z 1920 "$SAVE_DIR/$file" --out "$file" > /dev/null
    else
        echo "スキップ（サイズ内）: $file"
    fi
done

echo "--- 完了しました。元ファイルは '$SAVE_DIR' 内にあります ---"

変更方法

1. 4行目の SAVE_DIR="バックアップ用フォルダ" のダブルクォーテーションの中身を、お好みの名前に書き換えてください。
2. あとは先ほどと同様に、ターミナルで対象フォルダに移動して実行するだけです。

補足：sips コマンドの仕様上、-Z 1920 を指定すると「縦長画像」の場合は高さが1920pxになります。もし「縦長であっても高さは1080pxに抑えたい」といった厳密な制限が必要であれば調整可能です。現状のままで進めてよろしいでしょうか？

Raspberry Pi Zero 2 W（メモリ512MB）でUbuntu Serverを運用する場合、標準のシステム要件（1GB以上推奨）を下回るため、不要なサービスの停止は非常に効果的です。 

以下のサービスを停止・無効化することでメモリ使用量を削減できます。

1. 優先的に停止すべきサービス

• snapd: パッケージ管理システムですが、常駐メモリを多く消費します。使用していない場合は削除を推奨します。
  • コマンド: sudo apt purge snapd
• cloud-init: 初回起動時の設定用ツールで、起動後もメモリを消費し続けることがあります。
  • コマンド: sudo touch /etc/cloud/cloud-init.disabled (無効化)
• ModemManager: モデム接続用ですが、Wi-Fi/有線のみであれば不要です。
  • コマンド: sudo systemctl disable --now ModemManager
• unattended-upgrades: 自動更新サービス。手動更新にするなら停止可能です。
  • コマンド: sudo systemctl disable --now unattended-upgrades
• avahi-daemon: ネットワーク上の機器発見用。ホスト名でのアクセスが不要なら停止できます。
  • コマンド: sudo systemctl disable --now avahi-daemon 

2. メモリ節約のための設定

• GPUメモリの削減: 映像出力を使わない場合、GPUへの割り当てを最小限にします。
  • /boot/firmware/config.txt（または /boot/config.txt）に gpu_mem=16 を追記。
• Swapファイルの作成: メモリ不足によるフリーズを防ぐため、1GB程度のスワップ領域を確保してください。
• システムの状態確認: 以下のコマンドで、現在メモリを消費しているサービスを特定できます。
  • systemctl list-units --type=service --state=running
  • systemd-analyze blame（起動に時間がかかっているサービスの確認） 

SSH以外の不要なサービスを一つずつ sudo systemctl disable --now [サービス名] で止めていくのが安全です。

さらに軽量化を進めるために、現在どのような用途でこのサーバーを使用されていますか？用途に合わせて削れるものを追加で提案できます。 

fbiを使った画像表示を専門に行うサイネージシステムに使います。

FBI (linux Framebuffer Imageviewer) を使用したサイネージ用途であれば、ネットワーク、物理コンソール、バックグラウンド更新に関連するサービスをさらに削ることが可能です。

1. FBI専用機として削れる追加サービス

FBIはフレームバッファに直接描画するため、通常の対話型ログインや多機能なネットワーク管理は最小限にできます。

• getty (Ttyの制限): 複数の仮想コンソールが起動していますが、サイネージなら1つ（FBI実行用）以外は不要です。
  • コマンド: sudo systemctl disable getty@tty2.service（tty3以降も同様に停止可能）
• wpa_supplicant / NetworkManager: 画像をローカルから再生するだけであれば、Wi-Fi自体を無効化できます。
  • コマンド: sudo systemctl disable wpa_supplicant
• Multipathd: サーバー向けストレージ管理用で、ラズパイのSDカード運用には不要です。
  • コマンド: sudo systemctl disable --now multipathd
• packagekit: ソフトウェア情報の更新用。手動で行うなら不要です。
  • コマンド: sudo systemctl disable --now packagekit

2. サイネージを安定させるためのFBI最適化 

メモリが少ない環境では、FBIの実行オプションも重要です。

• 自動終了の回避とループ設定: FBIがメモリ不足で落ちないよう、キャッシュを溜め込まない設定にします。bashfbi -d /dev/fb0 -T 1 -a -noverbose -t 10 --cachemem 0 /path/to/images/*
  • --cachemem 0: メモリキャッシュを無効にし、その都度ファイルを読み込みます（512MB環境では必須級）。
  • -a: 画面サイズに自動追従させます。 

3. ZRAMの導入（強く推奨）

物理メモリが限界に近い場合、スワップをSDカードに書くのではなく、ZRAM（メモリ内の圧縮領域）を使用すると、パフォーマンスの低下を抑えつつ実質的なメモリ容量を増やせます。

• zram-tools などを導入し、メモリの1/2程度をZRAMに割り当てると、512MBでも動作が安定します。

4. GPUメモリの最小化

サイネージですが、FBIはフレームバッファ（CPU描画）を利用するため、GPU専用メモリは最小で問題ありません。

• /boot/firmware/config.txt に gpu_mem=16（または32）を記述して再起動してください。

現在は画像の更新（ネットワーク経由か、USB等か）はどのように行っていますか？更新方法によっては、さらにネットワーク関連のサービスを整理できます。

ネットワークドライブをマウントしています。

ネットワークドライブ（SMB/CIFSやNFS）をマウントして画像を読み込む運用であれば、

ファイル共有プロトコルに関連するメモリ消費と、マウント維持のためのオーバーヘッドを最小化するのが鍵です。

512MBの制限下で、以下の追加アクションを推奨します。

1. ネットワークマウントの効率化

マウント方法を工夫することで、常時接続によるリソース消費を抑えます。 

• AutoFS（自動マウント）の利用: 常時接続（fstab）ではなく、アクセスがあった時だけマウントし、一定時間使わなければアンマウントするようにします。これにより、接続維持のためのメモリやネットワーク待機のリソースを節約できます。
• マウントオプションの最適化:
  • SMB (CIFS) の場合、cache=none オプションを検討してください。メモリ上でのキャッシュを無効にし、FBIが画像を読み込む際に直接サーバーから取得するようにします。
  • vers=3.0 など、最新かつ軽量なプロトコルバージョンを明示的に指定して、古い互換モードの動作を避けます。 

2. 不要な「ファイル探索・待機」サービスの停止

ネットワーク経由でファイルを扱う際、Ubuntu Serverが裏で動かしている「お節介」なサービスを止めます。

• gvfs: デスクトップ環境用の仮想ファイルシステムですが、サーバー版でも依存関係で動いている場合があります。サイネージには不要です。
  • コマンド: sudo apt purge gvfs*
• cups (印刷サービス): ネットワーク上のプリンターを探し続けるため、メモリを消費します。
  • コマンド: sudo systemctl disable --now cups 

3. FBI実行時のメモリ管理（再掲・重要）

マウント先がネットワークドライブの場合、FBIが「全画像を一度にスキャン」しようとするとメモリが枯渇します。

• キャッシュの無効化: 前述の --cachemem 0 オプションを必ず使用してください。
• リストからの読み込み: 大量の画像がある場合、fbi /mnt/network_drive/* とするとファイルリストの展開だけでメモリを食います。テキストファイルに画像パスを書き出し、-l オプションで読み込む方が軽量です。 

4. その他、サイネージ専用機で削れるサービス

• man-db: 毎日深夜にマニュアルのインデックスを更新し、CPUとメモリを占有します。
  • コマンド: sudo systemctl disable --now man-db.timer
• polkit: 権限管理用ですが、GUIを使わない単一用途のサイネージなら停止を検討できます（システムの安定性と相談）。 

ZRAMの設定は済んでいますか？512MB環境では、物理メモリの半分程度をZRAMに割り当てるだけで、ネットワーク越しの画像展開時に発生する瞬間的なメモリ不足（OOM Killerによる強制終了）を劇的に防げます。

画像の枚数や1枚あたりの解像度はどの程度でしょうか？それにより、さらに踏み込んだメモリ制限設定が必要か判断できます。 

ubuntu server（Linux）で、特定のディレクトリ配下にある子フォルダをランダムに抽出する方法はいくつかあります。

後続の自作スクリプトにパスを渡しやすいよう、シンプルで堅牢な手法を紹介します。

1. shuf コマンドを使う（最も標準的）

Ubuntuには標準で shuf という行をシャッフルするコマンドが入っています。これと find を組み合わせるのが最も簡単です。

1つだけランダムに抽出してパスを表示する：

bash

find /path/to/target_dir -mindepth 1 -maxdepth 1 -type d | shuf -n 1

• -mindepth 1 -maxdepth 1: 指定したフォルダの「直下」にあるフォルダのみを対象にします。
• -type d: ディレクトリ（フォルダ）のみを抽出します。
• shuf -n 1: シャッフルして上から1行だけ取り出します。

---

2. 変数に格納してスクリプトを実行する

「抽出したフォルダに対してスクリプトを動かす」という用途であれば、以下のようなワンライナーやシェルスクリプトが実用的です。

ワンライナーの例：

bash

# ランダムに選ばれた1つのフォルダパスを変数 target に入れ、スクリプトを実行
target=$(find /path/to/target_dir -mindepth 1 -maxdepth 1 -type d | shuf -n 1) && ./your_script.sh "$target"

複数（例: 3つ）選んで連続で処理する場合：

bash

find /path/to/target_dir -mindepth 1 -maxdepth 1 -type d | shuf -n 3 | while read dir; do
    echo "Processing: $dir"
    ./your_script.sh "$dir"
done

---

3. 注意点：フォルダ名にスペースがある場合

フォルダ名にスペースや特殊文字が含まれている可能性がある場合は、-print0 と shuf -z を使うと安全です。

bash

# ヌル文字区切りで処理（最も安全な方法）
target=$(find /path/to/target_dir -mindepth 1 -maxdepth 1 -type d -print0 | shuf -z -n 1 | tr -d '\0')
./your_script.sh "$target"

応用：もっと深く（階層を問わず）探したい場合

もし直下だけでなく、サブフォルダのさらに中にあるフォルダもランダムに抽出したい場合は、-maxdepth 1 を外してください。

bash

find /path/to/target_dir -type d | shuf -n 1

まずは、「対象のフォルダが何個くらいあるか」や「一度に何個抽出したいか」を教えていただければ、より最適なコードに調整します。

1度に抽出するのは1フォルダのみ。対象のフォルダは現在500個ぐらいで増える予定。

対象フォルダが500個以上あり、今後も増える予定とのことですので、動作の軽快さと堅牢性を重視したスクリプト例を提示します。

Ubuntu Serverで標準的に利用できる shuf コマンドは、数百〜数千程度の項目数であれば一瞬で処理が完了するため、非常に効率的です。 

推奨される実行コマンド

後続のスクリプトへ確実にパスを渡すため、以下の書き方を推奨します。

bash

# 1. ランダムに1つのフォルダを抽出して変数に格納
# 2. そのフォルダが存在する場合のみ、自作スクリプトを実行
target_dir=$(find /path/to/parent_dir -mindepth 1 -maxdepth 1 -type d | shuf -n 1)

if [ -n "$target_dir" ]; then
    /path/to/your_script.sh "$target_dir"
else
    echo "対象のフォルダが見つかりませんでした。"
fi

ポイント

• 高速な処理: find と shuf の組み合わせは、数千個のフォルダに対しても非常に高速に動作します。
• 階層の固定: -mindepth 1 -maxdepth 1 を指定することで、親フォルダ自身（.）を除外し、直下の子フォルダのみを正確に抽出します。
• スペース対応: もしフォルダ名にスペースが含まれる可能性がある場合は、以下のように find の -print0 オプションと shuf の -z オプションを組み合わせると安全です。 

bash

# フォルダ名にスペースがある場合でも安全な書き方
target_dir=$(find /path/to/parent_dir -mindepth 1 -maxdepth 1 -type d -print0 | shuf -z -n 1 | tr -d '\0')

この方法であれば、フォルダが数千、数万と増えても Ubuntu Server 上で安定して動作します。

抽出されたフォルダに対して、どのような頻度（cronなど）でスクリプトを実行する予定ですか？設定方法についてサポートが必要であればお知らせください。

一日に１回抽出可能であればOKです。起動時に抽出して以後１日そのフォルダを使います。

「起動時に1回だけランダムにフォルダを選び、その日1日はそのフォルダを使い続ける」という運用ですね。

Ubuntu Serverでこれを実現するには、「起動時にランダム抽出して結果をファイルに保存する」仕組みを作るのが最も確実です。

1. 起動時にフォルダを固定する仕組み

まず、起動時にランダムで1つフォルダを選び、そのパスを /tmp/today_folder.txt などの固定ファイルに書き出す設定をします。

手順 A: 抽出用のスクリプト作成

/usr/local/bin/select_today_folder.sh として保存します。

bash

#!/bin/bash
# 親ディレクトリのパス
PARENT_DIR="/path/to/parent_dir"
# 結果を保存する一時ファイル
SAVE_FILE="/tmp/today_folder.txt"

# ランダムに1つ選んでファイルに保存
find "$PARENT_DIR" -mindepth 1 -maxdepth 1 -type d | shuf -n 1 > "$SAVE_FILE"

# 選ばれたフォルダに対して自作スクリプトを実行
TARGET=$(cat "$SAVE_FILE")
if [ -n "$TARGET" ]; then
    /path/to/your_script.sh "$TARGET"
fi

作成後、実行権限を与えます： sudo chmod +x /usr/local/bin/select_today_folder.sh

手順 B: 起動時に実行させる (crontab)

Ubuntu Serverで最も手軽なのは cron の @reboot 指定です。

1. crontab -e を実行。
2. 末尾に以下を追記して保存します。bash@reboot /usr/local/bin/select_today_folder.sh

---

2. そのフォルダを「1日中」使う方法

他のスクリプトやコマンドから「今日選ばれたフォルダ」を参照したいときは、先ほど書き出したファイルを読み込むだけです。

例：他のシェルスクリプトから使う場合

bash

# 今日選ばれたフォルダのパスを変数に読み込む
TODAY_DIR=$(cat /tmp/today_folder.txt)

echo "本日の対象フォルダは $TODAY_DIR です。"
# 以降、この $TODAY_DIR を使って処理を行う

この方法のメリット

• 一度決まったら変わらない: /tmp 内のファイルに書き出すため、OSを再起動しない限り、その日はずっと同じフォルダを指し示します。
• 再試行が簡単: もし手動で選び直したい場合は、スクリプトを再度叩くだけで /tmp/today_folder.txt が更新されます。
• メンテナンス性: フォルダが500個から数千個に増えても、find と shuf は一瞬で処理を終えるため、起動時間を遅延させません。

もし「サーバーを数日間起動しっぱなしにする」可能性がある場合は、@reboot の代わりに毎日決まった時間（深夜0時など）に更新する設定も可能です。必要であれば、その設定方法も提示できます。

いえ大丈夫です。この方法を試してみます。ありがとうございました。

承知いたしました！ぜひその方法で進めてみてください。

もし実際に動かしてみて、特定のフォルダを除外したくなったり、実行結果のログを残したくなったりするなど、追加の要望が出てきましたらいつでもご相談ください。

作業の成功を祈っております！

自作スクリプトの引数渡しやパスの指定で詰まった際などは、またいつでもお声がけください。

Raspberry Pi 上の Ubuntu Server でホスト名が元に戻ってしまう原因は、初期設定ツールである cloud-init が起動時に設定を上書きしているためです。 

固定するには、以下のいずれかの方法で cloud-init の設定を変更してください。

方法1：cloud-init のホスト名管理を無効にする（推奨）

これが最も確実な方法です。cloud-init によるホスト名の自動設定をオフにすることで、hostnamectl での設定が維持されるようになります。 

1. 設定ファイルを開きます。bashsudo nano /etc/cloud/cloud.cfg
2. preserve_hostname: false という行を探し、true に書き換えます。yamlpreserve_hostname: true
3. 保存して終了（Ctrl+O, Enter, Ctrl+X）し、再度ホスト名を設定して再起動します。bashsudo hostnamectl set-hostname <新しいホスト名> sudo reboot

方法2：user-data ファイルを直接編集する 

Raspberry Pi 版 Ubuntu の場合、/boot/firmware/user-data（または /boot/user-data）に記述されているホスト名が優先されることがあります。 

1. 設定ファイルを開きます。bashsudo nano /boot/firmware/user-data
2. hostname: ubuntu のようになっている箇所を、希望のホスト名に書き換えて保存します。
3. 再起動すると反映されます。 

注意点

ホスト名を変更した後は、/etc/hosts ファイル内にある旧ホスト名も新しいものに書き換えておかないと、sudo コマンド実行時に「名前解決ができない」といった警告が出ることがあります。 

bash

sudo nano /etc/hosts
# 127.0.1.1 の横にある旧ホスト名を新しいものに変更

これらを行っても解決しない場合、特定のネットワーク環境（DHCPサーバー側での強制指定など）の可能性はありますか？

Ubuntu Serverでディスプレイ出力を90度回転させる方法は、GUI（デスクトップ環境）の有無によって異なります。

1. GUIがない場合（コンソール画面のみ）

Ubuntu Serverの標準的なCUI画面（仮想コンソール）を回転させるには、フレームバッファ（fbcon）の設定を変更します。

• 即時反映させるコマンド:
  以下のコマンドを実行すると、現在の画面が即座に回転します。bash# 90度右回転 (時計回り) echo 1 | sudo tee /sys/class/graphics/fbcon/rotate_all # 90度左回転 (反時計回り) echo 3 | sudo tee /sys/class/graphics/fbcon/rotate_all # 0:標準, 1:90度, 2:180度, 3:270度
• 永続的に設定する方法（再起動後も有効）:
  GRUBの設定ファイルを編集して、起動オプションに回転設定を追加します。
  1. 設定ファイルを開く: sudo nano /etc/default/grub
  2. GRUB_CMDLINE_LINUX_DEFAULT 行に fbcon=rotate:1 を追記する（90度回転の場合）。
     例: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash fbcon=rotate:1"
  3. 設定を更新する: sudo update-grub
  4. システムを再起動する。 

2. GUIがある場合（Ubuntu Desktopを導入済み）

デスクトップ環境（GNOMEなど）を使用している場合は、xrandr コマンドまたは設定メニューを使用します。 

• コマンドで回転:bash# 90度右回転 xrandr -o right # 90度左回転 xrandr -o left # 元に戻す xrandr -o normal コードは注意してご使用ください。※ Wayland環境では gnome-monitor-config などのツールが必要になる場合があります。
• 設定メニューから変更:
  [設定] > [ディスプレイ] > [向き (Orientation)] から「Portrait Right（右縦）」または「Portrait Left（左縦）」を選択して適用します。 

現在、どちらの環境（コンソール画面かデスクトップ画面か）で作業されていますか？

GUIは未インストールでConsoleで作業しています。

GUIがインストールされていないUbuntu Server（コンソール画面）では、フレームバッファ（fbcon）の機能を設定することで画面を回転させることができます。 

1. コマンドで即時に回転させる（一時的）

現在ログインしているコンソール、またはすべての仮想コンソールを即座に回転させるには、以下のコマンドを実行します。

• すべてのコンソールを90度回転（時計回り）:bashecho 1 | sudo tee /sys/class/graphics/fbcon/rotate_all
• 各数値の意味:
  • 0: 標準（回転なし）
  • 1: 90度回転（時計回り）
  • 2: 180度回転（上下反転）
  • 3: 270度回転（反時計回り） 

2. 再起動後も設定を維持する（永続的）

再起動しても回転した状態を維持するには、ブートローダー（GRUB）の設定を変更して、カーネルパラメータに回転の指示を追加します。

1. 設定ファイルを開く:bashsudo nano /etc/default/grub
2. パラメータを追記する:
   GRUB_CMDLINE_LINUX_DEFAULT（または GRUB_CMDLINE_LINUX）の行に、fbcon=rotate:1 を追加します。
   • 例：GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity fbcon=rotate:1"
3. GRUBの設定を更新する:bashsudo update-grub
4. システムを再起動する:bashsudo reboot

注意事項

• ハードウェアの制限: 使用しているビデオカードのドライバやハードウェア構成によっては、フレームバッファの回転（fbcon rotation）がサポートされていない場合があります。
• 特定のアプリへの影響: この設定はコンソールのテキスト表示に対するものであり、フレームバッファを直接操作する一部のグラフィカルなアプリケーションには反映されないことがあります。 

この設定を試しても画面が変化しない場合、使用されているグラフィックドライバ名を教えていただけますか？

/etc/default/grubが新規ファイルとなっていたのですが、それでいいのでしょうか。 また、update-grubがcommand not foundで見つかりません。

/etc/default/grub

 が新規ファイルになり、update-grub コマンドが見つからない場合、お使いの環境は Raspberry Pi や ARMベースのシングルボードコンピュータ、あるいは クラウドイメージ（UEFIブートではない特殊な構成） である可能性が高いです。

これらの環境では GRUB の代わりに別のブートローダーや設定ファイルが使用されています。デバイスの種類に合わせて以下の方法を試してください。 

1. Raspberry Pi を使用している場合

Raspberry Pi版の Ubuntu Server では、設定は /boot/firmware/config.txt で管理されています。

1. 設定ファイルを開く:bashsudo nano /boot/firmware/config.txt コードは注意してご使用ください。
2. 回転設定を追記する:
   ファイルの末尾に以下の行を追加します。
   • 90度回転（時計回り）: display_rotate=1
   • 270度回転（反時計回り）: display_rotate=3
3. 保存して再起動:
   Ctrl+O → Enter で保存し、Ctrl+X で終了した後、sudo reboot で再起動してください。

2. 一般的な環境（x86/64）で GRUB がない場合

最近の Ubuntu Server では、GRUB の代わりに systemd-boot が使われるケースがあります。その場合、カーネルパラメータを直接編集します。 

1. コマンドでの即時確認（一時的）:
   まず以下のコマンドで回転するか確認してください。bashecho 1 | sudo tee /sys/class/graphics/fbcon/rotate_all
2. 永続化（スクリプト化）:
   systemd-boot 環境でパラメータを渡すのが難しい場合、起動時に自動実行するスクリプトを作成するのが確実です。
   • crontab -e を実行し、末尾に以下を追記します：
     @reboot echo 1 > /sys/class/graphics/fbcon/rotate_all 

3. 使用しているデバイスの確認

もし上記で解決しない場合、どのようなハードウェア（PC、Raspberry Piなど）で実行しているか教えていただければ、より正確な設定ファイルをご案内できます。

まずは echo 1 | sudo tee /sys/class/graphics/fbcon/rotate_all を実行して、画面が回転するかどうか確認してみてください。 

Raspberry pi zero2wを使っています。rotate_allでは回転します。

Raspberry Pi Zero 2 W を使用している場合、ブートローダーが GRUB ではなく 

cmdline.txt という設定ファイルを読み込むため、update-grub コマンドは存在しません。

rotate_all コマンドで回転が成功しているのであれば、以下の手順で設定を永続化（再起動後も有効化）できます。

設定の永続化手順

1. 設定ファイルを開く:
   Ubuntu Server on Raspberry Pi では、カーネルの起動オプションは以下のファイルに記述されています。bashsudo nano /boot/firmware/cmdline.txt コードは注意してご使用ください。※ 環境によっては /boot/cmdline.txt にある場合もあります。
2. パラメータを追記する:
   ファイル内の既存の記述の最後（改行せず、半角スペースで区切って）に以下の文字列を追加します。textfbcon=rotate:1 コードは注意してご使用ください。
   • 1: 90度回転（時計回り）
   • 3: 270度回転（反時計回り）
   注意: cmdline.txt は必ず「1行」で記述されている必要があります。複数行に分けないよう注意してください。
3. 保存して再起動:
   Ctrl+O → Enter で保存し、Ctrl+X で終了した後、再起動します。bashsudo reboot

もし上記でうまくいかない場合

Raspberry Pi のビデオドライバ（KMS/FKMS）が有効な場合、cmdline.txt の設定が無視されることがあります。その場合は、起動時に自動でコマンドを実行する設定を行います。

1. crontab を編集:bashsudo crontab -e コードは注意してご使用ください。※初回起動時はエディタの選択が出るので nano を選んでください。
2. 末尾に以下を追記:text@reboot echo 1 > /sys/class/graphics/fbcon/rotate_all
3. 保存して終了すれば、起動のたびに自動で 90度回転が適用されます。

この設定を試した後、画面の向きは正しく反映されましたか？

OKです。

無事に回転したようで良かったです！

Raspberry Pi Zero 2 Wのようなリソースの限られた環境では、GRUBの代わりに Official Raspberry Pi Documentation にあるような cmdline.txt や config.txt を使うのが基本ルールになります。

今後、もし「画面の向きはいいけど、キーボードの入力方向（上下左右）も合わせたい」といったことがあれば、console-setup の設定変更が必要になるので、その際はお気軽にご相談ください。

他にディスプレイ表示や初期設定について、何かお手伝いできることはありますか？

突然アレイが inactive（非活性）になると焦りますよね。

結論から言うと、「アレイが構成情報を失って停止している」状態ですが、データが消えた（壊れた）と決まったわけではありません。

RAID5のメタデータ（管理情報）の読み込みに失敗したり、起動時にデバイスが揃わなかったりすると、このように「とりあえずデバイスは認識しているが、アレイとしては動かさない」という保護状態になります。

以下の手順で復旧を試みてください。

1. アレイを強制的に開始させる

まず、現在の構成情報を使ってアレイを再活性化（start）させます。

bash

sudo mdadm --run --assemble /dev/md0 /dev/sd[bcdefg]1

※もし mdadm.conf が正しく設定されているなら、単純に sudo mdadm --assemble --scan でも構いません。

2. それでも起動しない場合（詳細の確認）

上記でエラーが出る場合は、各ディスクのメタデータがどうなっているかを確認します。

bash

sudo mdadm --examine /dev/sd[bcdefg]1

ここで “State : clean” や “active” と表示されているか、あるいは “dirty” や “failed” になっているディスクがないかチェックしてください。

3. 注意点

• --create は厳禁: 焦って mdadm --create を実行しないでください。データが完全に消去される可能性があります。 Linux RAID Wiki（英語）などの専門サイトでも、安易な再作成は推奨されていません。
• 原因の切り分け: 物理故障（ケーブル抜けやHDDの寿命）が原因で inactive になることが多いです。dmesg コマンドで I/Oエラーが出ていないか確認してください。

まずは --assemble を試して、その結果（エラーメッセージなど）を教えていただけますか？

どのコマンドでエラーが出ましたか？ または dmesg に何か怪しいログは残っていますか？

mdadm: –assemble would set mdadm mode to “assemble”, but it is already set to “misc”.

そのエラーは、「既に md0 という名前のデバイスが（不完全な状態で）存在しているため、新しくアセンブル（起動）モードに入れない」という mdadm の仕様によるものです。 

man7.org

現在の md0 は inactive（非活性）としてシステムに掴まれているため、一度それを解放（停止）してからやり直す必要があります。 

以下の手順を試してください。

1. 現在の不完全なアレイを停止する

まず、現在 inactive で残っている /dev/md0 を一度停止させます。

bash

sudo mdadm --stop /dev/md0

2. 再度アセンブルを実行する

停止できたら、改めてアレイの起動を試みます。

bash

sudo mdadm --assemble --run /dev/md0 /dev/sdf1 /dev/sdb1 /dev/sdg1 /dev/sdc1 /dev/sde1 /dev/sdd1

※ ディスクが全て揃っているはずなのに起動しない場合は、末尾に --force を付けることで、多少の情報のズレを無視して強制起動させることができます。 

もし「device or resource busy」と出る場合

もし mdadm --stop でエラーが出る場合は、そのデバイスを何らかのプロセスが掴んでいます。

• sudo zpool export（ZFSを使っている場合）や sudo vgchange -an（LVMを使っている場合）などで上位レイヤーを停止させてから再度試してください。

この手順で /proc/mdstat の表示は active に変わりましたか？ エラーが出る場合はその内容を教えてください。

assemble で mdadm: failed to RUN_ARRAY /dev/md0: Invalid argument と出ます。

Invalid argument

 エラーは、「アセンブルしようとしているディスク間のメタデータ（Events値など）に不整合がある」か、「既に inactive 状態でカーネルに認識されている md0 が邪魔をしている」場合に発生します。

一度 md0 を完全に停止させた上で、情報のズレを無視して強制的に組み立て直す必要があります。

手順：強制アセンブルの実行

1. 既存の不完全なアレイを停止する
   これをしないと、リソースが使用中（busy）になり、構成のやり直しができません。bashsudo mdadm --stop /dev/md0
2. --force を付けてアセンブルする
   ディスクが全て揃っている（または1台欠けまで）場合、--force を使うことで、メタデータのわずかな差異（シャットダウン時のタイミングのズレなど）を無視してアレイを強制起動させます。bashsudo mdadm --assemble --run --force /dev/md0 /dev/sd[bcdefg]1

上記で解決しない場合（情報の確認）

もしこれでも Invalid argument が出る場合は、ディスクごとのステータスを確認し、どの個体が「古い」または「異常」と判断されているか特定する必要があります。

以下のコマンドの結果を確認してください。

bash

sudo mdadm --examine /dev/sd[bcdefg]1 | grep -E 'Update Time|Events|State'

• Events の値が極端に離れているディスクはありませんか？
• State が active ではなく failed や faulty になっているものはありませんか？

--force で起動に成功しましたか？ もし失敗する場合、mdadm --examine の結果に Events値の食い違い がないか教えてください。

forceでもmdadm: failed to RUN_ARRAY /dev/md0: Invalid argumentになります。 examineではState : active Events : 69683 Array State : AAAAAA (‘A’ == active, ‘.’ == missing, ‘R’ == replacing) State : active Events : 69683 Array State : AAAAAA (‘A’ == active, ‘.’ == missing, ‘R’ == replacing) State : active Events : 69683 Array State : AAAAAA (‘A’ == active, ‘.’ == missing, ‘R’ == replacing) State : active Events : 69683 Array State : AAAAAA (‘A’ == active, ‘.’ == missing, ‘R’ == replacing) State : active Events : 69683 Array State : AAAAAA (‘A’ == active, ‘.’ == missing, ‘R’ == replacing) State : active Events : 69683 Array State : AAAAAA (‘A’ == active, ‘.’ == missing, ‘R’ == replacing) となります。

examine

 の結果、すべてのディスクで Events (69683) が一致し、Array State (AAAAAA) も正常であるにもかかわらず Invalid argument で失敗する場合、メタデータ自体ではなく、カーネルモジュールの不備やデバイスの重複認識が原因である可能性が高いです。

以下の3つのポイントを順に確認してください。

1. RAIDモジュールが読み込まれているか確認 

カーネルが RAID5 を制御する「パーソナリティ（モジュール）」を正しく認識できていないときにこのエラーが出ることがあります。

bash

sudo modprobe raid456

を実行した後、再度 sudo mdadm --assemble --run --force /dev/md0 /dev/sd[bcdefg]1 を試してください。

2. 重複している「古い」アレイ情報を消去する

cat /proc/mdstat で md0 : inactive と表示されている場合、カーネルが古い構成情報をメモリ上に保持しており、新しい組み立て命令を拒否（Invalid argument）している状態です。

一度、確実に停止させてから再実行します。

bash

sudo mdadm --stop /dev/md0
# もし md127 など別の名前で inactive があればそれも停止
sudo mdadm --stop /dev/md127 

この後、cat /proc/mdstat を見て unused devices: <none> だけになったことを確認してからアセンブルしてください。

3. Bad Block Log (BBL) の影響を確認

最近の mdadm（1.2以降のメタデータ）では、ディスク上の不良セクタ情報をメタデータに書き込みますが、これが原因で起動できない場合があります。

bash

sudo mdadm --assemble --run --update=force-no-bbl /dev/md0 /dev/sd[bcdefg]1

※これにより不良ブロックログが無視され、起動できることがあります。

4. カーネルログ (dmesg) の確認

上記でも失敗する場合、エラーの真因がカーネルログに出力されています。

bash

dmesg | tail -n 20

ここに “md: personality for level 5 is not loaded!” や “block size conflict” といった具体的な理由が出ていませんか？

modprobe 後のアセンブルで変化はありましたか？ もしダメなら dmesg の最後数行に記録されているエラーメッセージを教えてください。

modprobe後のassembleでmdadm: /dev/md0 has been started with 6 drives.と出ました。

無事にアレイが起動しましたね！お疲れ様でした。

mdadm: /dev/md0 has been started with 6 drives. という表示が出たのであれば、RAIDとしては正常に動き出しています。

念のため、以下の手順で最終確認と後処理を行ってください。

1. 状態の確認

まずは /proc/mdstat を見て、active になっていることと、リシンク（再同期）が走っていないか確認してください。

bash

cat /proc/mdstat

コードは注意してご使用ください。

md0 : active raid5 ... と表示され、末尾に [UUUUUU] とあれば完全復旧です。

2. ファイルシステムのマウント

アレイが認識されたので、次はデータを読み取れる状態にします。

bash

sudo mount /dev/md0 /mnt/your_mount_point

※ /mnt/your_mount_point はご自身の環境に合わせて読み替えてください。

3. 設定の保存（重要）

次回再起動時にまた inactive にならないよう、現在の（正常な）構成を mdadm.conf に反映させておくことを強く推奨します。

bash

# 現在の設定をスキャンして設定ファイルを更新
sudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf
# 初期RAMディスクの更新（OS起動時にRAIDを正しく認識させるため）
sudo update-initramfs -u

なぜ動かなくなったのか？

今回 modprobe で解決したということは、「何らかの理由でRAID5のカーネルモジュールが自動ロードされなかった」ことが原因の可能性が高いです。OSのアップデート後や、initramfsの不整合で稀に発生します。

マウントして中のデータにはアクセスできましたか？ もしマウント時にエラーが出る場合は、ファイルシステムのチェック（fsck）が必要になるかもしれません。

resync 97.0%ですね

ほぼ完了ですね！もう少しです。

現在、RAIDが全ディスクのデータの整合性を最終チェック（再同期）している状態ですが、97.0% ということは、あとわずかな時間で完了し、冗長性が完全に確保された状態（Clean）になります。

今後の流れと注意点

1. そのまま待機:
   100%になるまでそのまま待ってください。watch cat /proc/mdstat と打つと、進捗をリアルタイムで監視できます。
2. 負荷を避ける:
   再同期中はディスクI/Oが発生しているため、大量の書き込みや重い作業は避け、完了を待つのが安全です（読み取りは可能です）。
3. 完了後の表示:
   完了すると、/proc/mdstat の表示が [UUUUUU]（すべてU）となり、resync の文字が消えます。

念のためのアドバイス

今回、手動で modprobe しないと動かなかった点が気になります。前回の回答にある update-initramfs -u は、再同期が終わった後に必ず実行しておいてください。これを忘れると、次回の再起動時にまた同じ現象（inactive）が起きる可能性が高いです。

再同期が終わった後、ファイルの中身は無事に見られそうでしょうか？ df -h などのコマンドでマウント状況も確認してみてください。