Linux-haladó

Majd 15 éve használok Unix/Linux variánsokat. Mindíg is saját kernelt használtam, nem csak a stabilakat de az -rc -ket is.
Viszont egy jó ideje nem tudok működő kernelt fordítani. Legutolsó ami a mai napig biztosan működik, az a 2.6.30-rc2. Azóta az összes -rc és stabil kernelt próbáltam életre kelteni valahogy így:
Adott patch letölt, előző kernel könyvtár törlése. Kernel kitömörítése, patch bele. 2.6.30-rc2 konfigurációjának bemásolása .config -ként majd make oldconfig. Esetlegesen felmerülő kérdésekre értelemszerűen válaszolok. make && make modules_install install . Beállítom a grub-ben majd boot.
Eredmény: fekete képernyő a grub után és sokszor lefagy vagy csak ctrl+alt+del -re reagál. Van amikor sípolás van fekete képernyővel. Legvizuálisabb amikor simán újraindul rögtön a grub után a kernel betöltése helyett. Elég ritkán simán CRC hibát ír és azt hogy a rendszer halt állapotba került.

Amiket próbáltam: make allnoconfig, majd egyesével engedélyezni azokat a részeket amelyek szükségesek. Egyszer eljutottam odáig (folyamatosan engedélyezve a plusz lehetőségeket) 2.6.30(.1?)-al hogy ment a boot, volt hang, ment a hálózat és ment az Xorg-is. Sőt, hozzá tudtam adni a VirtualBox 3.0 kernel driver-eket és ment is a VirtualBox. Egy gond volt vele, nem volt hang a virtuális gépben. Engedélyeztem az ALSA OSS emulációját, majd reboot. Innentől megint halál, fekete képernyő. Időnként mentegettem a működő .config-ot, de valamit rosszul csinálhattam vagy nem tudom mi történt, de már azzal újrafordítva sem boot-ol.

Ami számíthat: Asus P5B alaplap, Core2Duo proci és 6 Gb RAM van a gépemben kétfejes ATI grafikus kártyával. 64 bites Debian testing/sid a rendszer, naprakészen tartva. A root FS az JFS.
Bármilyen ötletet szivesen veszek. Sajnos próbáltam Debian kernel-eket is, azok sem boot-olnak.

Egyszer úgy volt hogy meg kell néznem működik-e egy SB Audigy hangkártya. Ehhez visszaálltam 2.6.30-rc2 forrásra, bemásoltam a futó konfigurációt és csak az Audigy-t fordítottam pluszban bele. Tanulva az előzőekből extra névnek hozzátettem a -audigy jelzőt. Boot -> kernel halál. Innentől gyanakszom az új gcc-kre, libc6-ra, bármire ami userland. Hardware változtatás ugyanis nem volt. Egy szálon fordítok, régebben néha két szálon ment és akkor sem volt gond. Jó ideje már frissítettem BIOS-t, azaz nem az eredeti van az alaplapon (de hivatalos) és hosszú ideje semmi gondom nem volt vele. Most sem hiszem hogy az lenne a gond.

Hogyan tudnék ilyen problémát debug-olni? Ami eszembe jutott hogy felteszek egy stable chroot-ot és abban fordítok kernelt. Hazamegyek, ki is próbálom. Ha az abban fordított kernel sem működik, akkor végképp nem lesz ötletem mit csináljak. :-|
Olvastam valami JFS bugról, amely akadályozta a kernel helyes betöltését, de azt javították, nemde?
Ha memória hiba lenne, akkor a régi kernel sem boot-olna szerintem, valamint egyszer nem sikerült volna többszöri fordítással és többszöri boot-tal felépíteni egy egyre funkcionálisabb kernelt.

