HomeServer35 の履歴(No.2)

[ トップ ]   [ 新規 | 一覧 | 検索 | 最終更新 | ヘルプ ]

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• HomeServer35 へ行く。
  • 1 (2025-12-26 (金) 09:38:37)
  • 2 (2025-12-26 (金) 12:05:04)
  • 3 (2025-12-26 (金) 15:13:55)
  • 4 (2025-12-26 (金) 16:10:23)
  • 5 (2025-12-30 (火) 20:03:05)
  • 6 (2026-01-05 (月) 08:53:12)

---

障害内容 → 部品交換†

障害内容（2025/12/23）†

• EPGStation アプリが表示できなくなった（pukiwiki, samba 等は正常）
• reboot すらできなくなった

  [KGB2] munakata:~$ sudo reboot
  Broadcast message from root@kgb2 on pts/1 (Tue 2025-12-23 17:52:35 JST): 
  
  The system will reboot now! 
  
  Call to Reboot failed: Access denied

  • sudo reboot 自体は実行された
  • systemd が reboot トランザクションを開始
  • しかし 最後の reboot syscall が拒否された
  • systemd-logind は生きている
  • しかし reboot.target がロードできない
  • そのため Access denied（= 実行不能）
• systemdの再インストールを試みたが以下のエラーが出て更新できず

  dpkg: unrecoverable fatal error, aborting: 
  loading files list file for package 'logrotate': 
  cannot open /var/lib/dpkg/info/logrotate.list (不正なメッセージです) 
  Error: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit packagekit.service not found. 
  E: Sub-process /usr/bin/dpkg returned an error code (2)

  • これは systemd 以前に dpkg のデータベース自体が破損している 状態です。なので reboot.target が無いのも結果であって原因ではありません。
  • rescue 環境で fsck → dpkg 再構築 or OS 再インストール（/data 保持）を ChatGPT に勧められたが
• 起動用メディアの故障率が気になった（あなたのログには、危険信号が揃っています） -> nvme_error.txt

  [KGB2] munakata:~$ sudo dmesg | grep -i -E "ext4|nvme|i/o error"
  [563027.945734] EXT4-fs error (device nvme1n1p2): ext4_dx_find_entry:1798: inode #7602363: block 36: comm dpkg: Directory block failed checksum
  [563027.946248] EXT4-fs error (device nvme1n1p2): ext4_dx_find_entry:1798: inode #7602363: block 36: comm dpkg: Directory block failed checksum
  [563027.946961] EXT4-fs error (device nvme1n1p2): ext4_dx_find_entry:1798: inode #7602363: block 36: comm dpkg: Directory block failed checksum
  [563027.948109] EXT4-fs error (device nvme1n1p2): ext4_dx_find_entry:1798: inode #7602363: block 36: comm dpkg: Directory block failed checksum
  [563027.948801] EXT4-fs error (device nvme1n1p2): ext4_dx_find_entry:1798: inode #7602363: block 36: comm dpkg: Directory block failed checksum
  [563027.949384] EXT4-fs error (device nvme1n1p2): ext4_dx_find_entry:1798: inode #7602363: block 36: comm dpkg: Directory block failed checksum
  [563027.949787] EXT4-fs error (device nvme1n1p2): ext4_dx_find_entry:1798: inode #7602363: block 36: comm dpkg: Directory block failed checksum
  [563027.950963] EXT4-fs error (device nvme1n1p2): ext4_dx_find_entry:1798: inode #7602363: block 36: comm dpkg: Directory block failed checksum
  [563027.951360] EXT4-fs error (device nvme1n1p2): ext4_dx_find_entry:1798: inode #7602363: block 36: comm dpkg: Directory block failed checksum
  [563027.951831] EXT4-fs error (device nvme1n1p2): ext4_dx_find_entry:1798: inode #7602363: block 36: comm dpkg: Directory block failed checksum
  [616649.534913] EXT4-fs error: 10 callbacks suppressed
  [616649.534916] EXT4-fs error (device nvme1n1p2): htree_dirblock_to_tree:1109: inode #7602363: block 30417215: comm apport: bad entry in directory: inode out of bounds - offset=88192, inode=1936288814, rec_len=116, size=4096 fake=0
  [616649.535380] EXT4-fs error (device nvme1n1p2): htree_dirblock_to_tree:1083: inode #7602363: block 36: comm apport: Directory block failed checksum
  [616649.535839] EXT4-fs error (device nvme1n1p2): htree_dirblock_to_tree:1083: inode #7602363: block 36: comm apport: Directory block failed checksum
  [616868.773653] EXT4-fs (nvme0n1p1): error count since last fsck: 5
  [616868.773671] EXT4-fs (nvme0n1p1): initial error at time 1761496052: ext4_mb_generate_buddy:1217
  [616868.773679] EXT4-fs (nvme0n1p1): last error at time 1766019732: ext4_mb_generate_buddy:1217
  [627354.624630] EXT4-fs (nvme1n1p2): error count since last fsck: 129
  [627354.624643] EXT4-fs (nvme1n1p2): initial error at time 1765715322: htree_dirblock_to_tree:1083: inode 7602363: block 36
  [627354.624658] EXT4-fs (nvme1n1p2): last error at time 1766320222: htree_dirblock_to_tree:1083: inode 7602363: block 36
  [630992.102962] EXT4-fs error (device nvme0n1p1): ext4_mb_generate_buddy:1217: group 1805, block bitmap and bg descriptor inconsistent: 32760 vs 32762 free clusters

