Category: Linux

Debianでpartition swapを永久に止める

これ色々苦労しました．前にうまくいったのにメモが残っていないので今回も苦労しました．そこで，BLOGに残す次第です．

Raspberry Pi OSではdefaultのインストールでpartition swapを使いませんが，Debianではデフォルトのインストールでswapのパーティションを切られそこがアクティブになります．/etc/fstrabでそのパーティションの記述をなくしてもtypeがLinux swapのpartitionがある限り強情にpartition swapが起動されます．

いろいろやりましたが，どれが効いているか解りません．ChatGPTは，

  • /etc/fstab → swap 行コメントアウト
  • systemctl mask dev-sdaX.swap
  • /etc/initramfs-tools/conf.d/resume 削除 & update-initramfs -u
  • grub の resume= パラメータ削除 & update-grub
  • sgdisk --typecode=N:8300 /dev/sda でパーティションタイプを変更

といいます．たぶん全部するのがよいと思います．

swapoffしてfdiskでパーティションのtypeをlinux-swap以外にするのがpatition swapを使わない必要条件だと思います．しかし他の手続きをしておかないとブート時にタイムアウトまで待つようなことになって起動時間が余計にかかるなどの副作用があったように記憶しています．

ちなみに，今いじっているDebian ARM64 13 TrixieはM4 Mac miniのVMWare Fusion上で動かしていて，マスストレージ（仮想ディスク）は，/dev/nvme0n1で，swap partitionは，/dev/nvme0n1p4でした．

ついでに，M4 Mac miniのVMWare Fusion上で動かすDebian ARM64 Trixieは，他の仮想マシン・実マシンのどの環境よりも早いDebianです（当社比）．

筆者はfdiskを使います．

ATOM Cam 2のRTSPをRasPi3で見る update (2025/08/20)

その後もRaspberry Pi 3 Model B (RPi3)および同+ (RPi3+)で，ATOM Tech社のATOM Cam 2が出力するRTSPを受信して地デジテレビに表示しています．

画質はきれいで暗視性能も良く，その辺は問題ないのですが，やはりあいかわらず不安定性にさいなまれています．まあ業務用の監視カメラに比べるとシステム全体の価格が2〜3桁も違うのでそこら辺はアイデアで対処していきます．

不安定性はいくつかあって，ATOM Cam 2に起因するもの，RPi3(+)に起因するものがあります．

ATOM Cam 2は連続運用していると，まずhackで動いているFTPクライアントが落ちます．次にRTSPサーバーが落ちます．また，1台だけ，1番古い個体ですが，これはWi-Fi接続が切れます．

それらを回避する方法として，いつの頃からか定期的にリブートする仕組みが取り入れられました．Wi-Fiが落ちる一番古い個体は毎日1回，その他は週に3〜4回リブートするように設定しました．これでしばらく様子を見たいと思います．

また，RPi3(+)のほうも，RTSPの視聴に使用しているVLCが時々落ちますので，これもリスタートしたいのですが，ChatGPTに嘘を教えられて遠回りしてしまいました．

結局，VLCを起動するrun_vlc.service, run_vlc.timerファイルとは別に，

systemctl --user restart run_vlc

を実行するための，rerun_vlc.serviceとrerun_vlc.timerを作りました．ATOM Cam 2がリブートする2分後に実行するように設定しました．

また，現状ではRPi3+のほうがよく固まるので，ATOM Cam 2のリブートの2分後に加えて，早朝にも一度実行するように設定しました．

これでしばらく様子を見ます．

ChatGPTでRaspberry Pi OSを修復

ChatGPTは，これまでWeb検索でキーワードや質問を組み合わせたりして答えを探していたのを，文や文章で質問するとすぐ答えてくれて便利です．ただし，技術的な話でも社会問題や日常のことについてもときどき嘘を答えますので，まあそれなりの話し相手だと思えば悪くないです．

技術的な問題については，いきなりかなり詳しい答えを出してくれますが，そのまま使えたことは滅多にありません．

ところがです，最近Debianの最新リリース13.0 Trixieがリリースされ，AMD64 (x86_64)についてはあまり何も考えずサクッとupgradeできましたが，Raspberry Pi 5 Model Bについては，SSDベースで動かしているRaspberry Pi OS (RPi OS)+ KDE Plasma Desktop (KDE)と，SDカードベースで動いているRPiOS + PIXEL (RPiOSのdefault desktop)の両方とも壊してしまいました😓

apt upgradeをかけて出るエラーをChatGPTにかけたところ，ほとんど回答の手順からRPi OS + KDEのほうは回復できました．

一方のSDカードベースのPIXELのほうは，ChatGPTの示した手順通りにはいきませんでしたが，それでも何とか回復できました．

ということで，今回はChatGPTのすごさに感心した次第です．

ちなみに，ChatGPTのバックエンドがGPT-5になってから，対応が素っ気なくなったなと感じています（というより，4.xが質問者に寄り添いすぎたと思います）が，ネットでざっと検索すると，そう感じているのは筆者だけではないようです．

ただし，KDE Settingsで “About” が表示されないなど一部欠損があるようです．

バックアップディスクが不調になったのとほぼ同時にDebianがブートしなくなったのは偶然ではない

何言ってるか解らない題だと思いますが，自分宛のメモです．

現在Linux WSの第1 OSはManjaro，第2 OSはDebianです．両OSは同じ1TBのSSDのパーティションにあります（だいたい半分ずつ）．このほか仮想マシン（KVM/QEMU）のディスクイメージを保存するのに2TB SSDを，そのディスクイメージをバックアップするために3TB HDDを，ManjaroとDebian本体をバックアップするのに2TB HDDを使用してきました．

そのバックアップ用の2TB HDDが数日前から不調で，バックアップのためマウントしようとしても出来ません．取り出して外部のSATA用のアダプターに接続したら読み出すことが出来たので，手持ちの1TB SSD 2基に中身をコピーしました．

この不調が生じたのとほぼ同時期からDebianがブートしなくなりました．

よく考えてみると，Debianはバックアップ用のHDDの第1パーティションをEFIに使っているのです．メインOSのManjaroが自分のドライブの第1パーティションとしているのでDebianはそこを使えないためです．

もちろんManjaroのEFIから導かれたGRUBにはDebianも表示されますが，Debianが主体のEFI/GRUBがあった方が便利です．

このため，DebianのEFI/GRUBが置かれたバックアップ用の2TB HDDが不調になったらDebianはブートできないのです（起動時にマウントすべきEFIパーティションが見つからないため）．

2TB HDDの後任には2TB SSDを新規購入してあてがいました．今どき2TBだとSSDはHDDとほとんど値段が変わらなくて驚きました．

故障したSeagateの2TB HDDと新規購入したOricoの2TB SSD

2基の1TB SSDに待避したバックアップの中身を新規購入したSSDへコピーしましたが速いです．なんか，バックアップ用にするのはちょっともったいない気もします．

4基ともPCの筐体内に設置してあります．
とはいえなかなか煩雑ではあります．