Update #1:
Régi saját fordítású kernelek akkor is boot-olnak, ha a modul könyvtárakat előzőleg leszedtem alóluk. Régi Debian kernelek közül egy ad crc error - System halted üzenetet, többi boot-ol.
Régi saját kernelek a következő üzenettel kezdenek (régen is így volt és sokáig működtek):

Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[    0.236787] PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved
[    0.236816] PCI: Not using MMCONFIG.
Loading, please wait...
[    1.144098] hub 4-0:1.0: unable to enumerate USB device on port 2
INIT: version 2.86 booting
[...]

Amely kernelek reset-elnek, azoknál a

Decompressing Linux...

villan fel közvetlen a reset előtt.

HW hiba szerintem kicsukva, gép napi 24 órában simán megy. Kb hat Firefox ablak ötven füllel + virtualizált OS + dnetc mindkét processzormagon + torrent miatt ami a hálózaton kifér három HDD-ről gyönyörűen megy. Memtest-et futtattam, 6 Gb-al elég lassan megy, de 37%-ig lefuttatva az összes tesztet egyetlen hibát sem kaptam.
Működő kernel újrafordítása ugyanazzal a konfigurációval (csupán kapott egy -retry verziónév toldást) fekete képernyőt ad. Ugyan nem fagy le (ctrl+alt+del -re újraindul), de a fekete képernyőn túl más nincsen.

Kérdés, mit jelent a parsing ELF közvetlenül a kernel betöltése után? Az a binárisok felépítése és azt leszámítva hogy a kernel tudja őket kezelni még nem tudom mit keres ott amikor még a root FS sincs csatolva?

Update #2:
Csomagfrissítés volt ismét. Rohanvást voltam, de mintha gcc is benne lett volna.
Letöltöttem a legújabb Karmic napi live CD-t, szépen boot-olt 2.6.31-3 csomagverziójú kernellel. Felmount-oltam a Debian partíciómat és lefordítottam az azon lévő 2.6.30.1-es kernelt a korábban mentett és működő konfigurációval. Ezzel ismét boot-ol a gép és a már futó rendszer alatt fordítottam VirtualBox 3.0.2 kernel modulokat. Azokat hiba nélkül betöltötte és működik is a virtualizáció. Ugyanaz az egy gond van vele mint előzőleg. Mivel kihagytam az ALSA OSS emulációját a kernel-ből, a virtualizált OS alatt nincs hang.
Ebből én azt a következtetést vonom le hogy a Debian gcc-je az ami nem bír a kernellel (vagy megint szerencsém lett volna?). Távoli ismeretségem van Martin Michlmayr GCC teszterrel (fejlesztővel?), majd megpróbálom izolálni a problémát a segítségével.

Update #3:
Ubuntu alatt bekapcsoltam még az ALSA OSS emulációját plusz egy-két kimarad USB-s opciót. Továbbra is boot-ol. Elkapott a kisértés, lefordítottam Debian alatt, most ott is boot-ol. Meglehet hrgy84 soraiban van némi igazság, vagy mégis az a bug, amiért kiadták a 2.6.30.2-őt:

commit d7de59fb74b6e9b94af8b9fcbfdf39eeae3b27be
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Jul 12 11:25:04 2009 -0700

    Don't use '-fwrapv' compiler option: it's buggy in gcc-4.1.x
    
    commit a137802ee839ace40079bebde24cfb416f73208a upstream.
    
    This causes kernel images that don't run init to completion with certain
    broken gcc versions.
    
    This fixes kernel bugzilla entry:

http://bugzilla.kernel.org/show_bug.cgi?id=13012

    I suspect the gcc problem is this:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230

    Fix the problem by using the -fno-strict-overflow flag instead, which
    not only does not exist in the known-to-be-broken versions of gcc (it
    was introduced later than fwrapv), but seems to be much less disturbing
    to gcc too: the difference in the generated code by -fno-strict-overflow
    are smaller (compared to using neither flag) than when using -fwrapv.

Forrás.
Fordítottam 2.6.30.2-őt az előző konfiguráció alapján, szépen boot-ol és működik.

Sziasztok!

