Forum Debian Users Gang

Dzięki.
W syslogu znalazłem:

Unpacking udev ...
Setting up udev ...
udevadm_test:
udevadm_test:
A chroot environment has been detected, udev not started.

i na końcu:

Czytanie list pakietów...
Budowanie drzewa zależności...
Odczyt informacji o stanie ...
Następujące pakiety mają niespełnione zalezności:
mdadm: Wymaga: udev ale nie zostanie zainstalowany lub
makedev ale nie da się go zainstalować

Z grubsza rozumiem o co chodzi, ale nie mam pojęcia jak rozwiązać ten problem.
Zdziwiony jestem ciutkę bo kiedyś podobnie instalowałem debiana na macierzy od razu, co prawda /boot było na hda1 bez macierzy a reszta na urządzeniach RAID1 - tyle że tutaj problem jest z samą nieobecnością udev podczas instalacji a nie rozkładem drzewa na macierzach.

Ostatnio edytowany przez peadyr (2009-10-29 22:42:09)

tomii, tak też pomyślałem, spróbuję zainstalować stable na RAID1 i zrobić upgrade do testing.
Zastanawiam się czy jeśli postawię tak system testing  na RAID1 i będzie stał tak kilka lat w niedużym biurze głównie jako server samby, sftp, postgresql, dhcp, OpenLDAP cały czas aktualizowany w wersji testing, to czy po którejś aktualizacji mdadm bądź większych zmianach systemowych ta macierz mi się nagle nie posypie??

Jak się zastanowię to faktycznie stable wydaje się rozsądny, dotychczas jako że na lapku mam testing było mi bardzo wygodnie mając te same wersje pakietów na serwerze.
P.S. zacząłem ściagać stable.

Na stable zainstalowałem jak chciałem, niestety nie bardzawo rozumiem dlaczego nie mogłem na testing!!

Ostatnio edytowany przez peadyr (2009-11-02 22:11:58)

Jeżeli się nie myle to chodzi o wybranie użądzeć(partycji do raid) wybierz hda1 i hdb1 o ile są tego samego rozmiaru następnie do samo dla 5 i 6

mdadm --manage /dev/md0 --fail /dev/sdb1
mdadm --manage /dev/md0 --remove /dev/sdb1

a później dodajesz do nowa

Pierwsza ustawia /dev/sdb1 jako uszkodzony, druga usuwa uszkodzony /dev/sdb1 z macierzy.

Wykonaj cat /proc/mdstat przed tymi komendami i po kazdej - powinieneś zauważyć rożnicę (zwróć uwagi na znaki F, U, _)

Partycję /dev/sdb1 dodasz z powrotem poprzez:

mdadm /dev/md0 -a /dev/sdb1

i znowu zobacz /proc/mdstat, zobaczysz pasek postępu odbudowy macierzy

A podpiąłeś z powrotem dyski? Podepnij i sprawdź /proc/mdstat

Automatyczna synchronizacja byłaby bez sensu, bo skąd mdadm ma wiedzieć, że wcześniej usunięty/uszkodzony dysk jest sprawny? A i tak o zdegenerowaniu macierzy dowiesz się z logów/e-mail i będziesz musiał ustawić dany dysk/partycję jako uszkodzoną, usunąć z macierzy, a następnie po wymienieniu dysku dodać do macierzy.

Automatycznie dysk zostanie podmieniony i macierz zostanie odbudowana automatycznie, gdy wcześniej (przed awarią) dodasz dodatkowy ("zapasowy") dysk/partycję ustawisz go jako "hot spare" wtedy przejmie on zadanie tego uszkodzonego.

Musi być partycja, typ FD (Linix raid autodetect) no i o nie mniejszej pojemności niż ta uszkodzona, synchronizacja "ręczna". Albo od razu dołożyć dysk jako hot swap, ale w tym przypadku również musi być ww. partycja.

Przeprowadziłem chyba wszystkie możliwe scenariusze z awarią dysku. W każdej sytuacji mdadm sprawdził się w 100%. Jestem bardzo zadowolony z wyników testów. Ten temat pomógł mi w znacznym stopniu, dzięki chłopaki. Aż sobie go zapiszę gdzieś na dysku.

tomii napisał(-a):

możesz użyć : "sfdisk -d /dev/sda | sfdisk /dev/sdb" to skopiuje tablice partycji z jednego dysku na drugi .

Super się to sprawdziło po sformatowaniu jednego z dysków, który znajdował się w macierzy. Symulowałem wymianę dysku na nowy. Pięknie przywrócił tablice partycji. Macierz też się odbudowała bez problemów.

Ostatnio edytowany przez Luc3k (2011-01-22 12:50:44)

A jaki masz komunikat? Przypuszczam, że w Twoim przypadku pomoże instalacja gruba na wszystkich dyskach w macierzy.

PS. Wskazany byłby oddzielny wątek.