Re: PLD systemd i mdadm

[Arkadiusz Miśkiewicz]

On Thursday 28 of September 2017, stacho wrote:

> Wielkie dzięki za pomoc i naprowadzenie! :)
> Kombinowałem jak i gdzie wgrać pliki z linku, nie trafiłem.
> W akcie desperacji wziąłem mdadm z centos 7 i przegrałem
> z ich rpma unity i rule w te same katalogi. Bingo!!!
> Macierz się "złozyła" i fs zamontował. :)
> Ewidentnie więc w naszym mdadm tego brakuje.

Zobacz nasze mdadm rel 4 ... czy zadziała (unity z mdadm).

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLD systemd i mdadm

[stacho]

W dniu 2017-09-27 23:16, Tomasz Pala napisał(a):

On Wed, Sep 27, 2017 at 21:20:14 +0200, stacho wrote:


A co go składa? Kernel (podawałeś opcje do cmdline), czy initrd?


Hmm, nie wiem, co go składa, dlatego pytam.


No to nie kernel, bo to byś musiał sobie sam zrobić, więc byś 
wiedział;)

geninitrd jak przed chwilą wspomniałem, chyba nie składa /home. To
możesz sprawdzić w maintenance (cat /proc/mdadm).


Do tej pory robiłem mdadm --create .
Następnie: mdadm --detail --scan >>/etc/mdadm.conf
Dodany wpis do /etc/fstab i działalo.


Pfff... filmów się naoglądał i chce, żeby zawsze mu działało;)


Tam, filmów! Na własne oczy widziałem jak (na wersji 221) działało!


W takim razie wg mnie nie ma NIC, co miałoby tę macierz złożyć - bo to
się odbywało po staremu w /etc/rc.d/rc.sysinit.


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.


Na szybko - albo sprawdź te unity i rule, albo sobie ręcznie dopisz do
initrd składanie tego, co mu tam brakuje. Ewentualnie zamiana geninitrd
na dracuta, ale mnie osobiście dracut nie przekonuje, a w razie awarii
cholernie ciężko się przebić przez niego do jakiegoś shella.

Chyba że ktoś zna metodę, aby w systemie z systemd dracut nie używał
systemd w swoim initramfsie?


Wielkie dzięki za pomoc i naprowadzenie! :)
Kombinowałem jak i gdzie wgrać pliki z linku, nie trafiłem.
W akcie desperacji wziąłem mdadm z centos 7 i przegrałem
z ich rpma unity i rule w te same katalogi. Bingo!!!
Macierz się "złozyła" i fs zamontował. :)
Ewidentnie więc w naszym mdadm tego brakuje.

--
pzdr
Stacho Pal
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLD systemd i mdadm

[Tomasz Pala]

On Wed, Sep 27, 2017 at 21:20:14 +0200, stacho wrote:

>> A co go składa? Kernel (podawałeś opcje do cmdline), czy initrd?
> 
> Hmm, nie wiem, co go składa, dlatego pytam.

No to nie kernel, bo to byś musiał sobie sam zrobić, więc byś wiedział;)
geninitrd jak przed chwilą wspomniałem, chyba nie składa /home. To
możesz sprawdzić w maintenance (cat /proc/mdadm).

> Do tej pory robiłem mdadm --create .
> Następnie: mdadm --detail --scan >>/etc/mdadm.conf
> Dodany wpis do /etc/fstab i działalo.

Pfff... filmów się naoglądał i chce, żeby zawsze mu działało;)

W takim razie wg mnie nie ma NIC, co miałoby tę macierz złożyć - bo to
się odbywało po staremu w /etc/rc.d/rc.sysinit.

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

Na szybko - albo sprawdź te unity i rule, albo sobie ręcznie dopisz do
initrd składanie tego, co mu tam brakuje. Ewentualnie zamiana geninitrd
na dracuta, ale mnie osobiście dracut nie przekonuje, a w razie awarii
cholernie ciężko się przebić przez niego do jakiegoś shella.

Chyba że ktoś zna metodę, aby w systemie z systemd dracut nie używał
systemd w swoim initramfsie?

-- 
Tomasz Pala 
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLD systemd i mdadm

[Tomasz Pala]

On Wed, Sep 27, 2017 at 20:45:49 +0200, stacho wrote:

