Re: [Th] mdadm i mdadm.conf...
Dnia czwartek, 28 października 2010, Wieslaw Kierbedz napisał: W dniu 28.10.2010 21:26, Adam Gapiński anonsuje:: Ale initrd składa macierz i uruchamia ją poprawnie (choć tam w mdadm.conf jest uid wpisany). Dopiero po ruszeniu rc skryptów z tej macierzy pojawia się kłopot - rc.sysinit staje na: /sbin/mdadm --assemble --scan --auto=yes Znaczy linuxrc ją składa, a po przejściu w rootdevice coś ją rozkłada i rc.sysinit musi składać z powrotem? Jeżeli w ramdysku jest już pozbierana, to u mnie po przejściu do init X już nic macierzy nie dotyka, chyba, że mnie oczy oszukują. Zatem prawdopodobnie oczy Cię oszukują. Albo może poprostu robi się coś czego nie wiesz... Cóż zrobić... Nikt nie twierdzi, że macierz jest składana i rozkładana i składana spowrotem, a jedynie, że w rc.sysinit, mdadm z jakiegoś powodu czegoś się czepia tej macierzy w pewnych okolicznościach i my nie umiemy wymyśleć czego i dlaczego. ... No dobrze, to może od początku. Jest sobie partycja root na /dev/md1. I teraz, system wstaje bez żadnego problemu, czyli initrd uruchamia wszystko co trzeba i gdy w mdadm.conf jest wpis: ARRAY /dev/md0 uuid=19464854:03f71b1b:e0df2edd:246cc977 nie ma żadnych problemów i wszystko jest cacy. Natomiast gdy zamienimy w/w wpis w mdadm.conf na: ARRAY /dev/md0 devices=/dev/sda1,/dev/sdb1 rc.sysinit zatrzymuje się na wywołaniu mdadm --assamble --scan --auto=yes, wypluwając: mdadm: /dev/sdb1 has no superblock - assembly aborted Nie mam pojęcia po co, jakie ma ku temu powody i co ma w zamysle, ale system w tej sytuacji staje i tyle, co jest dziwne jeszcze bardziej, że te macierze są już złożone na etapie initrd i działają bez najmniejszego zająknięcia i na dodatek jak się po tym zatrzymaniu przjdzie dalej, czyli init 3 wszystko ładnie i grzecznie będzie działać. Ot co. Macierze są jakoś nie tak zrobione? Może mdadm ma jakiś problem? Ma ktoś jakiś hint?... Pozdrawiam -- : Grzegorz Pietrzak || gr...@artikon.pl : Cóż za smutna epoka, w której łatwiej jest rozbić atom niż zniszczyć : przesąd. : Albert Einstein ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: [Th] mdadm i mdadm.conf...
On Friday 29 of October 2010 09:32:29 Grzegorz Pietrzak wrote: Dnia czwartek, 28 października 2010, Wieslaw Kierbedz napisał: W dniu 28.10.2010 21:26, Adam Gapiński anonsuje:: Ale initrd składa macierz i uruchamia ją poprawnie (choć tam w mdadm.conf jest uid wpisany). Dopiero po ruszeniu rc skryptów z tej macierzy pojawia się kłopot - rc.sysinit staje na: /sbin/mdadm --assemble --scan --auto=yes Znaczy linuxrc ją składa, a po przejściu w rootdevice coś ją rozkłada i rc.sysinit musi składać z powrotem? Jeżeli w ramdysku jest już pozbierana, to u mnie po przejściu do init X już nic macierzy nie dotyka, chyba, że mnie oczy oszukują. Zatem prawdopodobnie oczy Cię oszukują. Albo może poprostu robi się coś czego nie wiesz... Cóż zrobić... Nikt nie twierdzi, że macierz jest składana i rozkładana i składana spowrotem, a jedynie, że w rc.sysinit, mdadm z jakiegoś powodu czegoś się czepia tej macierzy w pewnych okolicznościach i my nie umiemy wymyśleć czego i dlaczego. ... No dobrze, to może od początku. Jest sobie partycja root na /dev/md1. I teraz, system wstaje bez żadnego problemu, czyli initrd uruchamia wszystko co trzeba i gdy w mdadm.conf jest wpis: ARRAY /dev/md0 uuid=19464854:03f71b1b:e0df2edd:246cc977 nie ma żadnych problemów i wszystko jest cacy. Natomiast gdy zamienimy w/w wpis w mdadm.conf na: ARRAY /dev/md0 devices=/dev/sda1,/dev/sdb1 rc.sysinit zatrzymuje się na wywołaniu mdadm --assamble --scan --auto=yes, wypluwając: mdadm: /dev/sdb1 has no superblock - assembly aborted Nie mam pojęcia po co, jakie ma ku temu powody i co ma w zamysle, ale system w tej sytuacji staje i tyle, co jest dziwne jeszcze bardziej, że te macierze są już złożone na etapie initrd i działają bez najmniejszego zająknięcia i na dodatek jak się po tym zatrzymaniu przjdzie dalej, czyli init 3 wszystko ładnie i grzecznie będzie działać. Ot co. Macierze są jakoś nie tak zrobione? Może mdadm ma jakiś problem? Ma ktoś jakiś hint?... mozesz sprawdzic (strace) czy faktycznie mdassemble faktycznie odczytalo /dev/sdb1, czy dostalo jakis blad i komunikat 'has no superblock', to tylko bzdura. wrzuc tez nam wynik ' mdadm -QD /dev/md0' ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: [Th] mdadm i mdadm.conf...
Dnia piątek, 29 października 2010, Pawel Sikora napisał:
mozesz sprawdzic (strace) czy faktycznie mdassemble faktycznie odczytalo
/dev/sdb1, czy dostalo jakis blad i komunikat 'has no superblock',
to tylko bzdura.
wrzuc tez nam wynik ' mdadm -QD /dev/md0'
No to już...
Przy następujących wpisach w mdadm.conf:
DEVICE /dev/sd[ab][13]
ARRAY /dev/md1 devices=/dev/sdb1,/dev/sda1
ARRAY /dev/md3 devices=/dev/sdb3,/dev/sda3
#ARRAY /dev/md1 UUID=32e0590b:365f827d:8b62f743:401d69bd
#ARRAY /dev/md3 UUID=a74f0428:1997ebc4:504cb46f:032e2411
strace zeznaje następująco:
###stąd
execve(/sbin/mdadm, [/sbin/mdadm, --assemble, --scan, --auto=yes],
[/* 16 vars */]) = 0
brk(0) = 0x80ae164
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb777a000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=10433, ...}) = 0
mmap2(NULL, 10433, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb000
close(3)= 0
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0:n\1\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1421784, ...}) = 0
mmap2(NULL, 1432072, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7619000
mmap2(0xb7771000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x157) = 0xb7771000
mmap2(0xb7774000, 10760, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0xb7774000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7618000
set_thread_area({entry_number:-1 - 6, base_addr:0xb76186c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0,
mprotect(0xb7771000, 8192, PROT_READ) = 0
mprotect(0x8094000, 4096, PROT_READ)= 0
mprotect(0xb7798000, 4096, PROT_READ) = 0
munmap(0xb000, 10433) = 0
time(NULL) = 1288339796
getpid()= 1424
brk(0) = 0x80ae164
brk(0x80cf164) = 0x80cf164
brk(0x80d) = 0x80d
open(/etc/mdadm.conf, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0640, st_size=2911, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7779000
read(3, # mdadm configuration file\n#\n# m..., 4096) = 2911
brk(0x80cf000) = 0x80cf000
read(3, , 4096) = 0
read(3, , 4096) = 0
close(3)= 0
munmap(0xb7779000, 4096)= 0
uname({sys=Linux, node=poczta, ...}) = 0
geteuid32() = 0
open(/dev, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
getdents64(3, /* 1088 entries */, 32768) = 32744
getdents64(3, /* 1088 entries */, 32768) = 32744
getdents64(3, /* 783 entries */, 32768) = 23584
getdents64(3, /* 0 entries */, 32768) = 0
close(3)= 0
uname({sys=Linux, node=poczta, ...}) = 0
open(/dev, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
getdents64(3, /* 1088 entries */, 32768) = 32744
getdents64(3, /* 1088 entries */, 32768) = 32744
getdents64(3, /* 783 entries */, 32768) = 23584
getdents64(3, /* 0 entries */, 32768) = 0
close(3)= 0
open(/dev/sdb1, O_RDONLY|O_EXCL|O_DIRECT|O_LARGEFILE) = -1 EBUSY (Device or
resource busy)
write(2, mdadm: /dev/sdb1 has no superblo..., 54mdadm: /dev/sdb1 has no
superblock - assembly aborted
) = 54
###dotąd
Zatem zdaje się, że to nie wina mdadm...
Tylko po co on się czepia uruchomionej macierzy?...
A tutaj wynik mdadm -QD /dev/md1 zaraz po zatrzymaniu systemu:
###stąd
/dev/md1:
Version : 0.90
Creation Time : Mon Oct 25 11:38:02 2010
Raid Level : raid1
Array Size : 10490304 (10.00 GiB 10.74 GB)
Used Dev Size : 10490304 (10.00 GiB 10.74 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Fri Oct 29 10:15:32 2010
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : 32e0590b:365f827d:8b62f743:401d69bd
Events : 0.6
Number Major Minor RaidDevice State
0 810 active sync /dev/sda1
1 8 171 active sync /dev/sdb1
###dotąd
Pozdrawiam
--
: Grzegorz Pietrzak || gr...@artikon.pl
: Ciało dopiero przez erotyzm staje się interesujące i symboliczne.
: Karol Irzykowski
___
pld-users-pl mailing list
pld-users-pl@lists.pld-linux.org
Re: [Th] mdadm i mdadm.conf...
On Friday 29 of October 2010 11:02:08 Grzegorz Pietrzak wrote:
Dnia piątek, 29 października 2010, Pawel Sikora napisał:
mozesz sprawdzic (strace) czy faktycznie mdassemble faktycznie odczytalo
/dev/sdb1, czy dostalo jakis blad i komunikat 'has no superblock',
to tylko bzdura.
wrzuc tez nam wynik ' mdadm -QD /dev/md0'
No to już...
Przy następujących wpisach w mdadm.conf:
DEVICE /dev/sd[ab][13]
ARRAY /dev/md1 devices=/dev/sdb1,/dev/sda1
ARRAY /dev/md3 devices=/dev/sdb3,/dev/sda3
#ARRAY /dev/md1 UUID=32e0590b:365f827d:8b62f743:401d69bd
#ARRAY /dev/md3 UUID=a74f0428:1997ebc4:504cb46f:032e2411
strace zeznaje następująco:
###
(...)
open(/dev/sdb1, O_RDONLY|O_EXCL|O_DIRECT|O_LARGEFILE) = -1 EBUSY (Device
or resource busy)
write(2, mdadm: /dev/sdb1 has no superblo..., 54mdadm: /dev/sdb1 has no
superblock - assembly aborted
) = 54
###
Zatem zdaje się, że to nie wina mdadm...
z doswiadczenia wiem, ze EBUSY przy mdadm, oznacza, ze dane urzadzenie
jest juz zajete przez uruchomiona macierz, albo inna warstwe (np. lvm).
teraz trzeba tylko cos wyprostowac. zerknalem jeszcze raz w ten watek
i na poczatku pisales o md1 na sd{a,b}1
ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1
ARRAY /dev/md1 UUID=32e0590b:365f827d:8b62f743:401d69bd
pozniej piszesz o md0 na tych samych urzadzeniach sd{ab}1
ARRAY /dev/md0 uuid=19464854:03f71b1b:e0df2edd:246cc977
ARRAY /dev/md0 devices=/dev/sda1,/dev/sdb1
jest to nie jest jakas rekonfiguracja w trakcie rozwoju tego
watku, to chyba chcesz odpalic dwa razy macierz(e?) na tych
samych urzadzeniach podajac im explicite 'devices' w mdadm.conf.
mozesz wyjasnic gdzie siedzi md0 i md1, skoro md3 jest na sd{a,b}3?
___
pld-users-pl mailing list
pld-users-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: [Th] mdadm i mdadm.conf...
Dnia piątek, 29 października 2010, Pawel Sikora napisał:
On Friday 29 of October 2010 11:02:08 Grzegorz Pietrzak wrote:
Dnia piątek, 29 października 2010, Pawel Sikora napisał:
mozesz sprawdzic (strace) czy faktycznie mdassemble faktycznie
odczytalo /dev/sdb1, czy dostalo jakis blad i komunikat 'has no
superblock', to tylko bzdura.
wrzuc tez nam wynik ' mdadm -QD /dev/md0'
No to już...
Przy następujących wpisach w mdadm.conf:
DEVICE /dev/sd[ab][13]
ARRAY /dev/md1 devices=/dev/sdb1,/dev/sda1
ARRAY /dev/md3 devices=/dev/sdb3,/dev/sda3
#ARRAY /dev/md1 UUID=32e0590b:365f827d:8b62f743:401d69bd
#ARRAY /dev/md3 UUID=a74f0428:1997ebc4:504cb46f:032e2411
strace zeznaje następująco:
###
(...)
open(/dev/sdb1, O_RDONLY|O_EXCL|O_DIRECT|O_LARGEFILE) = -1 EBUSY
(Device or resource busy)
write(2, mdadm: /dev/sdb1 has no superblo..., 54mdadm: /dev/sdb1 has no
superblock - assembly aborted
) = 54
###
Zatem zdaje się, że to nie wina mdadm...
z doswiadczenia wiem, ze EBUSY przy mdadm, oznacza, ze dane urzadzenie
jest juz zajete przez uruchomiona macierz, albo inna warstwe (np. lvm).
teraz trzeba tylko cos wyprostowac. zerknalem jeszcze raz w ten watek
i na poczatku pisales o md1 na sd{a,b}1
ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1
ARRAY /dev/md1 UUID=32e0590b:365f827d:8b62f743:401d69bd
pozniej piszesz o md0 na tych samych urzadzeniach sd{ab}1
ARRAY /dev/md0 uuid=19464854:03f71b1b:e0df2edd:246cc977
ARRAY /dev/md0 devices=/dev/sda1,/dev/sdb1
jest to nie jest jakas rekonfiguracja w trakcie rozwoju tego
watku, to chyba chcesz odpalic dwa razy macierz(e?) na tych
samych urzadzeniach podajac im explicite 'devices' w mdadm.conf.
Oszfak...
Tonie rekonfiguracja to nieścisłość...
Od początku to jest:
DEVICE /dev/sd[ab][13]
ARRAY /dev/md1 devices=/dev/sdb1,/dev/sda1
ARRAY /dev/md3 devices=/dev/sdb3,/dev/sda3
#ARRAY /dev/md1 UUID=32e0590b:365f827d:8b62f743:401d69bd
#ARRAY /dev/md3 UUID=a74f0428:1997ebc4:504cb46f:032e2411
Jedyny odchył od normalności jest taki, że przy pierwszym podejściu zbudowana
była macierz /dev/md1 z /dev/sda1 i /dev/sdb1 z wersją metadanych której nie
rozumiało lilo i macierze zostały zrobione jeszcze raz z
opcją --metadata=0.90 (przy pomocy RescueCD)
Po tym w chroocie zainstalowany system i po pierwszym uruchomieniu już
rozważany błąd...
(ARRAY /dev/md0 uuid=19464854:03f71b1b:e0df2edd:246cc977 to jest wpis z
komentarzy w mdadm.conf, użyty przeze mnie na początku dla zobrazowania
problemu, bo nie miałem pod ręką problematycznego systemu. A póżniej to z
rozpędu powieliłem Przepraszam jeśli to zamieszało w rozważaniach...)
Pozdrawiam
--
: Grzegorz Pietrzak || gr...@artikon.pl
: Najlepsza część życia ludzkiego to małe, bezimienne i zapomniane akty
: dobroci i miłości.
___
pld-users-pl mailing list
pld-users-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: [Th] mdadm i mdadm.conf...
Osóbka znana jako Adam Gapiński, wystukała: # ls -l /dev/sd[ab]1 brw-rw 1 root disk 8, 1 2009-03-01 /dev/sda1 brw-rw 1 root disk 8, 17 2009-03-01 /dev/sdb1 # file -s /dev/sda1 /dev/sda1: x86 boot sector, LInux i386 boot LOader, code offset 0xeb # file -s /dev/sdb1 /dev/sdb1: x86 boot sector, LInux i386 boot LOader, code offset 0xeb Dokładnie tak samo jest po bootnięciu... Czyli wszystko działa, ale system zatrzymuje się na rc.sysinit... Co ciekawsze druga macierz wstaje bez problemu, czy to po dewajsach czy uidach. Problem dotyczy tylko tej powyższej, z której wstaje system. pozdrawiam -- Adam Gapiński : adas-news (at) artikon (dot) pl Na pytanie *Która godzina?* chciałem zainstalować rdate... (/me 18.05.2004) ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: [Th] mdadm i mdadm.conf...
On Thu, 28 Oct 2010 21:15:56 +0200, Adam Gapiński adas-n...@artikon.pl wrote: Osóbka znana jako Adam Gapiński, wystukała: # ls -l /dev/sd[ab]1 brw-rw 1 root disk 8, 1 2009-03-01 /dev/sda1 brw-rw 1 root disk 8, 17 2009-03-01 /dev/sdb1 # file -s /dev/sda1 /dev/sda1: x86 boot sector, LInux i386 boot LOader, code offset 0xeb # file -s /dev/sdb1 /dev/sdb1: x86 boot sector, LInux i386 boot LOader, code offset 0xeb Dokładnie tak samo jest po bootnięciu... nie patrz jak jest po bootnieciu, tylko jak jest na etapie initrd. prawdopodobnie major.minor urzadzenia zapakowanego do obrazu initrd nie zgadza sie z tym co jest w rzeczywistosci. ewentualnie problem moze tkwic w okrojonym mdassemble w initrd, ktore nie radzi sobie z zastana rzeczywistoscia :) ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: [Th] mdadm i mdadm.conf...
Osóbka znana jako Paweł Sikora, wystukała: On Thu, 28 Oct 2010 21:15:56 +0200, Adam Gapiński adas-n...@artikon.pl wrote: Osóbka znana jako Adam Gapiński, wystukała: # ls -l /dev/sd[ab]1 brw-rw 1 root disk 8, 1 2009-03-01 /dev/sda1 brw-rw 1 root disk 8, 17 2009-03-01 /dev/sdb1 # file -s /dev/sda1 /dev/sda1: x86 boot sector, LInux i386 boot LOader, code offset 0xeb # file -s /dev/sdb1 /dev/sdb1: x86 boot sector, LInux i386 boot LOader, code offset 0xeb Dokładnie tak samo jest po bootnięciu... nie patrz jak jest po bootnieciu, tylko jak jest na etapie initrd. prawdopodobnie major.minor urzadzenia zapakowanego do obrazu initrd nie zgadza sie z tym co jest w rzeczywistosci. ewentualnie problem moze tkwic w okrojonym mdassemble w initrd, ktore nie radzi sobie z zastana rzeczywistoscia :) Ale initrd składa macierz i uruchamia ją poprawnie (choć tam w mdadm.conf jest uid wpisany). Dopiero po ruszeniu rc skryptów z tej macierzy pojawia się kłopot - rc.sysinit staje na: /sbin/mdadm --assemble --scan --auto=yes pozdrawiam -- Adam Gapiński : adas-news (at) artikon (dot) pl Na pytanie *Która godzina?* chciałem zainstalować rdate... (/me 18.05.2004) ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: [Th] mdadm i mdadm.conf...
W dniu 28.10.2010 21:26, Adam Gapiński anonsuje:: Ale initrd składa macierz i uruchamia ją poprawnie (choć tam w mdadm.conf jest uid wpisany). Dopiero po ruszeniu rc skryptów z tej macierzy pojawia się kłopot - rc.sysinit staje na: /sbin/mdadm --assemble --scan --auto=yes Znaczy linuxrc ją składa, a po przejściu w rootdevice coś ją rozkłada i rc.sysinit musi składać z powrotem? Jeżeli w ramdysku jest już pozbierana, to u mnie po przejściu do init X już nic macierzy nie dotyka, chyba, że mnie oczy oszukują. -- WK ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: [Th] mdadm i mdadm.conf...
2010/10/27 Adam Gapiński adas-n...@artikon.pl: Czyli jednak nie zmienił deviców, bo: w mdadm.conf jest: [...] DEVICE /dev/sd[ab][13] #ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1 ARRAY /dev/md1 UUID=32e0590b:365f827d:8b62f743:401d69bd I teraz - wpisy z uidami działają zawsze, ale jak zostawię jawnie podane devajsy, to mam: # /sbin/mdadm --assemble --scan --auto=yes;echo $? mdadm: /dev/sdb1 has no superblock - assembly aborted 1 (oczywiście, po zmianie wpisów na uid mdadm zwraca grzecznie 2) Tu rc.sysinit woła o hasło roota. I teraz najlepsze - po wpisania hasła i: init 3 wszystko działa z devajsami podanymi jawnie w mdadm.conf. To jednak coś na poziomie kontaktu mdadm i rc.sysinit zgrzyta... Po wpisaniu hasła roota wystukaj: # ls -l /dev/sd[ab]1 # file -s /dev/sda1 # file -s /dev/sdb1 Pozdrawiam -- Artur Frysiak ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: [Th] mdadm i mdadm.conf...
Osóbka znana jako Artur Frysiak, wystukała: 2010/10/27 Adam Gapiński adas-n...@artikon.pl: Tu rc.sysinit woła o hasło roota. I teraz najlepsze - po wpisania hasła i: init 3 wszystko działa z devajsami podanymi jawnie w mdadm.conf. To jednak coś na poziomie kontaktu mdadm i rc.sysinit zgrzyta... Po wpisaniu hasła roota wystukaj: # ls -l /dev/sd[ab]1 # file -s /dev/sda1 # file -s /dev/sdb1 OK, jutro będę fizycznie przy maszynie to dam znać... Rozumiem, że mam to porównać, z tym co działa teraz, czyli: # ls -l /dev/sd[ab]1 brw-rw 1 root disk 8, 1 2009-03-01 /dev/sda1 brw-rw 1 root disk 8, 17 2009-03-01 /dev/sdb1 # file -s /dev/sda1 /dev/sda1: x86 boot sector, LInux i386 boot LOader, code offset 0xeb # file -s /dev/sdb1 /dev/sdb1: x86 boot sector, LInux i386 boot LOader, code offset 0xeb pozdrawiam -- Adam Gapiński : adas-news (at) artikon (dot) pl Na pytanie *Która godzina?* chciałem zainstalować rdate... (/me 18.05.2004) ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: [Th] mdadm i mdadm.conf...
On Tue, 26 Oct 2010, Grzegorz Pietrzak wrote: Czy wpisy w mdadm.conf typu: ARRAY /dev/md0 devices=/dev/sda1,/dev/sdb1 są dla aktualnego mdadm mniej koszerne niż: ARRAY /dev/md0 uuid=19464854:03f71b1b:e0df2edd:246cc977 ?!? Przy pierwszym wpisie mdadm (mdadm -A --scan --auto=yes - to jest w rc.sysinit ale puszczone z ręki jest identycznie) wywala błąd, przy drugim wszystko jest O.K.. Ki czort?... Błąd to brak metadanych w superbloku, czy coś koło tego, ale to raczej nie ma sensu bo macierz wstaje i tak, chyba że coś źle zrobiliśmy... UUID są zdecydowanie koszerniejsze. Na przykład jeżeli po upgrade kernela, albo powiedzmy po wymianie kontrolera SATA czy płyty głównej nagle kernel postanowi wykryć dawne /dev/sda jako /dev/sdc, a dawne /dev/sdb jako /dev/wtf, to przy konfiguracji z UUIDami nawet tego nie zauważysz. Wygląda na to, że właśnie coś takiego się u Ciebie stało i dlatego nie możesz zestawić areja po nazwach diwajsów. -- Pozdrawiam, Paweł ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: [Th] mdadm i mdadm.conf...
Dnia wtorek 26 październik 2010, Paweł Zuzelski napisał: UUID są zdecydowanie koszerniejsze. Na przykład jeżeli po upgrade kernela, albo powiedzmy po wymianie kontrolera SATA czy płyty głównej nagle kernel postanowi wykryć dawne /dev/sda jako /dev/sdc, a dawne /dev/sdb jako /dev/wtf, to przy konfiguracji z UUIDami nawet tego nie zauważysz. Wygląda na to, że właśnie coś takiego się u Ciebie stało i dlatego nie możesz zestawić areja po nazwach diwajsów. Ale to jest niuone instalacja... Nie było żadnego przenoszenia dysków czy czegokolwiek... I na dewajsach nie działa a na ułidach działa. WTF (ŁTF - tłumaczenie autora)? Pozdrawiam -- Grzegorz Pietrzak || g r z e h o r z wiadomoco t l e n wiadomoco p l Życie nie jest lepsze ani gorsze od naszych marzeń, jest tylko zupełnie inne. (William Szekspir) ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: [Th] mdadm i mdadm.conf...
W dniu 26.10.2010 22:21, Grzegorz anonsuje:: Dnia wtorek 26 październik 2010, Paweł Zuzelski napisał: UUID są zdecydowanie koszerniejsze. Na przykład jeżeli po upgrade kernela, albo powiedzmy po wymianie kontrolera SATA czy płyty głównej nagle kernel postanowi wykryć dawne /dev/sda jako /dev/sdc, a dawne /dev/sdb jako /dev/wtf, to przy konfiguracji z UUIDami nawet tego nie zauważysz. Wygląda na to, że właśnie coś takiego się u Ciebie stało i dlatego nie możesz zestawić areja po nazwach diwajsów. Ale to jest niuone instalacja... Nie było żadnego przenoszenia dysków czy czegokolwiek... I na dewajsach nie działa a na ułidach działa. WTF (ŁTF - tłumaczenie autora)? Ale instalację robiłeś cri, czy via rescue? Tak czy siak chrootem. A to już inny system - wystarczy inna kolejność ładowania modułów, a i to nie jest konieczne, żeby kolejność dysków sata/scsi się przestawiła. Wystarczy inny kernel. Paweł ci to przecież napisał. -- WK ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
