カテゴリー: 未分類

2024-07-29 別ディスクにリカバリしたらパーティションが認識されなかった。対応。

ddでリカバリしたはずなのにパーティションができていない。なぜだ？

lsblk

で見てもパーティションがないってことだ。

Windows側にこのディスクをつないでみるとパーティションがあるのだが。という謎現象だった。

しょうがないのでパーティションを指定してリカバリすることを試みる。

まず、リカバリするイメージをループデバイスにつなぐ。

sudo losetup -fP /path/to/BackupDirectory/Backup_xxx_ymd.img

これでどこのデバイスになっているかを確認。

sudo losetup -a

今回は　loop20　だった。

sudo parted /dev/loop20 print
モデル: Loopback デバイス (loopback)
ディスク /dev/loop20: 128GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt
ディスクフラグ:

番号 開始 終了 サイズ ファイルシステム 名前 フラグ
1 1049kB 2097kB 1049kB bios_grub
2 2097kB 540MB 538MB fat32 EFI System Partition boot, esp
3 540MB 76.0GB 75.5GB ext4

こんな感じだった。要はイメージのパーティション構成が分かる。

一部手順追加、ここから（2024-09-30）

sudo dd if=/dev/zero of=/dev/sdc bs=4M status=progress

要はゼロ埋めクリアしてからにしようかな。どうもこうしないとうまくいかないっぽい？？

ーーーここまで。

ディスク全体の最初の数MBをコピー:
これには、GRUBのブートローダー部分も含まれます。

sudo dd if=/dev/loop20 of=/dev/sdc bs=4M count=1

さて、これで以前のままのGrubがコピーされたのだろうか？

このまま起動できるといいのだがなぁ。

では次に、バックアップ先のディスクにパーティションを作る。

lsblk で調べて、sdcが対象のディスクとわかる。

sudo parted /dev/sdc

(parted) mklabel gpt
(parted) mkpart primary 1MiB 2MiB
(parted) set 1 bios_grub on
(parted) mkpart primary fat32 2MiB 540MiB
(parted) set 2 boot on
(parted) set 2 esp on
(parted) mkpart primary ext4 540MiB 76.0GiB
(parted) quit

要はここまででバックアップ先のディスクにパーティションを作ったわけだ。

sudo partprobe /dev/sdc

lsblk
sdc 8:32 0 111.8G 0 disk
├─sdc1 8:33 0 1M 0 part
├─sdc2 8:34 0 538M 0 part
└─sdc3 8:35 0 75.5G 0 part
sr0 11:0 1 1024M 0 rom

この状態になったので、イメージからディスクにddでコピーする。

パーティション単位。

sudo dd if=/dev/loop20p1 of=/dev/sdc1 bs=4M status=progress
sudo dd if=/dev/loop20p2 of=/dev/sdc2 bs=4M status=progress
sudo dd if=/dev/loop20p3 of=/dev/sdc3 bs=4M status=progress

とりあえずこの状態で起動できるかテスト。

再起動

起動できない場合、仕方ないのでGrubをインストールする必要があるかもしれない。

要は以前の設定のGrubとは違うことになるけど仕方ないということでね。

Grubの設定。

リカバリディスクのマウント：
sudo mount /dev/sdc3 /mnt/tmp
sudo mount /dev/sdc2 /mnt/tmp/boot/efi

重要なシステムディレクトリのバインド：

sudo mount –bind /dev /mnt/tmp/dev
sudo mount –bind /proc /mnt/tmp/proc
sudo mount –bind /sys /mnt/tmp/sys
sudo chroot /mnt/tmp

GRUBのインストール：
grub-install /dev/sdc
update-grub

chroot環境の終了とアンマウント：
exit
sudo umount /mnt/tmp/dev
sudo umount /mnt/tmp/proc
sudo umount /mnt/tmp/sys
sudo umount /mnt/tmp/boot/efi
sudo umount /mnt/tmp

2024-07-11　古いディスクは完全に消去。

コマンドメモ

lsblk

sudo dd if=/dev/zero of=/dev/sdb bs=4M status=progress

sudo dd if=/dev/urandom of=/dev/sdb bs=4M status=progress

sudo shred -v -n 3 /dev/sdb

2024-06-30 やっぱりddだけでは起動できなかった

要はUUIDが変わったのかな？