1. nvme1n1p2（root）が“進行性”に壊れている

   EXT4-fs (nvme1n1p2): error count since last fsck: 2 → 25 → 48 → 77 → 106 → 149

   1. fsck していないのに エラーカウントが増え続けている
   2. 同じ inode / block を何度も壊す
   3. 👉 メディア上の同一物理領域が不安定
2. ext4 の「チェックサム破壊」＋「inode out of bounds」

   Directory block failed checksum
   inode out of bounds
   bad entry in directory

   1. これはソフトウェアバグではほぼ起きない
   2. メモリ化けだけでもここまで繰り返さない
   3. 👉 ストレージ層でのビット化けを強く示唆
3. dpkg / apport / unattended-upgr が巻き添えで死んでいる

   comm dpkg
   comm apport
   comm unattended-upgr

   1. ランダムではなく「書き込みが多い領域」から壊れる
   2. /var/lib/dpkg が最初に死ぬのは典型

• 👉 「OS が壊れた」のではなく「OS を載せている床が崩れている」
• 起動用メディア（NVMeSSD /dev/nvme）を新品に交換して OS 再インストール が最も安全・最短・確実

交換前のディスクレイアウト（実メディアのみ）†

[KGB2] munakata:~$ df -h
Filesystem Size Used Avail Use% Mounted on 
/dev/nvme1n1p2 457G 49G 385G 12% / 
/dev/nvme1n1p1 1.1G 6.2M 1.1G 1% /boot/efi 
/dev/nvme0n1p1 3.6T 1.7T 1.8T 49% /dtv_recipe 
/dev/md0 7.3T 2.9T 4.0T 43% /raid_vol 
/dev/sdc1 15T 8.3T 5.5T 61% /dtv_h264B 
/dev/sdd1 13T 5.6T 6.5T 47% /dtv_h264A 
/dev/sde1 13T 8.1T 4.0T 68% /dtv_h264C

交換部品（nvme1n）†

• 現状 / ディレクトリは 50G 程度しか消費していないので、512G→256Gのサイズダウンを行った
• fanxiang SSD S500 Pro 256GB: NVMe PCIe Gen3.0x4 2800MB/s TLC 3D NAND M.2 2280 内蔵SSD 32Gb/s 200TBW 5年保証
  • 

リカバリー準備†

ファイルバックアップ → / 以外のHDDをすべて切断†

• /etc 以下

  sudo mkdir -p /raid_vol/reinstall_backup/etc
  sudo cp -a /etc /raid_vol/reinstall_backup/

• ユーザー、グループ情報

  getent passwd | sudo tee /raid_vol/reinstall_backup/passwd.txt > /dev/null
  getent group  | sudo tee /raid_vol/reinstall_backup/group.txt  > /dev/null

• cron / timers

  sudo crontab -l > sudo tee /raid_vol/reinstall_backup/root.cron > /dev/null
  crontab -l > /raid_vol/reinstall_backup/munakata.cron

• mdadm RAID

  sudo mdadm --detail --scan | sudo tee /raid_vol/reinstall_backup/mdadm.conf > /dev/null
  sudo mdadm --detail /dev/md0 | sudo tee /raid_vol/reinstall_backup/md0.detail > /dev/null

• netplan (network 設定)

  sudo cp -a /etc/netplan /raid_vol/reinstall_backup/

• Docker / コンテナ（mirakurun だけ Docker で運用中）
  • docker-compose / volumes（overlayfs は再構築されますが volume は残ります）

    sudo cp -a /var/lib/docker /raid_vol/reinstall_backup/
    sudo cp -a /etc/docker /raid_vol/reinstall_backup/

