[redhat/mandrake] Installer loopt vast op VIA EPIA

[Verwijderd]

Ik heb een probleem met het installeren van linux (verschillende distro's: Mandrake 9, Redhat 8, Redhat 7.3, PKLinux, ASPLinux).

Ik probeer op mijn VIA EPIA computer op een 3.5GB partitie Linux te installeren, de eerste keer dat ik met Linux werk trouwens, maar ik heb al eerder met FreeBSD gewerkt en Linux is alleen maar gebruiksvriendelijker wat dat betreft.

Als ik Redhat via FTP Install of Mandrake via CD probeer te installeren blijft de installer halverwege hangen: mijn muis doet het nog, ik kan nog naar consoles escapen, maar de installer doet niets, zelfs na een uur is er nog geen kraakje van de harddisk of blimpje over m'n netwerk geweest.

ASPLinux en PKLinux geven een kernel panic 11, maar ik wil liever Redhat of Mandrake hebben, die zijn een stuk meer mainstream, meer software (vooral omdat Redhat met een eigen kernel werkt).

Is er dus iemand die mij kan zeggen waar het aan ligt, het enige wat ik heb kunnen vinden is dat het aan de netwerkcontroller van VIA ligt, maar als ik de Mandrake CD boot terwijl de controller gedisabled staat in de BIOS hangt hij nog.

[ Voor 3% gewijzigd door Verwijderd op 26-02-2003 17:52 . Reden: Witregels ]

[Verwijderd]

Een signal 11!!!

http://www.bitwizard.nl/sig11/

[MikeN]

Ik zou het echt houden op brak geheugen/andere hardware. Mijn VIA Epia draait nl. al enkele maanden stabiel op Debian (24x7).
Zeker die sig11 wijst daarop.

[Verwijderd]

Als het geheugen brak is, waarom draait Win2K dan al ruim een half jaar zonder ook maar één keer een crash te veroorzaken? Sowieso verklaart het nog niet waarom Redhat en Mandrake vastlopen ná de kernelload helverwege de installatie, of wel?

[deadinspace]

Verwijderd schreef op 26 February 2003 @ 17:16:
ASPLinux en PKLinux geven een kernel panic 11

Ik ben nog steeds benieuwd wat je daarmee bedoelt
Volgensmij haal je twee dingen door elkaar, namelijk een kernel panic en een segmentation fault (aka signal 11 of sigsegv). Wat krijg je precies, en wanneer?

[Verwijderd]

kernel panic: signal 11
ik dacht dat het die was

[Verwijderd]

Verwijderd schreef op 26 February 2003 @ 23:34:
Als het geheugen brak is, waarom draait Win2K dan al ruim een half jaar zonder ook maar één keer een crash te veroorzaken? Sowieso verklaart het nog niet waarom Redhat en Mandrake vastlopen ná de kernelload helverwege de installatie, of wel?

Het kan zijn dat Win2K minder strenge eisen aan het geheugen stelt, het kan zijn dat het wat anders is (er gaat bijvoorbeeld iets fout bij het zoeken naar hardware) maar de vertaling van signal 11 luidt: "Je computer is kapot. Koop een nieuwe."

[Verwijderd]

hij crasht bij het installeren van de packages (halverwege dus), de kernel is dus volledig geladen en hardware detection is ook al gebeurd.
En nogmaals over dat signal 11, de computer is niet kapot, ik zei al dat hij rockstable draait onder windows 2000.

[Verwijderd]

Dat het onder Windows wel stabiel draait zegt wel iets maar niet alles. Het gebruik van geheugen onder Linux & Windows is totaal verschillend (de een begint bij het begin de ander bij het einde). Draai dus toch maar eens een memtest86. Dan kunnen we dat met zekerheid uitsluiten als daar niks uit komt.

[Wilke]

Verwijderd schreef op 26 February 2003 @ 23:34:
Als het geheugen brak is, waarom draait Win2K dan al ruim een half jaar zonder ook maar één keer een crash te veroorzaken? Sowieso verklaart het nog niet waarom Redhat en Mandrake vastlopen ná de kernelload helverwege de installatie, of wel?

Heb je de FAQ wel gelezen?

Awww...steek ik er tijd in om dat netjes uit te leggen, moeten mensen dat natuurlijk wel door gaan lezen he!

Hiero: Linux of Linuxprogramma's crashen op willekeurige momenten (segfault, signal 11, etc..). Hoe kan dit?.

Daarom zegt het dus niet alles (wel wat, maar niet alles) dat het onder Win2k wel prima draait.

Dus het eerste wat je nu gaat doen is memtest86 draaien, helemaal aangezien andere mensen aangeven met hetzelfde mobo wel Linux draaiend te hebben

[ Voor 5% gewijzigd door Wilke op 27-02-2003 15:18 ]

[igmar]

Verwijderd schreef op 27 February 2003 @ 13:45:
hij crasht bij het installeren van de packages (halverwege dus), de kernel is dus volledig geladen en hardware detection is ook al gebeurd.
En nogmaals over dat signal 11, de computer is niet kapot, ik zei al dat hij rockstable draait onder windows 2000.

Dat zegt echt helemaal niks. NT gebruikt geheugen top-down, Linux bottom-up.

[deadinspace]

Verwijderd schreef op 27 februari 2003 @ 00:03:
kernel panic: signal 11
ik dacht dat het die was

Kun je het dan nog eens proberen, en de melding (inclusief een aantal voorgaande regels, als die relevant zijn) overschrijven?

Verwijderd schreef op 27 februari 2003 @ 00:21:
...maar de vertaling van signal 11 luidt: "Je computer is kapot. Koop een nieuwe."

Nounou, dat is tamelijk kort door de bocht.

Een segmentation fault is wat optreedt als een process aan geheugen probeert te zitten waar het helemaal niet aan mag zitten. De kernel vangt dit af en stuurt het process in kwestie een SIGSEGV, signal 11. De standaard-uitwerking van dit signal is dat het ontvangende process afsluit (met de melding "Segmentation fault").

De oorzaak van een segmentation fault kan zeer goed in het programma zelf liggen, omdat het door een bug een verkeerd stuk geheugen benaderd (verkeerd gebruik van pointers, herhaaldelijk free()en van hetzelfde memory, te weinig memory allocceren, etc).

Maar geheugen dat niet helemaal lekker is, of een CPU die wat bokt kan ook segmentation faults veroorzaken (doordat het programma in het geheugen beschadigd raakt en daardoor verkeerde stukken geheugen wil lezen of schrijven).

Het is dus niet zo maar te zeggen waar een segfault aan ligt, maar uit de context kun je het vaak redelijk opmaken. Zo is gcc een zeer veelgebruikte compiler, die voor miljarden regels code gebruikt wordt. Als je gcc bij het kernel compilen dus op random momenten segvt, dan is dat waarschijnlijk aan de hardware te wijten en niet aan gcc (daarom wordt dit ook vaak als test voorgesteld). Ook als random progs "ineens" beginnen te segv-en is de hardware een verdachte.
Maar als bijvoorbeeld je browser altijd segvt als je een bepaalde site bezoekt, dan is dat hoogstwaarschijnlijk te wijten aan een bug in de browser, niet aan de hardware.

[Verwijderd]

ik heb memtest86 gedownload, maar ik heb daarbij hetzelfde probleem als bij 90% van de linux distro's. IK HEB GEEN FLOPPYDRIVE CONNECTOR! Sorry, maar het is storend dat dit soort programma's _alleen_ van floppy draaien. Is het niet gewoon mogelijk om het op mijn 7.8MB FAT16 partitie te dumpen? Iemand een suggestie om dat probleem te omzeilen?

[Verwijderd]

Beter kijken, er staan ook iso images voor op cd .

[Verwijderd]

dus ik moet een cd branden om er een programma van 82KB op te zetten? klinkt een beetje vaag vind ik en ik heb geen rewritables.

[Verwijderd]

Dan had je maar een systeem met floppy drive moeten kopen lijkt me. Klagen over dat je een cd moet branden lijkt me in jouw geval dan ook niet terecht. Bovendien kun je die memtest86 wel vaker gebruiken dan eenmalig.

[deadinspace]

De inhoud van die flop naar een partitie dumpen en deze dan booten werkt misschien wel.. Zo niet, kun je dan niet even een floppydrive ergens vandaan halen en in dat systeem hangen?

[Verwijderd]

het is een VIA EPIA, zo'n 17x17cm mobo. er was geen ruimte voor een floppy connector, anders had ik allang een floppydrive aangesloten.
Ik heb trouwens zonet nog even de geheugenbanken (2x128MB 133MHz) omgewisseld, maar dat geeft geen verandering, en het lijkt me erg onwaarschijnlijk dat beide geheugenbanken aan het eind rot zijn.
Mandrake geeft trouwens absoluut geen melding dat er iets mesgegaan is, als hij bezig is met het installeren van de packages (je zou dus verwachten dat er daar niets mis kan gaan, behalve bij corrupte packages)

[deadinspace]

Mja, CD-RW kopen dan he
Die dingen zijn imho sowieso handig om een of twee te hebben.

Je hebt btw ook memtest86 als GNU/Linux progje, maar die kan niet je hele geheugen testen (omdat hij zoveel ram niet krijgt van de kernel), terwijl de memtest86 van bootflop/cd dat wel kan. Misschien dat cpuburn ook nog interessant is om mee te testen, maar die doet weinig/niks met het geheugen.