2024-07-12 追加設定

Gpe4oさんに聞いた結果

lsblk

で対象ディスクを特定

ライブUSBでシステムを起動:

ライブUSBを使ってシステムを起動します。
SSDのパーティションをマウント:

ターミナルを開き、SSDのルートパーティション（おそらく/dev/sdb3）をマウントします。
bash
コードをコピーする
sudo mount /dev/sdb3 /mnt
必要なファイルシステムをバインド:

proc, dev, sysのファイルシステムをマウントします。
bash
コードをコピーする
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
chroot環境に入る:

chrootを使って、マウントしたファイルシステムにアクセスします。
bash
コードをコピーする
sudo chroot /mnt
GRUBのインストール:

GRUBを再インストールします。/dev/sdbに対してインストールします。
bash
コードをコピーする
grub-install /dev/sdb
update-grub
chroot環境から出る:

exitコマンドを使ってchroot環境から出ます。
bash
コードをコピーする
exit
ファイルシステムのアンマウント:

マウントしたファイルシステムをアンマウントします。
bash
コードをコピーする
sudo umount /mnt/dev
sudo umount /mnt/proc
sudo umount /mnt/sys
sudo umount /mnt
再起動:

システムを再起動し、SSDから起動することを確認します。
bash
コードをコピーする
sudo reboot

というか、外部HDDをつなぐと起動しない。

しかもその後に外部HDDを切断した後も起動しなくなるという謎現象が出ていた。

よって、移行後のSSDから起動した後に以下を実行。

sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install -y boot-repair
boot-repair

でもって、念のため外部HDDを接続して、認識された後に、再度上記を実行。

これでとりあえず、外部HDDを接続したままUbuntuが起動するようになった。

2024-06-29

HDD　１６０GBが注意表示になっていたので移行。

超古いHDDだったからな。IDEだし。

SSDに移行する。手持ちSSDは１２０GBだった。

VirutalboxにこのHDDを接続して、GnomeのDiskUtilityでパーティション縮小。

一時間ちょっとかかった。

この状態で起動できることを確認。

これをSSDに移行する。

この先の手順としては、ddかな？SSDにコピー。

Grub,ブートローダーの調整必要かも。

SSDから起動でOKのはず。

SSDだからパフォーマンスも爆上げするはず。

とりあえずこれか。gpt4oさんに聞いた内容。

ーーーーー

lsblkコマンドやfdisk -lコマンドでデバイス名を確認します。
例: /dev/sda がHDD、/dev/sdb がSSD。

sudo dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync status=progress

ーーーーー

lsblkで見たところ、今回は

HDD= /dev/sdb

SSD=/dev/sdc

だった。

で、コピー終了。dd終わり。これだけで起動すると楽なんだけどな。

LinuxコマンドでNordVPNを設定するときのメモ。

2024-09-02 NordVPNの接続のたびに設定を上に追加されしまうので。

#!/bin/bash


# 一時的に既存のルールを削除
sudo iptables -D FORWARD -s  -p tcp --dport  -j ACCEPT

# NordVPNのルールが適用された後に、再度ACCEPTルールを最上位に追加
sudo iptables -I FORWARD 1 -s  -p tcp --dport  -j ACCEPT

2024-09-02 テスト中。どれがまずいのかだね。

テストの方法がいろいろまずかった。
ブラウザがちょっとキャッシュの影響とかいろいろ。

curl http://100.xx.xxx.xx:8088/

とかでテストしよう。

sudo iptables -I INPUT 1 -s 100.xx.xxx.xxx -p tcp --dport 8088 -j ACCEPT

みたいにルールを追加する方がいいんだけどね。

駄目なら削除していく。
ようは、行番号を確認しながら、Nordvpnが追加したルールを削除していく。

sudo iptables -L FORWARD -v -n --line-numbers
sudo iptables -D FORWARD 行番号

sudo iptables -L INPUT -v -n --line-numbers
sudo iptables -D INPUT <番号>

どれがまずいのかなと。

FOWARDのこれだった。

1 18 936 DROP all -- * * 100.64.0.0/10 0.0.0.0/0 /* nordvpn-exitnode-permanent */

なるほどな。メッシュネットワーク内の通信をドロップしちゃってるな。

sudo iptables -I FORWARD 1 -s <from_IP> -p tcp --dport <dest_port> -j ACCEPT

