On 4 jan, 10:53, richard lucassen <spamt> wrote:
[..]
> --
> __________________________________________________ _________________
> It is better to remain silent and be thought a fool, than to speak
> aloud and remove all doubt.
>
> +------------------------------------------------------------------+
> | Richard Lucassen, Utrecht                                        |
> | Public key and email address:                                    |
> |[..]                       |
> +------------------------------------------------------------------+

Pff uiteindelijk wel ja! Tsjonge jonge wat een gedoe weer, nou weet ik
weer waarom ik tegenwoordig braaf vertrouw op de heren (en dames?)
distrobouwers voor dit soort zaken....

Het begint met een hele zut aan compile stuff met dependencies, die
geïnstalleerd moeten worden. Goed zo is Ubuntu nou eenmaal opgezet en
je kunt je er vreselijk over opwinden, maar uiteindelijk kost het 1
google query en een kwartiertje van je tijd ... Nee dan het compilen
zelf. In eerste instantie had ik de Ubuntu .config als uitgangspunt
genomen en dat was kennelijk een no go met de laatste vanilla kernel,
maar waarom een vrijwel geheel uit defaults opgebouwde config niet wil
compileren vind ik toch wel heel vaag, steeds weer andere errors en
uiteindelijk zelfs een crash van gcc zelf[1]!

Anyway een ochtend verder had ik dan uiteindelijk onze eigen custom
kernel, ben heel benieuwd of het ook wat gaat uitmaken :)

1 [10701.331055] Bad pte = 800000004fe46066, process = cc1, vm_flags =
100173, vaddr = 7ffff3aa5ff8 aldus netconsole, wellicht kan iemand
hier nog wat over zeggen?

On Wed, 13 Jan 2010 05:57:28 -0800 (PST)
Jeroen Beerstra <jeroen.beerstra> wrote:

> > make-kpkg --revision=mijn.eigen.kernel.1.0 kernel image
> >
> > En dan rolt er een .deb uit.

[..]
> maar waarom een vrijwel geheel uit defaults opgebouwde config niet wil
> compileren vind ik toch wel heel vaag, steeds weer andere errors en
> uiteindelijk zelfs een crash van gcc zelf[1]!
>
> Anyway een ochtend verder had ik dan uiteindelijk onze eigen custom
> kernel, ben heel benieuwd of het ook wat gaat uitmaken :)
>
> 1 [10701.331055] Bad pte = 800000004fe46066, process = cc1, vm_flags =
> 100173, vaddr = 7ffff3aa5ff8 aldus netconsole, wellicht kan iemand
> hier nog wat over zeggen?

Default config? Je moet wel eerst configgen natuurlijk anders ga je een
kernel bakken van een server die bij kernel.org staat ;-)

Aan de hand van lspci, lsmod, cat /proc/cpuinfo zet je de kernel zo
dat-ie voor jouw hardware is. En houd er rekening meer dat als je geen
initrd gebruikt je de belangrijke dingen zoals je IDE, scsi, ext3, raid
niet als module bakt maar het er hard in zet. Netwerkkaarten altijd als
modules erin zetten. Ik gebruik trouwens altijd "make menuconfig" voor
dit werk. Er is ook nog een "make xconfig" maar geen idee of die nog
bestaat. En de .config met vi te lijf gaan kan ook nog natuurlijk :)

Volgens mij is een

apt-get install build-essentials

voldoende om alles aan build progs naar binnen te slepen.

Om wat voor machine gaat het eigenlijk? Is het een HP-server of zo?

R.

On 13 jan, 15:10, richard lucassen <spamt> wrote:
> Default config? Je moet wel eerst configgen natuurlijk anders ga je een
> kernel bakken van een server die bij kernel.org staat ;-)
>

Haha, die leveren ze dan ook wijselijk niet mee. Nee ik doelde op make
localmodconfig [1] en dan zoveel mogelijk de defaults accepteren.

> Aan de hand van lspci, lsmod, cat /proc/cpuinfo zet je de kernel zo
> dat-ie voor jouw hardware is. En houd er rekening meer dat als je geen
> initrd gebruikt je de belangrijke dingen zoals je IDE, scsi, ext3, raid
> niet als module bakt maar het er hard in zet. Netwerkkaarten altijd als
> modules erin zetten. Ik gebruik trouwens altijd "make menuconfig" voor
> dit werk. Er is ook nog een "make xconfig" maar geen idee of die nog
> bestaat. En de .config met vi te lijf gaan kan ook nog natuurlijk :)
>
> Volgens mij is een
>
> apt-get install build-essentials
>
> voldoende om alles aan build progs naar binnen te slepen.
>