>> Używasz dracut, czy geninitrd?
> 
> Używam geninitrd, po dodaniu drugiej macierzy (md1),
> wygenerowałem "nowe" initrd.

OK, geninitrd AFAIR nie tyka wolumenów, które mu nie są potrzebne, więc
/home nie składa.

> Jak pisałem, zrobiłem ileś tam, takich systemów, instalacja z pld rescue 
> i tar.gz .
> Działają, md1 startuje "normalnie, ostatni w marcu tego roku.
> PLD zawsze aktualne (th+ready).

Do 25 lutego mieliśmy bardzo stare systemd (221), więc może tu się
zmieniło. Ale nie ma co grzebać w przeszłości, spróbuj wrzucić unity
systemd i reguły udeva, które podałem, zamiast naszych z mdadma.

-- 
Tomasz Pala 
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLD systemd i mdadm

[Tomasz Pala]

On Wed, Sep 27, 2017 at 21:33:28 +0200, Jacek Konieczny wrote:

>> BTW nasz mdadm 4.0 nie ma spakowanych ani unitów z upstreamu:
>> 
>> https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/systemd
>> 
>> ani reguł udeva, żeby składały macierze: udev-md-*.rules
>> https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/
> 
> A odpowiednie unity nie przychodzą z systemd/udev?

Nie, zgodnie z filozofią systemd, są właśnie w upstreamowych paczkach.
Bo ich autorzy najlepiej wiedzą, jak używać swoich narzędzi.

Gdyby istniała metoda złożenia MD/DM bez tychże narzędzi, to do udeva by
została zaakceptowana (patrz btrfs, można złożyć bez btrfs device scan,
tj. bez btrfs-tools), ale o ile mi wiadomo, to albo kernel samodzielnie,
albo właśnie mdadm jest wymagany.

>> Nie używam mdadma na żadnym współczesnym systemie (z systemd), więc nie
>> mam za bardzo jak tego sprawdzić, ale raczej nie jest dziwne, że nie
>> działa.
> 
> SOA#1

Chodziło mi o to, że - jak przejżeć commitlogi tych unitów oraz reguł z
mdadma, obsługują tam sporo dziwnych corner-case'ów, włączając w to np.
kaskadowe MD, multipath itp. Tymczasem bez reguł udeva nie ma u nas nic,
co ustawi SYSTEMD_READY; systemd nie próbuje nawet montowania urządzeń,
które wg udeva nie są gotowe (w przeciwieństwie do rc.scripts czy choćby
mount -a). Więc jeżeli działa, to czy aby nie masz tego zamontowanego
lub przynajmniej złożonego właśnie z initrd gdzieś? I to tego naszego 
geninitrd, a
nie dracuta (który w systemach z systemd sam zaciąga systemd). Tak, że systemd
przychodzi na gotowe?

> Znaczy się prawie dobrze??? ale to raczej przez LUKS niż mdadm.

Jeżeli masz maszynę odpowiednią do testów, to namiary na unity podałem:)
Sam nie chcę tego w ciemno zmieniać, bo mdadma na systemd jak już
wspomniałem nie mam, z kolei LUKS-y mam, ale bez żadnego RAID-a, zresztą
składane z initrd.

-- 
Tomasz Pala 
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLD systemd i mdadm

[Jacek Konieczny]

On 2017-09-27 16:21, Tomasz Pala wrote:
> BTW nasz mdadm 4.0 nie ma spakowanych ani unitów z upstreamu:
> 
> https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/systemd
> 
> ani reguł udeva, żeby składały macierze: udev-md-*.rules
> https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/

A odpowiednie unity nie przychodzą z systemd/udev?

> Nie używam mdadma na żadnym współczesnym systemie (z systemd), więc nie
> mam za bardzo jak tego sprawdzić, ale raczej nie jest dziwne, że nie
> działa.

SOA#1
Znaczy się prawie dobrze… ale to raczej przez LUKS niż mdadm.

Jacek


___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLD systemd i mdadm

[stacho]

W dniu 2017-09-27 16:21, Tomasz Pala napisał(a):

BTW nasz mdadm 4.0 nie ma spakowanych ani unitów z upstreamu:

https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/systemd

