[gentoo] 2.4 kernel wil niet, 2.6 wel

[deepbass909]

Ik ben met een oud beestje bezig om er een mp3/dvd bak van te maken.

Nu draai ik op het moment Gentoo met een 2.6 kernel. Nu heb ik die hele kernel wel gestript tot het hoogst noodzakelijke, maar echt lekker draait hij niet. Door o.a. udev start hij vrij traag op.

Nu heb ik totaal geen reden om persé een 2.6 kernel voor de machine te willen hebben, 2.4 zou ook uitstekend voldoen (aangezien de k6-2 in de machine al bestond voor de 2.4 beschikbaar kwam zit het wel goed met de ondersteuning).
Ik heb hiervoor een nieuwe kernel gebakken volgens hetzelfde recept als de al werkende 2.6.

Dat houdt in dat bijna alle hardware momenteel met externe modules worden aangeroepen (ik weet het, bevorderd de snelheid niet, maar dit is om te kijken wat er nou eigenlijk precies nodig is en zal later in de kernel geïntergreerd worden).
Belangrijke zaken als filesystem, ide e.d. zijn wel gewoon in de kernel gebakken.

Maar bij het filesystem gaat het fout. M'n root filesystem is ext3 geformateerd. In de kernel zijn zowel de ext2 als ext3 module meegebakken. In fstab staat netjes dat het een ext3 partitie is.
Kortom alles lijkt goed en voor de een 2.6 kernel werken al deze instellingen ook.

Maar als ik met de 2.4 kernel boot, dan start het boot process netjes maar loopt het vast op het controleren van het root filesystem.
De fout die ik krijg is de volgende:

code:

* Checking root filesystem ...
fsch.ext3: No such file or directory while trying to open /dev/hda3
/dev/hda3:
The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternater superblock:
    e2fsck -b 8193 <device>

* Filesystem couldn't be fixed :(

Nu is de grap dat een reboot naar 2.6 gewoon goed werkt.

Verder is ext3 is vrijwel gelijk aan ext2, dat mag dus niet het probleem zijn.

Moet ik een bepaalde kernel optie meegeven of gaat er iets anders fout?

[eghie]

Ik heb zo'n vermoeden dat de 2.4 kernel je HDD/partitie op een andere device node gooit. Probeer eens in de bootloader te spelen met root=/dev/hdx en root (hd0,0), etc.

[ Voor 31% gewijzigd door eghie op 30-08-2006 22:09 ]

[Verwijderd]

Heb je een initrd image gemaakt?
Is je ATA controller in de bzimage of als module gecompiled. Dat maakt namelijk wel wat uit.

[Boudewijn]

waarom per se die 2.4 kernel?
okay 2.6 is niet nodig, maar waarom niet het gewoon gebruiken?

je root fs is ext2 of ext3? (hoop ext3 voor je )

[Rainmaker]

Je 2.4 kernel heeft geen devices in /dev/

Je zei dat je udev gebruikte voor 2.6. Je weet dat udev niet werkt onder 2.4?

Onder 2.4 zul je dus als extraatje "devfs" moeten inbakken in je kernel.

[_JGC_]

Dan nog het fenomeen genaamd Gentoo gecompileerd "voor jouw PC". Let je er wel even op dat de glibc die op je systeem staat behalve NPTL ook nog linuxthreads met 2.4 kernels ondersteunt? AFAIK wordt standaard alleen NPTL gecompileerd, wat 2.6.6 of hoger vereist. Je zou na je devicenode probleem dus meteen op het volgende probleem stuiten: je C library die een nieuwere kernel vereist.

[Boudewijn]

jep maar als je het zonder nptl doet?
ik zou sowieso even een 2.4 profile gebruiken ,en dan heb je dat probleem al niet

[deepbass909]