Nee dus, al is hetgeen je nog extra moet installeren ook niet zo heel
dramatisch zoals eerder aangegeven. En die extra's zijn vooral nodig
om te voorkomen dat je je .config met vi te lijf moet gaan ;) Enne
xconfig is spinglevend, is zelfs een qt3 app geworden inmiddels!

> Om wat voor machine gaat het eigenlijk? Is het een HP-server of zo?
>
> R.

Nee niet eens, is een Asus Barebone met PhenomX2 CPU.

1 Schijnt een nieuwe feature te zijn die alleen dat meeneemt dat ook
daadwerkelijk voor jou van toepassing is, ik lees dat als "dat ook
daadwerkelijk geladen of actief is".

On Wed, 13 Jan 2010 06:47:52 -0800 (PST)
Jeroen Beerstra <jeroen.beerstra> wrote:

> > Volgens mij is een
> >
> > apt-get install build-essentials
> >
> > voldoende om alles aan build progs naar binnen te slepen.
>
> Nee dus, al is hetgeen je nog extra moet installeren ook niet zo heel
> dramatisch zoals eerder aangegeven. En die extra's zijn vooral nodig
> om te voorkomen dat je je .config met vi te lijf moet gaan ;) Enne
> xconfig is spinglevend, is zelfs een qt3 app geworden inmiddels!

ok, "make xconfig" is alweer wat jaartjes geleden voor me :)

> > Om wat voor machine gaat het eigenlijk? Is het een HP-server of zo?
>
> Nee niet eens, is een Asus Barebone met PhenomX2 CPU.
>
> 1 Schijnt een nieuwe feature te zijn die alleen dat meeneemt dat ook
> daadwerkelijk voor jou van toepassing is, ik lees dat als "dat ook
> daadwerkelijk geladen of actief is".

Kijk, zo pik je weer eens wat op. Handig :)

Jeroen Beerstra <jeroen.beerstra> writes:

> 1 [10701.331055] Bad pte = 800000004fe46066, process = cc1, vm_flags =
> 100173, vaddr = 7ffff3aa5ff8 aldus netconsole, wellicht kan iemand
> hier nog wat over zeggen?

De enige keer dat ik gekke dingen zag bij een kernel compilatie (lang
geleden) kwam ik snel tot de juiste conclusie dat het geheugen gaar
was. Ik heb de draad niet echt helemaal gevolgt, maar ik neem aan dat je
al een keer een lange (ik zelf zou het een hele nacht laten draaien)
geheugentest hebt gedaan?

Op Wed, 13 Jan 2010 12:38:02 -0600, schreef John Bokma:

> Jeroen Beerstra <jeroen.beerstra> writes:
>
>> 1 [10701.331055] Bad pte = 800000004fe46066, process = cc1, vm_flags =
>> 100173, vaddr = 7ffff3aa5ff8 aldus netconsole, wellicht kan iemand hier
>> nog wat over zeggen?
>
> De enige keer dat ik gekke dingen zag bij een kernel compilatie (lang
> geleden) kwam ik snel tot de juiste conclusie dat het geheugen gaar was.
> Ik heb de draad niet echt helemaal gevolgt, maar ik neem aan dat je al
> een keer een lange (ik zelf zou het een hele nacht laten draaien)
> geheugentest hebt gedaan?

Ja dat ligt wel voor de hand, echter een monster memtest run (3+ dagen)
resulteerde in 0 errors .... wat wel vreemd is dat een test op geheugen
snelheid (hdparm -T) maar tot +/- 3GB/s kwam. Dat is hier thuis met
soortgelijk geheugen toch een factor 2 hoger, memtest gaf echter wel een
goede snelheid aan. Wel vreemde timings, maar de ervaring leert dat
afhankelijk van de chipset ed memtest er wat dat betreft nog wel eens
naast wil zitten.

Al met al krijg ik het idee dat Ubuntu x86_64 toch de manke broer is van
de i386 versie:
- memtest slaagt met vlag en wimpel
- ik zie met grote regelmaat segfaults van php of apache maar beiden
draaien op zich probleemloos
- ik moest een python module van Debian installeren ter vervanging van de
Ubuntu versie om trac aan de praat te krijgen, IIRC ook segfaults

