/ dev / sdaと/ dev / sdaをどのように交換しますか？
少年、これはそうです。 a。つまらない。質問、そしてまだ誰もそれを正しく答えることができないようです。
/ dev/sdaを/ dev/sdbと交換するにはどうすればよいですか？
誰かが永続的なラベル付け（たとえば/ dev/disk/by- *）を使用することを提案できますが、最善の意図にもかかわらず、これは[〜＃〜] not [〜＃〜] 質問に答えて。はい、恒久的なラベル付けは使用できる場所で機能しますが、プログラムを使用するためにハードコーディングされている場合などです。/dev/sda、この質問は続きます。
インターネットで見つけたものからさらに問題を説明するには： http://ubuntuforums.org/showthread.php?t=1569238&page=2 （「Schadenfreude」を思い出させる）
このチャップは解決策を見つけたようですが、共有しませんでした（boo！）： http://ubuntuforums.org/showthread.php?t=944515
そして、私は潜在的な同様の危険を抱えています。私はCloneZillaを使用していますが、プログラムで次のように要求された場合：Would you like to backup /dev/sda to /dev/sdb or /dev/sdb to /dev/sda ?、Linuxがディスクの順序をランダムに割り当てるように見えることを知って、どれだけ緊張していると思いますか。私はまだ自分のバックアップでデータを上書きしていませんが、これはただ起こるのを待っています。
Linux内で/ dev/sd *をディスクに割り当てるものと、このプロセスにどのように影響しますか？これはudev（/ etc/udev /、udevadm）と関係があるのでしょうか？私のOSはCentOSですが、UbuntuとCloneZilla（ http://clonezilla.org ）でもこれを知る必要があり、この問題はすべてのシステムで発生するため、この問題はディストリビューションに関連していますが、カーネル、カーネルモジュール、またはカーネルに非常に近いものに関連しています。助けてください！
------------------編集：2013年8月25日ypnosが提供したリンクをアドバイスした後、私はそれをすべて読んで、1つのコマンドを試してみると、カーネルは私の画面全体でudevルールを「許可」しました。次に、メンテナンスを許可するためにルートパスワードを要求するか、再起動のために終了します。これは、このようなものが実際に初心者向けではないという証拠です。
また、もう少し詳しく調べました。 Linuxカーネルがどのように、いつロードされるかはわかりませんが、インターネット上のいくつかのメッセージはBIOSがブート可能ディスクのリストをgrubに渡していることを示しており、それはdevice.mapファイルを使用しますどのデバイスをどのgrubに割り当てるか（hd *、）。永続的なdevシンボリックリンクを使用できるため、この段階では/ dev/sdがすでに定義されていることに注意してください。これらのデバイスマップは、実際のルートファイルシステムに何らかの形で渡されるようです。これは今やブートローダーのことですか？
潜在的な解決策としてudevに戻って、Googleでバグレポートを見つけました http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578826 udev NAMEを変更することは推奨されていません（最終的には/ dev/sd *になります）。
推奨されるudev MANページ：
| The following keys can get values assigned:
|
| NAME
| The name of the node to be created, or the name the network
| interface should be renamed to.
NOTE: changing the kernel-provided name of device nodes
(except for network devices) is not supported and can result
in unexpected behavior.
Today, the kernel defines the device nodes names, and udev
is expected to only manage the node's permissions and
additional symlinks.
...しかし、とにかく少し変更された方法でそれをやりに行きました。
# vi /etc/udev/rules.d/00-corrections.rules
KERNEL=="sd?", ATTRS{model}=="SAMSUNG SP0411N", NAME="sda"
KERNEL=="sd??", ATTRS{model}=="SAMSUNG SP0411N", NAME="sda%n"
KERNEL=="sda", ATTRS{model}!="SAMSUNG SP0411N", NAME="sdb"
KERNEL=="sda?", ATTRS{model}!="SAMSUNG SP0411N", NAME="sdb%n"
基本的に、「モデルがsamsungの場合、NAME sda *を割り当てます。モデルがSamsungではなく、sda *が割り当てられている場合、NAME sdb *を割り当てます。」このルールは、可能な限り他のすべてのルールの前に配置されました。いくつかの「目に見えない」ルールファイルもあるように見えるので、これについてはわかりません。また、デバイスの名前を変更しましたが、「kernel-loaded-memory」のどこかにカーネルの参照が間違っている可能性があります。これは、/ var/log/boot.logファイルを見ると明らかになるかもしれません。
%G Welcome to [0;36mCentOS[0;39m
Starting udev: %G[60G[[0;32m OK [0;39m]Setting hostname UncleFloServer: [60G[[0;32m OK [0;39m]ERROR: asr: seeking device "/dev/sda" to 5999998795264
ERROR: ddf1: seeking device "/dev/sda" to 5999998795264
ERROR: ddf1: seeking device "/dev/sda" to 5999998664192
ERROR: hpt45x: seeking device "/dev/sda" to 5999998790144
ERROR: isw: seeking device "/dev/sda" to 5999998794752
ERROR: jmicron: seeking device "/dev/sda" to 5999998795264
ERROR: lsi: seeking device "/dev/sda" to 5999998795264
ERROR: nvidia: seeking device "/dev/sda" to 5999998794752
ERROR: pdc: seeking device "/dev/sda" to 137438913024
ERROR: pdc: seeking device "/dev/sda" to 137438920192
ERROR: pdc: seeking device "/dev/sda" to 137438927360
ERROR: pdc: seeking device "/dev/sda" to 137438934528
ERROR: sil: seeking device "/dev/sda" to 5999998795264
ERROR: via: seeking device "/dev/sda" to 5999998795264
Setting up Logical Volume Management: No volume groups found
[60G[[0;32m OK [0;39m]Checking filesystems
_CentOS-6.4-x86_: clean, 85517/655360 files, 662649/2621440 blocks
/dev/sda1: clean, 56/65536 files, 33367/262144 blocks
[60G[[0;32m OK [0;39m]Remounting root filesystem in read-write mode: [60G[[0;32m OK [0;39m]Mounting local filesystems: [60G[[0;32m OK [0;39m]Enabling local filesystem quotas: [60G[[0;32m OK [0;39m]Enabling /etc/fstab swaps: [60G[[0;32m OK [0;39m]
ここで、私のSamsungデバイスは40GB（/ dev/sdaとして）、そして大きなAreca Raidは6TB（/ dev/sdbとして）です。
いくつかの残りの質問が残っています
エラーはどういう意味ですか？
これらのエラーはカーネルの原因ですか、それともudevの00-corrections.rulesの前に実行されているルールファイルの原因ですか？
これらのエラーは、データを脅かす何かを示していますか？ Arecaパーティションは、fstabのフォルダーのいずれにも問題なくマウントされました。
より良い、以前のデバイス割り当て方法はありますか？
最近では、LinuxカーネルはUDEVルールに従って/ dev /を動的に設定します。
まず、デバイスファイルがどのように機能するかを説明します。各デバイスファイル（通常はブロックデバイスファイル）には、メジャー番号とマイナー番号があります。これらの数値は、実際にファイルが指すデバイスを示しています。名前はこの点で何の役割も果たしません。ディスクの特定のケースを見てみましょう。
# ls -l sd*
brw-rw---- 1 root disk 8, 0 Aug 22 15:45 sda
brw-rw---- 1 root disk 8, 1 Aug 22 15:45 sda1
brw-rw---- 1 root disk 8, 2 Aug 22 15:45 sda2
brw-rw---- 1 root disk 8, 3 Aug 22 15:45 sda3
brw-rw---- 1 root disk 8, 5 Aug 22 15:45 sda5
brw-rw---- 1 root disk 8, 6 Aug 22 15:45 sda6
ここで、最初のディスクにはさまざまなパーティションがあり、8月22日午後3時にブートしたことがわかります。カーネルはルールに従ってファイルを作成しました。また、メジャー番号は8であり、マイナー番号はパーティションにアクセスするために使用されることもわかります（0はディスク全体を指します）。各行の先頭の「b」は、これらのそれぞれが特別な「ブロックデバイス」ファイルであることを示しています。
先ほど言ったように、カーネルは「最近」ファイルを動的に作成します。それはいつもそうではなかったし、他のUnixシステムではそうではありませんでした。そこで、ファイルは静的に作成され、ユーザーはこれらのファイルを作成または操作します。
独自の名前とメジャー/マイナー番号を使用して、独自のデバイスファイルを作成することは完全に可能です。 mknod（man mknod）そのため。ただし、再度ブートすると、カスタムファイルは表示されなくなります。
2番目の可能性は、UDEVルールを変更することです。ルールはシステムの起動時に処理され、恒久的に一貫した動作を保証します。これらのルールに関する適切なガイドは、次の場所にあります。 http://www.reactivated.net/writing_udev_rules.html
デバイスに一致する特定のハードウェア情報が与えられると、「sda *」を作成するルールを定義できることがわかります。 sdaを作成する元のルールを自分のものに置き換える必要があります。これがどのように機能するかは、ディストリビューションによって異なります。
これは初心者にとって危険なビジネスだと思うので、具体的な手順については説明しません。上記でリンクしたドキュメントは、必要なすべての情報を提供します。実際にすべて読む必要があります。