Ik weet dat udev niet werkt onder 2.4, dat is ook zelfs 1 van de redenen om naar 2.4 te gaan (udev veroorzaakt een behoorlijke aanslag op m'n systeem bronnen, die al erg schaars zijn).

Ik heb daar dus ook al rekeningen mee gehouden en devfs ingebouwd.

Ik moet erbij zeggen dat de harde schijf gewoon benaderbaar is. Met m'n devices is niks mis. Het gaat alleen fout met die checkroot. Als ik met m'n root wachtwoord inlog dan kan ik de hele harddisk gewoon door bladeren, wat onmogelijk zou zijn als er iets niet zou kloppen met m'n device nodes in /dev/.

[Boudewijn]

hmmm h

gooi in fstab even de diskcheck uit.
werkt het nu wel ?

[_JGC_]

Overigens vraag ik me af wat udev voor aanslag op je systeem doet. Het voert geen flikker uit zolang jij geen nieuwe apparaten toevoegt en zolang jij het gewoon laat doen wat het moet doen, vreet het hooguit 1MB geheugen. Als dat een aanslag is wil je niet weten wat devfs + devfsd doet in kernelspace

[--MeAngry--]

_JGC_ schreef op donderdag 31 augustus 2006 @ 00:20:
Overigens vraag ik me af wat udev voor aanslag op je systeem doet. Het voert geen flikker uit zolang jij geen nieuwe apparaten toevoegt en zolang jij het gewoon laat doen wat het moet doen, vreet het hooguit 1MB geheugen. Als dat een aanslag is wil je niet weten wat devfs + devfsd doet in kernelspace

Inderdaad, ik meende juist dat udev er is gekomen om een heleboel overhead uit oa je /dev/ directory weg te halen. Als iets nieuwer is in Linuxland hoeft dat niet persé te betekenen dat het ook trager of logger is zoals vaak bij Windows het geval is.

[Boudewijn]

lol

over resourcegebruik laat ik me niet uit... maar vergelijk ls /dev/ | wc eens met devfs en udev.
ik vind udev dan toch wat minder fijn hoor

[Zr40]

Boudewijn schreef op donderdag 31 augustus 2006 @ 00:29:
lol

over resourcegebruik laat ik me niet uit... maar vergelijk ls /dev/ | wc eens met devfs en udev.
ik vind udev dan toch wat minder fijn hoor

Met udev heb je inderdaad minder device nodes. Echter, de 'ontbrekende' nodes zijn sowieso niet aanwezig. Dat is juist het fijne van udev, alleen de op dat moment aanwezige en dus bruikbare devices worden geplaatst in /dev.

[Boudewijn]

hier niet hoor (ook gentoo)

[Zr40]

Boudewijn schreef op donderdag 31 augustus 2006 @ 00:38:
hier niet hoor (ook gentoo)

offtopic:
Zet in /etc/conf.d/rc eens RC_DEVICE_TARBALL op no. Dat deze optie standaard op yes staat is wazigheid van een eerdere baselayout versie.
Als deze optie aan staat, wordt er bij het afsluiten een tarball van /dev gemaakt, die bij opstarten weer uitgepakt wordt. Dit maakt in feite udev nutteloos. Het is alleen handig als je zelf custom device nodes hebt aangemaakt.

[ Voor 27% gewijzigd door Zr40 op 31-08-2006 00:45 ]

[R_W]

Is het niet zo dat je support voor je root filesystem niet als module kunt gebruiken, omdat die modules juist op je root filesystem staan? Probeer ext3 'ns in je kernel te bakken i.p.v. met een module.

Verder zijn dit nog wel 2 links die je kunnen helpen (als je ze nog niet gezien had):
http://www.gentoo.org/doc...ook-x86.xml?part=1&chap=7
http://gentoo-wiki.com/HOWTO_Compile_a_Kernel_Manually

[edit]
Staat ook in het handbook:

Now go to File Systems and select support for the filesystems you use. Don't compile them as modules, otherwise your Gentoo system will not be able to mount your partitions.

En in de howto:

Select one or more of the following filesystems. _Your_ filesystem, the one on which gentoo is now running, MUST BE COMPILED INTO THE KERNEL, NOT as a module.

[ Voor 33% gewijzigd door R_W op 31-08-2006 00:52 ]

[--MeAngry--]

R_W schreef op donderdag 31 augustus 2006 @ 00:48:
Is het niet zo dat je support voor je root filesystem niet als module kunt gebruiken, omdat die modules juist op je root filesystem staan? Probeer ext3 'ns in je kernel te bakken i.p.v. met een module.

Verder zijn dit nog wel 2 links die je kunnen helpen (als je ze nog niet gezien had):
http://www.gentoo.org/doc...ook-x86.xml?part=1&chap=7
http://gentoo-wiki.com/HOWTO_Compile_a_Kernel_Manually

Hij heeft het filesystem wel in z'n kernel gebakken zoals in z'n TS staat.

[deepbass909]

m'n ext3 zit in m'n kernel (zie TS) dat mag het probleem niet zijn en heb ervaring genoeg met het bouwen van een eigen kernel (en wat modulair zou kunnen en wat niet).

Nogmaals, de schijf is netjes benaderbaar, dat is het probleem niet. Alleen die ROOT filesystem check gaat fout.

@_JGC_
als de machine draait, maakt udev idd niks uit. Alleen merk ik een wel heel erg duidelijke vertraging bij het opstart met udev aan of uit. Op dat moment staat deze, vrij trage cpu (k6-2 266Mhz) te zoeken naar hardware. Hardware die nooit zal veranderen en dus rustig statisch ingesteld mag staan.
Dat de /dev misschien wat voller is dan nodig zou hoeven zijn is hierbij geen probleem.

Ik vind het gewoon irritant dat een media pc er bijna 3 minuten over doet voor hij opgestart is, terwijl ik weet dat het veel sneller zou kunnen.

Momenteel doet hij over het echte opstarten van linux (vanaf het moment dat Grub opdracht geeft op de kernel te starten) 2minuut 22. Ik zou al heel blij zijn als die terug gebracht zou kunnen worden tot 1,5 minuut.

Ik ben met behulp van bootchart (prachtig programma btw. genereerd een png wat het hele opstart proces), zie hier voor m'n huidige opstart process
(waarschuwing, het is een nogal groot bestand)

@Boudewijn
deze check is een standaard onderdeel van het boot runlevel en kan helaas (en terrecht) niet uitgezet worden. Gentoo controleerd bij het afsluiten of het aanwezig is, en zo nee, dan wordt het vrolijk weer aangezet. Fstab heeft hier geen vat op.

[R_W]

--MeAngry-- schreef op donderdag 31 augustus 2006 @ 00:52:
[...]

Hij heeft het filesystem wel in z'n kernel gebakken zoals in z'n TS staat.

In de kernel zijn zowel de ext2 als ext3 module meegebakken.

Vandaar de verwarring, mijn excuses.

[Jungian]

Vraagje :

waarom wil je eigenlijk in godsnaam opnieuw opstarten ?

[JMW761]

Jungian schreef op donderdag 31 augustus 2006 @ 01:16:
Vraagje :

waarom wil je eigenlijk in godsnaam opnieuw opstarten ?

goeie vraag !!

daarbij wil ik graag nog opmerken dat, wat je ook van de 2.6 kernels' stability vindt, deze iig een beter/sneller geheugenbeheer heeft en onder andere daardoor, door de bank genomen een stuk (laten we zeggen 10 a 20%) sneller is.
dit is natuurlijk wel compleet afhankelijk van wat je exact met je server doet.

Juist voor een trage bak lijkt die 10 a 20% winst me enorm aantrekkelijk.

[_JGC_]

Dan doet Gentoo echt iets heel erg fout met udev. De bovengenoemde RC_TARBALL optie zorgde er op mijn laptop destijds iig voor dat die er 2-3 minuten over deed om op te starten met gentoo. Ik heb het maar 2-3 weken gedraaid voor ik het zat werd (best lang nog), dus de precieze details weet ik er niet van.

Je kunt udev dusdanig tunen dat er geen gebruik wordt gemaakt van autodetectie. Verder heb je altijd nog de keuze om met een statische /dev te werken, dit werkt ook altijd nog met 2.6 kernels, heb je geen 2.4 voor nodig. Devfs is een debiele oplossing die je niet wilt. Je wilt of udev, of een statische /dev, maar niet devfs.

[deepbass909]

@_JGC_
Ik vrees dat niet udev het probleem is, maar het moederbord/cpu dat de boel zo traag maakt. Op m'n eigen pc vliegt udev letterlijk over het scherm, maar bij deze blijft hij gewoon een 30 of meer seconden scannen naar hardware.
Een tarball laten maken doet hij al, alleen kost het uitpakken ook weer opstarttijd, waarbij 100% statisch deze tijd niet verspilt wordt.

@Jungian
Het is geen echte server, maar een mediacenter. Aangezien hij pal naast m'n bed staat en niks zit te doen als hij geen muziek speelt of dvd's afspeeld vind ik het lichtelijk overdreven om het 's nachts aan te laten. Maar ja, hij moet natuurlijk wel een beetje snel willen opstarten.

Om even een ideetje te geven over hoe traag sommige dingen gaan, het opstarten van grub duurt ook al snel 5 tot 10 sec, waar het op al m'n andere pc's direct start. Nu klinkt 5 sec niet als iets om over naar huis te schrijven, maar als er 10, 15 processen gestart kunnen worden met 5 seconde winst, dan praat je over een goed minuut sneller opstarten.

Verder is stability en geheugen beheer ook niet echt aan de orde in de zin die JMW waarschijnlijk bedoelt. Uptime zal zelden meer dan 10, 12 uur zijn waarbij de belasting zal bestaan uit mp3's afspelen, dvd's (via een dxr3 kaart) en misschien later mythtv. Op MythTV na taken die ook niet geheugen intensief zijn. Vandaar mijn opmerking dat de 2.6 kernel voor mij geen voordelen biedt en eerder een nadeel zal zijn door niet uitschakelbare features die overbodig zijn.

Nu zie ik met Bootchart (zie m'n port hierboven voor de grafiek) dat m'n load inmiddels behoorlijk verdeeld is. Ik heb dingen als consolefont en keymaps niet nodig, wat al bijna een minuut opstarttijd scheelt. Daarnaast mag het ip-adres best statisch zijn, waardoor dhcp ook komt te vervallen en weer wat winst geeft. Nu kost depscan.sh in totaal ook best wat tijd. Nu weet ik dat het een onderdeel is van de init processen (controlle of alle vereistte processen wel draaien). Ik weet dat die een nogal belangrijk process is, maar net als andere controles is het in deze machine niet echt nodig. Ik zou m'n init-tree ook met hand kunnen opbouwen aan de hand van de volgorde die ik nu heb.

als ik eigenlijk zo naar m'n eisen kijk, zoek ik een distro/oplossing met moderne software, maar een antieke (statische) opstart afhandeling.

[_JGC_]

Wat zijn de specs van die doos eigenlijk? Kan me geen systeem meer voorstellen wat zoveel tijd neemt om op te starten, zelfs mijn oude pentium 133 doosjes waren niet zo traag, die deden in 30 seconden tijd een complete netwerkboot met autodetectie van hardware, inclusief het starten van XFree86. (tijd gemeten vanaf het moment dat PXE de controle aan pxelinux geeft).

[deepbass909]

Het is een AMD K6-2 op 266 Mhz (66 x 4) of 250 Mhz (100 x 2.5) op een DFI KV3B+ (uit m'n hoofd) met 128Mb geheugen.
Qua specs niet super traag, maar ik weet uit ervaring dat de moederborden met de via83565 (MPV) chipset altijd traag waren met hardware detectie. Zo is de initialisatie van de BIOS ook erg traag vergeleken met andere moederborden.

Als je in de bootchar grafiek kijkt, kan je zien dat het hele opstartproces vanaf het moment dat de kernel start 2 minuten in beslag neemt, waarbij cpu belasting voor een overgroot deel de snelheid bepaald.
Andere hardware is lastig, omdat dit al een multi media pc is die ik al een tijd geleden heb gebouwt, met wat speciale hardware (lcd en irfrarood aansturing) door mijzelf gemaakt speciaal voor dit moederbord. Daarnaast is de cpu voor het uiteindelijke werk snel zat (opstarten van Xine is een kwestie van seconden).

Het is puur het opstarten van Linux wat ik erg traag vind gaan. Nu kan dit natuurlijk een eigenschap zijn van Gentoo op oudere hardware. Gentoo is in dit geval een absolute vereiste en ik wil best wel een andere distro erop zetten, mits hij wel recent is met z'n libraries en een goede package manager heeft. Debian zou een mogelijkheid kunnen zijn, maar ik vind debian persoonlijk niet zo lekker werken (wijkt teveel af van Gentoo, waar ik inmiddels behoorlijk in thuis ben).

[_JGC_]

DFI K6BV3+ of P5BV3+ is op zich niet een raar bord, heb dat ding zelf ook gehad. VIA MVP3 chipset, 1MB L2 cache en een BIOS die wat opties mist waardoor hij in performance een klein beetje, maar niet schrikbarend veel, achterblijft op de rest van de moederborden met dezelfde chipset.

Mocht je overigens nog een Pentium 166/200/233MMX hebben liggen: die doen het ook perfect op 2.5x100 op dit bord en lopen dan gewoon een K6/2-400 voorbij.

Waar je even op moet letten is de jumper bij je geheugenslots die het geheugen op AGP of FSB snelheid laten draaien, als deze op AGP snelheid staat draait het sowieso slechts op 66MHz.

Overigens zie ik in je bootchart dat je hotplug nog gebruikt? Sinds een bepaalde udev release doet udev dat allemaal uitstekend zelf en is hotplug compleet overbodig. Op Archlinux hebben we hotplug dan ook al een tijdje geleden uit de distro gegooid (we supporten geen linux 2.4 meer sinds de update naar glibc 2.4, dus is hotplug nu echt overbodig). Udev detecteert hier zelf in een paar seconden alle hardware, waar hotplug daar al snel een halve minuut over kon doen. Je zou ook kunnen zoeken naar een manier om hotplug en udev autodetect uit te kunnen schakelen op gentoo om vervolgens zelf de nodige modules in te laden. Een downgrade naar 2.4 gaat je helemaal niets helpen, je houdt hotplug op deze manier.

[deepbass909]

Het viel mij ook op dat hotplug in m'n bootchart nog steeds voor komt. Ik moet het heel even controleren met de laatste versie die ik heb gemaakt (deze was al wat ouder), want hotplug heb ik toch echt uit m'n runlevels gegooit.
Ik kan m'n geheugensnelheid niet met een jumper aanpassen, maar dat maakt ook weinig uit, aangezien er een 66Mhz reepje inzit.

Ik heb nog wel ergens een 166MMX liggen die uitstekend liep op 200 Mhz, misschien dat hij nog naar 250 wil, maar dat weet ik niet zeker. Maar daarvoor moet ik eerst een oude dell ontmantelen.

Wat betreft deze bordjes, ik werkte een paar jaar geleden op de TD van Paradigit te Utrecht, en dat was in de na-dagen van de K6 serie (de Athlon werd net geïntroduceerd) en ik weet uit die tijd dat deze bordjes altijd performance problemen kende. Daarnaast was de MVP3 chip een ramp in combi met win95/98 (ide drivers die niet wouden, USB dat slecht werkte). Maar het is een lekker compact bordje met pinheaders voor de parallel en seriële poorten (heb ik tenminste geen loop-back kabels nodig voor m'n lcd en ir) en dankzij de dxr3 kaart snel zat voor dvd's.

[deepbass909]

Ik ben nu aan het stoeien met udev, en deze blijkt eigenlijk geen invloed te hebben op de opstart tijd. Die is nu zo'n 1,5 minuut.

Een andere processor erin zetten gaat overigens niet zomaar. Om de prestaties te maximaliseren is alle software gecompileerd met optimalisaties voor de AMD K6-2 (niet alleen de kernel maar ook m'n CFLAGS staan zo ingesteld). Hercompileren zou dan zoveel tijd gaan kosten dat ik dan beter direct over kan gaan stoppen op slack of debian.

Als ik naar m'n startup kijk, zie ik op het moment niet echt ruimte voor verbetering.

[_JGC_]

Je zou nog kunnen proberen om hdparm vooraan in het bootproces te krijgen. Die oude MVP3 dingen zijn niet super qua IDE als ze niet goed ingesteld worden.

Verder is mij nooit opgevallen dat die MVP3 dingen zo ranzig traag zijn als jij het nu meemaakt. Ik heb op een DFI P5BV3+ en later op een K6BV3+ (zelfde bord, alleen de voedingsvoorziening is beter) een hele rij CPUs gedraaid:
- Cyrix 6x86MX-PR200 (traag kutding)
- K6/2-350 (minstens 2x zo snel)
- K6/2-500 (niet echt super veel beter dan die vorige)
- K6/3-400 (super CPU, eigen L2 cache)
- Pentium 166MMX @ 2.5x100 (trok een spelletje unreal tournament bijna mee met de K6/3-400, alleen de 384MB geheugen deed de 256MB cache area de nek om)
- K6/3+ 450 (laatste beestje, daarna is de boel vervangen door een duron 800)

Zolang ik er geen brakke 4500RPM disks of quantum bigfoots in hing was dat systeem gewoon redelijk snel, de cyrix uitgezonderd dan. Als jij een oude brakke 2GB of 4GB schijf in die doos hangt, wil ie wel sloom zijn ja.