Waarom dan toch Ubuntu? Ach ja mijn voorganger had dat nou eenmaal
geïnstalleerd en ik stond voor de uitdaging om een nieuwe server op te
leveren met de toch wel aanzienlijke werkende sw config van de oude. Dus
dan ga je voor de easy way out, tenminste dat denk je dan :) Inmiddels
wou ik dat ik 'gewoon' debian stable had gepakt zoals het hoort...

Jeroen Beerstra <jb> writes:

> Op Wed, 13 Jan 2010 12:38:02 -0600, schreef John Bokma:
>> Ja dat ligt wel voor de hand, echter een monster memtest run (3+ dagen)
> resulteerde in 0 errors .... wat wel vreemd is dat een test op geheugen
> snelheid (hdparm -T) maar tot +/- 3GB/s kwam.

Timing cached reads: 6886 MB in 2.00 seconds = 3445.54 MB/sec

hier, geen idee of dat in de lijn der verwachtingen ligt voor:
2GB DDR2 SDRAM 667MHz Dual Channel DT (zie rest specs:
http://johnbokma.com/mexit/2009/02/2...t-numbers.html )

> Dat is hier thuis met
> soortgelijk geheugen toch een factor 2 hoger, memtest gaf echter wel een
> goede snelheid aan. Wel vreemde timings, maar de ervaring leert dat
> afhankelijk van de chipset ed memtest er wat dat betreft nog wel eens
> naast wil zitten.
>
> Al met al krijg ik het idee dat Ubuntu x86_64 toch de manke broer is van
> de i386 versie:
> - memtest slaagt met vlag en wimpel
> - ik zie met grote regelmaat segfaults van php of apache maar beiden
> draaien op zich probleemloos
> - ik moest een python module van Debian installeren ter vervanging van de
> Ubuntu versie om trac aan de praat te krijgen, IIRC ook segfaults

Ik draai al een jaar+ 8.10 zonder problemen, x86_64 versie op een Dell
Vostro 200 ST. Nog geen gekke dingen gezien met uitzondering van wat
vorige week vrijdag gebeurde: computer heeeeel traag, niet meer booten
van HDD. Nadat ik (eindelijk) van live cd kon booten en de SMART waarden
uitgelezen had van de HDD (en een korte test gedaan via Disk Utilities)
werkte alles ineens weer. Eng, jazeker :-D.

> Waarom dan toch Ubuntu? Ach ja mijn voorganger had dat nou eenmaal
> geïnstalleerd en ik stond voor de uitdaging om een nieuwe server op te
> leveren met de toch wel aanzienlijke werkende sw config van de oude. Dus
> dan ga je voor de easy way out, tenminste dat denk je dan :) Inmiddels
> wou ik dat ik 'gewoon' debian stable had gepakt zoals het hoort...

Ik denk nog steeds aan een hardware issue hier. Willekeurig dingen er
uit knallen zou mij zeker hier ook opgevallen zijn :-) (ik gebruik
o.a. Python voor ontwikkelen, en nogal wat dingen draaien op Python
onder Ubuntu).

Op Wed, 13 Jan 2010 15:14:43 -0600, schreef John Bokma:

> Timing cached reads: 6886 MB in 2.00 seconds = 3445.54 MB/sec
>
> hier, geen idee of dat in de lijn der verwachtingen ligt voor: 2GB DDR2
> SDRAM 667MHz Dual Channel DT (zie rest specs:
> [..] )

Volgens mij wel, dit is echter 2GB DDR2 1066 low latency geheugen.
Memtest gaf echter wel 10GB/s bandbreedte aan

> Ik draai al een jaar+ 8.10 zonder problemen, x86_64 versie op een Dell
> Vostro 200 ST. Nog geen gekke dingen gezien met uitzondering van wat
> vorige week vrijdag gebeurde: computer heeeeel traag, niet meer booten
> van HDD. Nadat ik (eindelijk) van live cd kon booten en de SMART waarden
> uitgelezen had van de HDD (en een korte test gedaan via Disk Utilities)
> werkte alles ineens weer. Eng, jazeker :-D.
>

Dat is zeker eng! Zou als ik jou was zeker eens de tool van de
betreffende hd fabrikant een full test laten doen, heb zelf prive net de
3e Samsung retour gebracht, van de 4!!!