ani reguł udeva, żeby składały macierze: udev-md-*.rules
https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/


Da się te rzeczy dodać "ręcznie"?
Jeśli tak, to co dodać i gdzie?
Mam czas tylko na kilka prób, dlatego tak "lamersko" pytam. ;)


Nie używam mdadma na żadnym współczesnym systemie (z systemd), więc nie
mam za bardzo jak tego sprawdzić, ale raczej nie jest dziwne, że nie
działa.


Jak nie mdadm, to czego używasz, btfrs??
--
pzdr
Stacho Pal
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: 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
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLD systemd i mdadm

[stacho]

W dniu 2017-09-27 15:45, Jacek Konieczny napisał(a):

On 2017-09-27 15:35, stacho wrote:

Drugi raid nie startuje i już. :(

Pomogło dopisanie do rc.local:
/sbin/mdadm -A /dev/md1 /dev/sdc1 /dev/sdd1

i zmodyfikowanie fstab zamiast opcji "defaults" jest:
"nofail,x-systemd.device-timeout=1" .

Dziwne to jakieś. :(
Wie ktoś, jak systemd "składa" i montuje kolejne macierze (raid)??


Używasz dracut, czy geninitrd?


Używam geninitrd, po dodaniu drugiej macierzy (md1),
wygenerowałem "nowe" initrd.


Systemd, jeżeli ma zauważyć macierze złożone w initramfs, to muszą one
mieć takie metadane w udev jakby to sam systemd zrobił. Odpowiedni
mdadm.conf i dracut (który wrzuca systemd do initramfs) powinny
załatwić sprawę. Problemy zaczynają się, gdy do tego dorzuci się
jeszcze LUKS i LVM – niektóre kombinacje wciąż sprawiają problemy.

Jak wygląda Twój mdadm.conf? Używasz UUID, czy ścieżek do
poszczególnych składników?


Mój mdadm.conf:

DEVICE partitions
MAILADDR ad...@test.pl
ARRAY /dev/md0 metadata=1.2 name=pld-new-rescue:0 
UUID=88243ae0:11e45828:3ef8d0c7:fc735077
ARRAY /dev/md1 metadata=1.2 name=firmcog:1 
UUID=d269771d:8c01b088:0d130746:ad86fe62


Jak pisałem, zrobiłem ileś tam, takich systemów, instalacja z pld rescue 
i tar.gz .

Działają, md1 startuje "normalnie, ostatni w marcu tego roku.
PLD zawsze aktualne (th+ready).

--
pzdr
Stacho Pal,
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLD systemd i mdadm

[Tomasz Pala]

BTW nasz mdadm 4.0 nie ma spakowanych ani unitów z upstreamu:

https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/systemd

ani reguł udeva, żeby składały macierze: udev-md-*.rules
https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/

Nie używam mdadma na żadnym współczesnym systemie (z systemd), więc nie
mam za bardzo jak tego sprawdzić, ale raczej nie jest dziwne, że nie
działa.

-- 
Tomasz Pala 
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLD systemd i mdadm

[Tomasz Pala]

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?

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

-- 
Tomasz Pala 
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLD systemd i mdadm

[Jacek Konieczny]

On 2017-09-27 15:35, stacho wrote:

Drugi raid nie startuje i już. :(

Pomogło dopisanie do rc.local:
/sbin/mdadm -A /dev/md1 /dev/sdc1 /dev/sdd1

i zmodyfikowanie fstab zamiast opcji "defaults" jest:
"nofail,x-systemd.device-timeout=1" .

Dziwne to jakieś. :(
Wie ktoś, jak systemd "składa" i montuje kolejne macierze (raid)??


Używasz dracut, czy geninitrd?

Systemd, jeżeli ma zauważyć macierze złożone w initramfs, to muszą one 
mieć takie metadane w udev jakby to sam systemd zrobił. Odpowiedni 
mdadm.conf i dracut (który wrzuca systemd do initramfs) powinny załatwić 
sprawę. Problemy zaczynają się, gdy do tego dorzuci się jeszcze LUKS i 
LVM – niektóre kombinacje wciąż sprawiają problemy.


Jak wygląda Twój mdadm.conf? Używasz UUID, czy ścieżek do poszczególnych 
składników?


Jacek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl