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
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ł;)
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
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ś
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
>>
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/
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/
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
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" .
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
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
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
Witam,
Mam do instalacji taki dość pechowy serwerek.
Pierwszym problemem było (U)EFI, musiałem się nieźle podszkolić
z tego "wynalazku" żeby PLD wystartowało za pomocą biosu EFI.
Teraz mam kolejny problem, mam cztery dyski, dwa na system (/)
i dwa na dane/bazę (/home ). Oba zestawy to raid1 i o
13 matches
Mail list logo