Zat zelf ook te denken aan de hd's, alleen kan ik segfaults en kernel
panics moeilijk koppelen aan defecte storage, maar aan de andere kant
geheugen is het niet en een defecte chipset of cpu is volgens mij ook
niet iets dat vaak voorkomt ... en als dat toch zo is verwacht je eerder
lockups.

>> Waarom dan toch Ubuntu? Ach ja mijn voorganger had dat nou eenmaal
>> geïnstalleerd en ik stond voor de uitdaging om een nieuwe server op te
>> leveren met de toch wel aanzienlijke werkende sw config van de oude.
>> Dus dan ga je voor de easy way out, tenminste dat denk je dan :)
>> Inmiddels wou ik dat ik 'gewoon' debian stable had gepakt zoals het
>> hoort...
>
> Ik denk nog steeds aan een hardware issue hier. Willekeurig dingen er
> uit knallen zou mij zeker hier ook opgevallen zijn :-) (ik gebruik o.a.
> Python voor ontwikkelen, en nogal wat dingen draaien op Python onder
> Ubuntu).

Is wel Ubuntu server deze, al zou dat eerder een positief iets moeten
zijn :)

Jeroen Beerstra <jb> writes:

> Op Wed, 13 Jan 2010 15:14:43 -0600, schreef John Bokma:
>
>> Timing cached reads: 6886 MB in 2.00 seconds = 3445.54 MB/sec
>>
>> hier, geen idee of dat in de lijn der verwachtingen ligt voor: 2GB DDR2
>> SDRAM 667MHz Dual Channel DT (zie rest specs:
>> [..] )
>
> Volgens mij wel, dit is echter 2GB DDR2 1066 low latency geheugen.
> Memtest gaf echter wel 10GB/s bandbreedte aan

Ik heb weinig verstand van modern geheugen, maar ik begreep omdat mijn
processor een FSB heeft van 1066 (E6600 @ 2.40 GHz) dat ik met dual
channel 1066/2 voor de geheugensnelheid moet hebben -> 533 MHz, en dat
667 MHz dan afhankelijk van waar je leest al ietwat overkill
is. Maar... correct me if I am wrong, ik wil eigenlijk 8 GB in die
machine gaan zetten, dus als dat sneller kan, graag.


>> Ik draai al een jaar+ 8.10 zonder problemen, x86_64 versie op een Dell
>> Vostro 200 ST. Nog geen gekke dingen gezien met uitzondering van wat
>> vorige week vrijdag gebeurde: computer heeeeel traag, niet meer booten
>> van HDD. Nadat ik (eindelijk) van live cd kon booten en de SMART waarden
>> uitgelezen had van de HDD (en een korte test gedaan via Disk Utilities)
>> werkte alles ineens weer. Eng, jazeker :-D.
>
> Dat is zeker eng! Zou als ik jou was zeker eens de tool van de
> betreffende hd fabrikant een full test laten doen, heb zelf prive net de
> 3e Samsung retour gebracht, van de 4!!!

Ja, ik had liever ook /geen/ Samsung gehad, het is voor mij een ietwat
vaag HD merk, maar hier in Mexico is Samsung een van de merken die je
veel op ziet duiken, en ik gok dat daarom die HDD in de computer zit.

Wat al op de agenda stond: 500 GB harddisk kopen (WD of zo, iets met 5
jaar garantie tenminste, minimaal 3), en die als primary disk gebruiken,
en de 320 GB als opslag voor loze data (waarvan ik niet wakker lig als
dat ineens foetsie is). De disk is sowieso nog onder Dell garantie. Maar
goed, hardware shoppen in Mexico, tenminste waar ik woon, is een
ramp. Meestal te duur (stuk duurder dan in NL), en vaak vage merken, en
oud spul.

Ik vergat nog te vermelden dat ik ook de computer flink schoongemaakt
had na het boot issue, en voor dat het weer werkte. Misschien de CPU
oververhit door stofnest in koelblok? Ik kan mij voorstellen dat ie dan
eerst een stuk omlaag klokt, en dan thermisch afslaat?

> Zat zelf ook te denken aan de hd's, alleen kan ik segfaults en kernel
> panics moeilijk koppelen aan defecte storage, maar aan de andere kant
> geheugen is het niet en een defecte chipset of cpu is volgens mij ook
> niet iets dat vaak voorkomt ... en als dat toch zo is verwacht je eerder
> lockups.