Rá is térnék rögtön a lényegre.
Lenne egy DVD amit másolnom kellene, de az másolásvédett. Linux alatt van valami mód ennek a törésére?
Előre is köszhönöm a választokat!

Üdv.:
V007

hello

van két ftp szerver ami között szinkronizálni kellene az adatokat
kis fájlokról van szó
mindig csak egy irányban történne vagyis a masterFTP --> slaveFTP

úgy kellene működnie hogy az az ftp tartalom amire másolunk az csak nőjön
vagyis ha a 'master' ftp ről ha eltűnik valami az a 'slave' ftp-n azért maradjon meg

és ami legfontosabb debian esetleg ubuntu alatt kellene működjön

én az rsync re gondoltam de azzal nem sikerült megoldani

köszi előre is

Sziasztok!

Eddig még sose volt 4GB RAM-om egy gépben, de holnap veszek. A gépben Intel Centrino Duo processzor van, 32-bites Ubuntu Hardyt futtat, azzal a kernellel, amit az Ubuntu-telepítő alapból felrakott.

A 4GB RAM berakása után is 32-bites Ubuntu Hardyt szeretnék futtatni, tetszőleges olyan kernellel, ami az Ubuntu hivatalos repositoryjából csomagból felrakható. Az a kérdésem, hogy 3GB vagy 4GB RAM-ot fog a gép látni? Ez mitől függ, és hogyan állíthatom be, hogy melyik legyen? Igaz az, hogy a 4GB-os lehetőség kicsit lassabb (a PAE-ben levő mélyebb indirekció miatt), mint a 3GB-os?

Köszönettel:

pts

Hali!
Adott egy vas ami 2 xen virtualis gepet szolgal ki. Az egyiken apache es levelezes fut, a masikon sql szerver. Az apache-os gepen a load van, hogy 40-50-re is felugrik valamiert, egyertelmuen az apache jovoltabol. Volt egy kis uzemzavar ma, tapegyseget kellett cserelni a fizikai vasban, de a gepeken semmit nem allitottam el. Elotte is volt 1-2 alkalommal, hogy megugrott a load, de ennyire nem es foleg nem ilyen tartosan. Hogy es mit lehet allitgatni, hogy rendezodjon a helyzet?
Ami meg erdekes, hogy a host gepen nem latszik hogy szenvedne, a cpu 90%-ban idle, viszont az apache-os virtualis gepben joforman allandoan 60% folott megy. Neha meg ssh-zni sem tudok ra a load miatt.
Debian 4, xen 3.0.1, Celeron 3000, 2G RAM.
Ha akad valakinek valami tippje szivesen fogadom, mert mar nemsok otletem van ...
Koszi!
Udv!

Sziasztok!

Egy apró procmail.rc elírás miatt egy felhasználó levele a var/mail/felhasznalonev fájlba került.
hogy tudom onnan "elküldeni" neki?

előre is köszi

A kérdésem egyszerű, olyan programra vagy programokra lenne szükségem amivel, egyszerűen szinkronizálhatom a HTC touch-ot emailekkel és határidőnaplóval együtt. Ha rádugom a vasra akkor, csatlakoztat egy auth01 hálózatot, de semmi más nem történik. Wine alatt feltettem az ActiveSync-et, de nem reagál semmit! A FŐNÖKÖMNEK KELL!!! HA EZ SIKERÜL AKKOR LINUXOT FOG HASZNÁLNI! 2 ÉVE KÖNYÖRGÖK HOGY CSAK PRÓBÁLJA KI!

Sziasztok,

tökéletesen megy mind a Postfix, mind pedig a Spamassassin, beérkezik a levél s ha Spam, megjelöli és átkerül a Spam mappába.

Ha be van állítva az adott felhasználónak a vacation akkor a Spam-ként megjelölt levelekre is válaszol, így a kamu címekről visszapattanó "Undelivered Mail Returned to Sender" és egyéb tárgyú levelektől gyorsan megtelik a postaláda.

