今回はM.2 NVMe SSDについて試す。

違っていたところは、状態確認のコマンド、データ削除のコマンド。

もうひとつ、DELLノートパソコンで今回は実施したが、結果としてはBIOSのSystem Configuration＞SATA OperationでSATAのモードをRAID OnからAHCIに変更する必要があった。
RAID OnのままだとSSDをUbuntuから認識させることができず。

この変更でWindowsが起動できなくなったが、データを消したい対象であったため問題なし。

(1)USBメモリから起動。これは同じ。

(2)デバイスを調べる。これも同じ。

Gpartedで確認し、削除対象のデバイスは /dev/nvme0n1 とわかる。

lsblkコマンドでも確認可能。

(3)SSDの状態を確認する。これはコマンドが異なる。

SATA SSDでは hdparm を使い、NVMe SSDには nvme コマンドを使う。

nvmeコマンドが入っていない場合はインストールする。
sudo apt update
sudo apt install nvme-cli

状態確認のnvmeコマンド
sudo nvme id-ctrl /dev/nvme0n1

見るべきところはfna

sudo nvme id-ctrl /dev/nvme0 | grep -i "fna"

fna : 0
だと後のデータ消去時、format -s2 ※Crypto Erase に非対応だとわかる。

つぎにsanicap
sudo nvme id-ctrl /dev/nvme0 | grep -i "sani"
sanicap : 0x2
1：-a 4(crypto erase対応)
2：-a 2(block erase対応)
4：-a1(overwrite対応)
2ですと、sanitizeの -a 4 ※Crypt Eraseに非対応だとわかる

(4)frozen解除

NVMe は基本的にはfrozenはなく、作業は不要

(5)消去前に先頭セクタの中身を確認。コマンドは同じ

sudo hexdump -n 4096 -C /dev/nvme0n1
-n でバイト数を制限する（4098は余裕めに）

"EFI PART"などなんとなく意味のあるデータが入っていることがわかる。

(6)念のため、消去前に意味のある文字列の存在を確認。コマンドは同じ

sudo dd if=/dev/nvme0n1 bs=512 count=32 | strings
※512バイト(1セクタ)単位で読み込み、32セクタ = 16384バイト

やはりEFI PARTが文字列として残っている。

(7)更に念のため、末尾側セクタの中身を確認。コマンドは同じ。

sudo bash -c 'hexdump -C -s $(($(blockdev --getsz /dev/nvme0n1)*512 - 4096)) /dev/nvme0n1'

やはり、意味のあるデータが残っている。
次から消去プロセス。

(8)データ削除

[注意] formatコマンドでは /dev/nvme0n1 を使う。sanitizeでは /dev/nvme0 を使う

再利用前提 -s1
sudo nvme format /dev/nvme0n1 -s1

破棄前提 -s2　※非対応の場合あり。
sudo nvme format /dev/nvme0n1 -s2

破棄前提最強 sanitize -a 4　※非対応の場合あり
sudo nvme sanitize /dev/nvme0 -a 4

-a 4が使えなかったら
sudo nvme sanitize /dev/nvme0 -a 2

(9)もういちどGPartedで確認。

unallocated（未割り当て）になっていれば少なくともドライブ情報などは消えている。

(10)消去後に先頭セクタの中身を確認。コマンドは同じ。

sudo hexdump -n 4098 -C /dev/nvme0n1

(11)念のため消去後に末尾側セクタの中身を確認。コマンドは同じ。

sudo bash -c 'hexdump -C -s $(($(blockdev --getsz /dev/nvme0n1)*512 - 4096)) /dev/nvme0n1'

USB外付けケース（アダプタ）に繋いでWindowsからTxBENCH消せるのではと思ったが、Secure EraseはUSB経由ではNGとわかった。

マザーボードに直挿ししてUbuntuから消去することにする。

今回は2026.4.13現在の安定版、Ubuntu 24.04.4 LTSのLIVE USBを作成。

2026.6.11追記　s.m.a.r.tのチェック方法

sudo smartctl -a /dev/sda

使用時間を知りたい場合は、
sudo smartctl -a /dev/sda | grep Power_On_Hours

コマンドがない場合にはインストールする。
sudo apt update
sudo apt install smartmontools

(1)USBメモリから起動。

(2)デバイスを調べる

Gpartedで確認し、削除対象のデバイスは /dev/sda とわかる。

(3)SSDの状態を確認する。
sudo hdparm -I /dev/sda
Securityのセクションに注目。

----------
Security:
......
supported
not enabled
not locked
frozen

----------

supported：Secure Erase機能に対応している
not enabled：セキュリティロック（パスワード）が設定されていない
not locked：ロックされていない
frozen：BIOS/UEFIレベルでSSDへのアクセスが禁止されている