Yup. Ja, het klinkt erg vaag, ikzelf heb sterk het gevoel dat je met een
eigen kernel het niet op gaat lossen.

> Is wel Ubuntu server deze, al zou dat eerder een positief iets moeten
> zijn :)

Sites in mijn sig draaien op een LTS van Ubuntu (8.04?) (Slicehost,
dikke aanrader wat mij betreft, alles draait als een (virtueel)
zonnetje).

On 14 jan, 00:55, John Bokma <j> wrote:
> Ik heb weinig verstand van modern geheugen, maar ik begreep omdat mijn
> processor een FSB heeft van 1066 (E6600 @ 2.40 GHz) dat ik met dual
> channel 1066/2 voor de geheugensnelheid moet hebben -> 533 MHz, en dat
> 667 MHz dan afhankelijk van waar je leest al ietwat overkill
> is. Maar... correct me if I am wrong, ik wil eigenlijk 8 GB in die
> machine gaan zetten, dus als dat sneller kan, graag.

Dat heb ik ook gelezen, ben alleen sceptisch. Geheugen en CPU is meer
dan een 1/2 tje van FSB/2 in dual channel opstellingen. Je hebt immers
ook te maken met latency en die is, zeker bij modern geheugen, bepaald
niet te verwaarlozen! Zo is de trend steeds maar weer sneller
geheugen, maar ook steeds hogere latencies. Al met al zorgt dit ervoor
dat bijvoorbeeld het verschil in realtime bandbreedte tussen
bijvoorbeeld DDR2 6400 (800Mhz) en DDR2 8500 (1066Mhz) helemaal niet
zo groot is als je op basis van de theoretische bandbreedte op basis
van kloksnelheid en bus zou verwachten. Geloof dat het om procenten
gaat en dat als je kijkt naar daadwerkelijke reallife performance
winst het al helemaal verwaarloosbaar is. Dat gezegd hebbende, zie ik
toch wel degelijk verschil tussen 1066 5-5-5-15 geheugen in single en
dual channel modus in benchmarks, een groot verschil! Als je de FSB
mensen moet geloven zou 1 reepje van 1066Mhz (533x2) in het geval van
een FSB van 1066Mhz (266x4) al afdoende moeten zijn, maar dat klopt
dus niet.

> Ja, ik had liever ook /geen/ Samsung gehad, het is voor mij een ietwat
> vaag HD merk, maar hier in Mexico is Samsung een van de merken die je
> veel op ziet duiken, en ik gok dat daarom die HDD in de computer zit.

Vaag wil ik het niet noemen, eerder een relatief nieuwe speler. Je
leest wel vaker over veel problemen met Samsung schijven vooral in
RAID setups. Persoonlijk ben ik echter opgehouden om op basis van
ervaringen met een enkele of een aantal schijven, uitspraken te doen
over het complete merk. Je kunt ook gewoon pech hebben of andersom
natuurlijk ;) Ik heb pas 1x problemen met een hardware leverancier
gehad over bad sectors, die eikel zag dat als de hd evenknie van bad
pixels. Eikel is inmiddels volstrekt terecht failliet :) Voor de rest
wordt zo'n ding stilzwijgend en direct vervangen door een nieuwe, dus
ook Samsung kan niet aankomen met een serie hd's die zeg 50% uitval
vertonen.

> Ik vergat nog te vermelden dat ik ook de computer flink schoongemaakt
> had na het boot issue, en voor dat het weer werkte. Misschien de CPU
> oververhit door stofnest in koelblok? Ik kan mij voorstellen dat ie dan
> eerst een stuk omlaag klokt, en dan thermisch afslaat?

Volgens mij gaat ie dan direct uit, maar daar heb ik dan gelukkig weer
geen ervaring mee :D

> Yup. Ja, het klinkt erg vaag, ikzelf heb sterk het gevoel dat je met een
> eigen kernel het niet op gaat lossen.

We zullen het zien. Probleem is dat het typisch zo'n gevalletje is van
"slaat 1x per week vast, maar soms vaker", dus dit kan nog best een
langdurig verhaal worden.

> Sites in mijn sig draaien op een LTS van Ubuntu (8.04?) (Slicehost,
> dikke aanrader wat mij betreft, alles draait als een (virtueel)
> zonnetje).
>
> --
> John Bokma                                       j3b

