PLD systemd i mdadm

[stacho]

W dniu 2017-09-27 16:06, Tomasz Pala napisał(a):
> On Wed, Sep 27, 2017 at 15:35:36 +0200, stacho wrote:
> 
>> Teraz mam kolejny problem, mam cztery dyski, dwa na system (/)
>> i dwa na dane/bazę (/home ). Oba zestawy to raid1 i o ile ten
>> "rootowy" startuje (z EFI) bez problemów, to ten drugi "wisi"
> 
> A co go składa? Kernel (podawałeś opcje do cmdline), czy initrd?

Hmm, nie wiem, co go składa, dlatego pytam.
Do tej pory robiłem mdadm --create .....
Następnie: mdadm --detail --scan >>/etc/mdadm.conf
Dodany wpis do /etc/fstab i działalo.


>> przy starcie (90 sekund) z komunikatem że nie może się doczekać
>> na "md1" i wchodzi w tryb "maintenance", co odcina mi zdalny
> 
> Problem 90 sekund pojawia się na styku - eventów/stanów udeva, 
> mechaniki
> systemd oraz sposobu wskazywania składników wolumenu. W szczególności
> zobacz na moje rozwiązanie dot. BTRFS-a:
> 
> https://github.com/systemd/systemd/commit/0e8856d25ab71764a279c2377ae593c0f2460d8f
> 
> i dłuższa diagnoza przyczyn w bebechach w podłączonym tickecie.
> 
> W skrócie:
> - pojawia się urządzenie sda - ale nie jest gotowe,
> - pojawia się urządzenie sdb - wolumen jest gotowy do złożenia;
> - ...ale składnik pierwszy, tj. sda - wciąż nie jest gotowy, więc każda
>   próba odwołania się do niego zawodzi (zadziałałoby użycie sdb).
> 
> Rzecz w tym, że udev tworzy symlinki do gotowych urządzeń, więc gdyby
> montując btrfsa używać UUID-ów, wszystko automatycznie zadziała, gdy
> tylko odnajdzie się ostatnie urządzenie.
> 
> 
> W przypadku mdadma możesz szukać podobną ścieżką - gdy zostaniesz
> zrzucony do maintenance, sprawdź udevadm info stany poszczególnych
> składników (SYSTEMD_READY pewnie) i ustal, co próbuje, a nie może,
> złożyć macierzy.

Niestety brak czasu na takie próby, serwer jutro jedzie do klienta.

-- 
pzdr
Stacho Pal