これで行けた。

ってことはこれを複数スクリプトで設定すればいいか。

2024-09-01 メッシュネットの関係だったようだ。

なるほど。メッシュネットを有効にするとiptablesが追加されるんだな。
ということが分かったぞと。

# sudo iptables -L INPUT -v -n

で追加されたことが分かる。

Gpt4oさんからの回答は以下。

特定のIPアドレス（例えば、100.74.xx.xxxなど）からの接続を特定のポート（例えば、49xxx）で受け入れる。
上記IPアドレスからの通信で、プライベートIPレンジ（例えば、192.168.0.0/16、10.0.0.0/8）へのアクセスを拒否する。
100.64.0.0/10範囲内のIPからの既存の通信は受け入れるが、新しい接続は拒否する。

2024-08-31　いや、Nordvpnが勝手に追加しているんだからさ。追加された後で問題になっているものを無効にしないといけないかなと。

とりあえず、NordVpnがインストールされる前のバックアップに戻した。

現在のiptablesを保存。場合によってはリストアできるように。

sudo iptables-save > /path/to/backup/iptables-backup.rules

sudo iptables-restore < /path/to/backup/iptables-backup.rules

2024-08-27 フィルタリングが原因でhttpがつながらない。

iptables-persistent　の解説。

これでフィルタリングの設定を永続化できるのかな。

現在の設定を確認。

sudo iptables -L INPUT -v -n

なんだけどね。

sudo iptables -F
sudo iptables -X
sudo iptables -t nat -F
sudo iptables -t nat -X
sudo iptables -t mangle -F
sudo iptables -t mangle -X
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

をやると外部からつながるけど、

全部削除しちまっていいものか。ってね。

あと、

sudo iptables-save > /etc/iptables/rules.v4

をやると一応戻るっていうかつながる。

Gpt-4oさんに聞いた内容。

sudo iptables -A INPUT -j LOG –log-prefix “iptables-dropped: “

このログを確認して、問題を引き起こしているルールを特定します。ログは通常

/var/log/syslog

や

/var/log/kern.log に記録されます。

2024-08-26 不可思議な状態について様子見。

とりあえず分かったことはNordvpnのメッシュネットワークでアクセスできた。

IPでもマシン名でも可能だった。

あと、メッシュネットワークはVPNとは別動作みたい。

つまり、VPNつながっていなくてもメッシュネットワーク使える。つまりアクセスできる。

あと、外部からの接続できない状態が最初あった。

sudo iptables -S
sudo iptables -L -v -n

でつながったんだけど、なぜか再起動して設定元に戻ってからも問題なく接続できている。

NordvpnとDockerコンテナ（で動くWebサーバー）の起動のタイミングか？？

この辺不明なので様子見中。

2024-08-26 CPUリソースの問題。NATの問題。ログインの問題調整。

ログインだけGui、Gnomeの自動起動でやるか。

#!/bin/bash

sleep 20

# NordVPNのログインを試みるスクリプト

login_status=$(nordvpn login | grep "already logged in")

if [ -z "$login_status" ]; then
  echo "You are not logged in. Starting browser to login..."
  login_url=$(nordvpn login | grep -oP 'https://[^\s]+')
  
  # ここで特定のブラウザを指定して起動
  firefox "$login_url"
  # または
  # chromium-browser "$login_url"

  echo "Please complete the login in your browser."
else
  echo "You are already logged in."
fi

Cronで実行かな。こんな感じ。Ｂｏｏｔでも実行しないといけないかな。

#!/bin/bash

# 設定
EMAIL="your-email@example.com"  # 通知を送信するメールアドレス
LOG_FILE="/var/log/nordvpn_check.log"  # ログファイルの場所
CPU_THRESHOLD=80  # CPU使用率の閾値（%）
MEM_THRESHOLD=70  # メモリ使用率の閾値（%）
BRIDGE_IP="192.168.x.xxx"  # ブリッジ接続時に使用される固定IP

# ブリッジ接続かどうかを確認
if ip a | grep -q "$BRIDGE_IP"; then
    echo "$(date): ブリッジ接続が検出されました。VPN接続を維持します。" | tee -a "$LOG_FILE"
else
    echo "$(date): NAT接続が検出されました。VPN接続は不要です。" | tee -a "$LOG_FILE"
    nordvpn disconnect
    exit 0