Persoonlijk heb ik altijd mijn twijfels bij hosters die Fedora of
Ubuntu (LTS uitgezonderd) draaien, maar wellicht is dat gewoon een
vooroordeel ;)

Jeroen Beerstra <jeroen.beerstra> writes:

> On 14 jan, 00:55, John Bokma <j> wrote:

[ geheugen ]
> dual channel modus in benchmarks, een groot verschil! Als je de FSB
> mensen moet geloven zou 1 reepje van 1066Mhz (533x2) in het geval van
> een FSB van 1066Mhz (266x4) al afdoende moeten zijn, maar dat klopt
> dus niet.

Nee, ik had ook wel het gevoel dat iets meer dan 533 geen kwaad kon :-)

>
> Vaag wil ik het niet noemen, eerder een relatief nieuwe speler. Je
> leest wel vaker over veel problemen met Samsung schijven vooral in
> RAID setups. Persoonlijk ben ik echter opgehouden om op basis van
> ervaringen met een enkele of een aantal schijven, uitspraken te doen
> over het complete merk. Je kunt ook gewoon pech hebben of andersom
> natuurlijk ;) Ik heb pas 1x problemen met een hardware leverancier
> gehad over bad sectors, die eikel zag dat als de hd evenknie van bad
> pixels. Eikel is inmiddels volstrekt terecht failliet :) Voor de rest
> wordt zo'n ding stilzwijgend en direct vervangen door een nieuwe, dus
> ook Samsung kan niet aankomen met een serie hd's die zeg 50% uitval
> vertonen.

Ha ha ha, ook omdat ik mijn 2e Canon A640 terug gebracht heb omdat er 1
witte pixel in de sensor zat. Aangezien de A640 out-of-the-box geen raw
doet, heb je dus in je uiteindelijke foto een vlekje van een aantal
pixels. (De 1e A640 had een wit draadje achter de lens). Mijn 3e A640
heeft inmiddels wat blauwe pixels, en een clip in het batterrijenvakje
zit met lijm uit een lijmpistool op de plaats. Maar goed, ik snap niet
dat mensen dode pixels acceptabel vinden.

> We zullen het zien. Probleem is dat het typisch zo'n gevalletje is van
> "slaat 1x per week vast, maar soms vaker", dus dit kan nog best een
> langdurig verhaal worden.

Oeps, ja, dat is nog minder. Dan zou ik zelf de hardware eens vervangen.

>> Sites in mijn sig draaien op een LTS van Ubuntu (8.04?) (Slicehost,
>> dikke aanrader wat mij betreft, alles draait als een (virtueel)
>> zonnetje).
>
> Persoonlijk heb ik altijd mijn twijfels bij hosters die Fedora of
> Ubuntu (LTS uitgezonderd) draaien, maar wellicht is dat gewoon een
> vooroordeel ;)

Het was eigen keuze ;-) Ik draai op de desktop Ubuntu dus dacht: wel zo
handig als ik dat op mijn virtuele server ook draai. Zie
http://www.slicehost.com/questions/#distros

voor een lijst van distros. (Ik zat eerst aan *BSD te denken, maar dat
doen ze nog niet).

Ik heb ervaring met Unix sinds ca. eind jaren 80, en met Linux sinds RHL 3
of zo (die van de vorige eeuw, niet RHEL3 :-) ) en een tijd op SGIs
ontwikkeld, maar nooit echt diep er in gezeten. Ik had nog nooit iets
met postfix en dovecot gedaan, en het was best leuk om dat allemaal even
uit te zoeken, en nu een hele (hele) berg minder spam te hebben. Apache
kon ik wel weer dan, maar ik ben nu eigenlijk pas het sysadmin/server
deel echt aan het leren.

Ok met de nieuwe kernel geen kernel panics meer, maar de (steeds
vagere) segfaults vlogen ons om de oren en een reboot was niet eens
meer mogelijk. Dus voor de zekerheid toch nog maar een memtest gedaan
en ja hoor deze keer binnen no time een rits fouten! Nieuw geheugen is
inmiddels besteld en ik heb weer wat geleerd. Al is de vraag
natuurlijk wel wat ik moet met de kennis dat een memtest86+ run of tig
kennelijk van weinig waarde is.....