Feltételezem az volna a megoldás, hogy ne válaszoljon a Spam-ként megjelölt levelekre, de ezt hol és hogyan kell beállítani?

Segítségeteket előre is köszönöm!

Sziasztok,
szeretnék a grub menübe egy fsck futtatási lehetőséget. Egyelőre egy bash envronment-et indítok, onnan nézelődök:

title Bash Environment
kernel (hd1,0)/boot/bzImage root=/dev/sdb1 init=/bin/bash
initrd (hd1,0)/boot/initrd

Innentől aztán csak nézek hülyén magam elé, mert az fsck-t ugyan el tudom indítani, de a boot folyamat ezen állapotában még nincs ott a nekem kellő /dev/sdb1. A /dev-ben ilyenkor még csak 4 tétel van: console, null, tty, zero.
Hogyan tudnám az fsck-t indítani?
István

A topik régi címe "Linux szerver mentése Windows alól" volt. Most már közeledem a megoldáshoz, de mert volt aki kíváncsi, hogy mi lesz a megoldás ezért itt folytatom. Szóval vettünk egy NAS eszközt...
Ennél a kérdésnél kezdődik az ezzel kapcsolatos aktuális problémám illetve az új kérdéseim! :-{)E
#===
Innentől a topik jelen állapot szerint már többnyire elavult része:
#===
Van egy részlegünk, ahol van egy Linux szerver (Ubuntu 8.04 LTS), amin sambát és MySQL adatbázist használunk. Két Windowsos gépen fut egy program, ami a szerver MySQL adatbázisába dolgozik.
Szeretnék minden nap a munka végén csinálni egy komplett mentést.
A mentés az alábbiakból állna:
- MySQL adatbázis teljes mentése. Nem csak az alkalmazáshoz tartozó, hanem az adminisztrációs táblákat is menteném.
- A szerver config fájlok mentése.
- Azt a sambas megosztás mentése, ahova a Windowsos alkalmazás, még fájlokat pakol. Ez a legkönnyebb, mert a Windowsos gépekre fel van mappelve.

A mentés eredménye a Windowsos gép merevlemezére kerülne.

Mindezt a Windows munkaállomásról kezdeményezve, de úgy, hogy az ott dolgozók számítástechnikai ismerete nulla. Szóval olyan, hogy ssh-n belép és menteget akár csak egy szkriptet is elindít nem jöhet szóba. A Dolgozó csak annyit tud, hogy van az asztalon egy ikon, aminek az a neve, hogy "Napi mentés", ő este arra rákattint és megvárja amíg a végén kiírja, hogy a "Mentés befejeződött!"

Szóval az kellene, hogy a Windowsos gépen elindítok egy parancsfájlt, (bat vagy cmd) ami elindít a Linux szerveren egy (ott már kész) szkriptet a megfelelő jogosultsággal úgy, hogy a Windows megvárja annak lefutását és a Windowson futó parancsfájl akkor folytassa a saját tevékenységét, amikor a Linuxon már lefutott a mentés Linuxos része.

Gondoltam a Linux oldalon időzített mentésre, ami a munka végén lefut, de így nem tudom biztosítani, hogy az alkalmazásokból már kilépjenek mire a mentés fut. És sajnos nem hajszál pontosan minden nap ugyanakkor fejezik be a munkát.

Kiegészítés:
Néhányan fennakadtak, a konfigurációs fájlok mentésének gyakoriságán ezért ezt még hozzátenném:
A konfig fájlokat valóban elég ritkábban menteni. Hetente vagy havonta illetve adminisztrációs beállítások után.
Azonban:
Az SQL adatbázist és a program munkakönyvtárat naponta kell menteni, akkor lehet, hogy az 1-2 perc futásidő és néhány 100kb tárterület, -ami a konfigok mentéséhez kell-, már nem sok erőforrást igényel és egyszerűbb, mint két vagy több fajta mentést futtatni különböző ütemezésekkel.