kiyoshi による投稿:

えっと、論点がずれていると思います。小生が謝罪を求めているのは、
１）「引っかき回すだけ引っかき回す」という表現方法の失礼さと、
２）jenpeterさんの#1と#3の状況を小生が無視せずに考慮して#4を投稿しているのに、小生が「毎回・・・相手の状況を無視して」ということを、そのトピック内の
https://forums.ubuntulinux.jp/viewtopic.php?pid=47474#p47474
でhitoさんが書き込まれたことが不適切であること
の2点です。

論点を把握しました。その2点については謝罪します。申し訳ありませんでした。
この機会に便乗するようで恐縮なのですが、「fdiskやddを用いた手段を案内するには、それ以外の手段がない場合だけにできないか、という相談をさせて頂きたいのですが、よろしいでしょうか。理由は次の通りです。これらには「毎回毎回」といった表現の背景も含まれます。

まず総論としては、
　・ddは強力すぎ、危険すぎるコマンドであるため、常用手段として使われては困る
　・デバイスの存在・動作確認の方法としてfdiskを使うのは妥当ではない
ということです。

100%確信を持って間違えることは仕方ないことですが、ddを紹介する、fdiskでデバイスの確認をする、というのは、「目的が果たされる手段のなかで最悪手」である可能性が高いです。少なくとも技術者としての主観では、kiyoshiさんのこれまで案内されているddを利用した確認やバックアップ手法については、「なんでこんなに危ないことをするんだろう」というレベルにあります。

たとえば、Linux上のddによるI/Oは/var/log/messagesの確認を必ず行わなければいけません。ddのコマンド出力の結果はI/Oの結果と合致することが保証されておらず、kernelレベルからI/Oエラーが返され、/var/log/messages等に記録されることがあります。特にwriteは、です。同様に、fdiskが報告するパーティションテーブル情報は不安定なハードウェア上では不適切なケースもあり、ddを行うための情報としては全く妥当ではありませんし、リムーバブルメディアの認識確認のために使うべきではありません。fdisk上認識されているが、何かの弾みでデバイス認識が変化し、また見えなくなる、というのは良くあることです。ddやfdiskの正確な動作は、ほかの基本コマンドに比べて複雑で、少なくともkernelのソースを読めるレベルでなければ把握できません。

また、ddは対話式のコマンドではないため、of/ifの間違いだけでも致命的な結果を招きますから、得られる結果に対して副作用やリスクが大きすぎるように思います。Windowsであれば修復インストールによるMBRの復元がありますし、リカバリCDによる復元など、MBR/PBRのバックアップを用いなくても元に戻す方法はいくらでもあります。ddをどうしても使うのであれば、HDD全体であれば複雑性が低くなり、楽な上にそれなりの安全性も担保できるでしょう（ただし、ほかの手段の方が確実です。確実に戻したいならそちら）。MBRやPBRを部分バックアップ・復元する方がメリットが、と思うかもしれませんが、フォーラム上でそれを行うことは困難でしょう（管理者やモデレータがそうした手順に触れていないことには気づいて頂いていると思うのですが、そうした「熟練者が案内したがらない手順」には相応以上の危険性があります）。

大半の場合はddやfdiskでの確認でも問題にならないから、ということで特にコメントせず放置していたこちらも悪いのですが、

また、小生の書いた内容が誤っていたり、「十分な使い分けがなされていない」、「目に余るケースが目立つ」と思われるのなら、そのような問題が小生によって書かれているトピック内で、誤りを指摘してくだされば良いのです。そのような批判は小生にとっても非常に有難いです。

という認識で行われているのであれば、話は別です。

十分な背景知識を持つのでなければ、「ddを用いた手法は常に危険である」「fdiskは、ふさわしくないケースの方が多い」と思って頂いた方が無難ですし、それで「救えないケース」が出てきても、致命的なリスクを背負うよりは良いでしょう。言い換えれば、常に「十分な使い分けがなされていない」「目に余る」、あるいは「フォーラム上で説明して案内するにはスキル不足である」と思って頂くべきです。

（この部分kiyoshiさん以外の人にも向けて）
ただし、この記述を権力装置として「ほかのddを紹介している人」への指摘として使うのは止めてほしいですし、ddを紹介している人に「これを見ろ」的な使い方をするのも止めてほしいです。
（ここまで）

危険を押して、それでも出すべき、と判断されるのはかまわないかと思いますが、現在の頻度で出てくるのはありえません。

さらに便乗で申し訳ありませんが、#2でいうところのfdiskの適切で無い使用例とはどういうものかご教示願えないでしょうか。
私も割と気軽にインストールに失敗した方などに、「sudo fdisk -lを実行して結果を教えて下さい」などと書いている方ですが、そのようなケースでも他に良い方法ありますでしょうか。
今回の議論の流れからデバイスが認識されているかの確認に、fdiskを用いるのは適切では無い、とも読めたのですが、ちょっと気になったので。。

拝承です。
ご教示ありがとうございました。

確かに同じHDDでも意図しない動作が起こると再起動をした後でも２つのコマンドは違う結果を示していますね。
(再起動後の同じHDDのデータサンプル)

デバイス ブート     始点        終点    ブロック   Id システム
/dev/sda1   *           1        1138     9140953+  83  Linux
/dev/sda2            1139        3816    21511035   83  Linux
/dev/sda3            3817        3817        8032+  83  Linux
/dev/sda4            3818        7296    27945067+   5  拡張領域
/dev/sda5            3818        4965     9221278+  83  Linux
/dev/sda6            4966        4969       32098+  82  Linux スワップ / Solaris
/dev/sda7            6584        7296     5727141   83  Linux
/dev/sda8            4970        6509    12370018+  83  Linux
/dev/sda9            6510        6583      594373+  82  Linux スワップ / Solaris

番号  開始    終了    サイズ  タイプ    ファイルシステム  フラグ
 1    32.3kB  9360MB  9360MB  primary   fat32             boot
 2    9360MB  31.4GB  22.0GB  primary   ext4
 3    31.4GB  31.4GB  8225kB  primary   ext4
 4    31.4GB  60.0GB  28.6GB  extended
 5    31.4GB  40.8GB  9443MB  logical   ext4
 6    40.8GB  40.9GB  32.9MB  logical   linux-swap(v1)
 8    40.9GB  53.5GB  12.7GB  logical   ext3
 9    53.5GB  54.1GB  609MB   logical   linux-swap(v1)
 7    54.1GB  60.0GB  5865MB  logical   ext3

ファイルシステムに関してはpartedが参照しているの方が正確である（ケースによる）

基本的にfdisk がダメなのでは無く、組み合わせて判断することで罠に落ちる可能性を軽減するとの事ですね。
勉強になりますm(__)m

※規約違反により追放されたユーザの投稿は、ログインユーザにのみ表示されます。

※規約違反により追放されたユーザの投稿は、ログインユーザにのみ表示されます。