Hozzászólások
-
Bejegyzés
-
Goosfrabaa wrote:Akarhogy mesterkedek, meg mindig azt hiszi, hogy 60671456 blokk van fizikailag a lemezen, pedig 60671480 block van.
A dumpe2fs -h /dev/md1 szerint (is):
Block count: 60671480Honnan a bubanatbol veszi a rossz erteket?
A szoftver RAID állandó szuperblokk miatt van kisebb helyed (24 blokk, 384kB ha 16kB egy blokk), valamiért nem veszi észre az ext3. Leszedheted az /etc/raidtab módosításával, de ebben a szuperblokkban van tárolva egy egy rakás RAID információ, e nélkül nem lehet csatolni a RAID partíciót anélkül hogy minden egyes apró adatot pontosan meg ne adnál, különben lőttek minden adatodnak ha valamit rosszul adsz meg (pl. egy újratelepítés után).
http://tldp.org/HOWTO/Software-RAID-HOWTO-5.html#ss5.9
Szerk: azt hiszem már értem mi a gond (kicsit meg vagyok fázva, tompa az agyam 😀 ). Az egyik partíció sima ext3-ként van megformázva, a másik meg RAID tömbnek és utána ext3-nak. Vagy az egyik merevlemezen van RAID szuperblokk, a másikon meg nincs. a kettő közül az egyik miatt van méretbeli különbség. Mint látom a két vinyó között másolgattál, és nem egyszerre formáztad meg.
Goosfrabaa wrote:Akarhogy mesterkedek, meg mindig azt hiszi, hogy 60671456 blokk van fizikailag a lemezen, pedig 60671480 block van.
A dumpe2fs -h /dev/md1 szerint (is):
Block count: 60671480Honnan a bubanatbol veszi a rossz erteket?
A szoftver RAID állandó szuperblokk miatt van kisebb helyed (24 blokk, 384kB ha 16kB egy blokk), valamiért nem veszi észre az ext3. Leszedheted az /etc/raidtab módosításával, de ebben a szuperblokkban van tárolva egy egy rakás RAID információ, e nélkül nem lehet csatolni a RAID partíciót anélkül hogy minden egyes apró adatot pontosan meg ne adnál, különben lőttek minden adatodnak ha valamit rosszul adsz meg (pl. egy újratelepítés után).
http://tldp.org/HOWTO/Software-RAID-HOWTO-5.html#ss5.9
Szerk: azt hiszem már értem mi a gond (kicsit meg vagyok fázva, tompa az agyam 😀 ). Az egyik partíció sima ext3-ként van megformázva, a másik meg RAID tömbnek és utána ext3-nak. Vagy az egyik merevlemezen van RAID szuperblokk, a másikon meg nincs. a kettő közül az egyik miatt van méretbeli különbség. Mint látom a két vinyó között másolgattál, és nem egyszerre formáztad meg.
Goosfrabaa wrote:De akkor miért van különbség a dd-s és a grub-installos megoldásban?A grub lényegében nem telepít az MBR-be egyetlen komponensét sem, mindösze egy betöltő kódot tesz ami elindítja a boot kódot. Méghozzá úgy, hogy megkeresi a stage1 fájl offset (eltolás) pozícióját a vinyón, majd azt írja bele az MBR-be. Tehát ha másolod a /boot könyvtárat, akkor más lesz a fájl pozició is, ezért nem működik. Ezért szokás külön /boot partíciót készíteni, mert egyedül a grub érzékeny a merevlemezen elfoglalt pozícióra. Viszont ha backup után elindítod a grub-install parancsot, akkor már működni fog.
Goosfrabaa wrote:A kicsiny (512 byteos) kód lenne értelmezésem szerint az, amit simán dd-vel lehet menteni a régi merevlemezről és visszaírni az újra. (A http://wiki.hup.hu/index.php/GRUB leírás „Előfordulhat az a kellemetlen helyzet, hogy a Windows boot managerét felülírod a Grubbal. ” rész is ebben erősít meg).Sajnos rosszul értelmezted az olvasott infókat. Nagyjából igaz amit írtál, de csak akkor működik, ha a dd-vel lementett MBR-t ugyanoda másolod vissza és a /boot érintetlen. A dd-t így kell használni:
– dd másolat az MBR-ről
– Windows telepítés, ekkor szó nélkül felülíródik az MBR
– MBR visszamásolása dd-vel oda ahol eddig volt.Tony Magic wrote:A /dev/sdd1 és a /media/disk mappába van csatolva. Melyik résznél csúszott meg a grub telepítése?Mindjárt a 0. résznél hibáztál. Azt feltételezted, hogy a grub-install a grubot feltelepíti oda ahova akarod. Pedig nem. Ahogy fent is írtam a grub-install csak egy részben dinamikus kódot készít, bár nem egészn igaz, akár felfoghatod egy belső konfigurációs fájlnak is, ugyanis azt (is) tartalmazza, hogy hol van fizikailag az indító fájl (stage1). Először másold át a grub-ot a pendive-ra:
# cp -r /boot /media/disk
utána már működnie kell a grub-install parancsnak, úgyanis nem találta a grub fájloat a pendrive-on.
Goosfrabaa wrote:De akkor miért van különbség a dd-s és a grub-installos megoldásban?A grub lényegében nem telepít az MBR-be egyetlen komponensét sem, mindösze egy betöltő kódot tesz ami elindítja a boot kódot. Méghozzá úgy, hogy megkeresi a stage1 fájl offset (eltolás) pozícióját a vinyón, majd azt írja bele az MBR-be. Tehát ha másolod a /boot könyvtárat, akkor más lesz a fájl pozició is, ezért nem működik. Ezért szokás külön /boot partíciót készíteni, mert egyedül a grub érzékeny a merevlemezen elfoglalt pozícióra. Viszont ha backup után elindítod a grub-install parancsot, akkor már működni fog.
Goosfrabaa wrote:A kicsiny (512 byteos) kód lenne értelmezésem szerint az, amit simán dd-vel lehet menteni a régi merevlemezről és visszaírni az újra. (A http://wiki.hup.hu/index.php/GRUB leírás „Előfordulhat az a kellemetlen helyzet, hogy a Windows boot managerét felülírod a Grubbal. ” rész is ebben erősít meg).Sajnos rosszul értelmezted az olvasott infókat. Nagyjából igaz amit írtál, de csak akkor működik, ha a dd-vel lementett MBR-t ugyanoda másolod vissza és a /boot érintetlen. A dd-t így kell használni:
– dd másolat az MBR-ről
– Windows telepítés, ekkor szó nélkül felülíródik az MBR
– MBR visszamásolása dd-vel oda ahol eddig volt.Tony Magic wrote:A /dev/sdd1 és a /media/disk mappába van csatolva. Melyik résznél csúszott meg a grub telepítése?Mindjárt a 0. résznél hibáztál. Azt feltételezted, hogy a grub-install a grubot feltelepíti oda ahova akarod. Pedig nem. Ahogy fent is írtam a grub-install csak egy részben dinamikus kódot készít, bár nem egészn igaz, akár felfoghatod egy belső konfigurációs fájlnak is, ugyanis azt (is) tartalmazza, hogy hol van fizikailag az indító fájl (stage1). Először másold át a grub-ot a pendive-ra:
# cp -r /boot /media/disk
utána már működnie kell a grub-install parancsnak, úgyanis nem találta a grub fájloat a pendrive-on.
Erről beszélek:
Code:void tulajdonnev(char question[], int min, int max, wchar_t *textki) {
int jo, i, hossz;
wchar_t *read;jo = 0;
do {
printf (question);
scanf („%ls”, &read);
hossz = wcslen (read);
if (hossz == 0) {
printf („nNem adtal meg szoveget!n”);
continue;
}
wcsncat (textki, read, max);
free (read);
if (wcscmp(textki, L”kilép”) == 0)
break;
if (hossz < min) { printf ("nA megadott szovegnek legalabb %d hosszunak kell lennie!n",min); continue; } if (hossz > max) {
printf („nA megadott szovegnek maximum %d karakter lehet!n”,max);
continue;
}
for (i = 0 ; i < hossz - 1 ; i++) { if (iswalpha(textki[i]) jo=1; textki[i+1] = towlower (textki[i+1]); } else { printf("nA megadott szoveg nem megengedett karaktert/karaktereket tartalmaz!n"); jo = 0; break; } if ((jo==1) && iswupper(textki[0])) jo = 1; else { jo = 0; printf("nA tulajdonnev elso betuje mindig nagybetu!n"); break; } if ((i!=0) && (textki[i] == L' ')) textki[i+1] = towupper (textki[i+1]); } } } while (!jo); }CyrSyS wrote:Utánjárásom során tényként közölték hogy a C nyelvben egy kicsit macerás az ékezetes betűk kezelése! Hát ezt én is belátom de ha adódik egy olyan feladat hogy ellenőrzött névbekérés ahol akár nagy Á É Í Ő Ú Ű betűk is előfordulhatnak nem tehetek kifogást. A nyelvnek azonban nem nagyon tetszik hogy erőltetem a dolgot!(…)
– És ez mind működjön ékezetes betűknél is!
> nekem valójában itt a bibi csak!Az elv egyszerű, de ha TurboC a fordító akkor lehetetlen vállakozás (hiányzik belőle a wchar támogatás). Egyszerűen csak megfelelően beállított setlocale() és wchar típusú sztringek kellenek. Meg az isalpha() helyett iswalpha(), isupper() -> iswupper(), islower() -> iswlower(), és akkor az összes ékezetes betű megfelelően lesz kezelve. A dolog akkor nehezedik, ha UTF-8 alapú a kódolás, mert akkor több bájtos karaktereket kell átalakítani széles karaktrekké. De erre ott van az mbsrtowcs(), de csak C99 (ISO 9899:1999) alapú fordítókkal meg rendesen.
Ilyesmi előfordul, ha frissebb fordítóval dolgozol, mit a libxml feljesztők. A nanohttp.c:1588 sorban van egy open() hívás, aminek a második paramétere az O_CREAT, de az open() ebben az esetben igényel egy harmadik ‘mode’ paramétert, ami hiányzik (lásd: man 2 open). A régebbi fordítókkal simán fordul a kód, csak futásnál jelez hibát.
Ilyesmi előfordul, ha frissebb fordítóval dolgozol, mit a libxml feljesztők. A nanohttp.c:1588 sorban van egy open() hívás, aminek a második paramétere az O_CREAT, de az open() ebben az esetben igényel egy harmadik ‘mode’ paramétert, ami hiányzik (lásd: man 2 open). A régebbi fordítókkal simán fordul a kód, csak futásnál jelez hibát.
szabogy76 wrote:Nem sikerül a névfeloldás a kliens (winxp) gépeken. Gondolom addig ne is próbáljam az internet működését?Eddig úgy tudtam, hogy a névfeloldás az internet működésének az egyik alapja. Még ha Microsoft Windows Szerver végzi akkor is.
szabogy76 wrote:a suse-n a névfeloldást jól gondolom, hogy nem a proxy végzi, hanem a ip route alapján kellene működnie?1. „a suse-n” => mintha külön állatfaj lenne, pedig csak olyan mint egy doboz, van belőle kék, piros, zöld, … (SuSe, RedHat, Debuan, Fedora, UHU, …), az a lényeg ami benne van.
2. „jól gondolom” => Felőlem, de ha akarod a squid is meg tudja csinálni, de máshogy is lehet (bind, ip forward, …).
3. „nem a proxy végzi” => Ez igaz, nem a proxy feladata a DNS névfeloldás. De a Squid nem csak proxy, hanem HTTP és DNS cache is többek között.
4. „ip route alapján kellene működnie?” => Akár, de ennek mi köze a mondat többi részének? Vagy ezzel azt kérdezed, hogy a nem ismert céges irányelvek alapján a nem ismert hálózati topológiához ez illik-e a legjobban?
Egyáltalán érted a saját kérdésed, kifejlenéd bővebben mire gondolsz?
szabogy76 wrote:A squid access.log-ba nem történik bejegyzés, úgy néz ki, hogy nem is jut el a kliens kérése a squid-ig. Azt azonban nem tudom, hogy miért nem.. 🙁Nem véletlenül ajánlottam a wireshark-ot, azzal meg tudod nézni, hogy egyáltalán a kérés eljut-e a szerverig. Ha nem akkor meddő dolog a squid és a route beállításokkal foglalkozni.
szabogy76 wrote:Csatolom a squid.conf fájlt véleményezésre.Ezekkel az alap beállításokkal kihasználod a Squid képességeinek 0,001%-át. Működik, de otthonra sem ajánlott így használni. Több szót nem érdemes vesztegetni rá.
szabogy76 wrote:Nem sikerül a névfeloldás a kliens (winxp) gépeken. Gondolom addig ne is próbáljam az internet működését?Eddig úgy tudtam, hogy a névfeloldás az internet működésének az egyik alapja. Még ha Microsoft Windows Szerver végzi akkor is.
szabogy76 wrote:a suse-n a névfeloldást jól gondolom, hogy nem a proxy végzi, hanem a ip route alapján kellene működnie?1. „a suse-n” => mintha külön állatfaj lenne, pedig csak olyan mint egy doboz, van belőle kék, piros, zöld, … (SuSe, RedHat, Debuan, Fedora, UHU, …), az a lényeg ami benne van.
2. „jól gondolom” => Felőlem, de ha akarod a squid is meg tudja csinálni, de máshogy is lehet (bind, ip forward, …).
3. „nem a proxy végzi” => Ez igaz, nem a proxy feladata a DNS névfeloldás. De a Squid nem csak proxy, hanem HTTP és DNS cache is többek között.
4. „ip route alapján kellene működnie?” => Akár, de ennek mi köze a mondat többi részének? Vagy ezzel azt kérdezed, hogy a nem ismert céges irányelvek alapján a nem ismert hálózati topológiához ez illik-e a legjobban?
Egyáltalán érted a saját kérdésed, kifejlenéd bővebben mire gondolsz?
szabogy76 wrote:A squid access.log-ba nem történik bejegyzés, úgy néz ki, hogy nem is jut el a kliens kérése a squid-ig. Azt azonban nem tudom, hogy miért nem.. 🙁Nem véletlenül ajánlottam a wireshark-ot, azzal meg tudod nézni, hogy egyáltalán a kérés eljut-e a szerverig. Ha nem akkor meddő dolog a squid és a route beállításokkal foglalkozni.
szabogy76 wrote:Csatolom a squid.conf fájlt véleményezésre.Ezekkel az alap beállításokkal kihasználod a Squid képességeinek 0,001%-át. Működik, de otthonra sem ajánlott így használni. Több szót nem érdemes vesztegetni rá.
legutóbbi hsz