リカバリー（環境）†

OS re-install†

• Ubuntu 24.04.3 server を利用
  • Release Notes
• NVMeSSD　には手動でパーティションを作成

  Partition	Mouont Point	Size	Format
  nvme0n1p1	未使用	端数（1M）
  nvme0n1p2	/boot	32G	ext4
  nvme0n1p3	/	残りすべて(206G)	ext4

• Ubuntu serverはOSインストール中にnetplanを利用した固定IP設定を行う

  [KGB2] munakata:/raid_vol/reinstall_backup/etc$ sudo cat netplan/50-cloud-init.yaml 
  # This file is generated from information provided by the datasource.  Changes
  # to it will not persist across an instance reboot.  To disable cloud-init's
  # network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
      ethernets:
          enp7s0:
              addresses:
              - 192.168.11.20/24
              nameservers:
                  addresses:
                  - 192.168.11.1
                  search: []
              routes:
              -   to: default
                  via: 192.168.11.1
      version: 2
      wifis: {}

RAID0†

• RAIDディスクペアを接続した時に sda-sda1-md127 と sdb-sdb1-md127 という２つのボリュームが見える
  • RAID1 の メンバーは正しく検出されている
  • しかし旧 md0 の名前が引き継がれず system が 一時名 md127 を振った
• sda1, sdb1 の UUID が一致していることを確認

  lsblk
  cat /proc/mdstat
  sudo mdadm --examine /dev/sda1
  sudo mdadm --examine /dev/sdb1

• 自動生成された md127 を停止する

  sudo mdadm --stop /dev/md127

• md0 としてRAID0を再構成

  sudo mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1

• md0に対してfsckを実行

  sudo fsck.ext4 -f /dev/md0

• 手動マウント

  sudo mkdir -p /raid_vol
  sudo mount /dev/md0 /raid_vol

• 永続化

  sudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf

• initramfs 更新

  sudo update-initramfs -u

• 再起動して md0 が正常にマウントされることを確認

その他 HDD/SSD リカバリー → ディスク認識†

• 各ドライブを接続し、マウントする前に各パーティションに対して fsck をかける
• /boot のフォーマット指定が変わった（FAT32 → ext4) のでUUIDの指定が変わった
• 現状の fstab の設定

  # <file system> <mount point>   <type>  <options>       <dump>  <pass>
  /swap.img	none	swap	sw	0	0
  /dev/md0 /raid_vol ext4 defaults,nofail 0 0
  
  UUID=26648dca-75d8-474a-8d4e-e4c0661909da /           ext4 defaults 0 1
  UUID=eefb4256-7f5f-4dd9-9e20-2ef0837a5e68 /boot       ext4 defaults 0 1
  UUID=2665e64e-338c-43b7-963a-2465a48f973c /dtv_recipe auto nosuid,nodev,nofail 0 0
  UUID=673bf4bd-ab71-41e3-adfa-2326241f1152 /dtv_h264A  auto nosuid,nodev,nofail 0 0
  UUID=ddf9c10e-9018-4a38-aecb-d94eccf8f061 /dtv_h264B  auto nosuid,nodev,nofail 0 0
  UUID=6c0e0325-f4b9-4fb4-84b3-e9c31adb5a5b /dtv_h264C  auto nosuid,nodev,nofail 0 0

sshd 有効化†

• ssh-server のインストール（インストーラで対応済の可能性もある）

  sudo apt install openssh-server

• 設定情報はバックアップから戻す（）
  • ssh ポート = 8722
  • rootによるログイン禁止
  • パスワードによるログイン禁止
  • 公開鍵方式のログインのみ受付
• 認証情報は home/munakata/.ssh の下に残っている
• 自動起動設定（systemd サービス登録）

  sudo systemctl enable ssh
  sudo systemctl start ssh

samba 有効化†

†

†

サーバー証明書（Let's Encrypt）†

• インストール
• 自動更新管理

リカバリー（アプリ）†

Pukiwiki†

• インストール
  • 管理者パスワード更新（!frex7785）
• データ調整

mirakurun (TVチューナーサーバー)†

• Docker インストール

EPGStation（TV録画アプリ）†

• リモートアクセス

APCUPS（自動シャットタウン）†

リカバリー（運用系）†

     

Site admin: munakata

PukiWiki 1.5.4 © 2001-2022 PukiWiki Development Team. Powered by PHP 8.3.6. HTML convert time: 0.005 sec.