(4)frozen解除のため、OSをスリープさせる。
sudo systemctl suspend

GUIでは画面右上の電源マークから。

UbuntuではSuspendを選ぶ。

サスペンドの後、not frozenに変わった。

(5)消去前に先頭セクタの中身を確認
sudo hexdump -n 4096 -C /dev/sda
-n でバイト数を制限する（4098は余裕めに）

"EFI PART"などなんとなく意味のあるデータが入っていることがわかる。

(6)念のため、消去前に意味のある文字列の存在を確認
sudo dd if=/dev/sda bs=512 count=32 | strings
※512バイト(1セクタ)単位で読み込み、32セクタ = 16384バイト
stringsコマンドがないとエラーになったら、インストール可能。
sudo apt install binutils

やはりEFI PARTが文字列として残っている。

(7)更に念のため、末尾側セクタの中身を確認

sudo bash -c 'hexdump -C -s $(($(blockdev --getsz /dev/sda)*512 - 4096)) /dev/sda'

やはり、意味のあるデータが残っている。
次から消去プロセス。

(8)一時パスワードの設定
sudo hdparm --user-master u --security-set-pass p /dev/sda

(9)Secure Eraseを実行する。
sudo hdparm --user-master u --security-erase p /dev/sda

(10)もういちどGPartedで確認。

unallocatedになっていれば少なくともドライブ情報などは消えている。

(11)消去後に先頭セクタの中身を確認
sudo hexdump -n 4098 -C /dev/sda

読み取りができる何か意味のある文字列が残っていないか確認をする。
今回の場合、4098バイトの上限に満たずに読み込みが止まっている。止まっているということは良い兆候とChatGPTは言った。
Secure Erase前はどこまでもスムーズにデータが取れ得る、Secure Erase後読み込みが途中で止まるのは異常ではないとのこと。

(12)念のため消去後に末尾側セクタの中身を確認
sudo bash -c 'hexdump -C -s $(($(blockdev --getsz /dev/sda)*512 - 4096)) /dev/sda'

同じく有効なデータが何もないこととと、すべて読み込めていないことを確認。

ところが、

https://example.com/sub/.htaccess へブラウザでアクセスすると .htaccessがダウンロードできてしまい中身が見えてしまう問題に出会う。

なぜなのか理由がわからず。

ドキュメントルート直下の .htaccess にはアクセスを禁止する記述を書いていない。よって、httpd.confなど上位でやっているのだろう。
そして、サブフォルダ sub/.htaccessに許可する記述も書いていない。なぜだ。

このままでは怖いため、ドキュメントルート直下の .htaccess先頭に下記を明示することにした。

<Files ~ "^\.ht">
    Require all denied
</Files>

そうすると、下位階層でも 403になってくれた。

ちなみにダウンロードされるファイルは、Windowsではhtaccessに、Macでは Untitled.htaccessになった。ドットで始まるファイルはダウンロードできないようになっているのだろう。ブラウザの危機回避か。

findでファイルを抽出してsedにわたす。

以前、bashでの置換例を書きsedは遅いと書いた。
bashで文字列置換をする

遅くても便利なら使うのだ。

さて、"abc" を "efg" に書き換えるワンライナー（1行実行）の例は下記。

find . -type f -name "*.twig" -exec sed -i 's/abc/efg/g' {} +

これは、Gnu版のsedを使用する例
sed --version
sed (GNU sed) 4.2.2

同じコマンドをMacOSのBSD版で実施すると、エラーになる
エラーメッセージ「sed: 1: "./t2/index.twig": invalid command code .」
これには、ちょっとはまって混乱した。

BSD版sedでは、バックアップをとらないとき -i '' という明示をしないとだめということらしい。

Macでは、下記のコマンドになる。

find . -type f -name "*.twig" -exec sed -i '' 's/abc/efg/g' {} +

逆に、GNUのsedでこれをやると、
エラー「sed: s/abc/efg/g を読み込めません: そのようなファイルやディレクトリはありません」
-i に関して互換性がない。

ちなみに、今回一括置換をやろうと思ったのは、EC-CUBEのバージョンアップで .twig ファイルの書式が変わり、修正が必要になったため。

{% for f in form if f.vars.eccube_form_options.auto_render %}
↓
{% for f in form|filter(f => f.vars.eccube_form_options.auto_render) %}

下記のようなワンライナーで処理。

find . -type f -name "*.twig" -exec sed -i 's/ if f.vars.eccube_form_options.auto_render %}/|filter(f => f.vars.eccube_form_options.auto_render) %}/g' {} +

ssh -i ファイル名.ppk ユーザ名@サーバ名 -p ポート番号