fi

# NordVPNの状態を取得
STATUS=$(nordvpn status)

# 接続状態の確認
if echo "$STATUS" | grep -q "Status: Connected"; then
    echo "$(date): NordVPNは接続されています。" | tee -a "$LOG_FILE"
else
    echo "$(date): NordVPNは接続されていません。接続を開始します。" | tee -a "$LOG_FILE"
    
    nordvpn set lan-discovery on
    nordvpn set meshnet on

    nordvpn connect

    # 再度接続確認
    if nordvpn status | grep -q "Status: Connected"; then
        echo "$(date): 再接続に成功しました。" | tee -a "$LOG_FILE"
    else
        echo "$(date): 再接続に失敗しました。" | tee -a "$LOG_FILE"
        echo "NordVPNの再接続に失敗しました。" | mail -s "NordVPN再接続エラー" "$EMAIL"
        exit 1
    fi
fi

# リソース使用率の確認
CPU_USAGE=$(ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | grep nordvpn | grep -v grep | awk '{print $5}' | head -n 1)
MEM_USAGE=$(ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | grep nordvpn | grep -v grep | awk '{print $4}' | head -n 1)

if [ "$(echo "$CPU_USAGE > $CPU_THRESHOLD" | bc)" -eq 1 ] || [ "$(echo "$MEM_USAGE > $MEM_THRESHOLD" | bc)" -eq 1 ]; then
    echo "$(date): NordVPNのリソース使用量が高いため、サービスを再起動します。" | tee -a "$LOG_FILE"
    
    # サービスを再起動
    systemctl restart nordvpnd
    
    # 少し待ってから再接続
    sleep 10
    
    # VPN接続を再確立
    nordvpn connect
    
    # 接続確認
    if nordvpn status | grep -q "Status: Connected"; then
        echo "$(date): サービス再起動後、接続に成功しました。" | tee -a "$LOG_FILE"
    else
        echo "$(date): サービス再起動後の再接続に失敗しました。" | tee -a "$LOG_FILE"
        echo "NordVPNの再起動後の再接続に失敗しました。" | mail -s "NordVPN再接続エラー" "$EMAIL"
        exit 1
    fi
fi

2024-08-22　ログインスクリプト、自動で接続するためにいろいろ。

とりあえずログインはブラウザでGUIでやるしかないかなぁ。

Gnomeの自動起動で設定。

bash -c “/path/to/start_nordvpn/chk_login.sh”

とりあえずこれでログインしてくれーってGUIで出るようになるからな。

とりあえず起動したときにログインしていれば特に何も出ない。

#!/bin/bash
# NordVPNのログインを試みるスクリプト

login_status=$(nordvpn login | grep "already logged in")

if [ -z "$login_status" ]; then
  echo "You are not logged in. Starting browser to login..."
  login_url=$(nordvpn login | grep -oP 'https://[^\s]+')
  
  # ここで特定のブラウザを指定して起動
  firefox "$login_url"
  # または
  # chromium-browser "$login_url"

  echo "Please complete the login in your browser."
else
  echo "You are already logged in."
fi

2024-11-18　いきなりビルドできなくなったので。

NordVpnのせいだった。

Nordvpnで除外に設定したりもしたんだけど全然ダメっぽかったので、しょうがねーなー。と。

いちいちツールの設定を頑張ったけど、とりあえず、もうとりあえずその時だけNordvpnオフで。

Gpt4oさんの回答ーーーーー

おすすめのアプローチ
手軽さを優先する場合 → Gradleのローカル化がおすすめ。
完全に分離された環境を優先する場合 → VirtualBoxでUbuntuを利用。
リソース消費を抑えたい場合 → Docker。
どれも実現可能ですが、まずは簡易的な方法から試していき、最終手段としてDockerやVirtualBoxを検討するのが良いと思います。

あなた:
はー。まったく。しょうがないなぁ。ビルドするときだけ一時的にNordvpnをオフにする。っていうどうしようもない対応をしようかな・・・・・。
ChatGPT:
ChatGPT
それも一つの現実的な対応策ですね！特に、NordVPNをオフにすることで確実に問題が解決するのであれば、ビルド作業中のみVPNを一時的にオフにするのは、作業効率を優先するうえで最小限の手間で済む方法です。

ーーーーーーーーーーーーー