Re: rtld i386 versus amd64
On 02/21/11 14:35, kron24: Druhy problem je komunikace pres routing-socket, kde se predavaji binarni data a asi jsou spatne interpretovana - to je trochu horsi. Lepsi varianta je, ze to je nezamysleny bug - bud' ta data nemaji byt architekturne zavisla (a chyba je, ze jsou), nebo zavisla byt mohou a kernel je ma zavisle interpretovat (a chyba je v teto logice). V takovem pripade je treba chybu najit, odreportovat U toho "route" me trochu znervoznuje, ze takovych nefunkcnich programu muze byt vic a ja si jich akorat zatim nevsiml. Zkratka pocet prekazek cestou jeste muze rust. Ne az tam moc. Nejedna se o rutinni provoz hybridniho amd64/kernel+i386/world systemu. Jedna se o transientni stav v prubehu upgrade. Staci tedy, pokud budou fungovat ty utility, ktere jsou treba k provedeni dalsi faze upgrade - coz je 'make', 'install' a jelikoz je treba pristup k siti, tak take utility, ktere umozni konfiguraci site - tedy 'ifconfig' a 'route'. O moc vic by treba byt nemelo. Nasi situaci pak zjednodusuje to, ze oba naposled jmenovane jsou v adresari /rescue/, takze nam staci zaridit aby se behem tohoto kroku upgrade pouzivaly tyhle (jsou staticky slinkovane, takze nepotrebuji zadne knihovny) a nikoliv i386 varianty z upgradovaneho systemu. Otazka pro tento okamzik tedy je - jak doplnit do PATH /rescue (na zactek) tak brzo, aby se zmena uplatnila uz po restartu a tedy pro pro spoustene /etc/rc.d scripty. I shell pouziva '/etc/profile', takze by to nemel byt slozity problem. Co kdybychom si zjednodusili zadani a mohli vyuzit swap? Odpojit, nahrat na nej mfsBSD Martina Matusky, "nejak" (ted hned nevim jak) prinutit loader, aby po rebootu natahl msfBSD Pouze zasahem do loaderu. Loader natahuje vzdy partition 'a'. Cekove se mi to ale az tak moc nelibi - to bude znamenat vypadek poskytovanych sluzeb po celou dobu upgrade. Ja jsem zatim zvykly spis na to, ze mi stroje co mozna nejnormalneji funguji i behem upgrade, globalni vypadky zpusobuji jen restarty - a lokalni pak samozrejme restarty jednotlivych sluzeb behem upgrade portu. Neni to sice bezpodminecne nutne, ale ... Reboot, z mfsBSD jednoduse prerazit puvodni system Navic - kdyby takhle, tak to znam jednodussi zpusob. Ten, kterym jsem v uvahach zacal uplne puvodne. Po upgrade kernelu tak, jak ho mame popsany uz ted, bych jest epred restartem udelal make DESTDIR=/amd64 installworld tim bych dostal "cistou" instalaci amd64 worldu - jen ne v rootu, ale v jinem adresari Pak uz zbyva napsat kernelovy modul, ktery dokaze namountovat disk 'rw' a udelat move vsech souboru a adresaru do rootu. Po restartu nabehne amd64 kernel - a nez vubec dojde na prvni program worldu, popsany kernelovy modul prehazi /amd64 do / - system tak nabehne uz do stavu amd64/kernel+amd64/world Takovy modul by ve skutecnosti nebyl ani dlouhy, ani slozity ... Dan -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: rtld i386 versus amd64
On 02/22/11 13:01, Dan Lukes: Nasi situaci pak zjednodusuje to, ze oba naposled jmenovane jsou v adresari /rescue/, takze nam staci zaridit aby se behem tohoto kroku upgrade pouzivaly tyhle (jsou staticky slinkovane, takze nepotrebuji zadne knihovny) a nikoliv i386 varianty z upgradovaneho systemu. Mozna blabolim ... Nemame spravny ld-elf.so.1 - nejsem si az tak jisty, zda muzeme pouzit amd64/binar byt' staticky slinkovany ... Dan Asi bych mel zajit za lekarem, kdyz uz v odbornych konferencich oponuju sam sobe ... -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: rtld i386 versus amd64
Dan Lukes wrote: On 02/21/11 14:35, kron24: [...] Co kdybychom si zjednodusili zadani a mohli vyuzit swap? Odpojit, nahrat na nej mfsBSD Martina Matusky, "nejak" (ted hned nevim jak) prinutit loader, aby po rebootu natahl msfBSD Pouze zasahem do loaderu. Loader natahuje vzdy partition 'a'. Cekove se mi to ale az tak moc nelibi - to bude znamenat vypadek poskytovanych sluzeb po celou dobu upgrade. Behem vsech tech vylomenin s ld-elf atd. chces mit v provozu vsechny sluzby? To bych se skoro bal tohle risknout. Ja jsem zatim zvykly spis na to, ze mi stroje co mozna nejnormalneji funguji i behem upgrade, globalni vypadky zpusobuji jen restarty - a lokalni pak samozrejme restarty jednotlivych sluzeb behem upgrade portu. Neni to sice bezpodminecne nutne, ale ... Take jsem zvykly na minimalni vypadky jen pri rebootu, ale v pripade prechodu z i386 na amd64 bych si dokazal oduvodnit par minut downtime navic na to casove okno, po ktere bych provadel nahrazeni puvodnich 32bit souboru temi novymi 64bitovymi. (coz by v zavislosti na rychlosti disku a jednoho rebootu navic, bylo stejne jen par minut) Takze to vase snazeni tady mi prijde jako zbytecne slozite a jen s usmevem ho pozoruji z povzdali. Stale si myslim, ze je proste jednodussi na chvili pouzit swap, nebo tmp, kam si hodim system, ze ktereho nabootuji a pak puvodni 32bit nahradim 64bit... zadne upravy ve zdrojacich, psani kernelobych modulu atd. V ramci rocniho uptime se timhle stejne snizi dostupnost sluzeb asi tak o setinu promile :) Mirek -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: rtld i386 versus amd64
On 02/22/11 16:40, Miroslav Lachman: Cekove se mi to ale az tak moc nelibi - to bude znamenat vypadek poskytovanych sluzeb po celou dobu upgrade. Behem vsech tech vylomenin s ld-elf atd. chces mit v provozu vsechny sluzby? To bych se skoro bal tohle risknout. Kdyz ta sluzba nebude fungovat, nebude to horsi, nez kdyz bude programove vypnuta. A mimochodem - zatim jsme se vetsim vylomeninam uspesne vyhnuli. Momentalne drhneme na jedinem vetsim problemu - ze proklamovana kompatibilita umoznujici beh 32bitovych aplikaci na 64bitovem jadre neni, podle vseho tak univerzalni, jak se tvrdi. Jo - a pak jeste na tom, ze nikdo zucastnenych nevi jak vlastne presne funguje ldconfig ... Take jsem zvykly na minimalni vypadky jen pri rebootu, ale v pripade prechodu z i386 na amd64 bych si dokazal oduvodnit par minut downtime navic na to casove okno, po ktere bych provadel nahrazeni puvodnich 32bit souboru temi novymi 64bitovymi. (coz by v zavislosti na rychlosti disku a jednoho rebootu navic, bylo stejne jen par minut) Zalezi kolik stroju mas v provozech, kdy se vypadek ta udelat pouze o weekendu v noci a i tak se ta tebe osklive ksichti. Mozna bys zjistil, ze rok nema tolik weekendu, abys mohl delat updaty na miste. Takze to vase snazeni tady mi prijde jako zbytecne slozite a jen s usmevem ho pozoruji z povzdali. Nepsal jsem posledne, ze jsem nad tim premyslel pri skrabani brambor ? To neni o tolik vetsi ztrata casu nez "pozorovat a usmivat se" ;-) Ja nevim, jestli se to podari dotahnout do funkcniho stavu, a popravde receno, tim myslim takovy stav, abych si ho troufnul skutecne rutinne pouzivat. Zatim je to spis takove mentalni cviceni pro volne chvile. A nevim co si z toho odnese kdo jiny, ale ja uz mam par novych poznatku, ktere sice mozna neuplatnim nakonec pri zadnem upgrade, ale kdo vi, pri reseni jakeho/ciho problemu kdy budou potreba ... Ber to tak, ze mam spoustu prace a obcas se potrebuju vytrhnout a premyslet o necem, o cem zrovna premejslet povinne nemusim. No tak jsem si vybral tohle. Jo, ano, jasne - mas pravdu - o zenskejch uz jsem taky slysel. To ale probiram v jiny konferenci. ;-) Stale si myslim, ze je proste jednodussi na chvili pouzit swap, nebo tmp, kam si hodim system, ze ktereho nabootuji a pak puvodni 32bit nahradim 64bit Ja mluvim o tom, ze ten upgrade udela script. To, cos tak pekne popsal dvema vetama ja vidim bud' na docela slozite shellovske programovani, nebo na dost velky objem dat prenaseny po siti - cast dokonce opakovane. A to nemluvim o tom, ze zdaleka ne vsude mam swap ani o problemech, se kterymi se opakovane potykam pri pokusech editovat MBR nebo LABEL na "zivem" systemu. Nicmene ano, i timhle smerem by reseni mohlo vest. Dan -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: FBSD a cestina
Hmmm - tak asi chci po systemu hold moc... :-( Dne 18.2.2011 18:42, Zbyněk Burget napsal(a): Jde mi o to, ze mam na nejakem disku data, kodovani v nazvech souboru je utf-8. A ja bych potreboval je spravne videt jak na terminalu ve FBSD, fajn, slevim z toho, ze to nemusim videt spravne v terminalu - to nejak zkousnu tak pres systemove ftpd (X netreba resit - ty tam nejsou a nikdy ale to ftpd proste musim nejak rozchodit. V pripade nouze nejvyssi ani nebudu trvat na systemovem ftpd a neco priinstaluju (napr. jinde pouzivam proftpd, takze kdyby to napr. slo pres nej) - systemove ftpd bych ale bral nejradsi. Pokud to ma nejaky vyznam, tak dodam, ze jako ftp klient se bude pouzivat TotalCommander na Win - a tam proste potrebuju za kazdou cenu videt spravne nazvy souboru. -- Zbyněk Burget Nádražní 224 798 26 Nezamyslice tel: 588 580 000, 739 930 931 IČ: 606 88 220 DIČ: CZ7210184674 -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: FBSD a cestina
Dne 20.2.2011 17:46, Kaminar napsal(a): FreeBSD UTF-8 v konzoli zatim nepodporuje. Ale snad se na tom pracuje. Tahle informace mne celkem prekvapila, kdyz uz par let je v locale i cs_CZ.UTF-8 Ja ale opravdu cestinu nemel dlouho duvod resit, tak jsem ani nepatral po tom co jak v teto oblasti funguje... -- Zbyněk Burget Nádražní 224 798 26 Nezamyslice tel: 588 580 000, 739 930 931 IČ: 606 88 220 DIČ: CZ7210184674 -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: rtld i386 versus amd64
Dne 22.2.2011 13:01, Dan Lukes napsal(a): Co kdybychom si zjednodusili zadani a mohli vyuzit swap? Odpojit, nahrat na nej mfsBSD Martina Matusky, "nejak" (ted hned nevim jak) prinutit loader, aby po rebootu natahl msfBSD Pouze zasahem do loaderu. Loader natahuje vzdy partition 'a'. Ne, jde to zvladnout i konfiguracne. Tyhle radky v loader.conf (v puvodnim systemu) mi zajistily reboot do noveho systemu na byvalem swapu: currdev="disk0s1b" rootdev="disk0s1b" vfs.root.mountfrom="ufs:/dev/ad0s1b" Mozna jde vypustit rootdev, nezkousel jsem, proste jsem si vzal ksandy i opasek :-) Vlastne uz se mi ten "zjednoduseny" prevod 32bit na 64bit pres ssh povedl, kdyby nekdo mel zajem, dam dokupy poznamky a sepisu to. Nepouzil jsem mfsBSD, ale "standarni" minimalni system. Jinak to vicemene odpovidalo tomu memu nastrelu. Cekove se mi to ale az tak moc nelibi - to bude znamenat vypadek poskytovanych sluzeb po celou dobu upgrade. Je to vypadek na par minut, kdy z "provizorniho" systemu nainstalujes novy kernel a world a prekonfigurujes loader. Takze souhlasim s Mirkem. Nicmene tvoje puvodni hybridni varianta mi porad pripada jako zajimava hricka a doufam, ze se mi k ni podari vratit. Oli -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: rtld i386 versus amd64
On 02/22/11 21:30, kron24: Pouze zasahem do loaderu. Loader natahuje vzdy partition 'a'. Ne, jde to zvladnout i konfiguracne. currdev="disk0s1b" rootdev="disk0s1b" vfs.root.mountfrom="ufs:/dev/ad0s1b" To jsem presne myslel, kdyz jsem rikal, ze i kdyby z remote upgrade nic nebylo, dozvim se ledacos noveho. O tomhle jsem byl presvedceny, ze to nejde ... Je to vypadek na par minut, kdy z "provizorniho" systemu nainstalujes novy kernel a world a prekonfigurujes loader. Takze souhlasim s Mirkem. Kdyz ja mam nektere ty systemy za dost pomalou sitovou linkou - a takhle je to o dost vic dat ... Ale v pohode - i ja to zatim beru jako hracku. Az to budu potrebovat nutne, tak to tim ci onim smerem nakonec nejak uchodim ;-) Dan -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: rtld i386 versus amd64
Dan Lukes wrote: On 02/22/11 16:40, Miroslav Lachman: Cekove se mi to ale az tak moc nelibi - to bude znamenat vypadek poskytovanych sluzeb po celou dobu upgrade. Behem vsech tech vylomenin s ld-elf atd. chces mit v provozu vsechny sluzby? To bych se skoro bal tohle risknout. Kdyz ta sluzba nebude fungovat, nebude to horsi, nez kdyz bude programove vypnuta. No z meho pohledu je lepsi, kdyz sluzba nebezi vubec, nez aby bezela s neocekavanym chovanim / vysledkem / poskozenim dat atp. [...] Zalezi kolik stroju mas v provozech, kdy se vypadek ta udelat pouze o weekendu v noci a i tak se ta tebe osklive ksichti. Mozna bys zjistil, ze rok nema tolik weekendu, abys mohl delat updaty na miste. Uznavam, ze jich urcite spravuji min nez ty, co je ale u me jasnou vyhodou je siroke spektrum zakazniku i sluzeb na tech serverech provozovanych, takze u me jsou naopak i servery, ktere maji o vikendu tu nejvetsi navstevnost a nejvhodnejsim casem pro upgrade je pondelni rano :) Tim si muzu podobne zasahy rozlozit do vice dnu oproti tobe (pokud tedy musis vse delat jen o vikendech v noci) [...] Stale si myslim, ze je proste jednodussi na chvili pouzit swap, nebo tmp, kam si hodim system, ze ktereho nabootuji a pak puvodni 32bit nahradim 64bit Ja mluvim o tom, ze ten upgrade udela script. To, cos tak pekne popsal dvema vetama ja vidim bud' na docela slozite shellovske programovani, nebo na dost velky objem dat prenaseny po siti - cast dokonce opakovane. Ja to tedy jeste v praxi nezkousel, ale ta teorie v hlave mi rika, ze to nebude zadne slozite shellovske programovani, protoze tomu ja bych se rozhodne vyhnul, neb ho moc neumim. Ovsem stale je mi blizsi napsat jednoduchy shellscript, nez z meho pohledu slozity modul pro kernel (ktery jsi zminoval), ci jine hacky do zdrojaku. Ale myslim si, ze ten muj zpusob nebude vyzadovat o nic vetsi trafik po siti, nez tvuj. V obou pripadech potrebujeme na cilovy system dostat amd64 system, ty ho tam muzes dostat treba jako zdrojaky a pak prelozit, nebo primountovat NFS s prelozenym a jen udelat installkernel / installworld. A podobne to bude i v mem pripade s instalaci do swapu, nebo jineho oddilu - amd64 kernel a world potrebuju nainstalovat jen jednou, pak ho na misto puvodniho systemu muzu zkopirovat z toho swapu / jineho oddilu a uz ho nemusim tahat znovu po siti. A to nemluvim o tom, ze zdaleka ne vsude mam swap ani o problemech, se kterymi se opakovane potykam pri pokusech editovat MBR nebo LABEL na "zivem" systemu. Nepritomnost swapu, nebo jineho oddilu, ktery by se pro tyhle ucely dal pouzit je prekazou, to je jasne. Nicmene ja takove stroje nastesti nemam a na vetsine stroju, kde se pouzivaji dnesni velke disky, si nechavam pro jistotu na konci disku 1GB volneho mista / prazdnou partition, prave pro pripad, ze bych tam nekdy potreboval delat nejake vylomeniny, i treba vzdaleny restore po nejake havarii atd. A editovat MBR / LABEL by ani v mem pripade nemelo byt potreba. Jak uz napsal Oli, staci editace loader.conf, pripadne prikaz nextboot. Takze ano, kazdy hledame nejvhodnejsi zpusob pro ty svoje podminky a v tech podminkach se trochu rozchazime. Jsem rad, ze moje podminky jsou jednodussi, nez ty tvoje :) Mirek -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