そうすると、下記のエラー。

Load key "ファイル名.ppk": invalid format

フォーマットが違うと。それは、想定内。ppk形式だったから。
形式変換をする。

puttygen 変換前ファイル名.ppk -O private-openssh -o 変換後ファイル名_rsa

そうすると別のエラー。

sign_and_send_pubkey: no mutual signature supported
ユーザ名@サーバ名: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

rsaが許可されていないということか？

.ssh/config に以下を書き足す。

Host 接続先ホスト名
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

ここまでの対応で、踏み台サーバへのログインに成功する。

次に、本来接続したい、接続先への接続を試みる。
踏み台経由のscpについては、以前記事を書いた。

「scpで踏み台サーバを経由した多段転送のメモ」

ssh について踏み台経由の直接アクセスは下記のはず。

ssh -o ProxyCommand='ssh -W %h:%p -i 踏み台用の秘密鍵ファイル -p 踏み台ポート 踏み台ユーザ名@踏み台サーバ' -i 接続先秘密鍵ファイル 接続先ユーザ名@接続先サーバ名

すると下記のエラー。

Load key "接続先秘密鍵ファイル名": Invalid key length

キーの長さが異常だと。

OpenSSH 7.6以降では 1024bitのRSA鍵が使えなくなったとのこと。
ローカルのmacは OpenSSH 9.6 だったので、こりゃダメだ。
ssh -V
OpenSSH_9.6p1, LibreSSL 3.3.6

つまり、提供を受けた秘密鍵は、形式が違い、古く、ビット数が少ないものだったということ。

結果的には、多段の一連でのsshログインができなかった。
Windowsではできたかもしれないが、Putty、Poderosa、TeraTermどれも何かしらうまく行かない。設定が違うのか、ppkがそのままでは使えないのか未解決。

結果的には、ローカル(Mac)のOpenSSHからでは、Invalid kye lengthが解消できなかったため、一旦踏み台にログインし、踏み台では OpenSSH 6.Xだったことから、踏み台から改めて接続先サーバへsshすることで一応は解決。
気持ちの悪い結果になってしまった。

sedの遅さ（重さ）については、参考ページで数値化してくださっている。数百倍遅いとのこと。
参考ページ）
https://qiita.com/ko1nksm/items/b4b342f77f6d3ee1a0a9

bashでは正規表現の置換ができる。

aaaをcccに置換するとき、

DATA="aaa,bbb,aaa"
echo "${DATA/aaa/ccc}"

結果
ccc,bbb,aaa

最初にマッチした1つしか置換しないようだ。

全部置換するには、スラッシュを2個つける。

DATA="aaa,bbb,aaa"
echo "${DATA//aaa/ccc}"

結果
ccc,bbb,ccc

下記の例で、linux系のパスのディレクトリ部分だけ取り出して、Windows向けにスラッシュを円記号に変える処理。
dirnameと basenameも使い方（どっちだっけ？）をすぐ忘れてしまう。

path='aaa/bbb/ccc/test.html'
dir=`dirname $path`
file=`basename $path`

echo "dir:${dir}"
echo "file:${file}"

echo "dir(win):¥${dir//\//¥}" # すべて置換

結果
dir:aaa/bbb/ccc
file:test.html
dir(win):¥aaa¥bbb¥ccc

期待通りに動いた。スラッシュ（/）にエスケープのためのバックスラッシュ（\）をつけている。

CentOS系では、「shはbashのシンボリックリンクである」という情報を見かけた。

MacOSはBSD系らしいが、シンボリックリンクにはなっておらず、バイナリのサイズが違った。

しかし、上記の文字列置換のbash記述を/bin/shとしても問題なく実行できた。

「Ubuntuをインストール」をクリックする。

キーボードレイアウトでJapaneseを選択する

無線アクセスポイントへの接続設定。
「このネットワークに接続する」を選択して、利用可能なSSIDを選び暗号化キーを入力してインターネットに接続する。

通常のインストールで進めてみる。

状況を補足すると、端末はノートパソコンで内蔵ストレージ（SSD）にはWindows 11がインストールされている状態。
そこに、UbuntuのインストーラーUSBを挿しこのUSBから起動している。
そして、もう一本空の購入したままのUSBメモリを挿している。

内蔵SSDにWindowsとは別のパーティションを切ってUbuntuをインストールするのであれば、一番上の「Ubuntu を Windows Boot Manager とは別にインストール」でも良かったと思う。

Windowsを消してUbuntuを入れたいのであれば2番目の「ディスクを削除して Ubuntuをインストール」で良い。

今回は上記どちらでもなく、単独で起動可能なUbuntuのUSBメモリを作成したかった。

