Chłopcze, to takie. za. trywialny. pytanie, a jednak nikt nie jest w stanie odpowiedzieć poprawnie.

Jak zamienić / dev / sda na / dev / sdb?

Ktoś może zasugerować używanie trwałego etykietowania (np. / Dev / disk / by- *), ale mimo najlepszych intencji to robiNIE Odpowiedz na pytanie. Tak, trwałe etykiety działają tam, gdzie można ich używać, ale jeśli program jest na stałe używany, np. / dev / sda, to pytanie trwa.

Aby zilustrować problem dalej od tego, co znalazłem w Internecie:http://ubuntuforums.org/showthread.php?t=1569238&page=2 (Przypomina mi „Schadenfreude”)

Ten facet najwyraźniej znalazł rozwiązanie, po prostu go nie udostępnił (boo!):http://ubuntuforums.org/showthread.php?t=944515

I tbh, mam potencjalne podobne zagrożenie. Używam CloneZilla i jeśli program pyta:Would you like to backup /dev/sda to /dev/sdb or /dev/sdb to /dev/sda ?Zgadnij, jak zdenerwowany jestem, wiedząc, że linux wydaje się losowo przypisywać zlecenia dyskowe. Nie nadpisałem jeszcze moich danych własną kopią zapasową, ale to tylko czeka, aby się wydarzyło.

Co w Linuksie przypisuje / dev / sd * do dysków i jak wpływasz na ten proces? Czy ma to coś wspólnego z udev (/ etc / udev /, udevadm)? Mój system operacyjny to CentOS, ale muszę to wiedzieć także dla Ubuntu i CloneZilli (http://clonezilla.org), a ten problem występuje we wszystkich systemach, więc domyślam się, że ten problem nie jest związany z dystrybucją, ale raczej z jądrem, modułami jądra lub czymś bardzo blisko jądra. Proszę pomóż!

------------------ EDYCJA: 25 sierpnia 2013 r Po powiadomieniu o linku, który podał ypnos, przeczytałem to wszystko, wypróbowałem jedno polecenie, a jądro po prostu „przepuściło” reguły udev na całym ekranie. Następnie monit o podanie hasła roota, aby zezwolić na konserwację, lub zamknij na ponowne uruchomienie. To dowód, że rzeczy te nie są dla nowicjusza.

Spojrzałem też trochę dalej. Nie rozumiem, jak lub kiedy ładuje się jądro Linuksa, ale kilka wiadomości w Internecie wskazuje, że BIOS (!! wierz lub nie) przekazuje listę dysków booteable do grub, która następnie używa pliku device.map przypisać urządzenia, do których grub (hd *,). Zauważ, że / dev / sd zostały już zdefiniowane na tym etapie, ponieważ możesz użyć stałych dowiązań symbolicznych. Te mapy urządzeń wydają się w jakiś sposób przekazywać do rzeczywistego głównego systemu plików. Czy to teraz jest bootloader?

Wracając do udev jako potencjalnego rozwiązania, znalazłem raport błędu w googlehttp://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578826spowodowało to rozwiązanie, w którym DISADviced zmienił nazwę udev NAME (która ostatecznie stanie się / dev / sd *, jaką znamy).

Sugerowane strony 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.

... Ale i tak poszedłem zrobić to w nieco zmieniony sposób.

# 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"

Zasadniczo to, co robi, to „Jeśli model jest samsung, przypisz mu nazwę NAZWA sda *. Jeśli model nie jest Samsungiem, ale został przypisany sda *, przypisz mu nazwę NAZWA sdb *”. Ta zasada została umieszczona przed wszystkimi innymi regułami w jak największym stopniu. Zauważ, że nie jestem tego pewien, ponieważ wydaje się, że istnieją także „niewidzialne” pliki reguł, I chociaż nazwy urządzeń zostały zmienione, jądro gdzieś w „pamięci ładowanej przez jądro”, nadal może być błędne. Może to być oczywiste, gdy spojrzysz na plik /var/log/boot.log, gdzie w moim przypadku, na początku mówi:

%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]

Tutaj moje urządzenie Samsunga ma 40 GB (chciałbym jako / dev / sda), a moja duża Areca Raid to 6 TB (chciałbym, aby był to / dev / sdb).

Pozostałe pytania pozostają

Co oznaczają błędy?

Czy te błędy są przyczyną jądra lub przyczyną pliku reguł nadal działającego przed moimi poprawkami 00.rules z udev?

Czy te błędy wskazują na coś zagrażającego danych? Partycja Areca nie zawierała żadnych problemów w jednym z moich folderów w fstab.

Czy istnieje lepsza, wcześniejsza metoda przypisywania urządzeń?