Al met al lijkt het dat al die panics en geforceerde reboots
behoorlijk wat schade hebben aangericht, zo kan ik inmiddels niet eens
meer localhost pingen en bleek bij inspectie nsswitch.conf een binairy
file te zijn geworden!!!!! Verder is de RAID1 array inmiddels degraded
en wacht, correctie hoop, ik nu op een schijnbaar eeuwigdurende
resync :( Ach ja, worst case scenario: from scratch beginnen met een
echte distro als Debian ;)

Jeroen Beerstra <jeroen.beerstra> writes:

> Ok met de nieuwe kernel geen kernel panics meer, maar de (steeds
> vagere) segfaults vlogen ons om de oren en een reboot was niet eens
> meer mogelijk. Dus voor de zekerheid toch nog maar een memtest gedaan
> en ja hoor deze keer binnen no time een rits fouten! Nieuw geheugen is
> inmiddels besteld en ik heb weer wat geleerd. Al is de vraag
> natuurlijk wel wat ik moet met de kennis dat een memtest86+ run of tig
> kennelijk van weinig waarde is.....

Dat ligt er aan. Het klinkt (opnieuw) als een hardware probleem. Als het
koude gerelateerd is kan het zijn dat als je uren en uren een memtest
draait, gestart nadat de computer al even aanstaat je niks ziet. Maar
als je de computer net aangezet hebt, en je test dan, dat je fout na
fout ziet.

> Al met al lijkt het dat al die panics en geforceerde reboots
> behoorlijk wat schade hebben aangericht, zo kan ik inmiddels niet eens
> meer localhost pingen en bleek bij inspectie nsswitch.conf een binairy
> file te zijn geworden!!!!! Verder is de RAID1 array inmiddels degraded
> en wacht, correctie hoop, ik nu op een schijnbaar eeuwigdurende
> resync

Klinkt alsof er meer mis is met die doos.

> :( Ach ja, worst case scenario: from scratch beginnen met een
> echte distro als Debian ;)

Eh, hoe kan Ubuntu dat gewoon Debian is met een toeter en een bel extra
minder echt zijn? Geloof je toch niet echt he? Daarnaast, nogmaals, dit
klinkt als hardware issue(s), dat ligt niet aan de software die je er op
draait.

Jeroen Beerstra wrote:
> Al met al lijkt het dat al die panics en geforceerde reboots
> behoorlijk wat schade hebben aangericht, zo kan ik inmiddels niet eens
> meer localhost pingen en bleek bij inspectie nsswitch.conf een binairy
> file te zijn geworden!!!!! Verder is de RAID1 array inmiddels degraded
> en wacht, correctie hoop, ik nu op een schijnbaar eeuwigdurende
> resync :( Ach ja, worst case scenario: from scratch beginnen met een
> echte distro als Debian ;)

Vermoedenlijk fouten die opgetreden zijn door een forced reboot. Doe
eens een fsck.

houghi

On Mon, 18 Jan 2010 07:03:34 -0800 (PST)
Jeroen Beerstra <jeroen.beerstra> wrote:

> Ok met de nieuwe kernel geen kernel panics meer, maar de (steeds
> vagere) segfaults vlogen ons om de oren en een reboot was niet eens
> meer mogelijk. Dus voor de zekerheid toch nog maar een memtest gedaan
> en ja hoor deze keer binnen no time een rits fouten! Nieuw geheugen is
> inmiddels besteld en ik heb weer wat geleerd. Al is de vraag
> natuurlijk wel wat ik moet met de kennis dat een memtest86+ run of tig
> kennelijk van weinig waarde is.....

Ik denk dat je dat verkeerd ziet: als memtest fouten vindt dan is dat
evident. Als memtest geen fouten vindt wil dat niet zeggen dat er geen
fouten zijn.

> Al met al lijkt het dat al die panics en geforceerde reboots
> behoorlijk wat schade hebben aangericht, zo kan ik inmiddels niet eens
> meer localhost pingen en bleek bij inspectie nsswitch.conf een binairy
> file te zijn geworden!!!!! Verder is de RAID1 array inmiddels degraded
> en wacht, correctie hoop, ik nu op een schijnbaar eeuwigdurende
> resync :( Ach ja, worst case scenario: from scratch beginnen met een
> echte distro als Debian ;)

Geen enkele distro is bestand tegen rot geheugen. Als je iets
wegschrijft dan gaat het eerst het geheugen in en als het daarna
geflusht wordt heb je junk op je schijf.

R.