よって、最後の「それ以外」を選択した。

次の画面でインストール先を選択することになる。

前述の通り、/dev/sda は内蔵SSDでWindows。
/dev/sdb は起動したインストーラーUSB。
/dev/sdc はUbuntuをインストールしたい、新品の64GBUSBメモリ。
新品はFAT32になっていたので、ファイルシステムを変更してみる。

ext4を選択し、マウントポイントを / にした。

sdcへのインストールを進める。

データが消えるよ的な警告。問題なく続ける。

地域の指定。

初期ユーザを作成。

インストールが進む。後は待つだけ。
3〜4時間くらいかかったかも？
USBメモリ自体は3.0対応だったものの、USB 2.0のポートへ挿したからか。

無事にインストールが完了。

USBブートを行う。
特に指定はしなかったが、ローダの名称がubuntuでした。

無事に起動完了。

ちなみに、USBインストーラーで起動した時は、tryで試用すると、ユーザログインは不要。
いわゆるシングルユーザモードのような感じだった。

今回インストーラで正式にインストールしたubuntuは、インストール時にユーザを作成したように、ユーザログインが必要であった。

もう一つ、今回新規インストールしたUbuntuには Gparted がインストールされていなかった。

Ubuntu Softwareから簡単にインストールができた。

検索し、

インストールをクリックするだけ。
GUIで済んでしまう。

rpmとかyumとか、ターミナルでパッケージマネージャすら使わなくて良いみたい。
昔よりも楽になっている。

以前作ったUbuntu 19.04をしばらく使っていたところで、現在の最新版 22.04で作り直してみることにした。

(1)UbuntuのISOイメージをダウンロードする
(2)ISOイメージをRufusを使ってUSBメモリに書き込む

ちなみに、Rufusは
https://s-pro4.com/page-145.html
でも使用した。

まず、(1)UbuntuのISOイメージをダウンロードする

Ubunt日本語サイトへアクセスする。
https://www.ubuntulinux.jp/download

おそらくより日本語化されているであろう、日本語Remixを選択しておく。

ミラーサイトのどこからダウンロードしても良い。
今回は一番上の富山大学を選択した。

ubuntu-ja-22.04-desktop-amd64.iso をダウンロードする。
これで最初のステップは終わり。

次に (2)ISOイメージをRufusを使ってUSBメモリに書き込む

前段として、Rufus をダウンロードする。(Windowsの話)
https://rufus.ie/ja/

64ビット版の普通の .exe をダウンロードする。

rufus-4.4.exe はインストーラーではなくそのまま実行可能。

「選択」で前段でダウンロードした .iso ファイルを選択すると、「ボートの種類」に入る。

「パーティションの構成」でMBRかGPTが選択できた。
メリット・デメリットがあるが、MBRにしておいた。
あとは、念の為2箇所チェック。

「スタート」をクリックすると、選択と警告のポップアップが3つ続く。

でUSBメモリへインストーラの作成が完了。

中身のデータはこんな感じ。

そして、USBブートをしてみるといくつか選択可能。

「Try or Install Ubuntu」を選択すると下記の画面。

Ubuntuを試すこともできるし、Ubuntuをインストールすることもできる。

「試す」でもインターネットには接続でき、GPartedも使えるため、これだけでも十分な気がする。

次の記事「UbuntuをUSBメモリにインストールする」でインストールの流れを書いた。

mysqldump --default-character-set=utf8 --no-tablespaces -u {DBユーザ名} -p{DBパスワード} {DB名} -h {DBホスト名} | gzip -c > dump.sql.gz

mysqldump: [Warning] Using a password on the command line interface can be insecure.

Google翻訳によると日本語訳は、

mysqldump: [警告] コマンド ライン インターフェイスでのパスワードの使用は安全でない可能性があります。


言いたいことはわかりますね。パスワードを生で(見える状態で)打つのは危険とのこと。

ひとつは、-p にコマンドラインではパスワードを与えず、
mysqldump --default-character-set=utf8 --no-tablespaces -u {DBユーザ名} -p {DB名} -h {DBホスト名} | gzip -c > dump.sql.gz

Enter password: のプロンプトが出たらパスワードを打つこと。


もうひとつは、パスワードを含むDB接続情報を外部ファイルにしておくこと。

参考ページ）
https://beyondjapan.com/blog/2016/08/mysql56-warning/

mysql.cnfなどのファイル名で下記の内容を記載する。

[client]
user = hoge
password = hogehoge
host = 192.168.1.1

コマンドラインでは、--defaults-extra-file を使う。

mysqldump --defaults-extra-file=mysql.cnf '--default-character-set=utf8' --no-tablespaces {DB名}

こんな感じ。