Re: KDE 4.5.2, kate scripting
On Friday 29 of October 2010 16:03:53 Daniel Dawid Majewski wrote: > W odpowiedzi na wiadomość z dnia 28.10.2010 21:52, od Marcin Kurzyna: > > Cześć, > > > > Czy komuś z was działa pisanie skryptów (JS) do kate? A jeśli tak to co > > trzeba zrobić, żeby pojawilo się coś w ustawienia -> rozszerzenia -> > > skrypty oraz jako menu w narzędziach? > > > > KDE 4.5.2 - testowane na Th (main+devel) i na Ti (main+dev+dev-test) - > > na obu liniach identyczny efekt (a raczej jego brak). > > Tak sobie googlnąłem : > http://docs.kde.org/ > stable/en/kdesdk/kate/advanced-editing-tools-scripting.html Cieszę się, to teraz już wiesz co można osiągnąć dzięki skryptom. serdecznie pozdrawiam m ps. sorry, ale twoja odp jest mało uzyteczna. ja wiem jak działają skrypty i jak je pisać. pytanie dotyczy *czemu*w*PLD*nie*działa. no chyba że SOA#1 - to też jakaś odp bo mogę szukać u siebie błędu, ew różnic w wersjach, ale tego też nie powiedziałeś. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: KDE 4.5.2, kate scripting
W odpowiedzi na wiadomość z dnia 28.10.2010 21:52, od Marcin Kurzyna: > Cześć, > > Czy komuś z was działa pisanie skryptów (JS) do kate? A jeśli tak to co > trzeba > zrobić, żeby pojawilo się coś w ustawienia -> rozszerzenia -> skrypty oraz > jako menu w narzędziach? > > KDE 4.5.2 - testowane na Th (main+devel) i na Ti (main+dev+dev-test) - na > obu > liniach identyczny efekt (a raczej jego brak). Tak sobie googlnąłem : http://docs.kde.org/ stable/en/kdesdk/kate/advanced-editing-tools-scripting.html -- Pozdrawiam, Daniel Dawid Majewski jabber:light-i/pld-users.org ___ 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...
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ł:
> 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
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 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
