[Debian] kernel recompile trubbels

[UltraSub]

Heb hier een nieuw systeem staan, heb geupgrade van een ouwe C366@550, naar een MSI K8N Neo4 Platinum, met AMD64 3200+. Alles gewoon omgeprikt, en booten. Werkt flawless. Linux roeleert

Maarrr... Na de reboot zag ik natuurlijk toch wat dingetjes (oa highmem support needed), en natuurlijk wilde ik de kernel optimizen voor de AMD64. Dus recompile. Ik reboot, en krijg alleen maar permission denied errors op alle partities op hda. Daarnaast zegt mdadm dat hij geen devices kan vinden voor md2 (een raid-1), en dat terwijl toch echt alle drives perfect herkend worden, en aanwezig zijn. Reassembling md2 met het handje, dus op cmdline zelf drives opgeven, werkt wel. Array wordt gestart, is te mounten en te lezen. Laat ik mdadm scannen, dan ziet hij dus wel dat er een md2 is, maar verder ziet hij geen drives. Weird. Maar het wordt nog beter......

Ik denk, ah, foutje met compilen. Dus niet (denk ik). Want wat blijkt? Iedere kernel die ik compile, heeft deze twee problemen (de permission denied errors op hda partities en het mdadm probleem). Sterker nog, als ik de huidige kernel-source gebruik, en ik recompile met de .config die nu draait, dan doet die "nieuwe" kernel precies hetzelfde! Dat kan toch niet?? Ik draai op dit moment diezelfde kernel, en die werkt perfect.

Het komt er dus op neer dat geen enkele kernel die nieuw wordt gecompileerd werkt voor me. De enige die werkt, is de al bestaande... Ik ben de draad volledig kwijt.
Heb dus nu wel een werkende server, maar ik mis dus een gieg ram, en de kernel is niet optimized. Nieuwe kernel krijg ik dus gewoon niet voor elkaar.

Kan iemand me een zetje in de juiste richting geven? Heb me vannacht al rot gegoogled en ge-irc'ed tot 0430, maar ik kom er niet uit...

[terabyte]

Ik reboot, en krijg alleen maar permission denied errors op alle partities op hda. Daarnaast zegt mdadm dat hij geen devices kan vinden voor md2 (een raid-1),

Je moet toch echt meer info posten (lees: volledige output van je console)

[UltraSub]

Komt goed... ik zal straks wat meer info posten..
Ben nu weer een kernel aan het bakken, en daar post ik dadelijk wel ff dmesg van. Die permission denied errors staan nergens na de boot, alleen op console. Maar die zijn simpel uit te leggen. Alle write acties op partities op hda (boot, /, /var, enz) krijgen permission denied. Zelf als root user een touch doen gaat ook niet. Wat dan wel weer gaat in vi is een override: :wq!
Dan zijn ze dus niet read-only mounted. Toch?

/edit:
Thank god een kernel compile duurt op deze bak maar 10 minuten, in tegenstelling tot een uur op de vorige

[ Voor 12% gewijzigd door UltraSub op 11-02-2006 11:58 ]

[daft_dutch]

compileerd je ook initrd. wat is je commando welke source gebruik je.

[UltraSub]

Ok, deze draait perfect:
Linux viper 2.6.8-050107 #1 Fri Jan 7 20:40:28 CET 2005 i686 GNU/Linux
En als ik dezelfde 2.6.8 source gebruik, met dezelfde .config als die wat nu draait, nogo.

Ben nu 2.6.15 aan het compilen, maar weet al bijna zeker dat die niet gaat werken.
Deze gebruik ik: time make-kpkg --initrd --revision=1 kernel_image
Maakt daarna tijdens dpkg -i met yaird een initrd'tje aan.
Zo heeft het voor mij altijd gewerkt. Geen idee wat hier mis gaat

[UltraSub]

Relevante output uit dmesg:

code:

Probing IDE interface ide0...
hda: ST320423A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
PDC20268: IDE controller at PCI slot 0000:01:07.0
PDC20268: chipset revision 1
PDC20268: ROM enabled at 0xfd8b0000
PDC20268: 100% native mode on irq 18
    ide2: BM-DMA at 0xdb00-0xdb07, BIOS settings: hde:pio, hdf:pio
    ide3: BM-DMA at 0xdb08-0xdb0f, BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: Maxtor 6Y120P0, ATA DISK drive
ide2 at 0xdf00-0xdf07,0xde02 on irq 18
Probing IDE interface ide3...
hdg: Maxtor 6Y120P0, ATA DISK drive
ide3 at 0xdd00-0xdd07,0xdc02 on irq 18
Probing IDE interface ide1...
hda: max request size: 128KiB
hda: 40011300 sectors (20485 MB) w/512KiB Cache, CHS=39693/16/63, UDMA(66)
hda: cache flushes not supported
 hda: hda1 hda2 hda3 < hda5 hda6 hda7 hda8 hda9 >
hde: max request size: 128KiB
hde: 240121728 sectors (122942 MB) w/7936KiB Cache, CHS=65535/16/63, UDMA(100)
hde: cache flushes supported
 hde: hde1
hdg: max request size: 128KiB
hdg: 240121728 sectors (122942 MB) w/7936KiB Cache, CHS=65535/16/63, UDMA(100)
hdg: cache flushes supported
 hdg: hdg1
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
raid5: automatically using best checksumming function: pIII_sse
   pIII_sse  :  6460.000 MB/sec
raid5: using function: pIII_sse (6460.000 MB/sec)
raid6: int32x1    930 MB/s
raid6: int32x2   1223 MB/s
raid6: int32x4    729 MB/s
raid6: int32x8    651 MB/s
raid6: mmxx1     1716 MB/s
raid6: mmxx2     3138 MB/s
raid6: sse1x1    1426 MB/s
raid6: sse1x2    2337 MB/s
raid6: sse2x1    2313 MB/s
raid6: sse2x2    3136 MB/s
raid6: using algorithm sse2x2 (3136 MB/s)
md: raid6 personality registered as nr 8
md: multipath personality registered as nr 7
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
ReiserFS: hda2: found reiserfs format "3.6" with standard journal
ReiserFS: hda2: using ordered data mode
ReiserFS: hda2: journal params: device hda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda2: checking transaction log (hda2)
ReiserFS: hda2: Using r5 hash to sort names
Adding 489940k swap on /dev/hda7.  Priority:-1 extents:1 across:489940k
usbcore: registered new driver usbfs
usbcore: registered new driver hub
usbcore: registered new driver usbkbd
drivers/usb/input/usbkbd.c: :USB HID Boot Protocol keyboard driver
md: md2 stopped.
ReiserFS: hda1: found reiserfs format "3.6" with standard journal
ReiserFS: hda1: using ordered data mode
ReiserFS: hda1: journal params: device hda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda1: checking transaction log (hda1)
ReiserFS: hda1: Using r5 hash to sort names
ReiserFS: hda5: found reiserfs format "3.6" with standard journal
ReiserFS: hda5: using ordered data mode
ReiserFS: hda5: journal params: device hda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda5: checking transaction log (hda5)
ReiserFS: hda5: Using r5 hash to sort names
ReiserFS: hda6: found reiserfs format "3.6" with standard journal
ReiserFS: hda6: using ordered data mode
ReiserFS: hda6: journal params: device hda6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda6: checking transaction log (hda6)
ReiserFS: hda6: Using r5 hash to sort names
ReiserFS: hda8: found reiserfs format "3.6" with standard journal
ReiserFS: hda8: using ordered data mode
ReiserFS: hda8: journal params: device hda8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda8: checking transaction log (hda8)
ReiserFS: hda8: Using r5 hash to sort names
ReiserFS: hda9: found reiserfs format "3.6" with standard journal
ReiserFS: hda9: using ordered data mode
ReiserFS: hda9: journal params: device hda9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda9: checking transaction log (hda9)
ReiserFS: hda9: Using r5 hash to sort names
EXT3-fs: unable to read superblock

De enige ext3 in het systeem, is die op /dev/md2.

Wat is er in mdadm.conf:

code:

viper:~# cat /etc/mdadm/mdadm.conf 
DEVICE /dev/hde /dev/hdg
ARRAY /dev/md2 level=raid1 num-devices=2 UUID=a8743448:13ccfd88:74db35b1:2e8f2033
   devices=/dev/hde1,/dev/hdg1

Laat mdadm zelf maar eens scannen, en vind niets:

code:

viper:~# mdadm --detail --scan

Assemble en start maar, maar zoek het zelf uit (aan de hand van mdadm.conf):

code:

viper:~# mdadm -As
mdadm: no devices found for /dev/md2

Toch zijn ze er:

code:

viper:~# mdadm --examine /dev/hde1
/dev/hde1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : a8743448:13ccfd88:74db35b1:2e8f2033
  Creation Time : Sat Feb 11 00:21:13 2006
     Raid Level : raid1
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 2

    Update Time : Sat Feb 11 12:11:25 2006
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 97da1495 - correct
         Events : 0.11710


      Number   Major   Minor   RaidDevice State
this     0      33        1        0      active sync   /dev/hde1

   0     0      33        1        0      active sync   /dev/hde1
   1     1      34        1        1      active sync   /dev/hdg1

code:

viper:~# mdadm --examine /dev/hdg1
/dev/hdg1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : a8743448:13ccfd88:74db35b1:2e8f2033
  Creation Time : Sat Feb 11 00:21:13 2006
     Raid Level : raid1
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 2

    Update Time : Sat Feb 11 12:11:25 2006
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 97da1498 - correct
         Events : 0.11710


      Number   Major   Minor   RaidDevice State
this     1      34        1        1      active sync   /dev/hdg1

   0     0      33        1        0      active sync   /dev/hde1
   1     1      34        1        1      active sync   /dev/hdg1

Dan maar met het handje opgeven op de commandline, en dat werkt gewoon:

code:

viper:~# mdadm -A /dev/md2 /dev/hde1 /dev/hdg1
mdadm: /dev/md2 has been started with 2 drives.

code:

viper:~# cat /proc/mdstat 
Personalities : [linear] [raid0] [raid1] [raid5] [multipath] [raid6] 
md2 : active raid1 hde1[0] hdg1[1]
      120060736 blocks [2/2] [UU]
      
unused devices: <none>

Hier de filesystem layout:

code:

viper:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda2             479M  267M  212M  56% /
tmpfs                1013M     0 1013M   0% /dev/shm
/dev/hda1              95M   43M   52M  46% /boot
/dev/hda5             9.4G   33M  9.3G   1% /free
/dev/hda6             4.7G  4.3G  440M  91% /usr
/dev/hda8             2.4G  438M  2.0G  19% /home
/dev/hda9             1.8G  318M  1.5G  18% /var
tmpfs                  10M   68K   10M   1% /dev
/dev/md2              113G   25G   83G  23% /data

Permission denied:

code:

viper:/var/log# touch test
viper:/var/log# rm test
rm: cannot remove `test': Operation not permitted

Maar in het root filesystem werkt het dus blijkbaar toch wel:

code:

viper:/etc# touch test
viper:/etc# rm test

Lijken dus alleen maar subdirs in /var te zijn. In de root van /var gaat het wel.
Nog weirder

* UltraSub gaat weer terug naar werkende kernel booten...


/edit
Ok, ik denk misschien ligt het wel aan de AMD64 instructies, en mis ik iets fundamenteels.
Dus een default debian kernel ge-apt-get (de K8), geinstalleerd, en geboot. En verrek, die doet geen rare dingen in /var, of permission denieds. Maar geen nics gevonden, en geen raid in de kernel
Dus nieuwe kernel bakken, en verrek, weer het zelfde.... **zucht**
Krijg ik net bij het opruimen een ingeving, laten we de .config van die default debian kernel eens gebruiken als start file. En zo gezegd zo gedaan, die compiled nu. Alleen raid-1 in de kernel geplopt, highmem aangezet en de 3com nics in de kernel gebakken, verder niets veranderd. Kijken offie nu wil booten.

[ Voor 7% gewijzigd door UltraSub op 11-02-2006 17:26 ]

[UltraSub]

Ok... ik heb het gehad. Sla mijn kop bijna door de muur heen hier.

Ik weet het echt niet meer. Net zoals gezegd een kernel gebakken met minimaal dezelfde config als de default debian amd64 kernel, ik boot... exact hetzelfde. Mdadm wil niet, en permission denied's op /var...

I'm flabbergasted
Begin zelfs zwaar te twijfelen of een volledige herinstallatie middels netinstall de oplossing gaat zijn
Ben ik misschien nog verder van huis....

[webfreakz.nl]

Geheugen misschien brak?

[UltraSub]

Sja... zou kunnen, maar lijkt me sterk, want ik heb geen enkel probleem met de huidige kernel, en die krijgt ze toch best op zijn flikker regelmatig...
Maar jij denkt omdat de recompiles allemaal mis gaan, en pre-compiled kernels goed zijn?
Hmmmm... sja, die wat werkt, was natuurlijk op het oude systeem gecompiled. En die debian k8 kernel, die deed het ook.... Very strange indeed. Het lijkt er inderdaad op dat mijn compiles allemaal verneukt worden. Wel raar dat ze dan allemaal exact hetzelfde gedrag vertonen. Als het geheugen was, had ik random shit verwacht.
Zal binnenkort eens memtest draaien...

[terabyte]

Of vraag het eens op een Debian-mailinglist.

[halfgaar]

Als je boot met die niet-werkende kernel, wat zegt mount dan? Ik ben wel benieuwd of hij zegt of het RO is. Ik denk het niet, want je kan touchen.

Ik vind het een heel raar probleem. Het kan haast niet. Het moet inderdaad haast wel iets met de hardware ofzo zijn.

Laat trouwens de high-mem optie eens weg. Dat is de enige echte verandering die je doet ten opzichte van de standaard config.

Wat staat er trouwens in de syslog? In debian is de file die ik bedoel denk ik /var/log/syslog. Ik weet niet precies hoe die logfiles zijn verdeeld. Als er één is waar alles in staat (mail, kernel, auth, blabla) zou ik daar even in kijken.

Trouwens, op een zijspoor, waarom alleen /data op RAID1? Als je gewoon alles op RAID1 zet, heb je geen moeite als er een schijf stuk gaat. /data en /free zijn trouwens geen FHS-correcte paden . Dat moet in /mnt...

[UltraSub]

terabyte schreef op zaterdag 11 februari 2006 @ 19:45:
Of vraag het eens op een Debian-mailinglist.

Heb al in #debian en #debian-amd64 gevraagd, niemand kan me helpen...

halfgaar schreef op zaterdag 11 februari 2006 @ 19:52:
Als je boot met die niet-werkende kernel, wat zegt mount dan? Ik ben wel benieuwd of hij zegt of het RO is. Ik denk het niet, want je kan touchen.

Zal straks eens kijken.

Ik vind het een heel raar probleem. Het kan haast niet. Het moet inderdaad haast wel iets met de hardware ofzo zijn.

Ja, ik denk ook steeds meer dat het hardware gerelateerd is. Ik dacht zelf aan de amd64. Maar goed, je moet toch gewoon een 32-bit kernel kunnen compilen in een 32-bits omgeving. Om te testen of het hardware is, ben ik nu de kernel die ik zou willen hebben, aan het bakken op de doos van mijn maat. Haal ik die straks even over, en dan kijken wat die doet. Als die wel werkt.. sja... dan lijkt mij vrij duidelijk dat er iets vernaggeld wordt tijdens het compilen op mijn doos.

Laat trouwens de high-mem optie eens weg. Dat is de enige echte verandering die je doet ten opzichte van de standaard config.

Heb ik al geprobeerd. Heb zoals ik al zei, de exacte config gebruikt, met exact dezelfde source. Dus in theorie zou daar exact dezelfde kernel moeten uit komen zoals die wat wel draait. En wat denk je? Niks. Nogo..

Wat staat er trouwens in de syslog? In debian is de file die ik bedoel denk ik /var/log/syslog. Ik weet niet precies hoe die logfiles zijn verdeeld. Als er één is waar alles in staat (mail, kernel, auth, blabla) zou ik daar even in kijken.

In syslog zie ik niets geks, buiten verklaarbare meldingen, omdat de boot niet lekker is.

Trouwens, op een zijspoor, waarom alleen /data op RAID1? Als je gewoon alles op RAID1 zet, heb je geen moeite als er een schijf stuk gaat. /data en /free zijn trouwens geen FHS-correcte paden . Dat moet in /mnt...

Zit nog in een conversie
Systeem was ooit 20GB, heb daar 2x120 bij gezet in raid. Dat beviel me zo goed, dat ik nu in het nieuwe systeem 2x 80 sata heb, waar straks het os op komt (uiteraard raid1). Maar ik wil eerst de oude situatie werkend hebben op de nieuwe hardware, en dan van daar uit verder.
Alleen kom ik zo niets verder

* UltraSub is heeeeel benieuwd naar wat die op een ander sys gebakken kernel dadelijk doet.

[Wirehead]

Imho zou ik de boel herinstalleren naar pure64 om maximale winst uit je proc te halen. Je data kan je perfect behouden.

[UltraSub]

Nah.. Ik ga niet zo leading edge zitten, dat levert doorgaans alleen maar gedonder op, en maak ik het mezelf moeilijk. Ik kan me best staande houden in Linux land, en wordt ieder jaar beter, maar ik leer doordat andere mensen dezelfde problemen hebben (hadden), en daar hun oplossingen van op het net zetten. En let's face it, er zijn nog lang niet zoveel mensen die pure64 draaien, dus ben je vaak op je zelf aangewezen.

Daarnaast zijn de voordelen niet groot genoeg. Meer als 4GB krijg ik toch niet op mijn (net nieuwe) plank, en het beetje snelheidswinst dat er is, ga ik nooit merken denk ik.
Nah, ik wacht dus nog even af

[daft_dutch]

Mischien is de intrd die je maakt wel verkeerdt.
Ik lul nu ook maar wat maar wat kan het anders zijn

Probeer eens zonder initrd te booten.

[UltraSub]

Zou best kunnen, vroeger maakte ik mijn initrd's met initrdtools, tegenwoordig geef ik --initrd mee tijdens compile, en tijdens installeren maakt dpkg met yaird zelf de initrd. Het zou dus best kunnen dat daar iets mis mee gaat. Maar aan de andere kant, op deze manier heb ik al vele kernels gemaakt, alleen nog nooit op dit huidige systeem (qua installatie dan, niet qua hardware bedoel ik)...

[UltraSub]

Ok, heb net een kernel gecompileerd op de bak van een maat. Guess what... Die boot goed. Geen permission denied shit here. Maarrrr.... de array problemen blijven. Het raid1 array wil gewoon niet automatisch starten. Handmatig assemblen werkt wel. Ik zie dat veel mensen op het net dit lijken te hebben na een kernel upgrade. Echter een oplossing heb ik nog nergens gevonden.
Iemand hier dan een oplossing voor?

[halfgaar]

Ik neem aan dat je raid1 niet als module hebt? In de kernel zelf is veel robuster. Je zei hierboven wel dat je het "in de kernel had geplopt", maar ik vraag maar even voor de zekerheid of je het toch niet als module hebt.

Verder, de partitietypes zijn neem ik aan raidautodetect? Doe eens fdisk -l /dev/hdg en fdisk -l /dev/hde.

Verder, hoe ziet /proc/mdstat eruit als de array nog niet gestart is? Met een broken disc, of gewoon helemaal niet gestart?

Heb je eigenlijk al memtest gedraaid? Dat die ene kernel wel werkt die je ergens anders hebt gecompileerd, impliceert wel problemen. Ik zou er wel voor zorgen dat je de oorzaak van dat probleem oplost.

Trouwens, ik heb heel wat Linux ervaring, en heb verschillende distro's gebruikt, maar nog nooit heb ik iets met initrd moeten doen. Ik compile gewoon de kernel met "make dep clean bzImage modules modules_install" (of misschien geen dep meer met 2.6, weet ik zo niet uit mijn hoofd) en installeer die kernel.

[UltraSub]

halfgaar schreef op maandag 13 februari 2006 @ 16:51:
Ik neem aan dat je raid1 niet als module hebt? In de kernel zelf is veel robuster. Je zei hierboven wel dat je het "in de kernel had geplopt", maar ik vraag maar even voor de zekerheid of je het toch niet als module hebt.

Nope, gewoon netjes in de kernel gecompileerd.

Verder, de partitietypes zijn neem ik aan raidautodetect? Doe eens fdisk -l /dev/hdg en fdisk -l /dev/hde.

Al gechecked, is correct:

code:

viper:/# fdisk -l /dev/md0
viper:/# fdisk -l /dev/hde

Disk /dev/hde: 122.9 GB, 122942324736 bytes
16 heads, 63 sectors/track, 238216 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hde1               1      238216   120060832+  fd  Linux raid autodetect
viper:/# fdisk -l /dev/hdg

Disk /dev/hdg: 122.9 GB, 122942324736 bytes
16 heads, 63 sectors/track, 238216 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdg1               1      238216   120060832+  fd  Linux raid autodetect

Verder, hoe ziet /proc/mdstat eruit als de array nog niet gestart is? Met een broken disc, of gewoon helemaal niet gestart?

Gewoon leeg... Alleen de personalities genoemd. Zodra de array wordt gestart (dus met handmatig assemblen), ziet die er goed uit.

Heb je eigenlijk al memtest gedraaid? Dat die ene kernel wel werkt die je ergens anders hebt gecompileerd, impliceert wel problemen. Ik zou er wel voor zorgen dat je de oorzaak van dat probleem oplost.

Nee, nog steeds niet gedaan. Heb een beetje een tijdprobleem hier
Wat ik nu zelf vermoed is dat op zijn systeem gcc4+ staat, en hier gcc3+. Ik kan me nog herinneren van zijn installatie dat ik daar toen iets had wat met gcc had te maken. Heb net de mijne geupgrade, zal straks nog eens proberen of dat het issue was/is.
Hier zijn versies:

code:

spar:/usr/src# dpkg -l |grep gcc
ii  gcc                                  4.0.2-2               The GNU C compiler
ii  gcc-3.3-base                         3.3.6-12              The GNU Compiler Collection (base package)
ii  gcc-4.0                              4.0.2-5               The GNU C compiler
ii  gcc-4.0-base                         4.0.2-5               The GNU Compiler Collection (base package)
ii  libgcc1                              4.0.2-5               GCC support library

En hier de mijne:

code:

viper:/# dpkg -l |grep gcc
ii  gcc                                      4.0.2-2                    The GNU C compiler
ii  gcc-3.3                                  3.3.4-4                    The GNU C compiler
ii  gcc-3.3-base                             3.3.4-4                    The GNU Compiler Collection (base package)
ii  gcc-4.0                                  4.0.2-9                    The GNU C compiler
ii  gcc-4.0-base                             4.0.2-9                    The GNU Compiler Collection (base package)
ii  libgcc1                                  4.0.2-9                    GCC support library

Trouwens, ik heb heel wat Linux ervaring, en heb verschillende distro's gebruikt, maar nog nooit heb ik iets met initrd moeten doen. Ik compile gewoon de kernel met "make dep clean bzImage modules modules_install" (of misschien geen dep meer met 2.6, weet ik zo niet uit mijn hoofd) en installeer die kernel.

Ik gebruik de debian manier
En daar geef je --initrd mee als je plant dat te gaan gebruiken.

[Buffy]

Heeft er misschien niks mee te maken maar gebruik je soms udev?

Vanaf kernel 2.6.12 is de udev interface op de schop gegaan. De oude versie van udev werkt dus niet met de 2.6.15 kernel en de nieuwe niet met de 2.6.8 kernel. En de debian maintainer van udev vindt dat gebruikers die willen upgraden zelf maar moeten uitzoeken hoe ze die catch-22 kunnen omzijlen.

Je moet dus zelf zorgen dat alle relevante modules geladen worden en /dev entries aangemaakt zijn zodat je de nieuwe kernel kan boot'en en daarna udev updaten.

[halfgaar]

Staat die /data in fstab, zodat hij automatisch gemount wordt? Zo ja, hoe is /data dan gemount voordat de array zichtbaar is?

De GCC versie lijkt me trouwen weinig te maken hebben met je no-access probleem. Zoals je in je startpost al aangaf, een linux schijf moet je gewoon in een ander systeem kunnen douwen, geen probleem. Je moet alleen uiteraard even de juiste IDE drivers en dergelijke aanzetten en dan moet het gewoon werken. Jouw problemen met die kernel-build en je RAID zijn erg vaag.

Heb je trouwens wel de kernel voorzien van de Nvidia IDE/SATA support?

[UltraSub]

Dawns_sister schreef op maandag 13 februari 2006 @ 22:26:
Heeft er misschien niks mee te maken maar gebruik je soms udev?

Vanaf kernel 2.6.12 is de udev interface op de schop gegaan. De oude versie van udev werkt dus niet met de 2.6.15 kernel en de nieuwe niet met de 2.6.8 kernel. En de debian maintainer van udev vindt dat gebruikers die willen upgraden zelf maar moeten uitzoeken hoe ze die catch-22 kunnen omzijlen.

Je moet dus zelf zorgen dat alle relevante modules geladen worden en /dev entries aangemaakt zijn zodat je de nieuwe kernel kan boot'en en daarna udev updaten.

Ik zag dit inderdaad al tijdens mijn vele google acties. Ik ga dit zeker eens nakijken, maar het verklaart niet waarom exact dezelfde kernel als de huidige (alleen nieuw gecompileerd) niet wilde starten.

halfgaar schreef op maandag 13 februari 2006 @ 23:06:
Staat die /data in fstab, zodat hij automatisch gemount wordt? Zo ja, hoe is /data dan gemount voordat de array zichtbaar is?

Yup, staat voor het gemak in fstab. Echter wordt niet gemount. Doordat de array niet gestart is, zie ik ergens in de log een melding dat er geen superblock is.

De GCC versie lijkt me trouwen weinig te maken hebben met je no-access probleem. Zoals je in je startpost al aangaf, een linux schijf moet je gewoon in een ander systeem kunnen douwen, geen probleem. Je moet alleen uiteraard even de juiste IDE drivers en dergelijke aanzetten en dan moet het gewoon werken. Jouw problemen met die kernel-build en je RAID zijn erg vaag.

En of die vaag zijn... Nondeju zeg

Heb je trouwens wel de kernel voorzien van de Nvidia IDE/SATA support?

Yup.
* UltraSub slikt..
SATA support ja
Maar ik vergat voor het gemak dat de bootdisk op IDE loopt. Dit zou het best nog eens kunnen zijn.
Maar dan zou het toch wel toevallig zijn dat die nu wel in de huidige kernel zit, en als ik met díe config een nieuwe bouw, hij er dan niet meer in zit.
Anyway, straks ff kijken. SATA support zit er dus in, maar hoeft er nog niet in. Die twee SATA disks ga ik pas gebruiken als alles stabiel is. Tot die tijd hoef ik maar 3 ide disks aan de gang te krijgen. De bootdisk vanaf de nvidia ide poort op het bord, en de 2 raid disks vanaf een promise controller.

Hij draait dus nu, maar ik ben nog lang niet uitgetest. En ik moet nondeju die array zo ver krijgen dattie automatisch mount, want das vet irritant, als dat bij iedere boot met het handje moet.

[webfreakz.nl]

Zet een mount-script in je startup scripts?

En wat is nu de status van je probleem? Is het al opgelost of niet?

[halfgaar]

Ik ben benieuwd wat het resultaat is van nvidia IDE aanzetten in de kernel. Ik ga wel verder met raden zodra je daar over hebt bericht

Zet een mount-script in je startup scripts?

Dat zou natuurlijk een kludge zijn.

[UltraSub]

webfreakz.nl schreef op dinsdag 14 februari 2006 @ 11:41:
Zet een mount-script in je startup scripts?

Blegh.. mdadm doet gewoon niet wattie moet doen right now, en dat zie ik graag opgelost.

En wat is nu de status van je probleem? Is het al opgelost of niet?

Nope. Moet overdag werken, en heb het 's avonds best druk. Ben blij dattie draait (met wat handmatige acties) en ik dus rustig aan kan klooien, maar natuurlijk probeer ik het zo snel mogelijk op te lossen, en het topic hier (uiteraard) up-2-date te houden.

halfgaar schreef op dinsdag 14 februari 2006 @ 12:29:
Ik ben benieuwd wat het resultaat is van nvidia IDE aanzetten in de kernel. Ik ga wel verder met raden zodra je daar over hebt bericht

En das precies wat ik vanavond (alhoewel... valentijn ) wilde gaan testen.

[...]
Dat zou natuurlijk een kludge zijn.

Psies, dat gaat er bij mij niet in


/edit:
Damn, nvidia ide zat er al in
Toch nog ff recompilen, kijken of deze wel gaat werken nu...
Wishfull thinking: misschien moest de kernel optimized zijn voor AMD64 tijdens een compile, en worden daarom kernel compiles verneukt op deze machine.

[ Voor 13% gewijzigd door UltraSub op 14-02-2006 17:23 ]

[UltraSub]

Update!
Op de een of andere manier is er iets raars aan de hand.
Ik heb vroeger op beide hd's een md0 gehad, maar heb die weg gegooid, en (in het kader van op handen zijnde migratie) de boel gefisked, en de superblocks gezeroed. Daarna een md2 aangemaakt. Die werkt dus ook. Maar net kreeg ik die ook niet meer online
Dus ik maar eens scannen, en wat eerst geen output opleverde, retourneerde nu:

code:

viper:~# mdadm --detail --scan
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=a8743448:13ccfd88:74db35b1:2e8f2033

Ik denk wtf?? Ff UUID's vergelijken, of we het over dezelfde hebben:

code:

viper:~# mdadm --examine /dev/hde1
/dev/hde1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : a8743448:13ccfd88:74db35b1:2e8f2033
  Creation Time : Sat Feb 11 00:21:13 2006
     Raid Level : raid1
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 2

    Update Time : Tue Feb 14 17:43:33 2006
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 97e03911 - correct
         Events : 0.73424


      Number   Major   Minor   RaidDevice State
this     0      33        1        0      active sync   /dev/hde1

   0     0      33        1        0      active sync   /dev/hde1
   1     1      34        1        1      active sync   /dev/hdg1
viper:~# mdadm --examine /dev/hdg1
/dev/hdg1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : a8743448:13ccfd88:74db35b1:2e8f2033
  Creation Time : Sat Feb 11 00:21:13 2006
     Raid Level : raid1
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 2

    Update Time : Tue Feb 14 17:43:33 2006
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 97e03914 - correct
         Events : 0.73424


      Number   Major   Minor   RaidDevice State
this     1      34        1        1      active sync   /dev/hdg1

   0     0      33        1        0      active sync   /dev/hde1
   1     1      34        1        1      active sync   /dev/hdg1

Ja dus! Hmm, eea aangepast, en nou krijg ik hem dus wel online, zonder de beide disks op te hoeven geven... Very strange! Die md0 wás weg, en md2 heeft gewerkt!


/edit
HUH!?!

code:

viper:/etc/mdadm# mdadm -S /dev/md0
viper:/etc/mdadm# mdadm -As
mdadm: no devices found for /dev/md0
viper:/etc/mdadm# mdadm --detail --scan

/edit2
Nondeju:

code:

viper:/etc/mdadm# mv mdadm.conf mdadm.conf.bak2
viper:/etc/mdadm# mdadm -As
mdadm: No arrays found in config file
viper:/etc/mdadm# mdadm --detail --scan
viper:/etc/mdadm# mdadm -A /dev/md0 /dev/hde1 /dev/hdg1
mdadm: /dev/md0 has been started with 2 drives.

Ik word gek. Maar misschien ziet iemand nu het licht (bij mij is het iig uit nu)

Overigens, die laatste recompile op mijn eigen bak, werkte vlekkeloos. Niks veranderd, alleen cifs support toegevoegd, die zag ik toevallig staan
Blijft over het mdadm probleem, en that's a big pain in the ass now.

* UltraSub gaat rap koken voor het meissie thuiskomt en er een verhaal over valentijnsdag komt

[ Voor 18% gewijzigd door UltraSub op 14-02-2006 18:04 ]

[UltraSub]

Hmm... ik kom er net achter dat als ik een 'mdadm -As' doe, ik standaard de melding krijg dat er geen arrays in de config staan. Default is die config file (volgens manpage) /etc/mdadm.conf.
Uiteraard heb ik mijn confs dus daar naar toe verplaatst, maar ook dan krijg ik de melding dat er geen arrays in de config staan. Maar nou het rare, als ik --config=/etc/mdadm.conf opgeef, dan vind hij ze wel.
Het lijkt er dus op dat mdadm een andere config gebruikt. Ik heb met locate alle mdadm files gezocht, maar ik zie nergens anders config files. Alleen /etc/default/mdadm, waar wat autostart gegevens staan. Als ik daar de array config in zet, dan krijg ik gewoon dezelfde melding. Als mdadm een een config file ziet, scant hij niet meer, maar volgt blind die config. Als daar dan niks (of niet de juiste) info in staat, dan krijg ik de situatie zoals ik die nu heb. Maar waar o waar zou dan nog een config kunnen staan? Het feit dat het wel werkt als ik --config= mee geef, doet me hier belanden. Of zie ik iets over het hoofd?

[Buffy]

Probeer eens 'strace mdadm -As >/tmp/output.txt 2>&1 en kijk in output.txt welke bestanden er allemaal geopend worden.

[halfgaar]

als eerst, in debian staan in /etc/default de configfiles voor de bootscripts. Opzich zou het daar niet in moeten staan.

mdadm hoeft trouwens eigenlijk niet eens een configfile te hebben. Je kan hem gebruiken voor het maken van je array, maar het is niet nodig. Voor het starten helemaal niet zelfs.

Maar mij ben je onderhand wel kwijt... Ik heb ook weinig ervaring met mdadm. Ik ben nog "oldskool", met de raid2 tools... Het enige dat ik met mdadm heb hoeven doen is twee keer een broken disk vervangen. Ik denk dat ik eens een oude bak optrommel om eens met mdadm te spelen.

Maar je array wil nog steeds niet autostarten?

En over cifs, waarom zou dat iets uitmaken voor je permission denied probleem? Tenminste, je hebt het toch wel over "Common Internet file system. Used for client/server communication within Microsoft® operating systems."

[UltraSub]

Dawns_sister schreef op dinsdag 14 februari 2006 @ 23:51:
Probeer eens 'strace mdadm -As >/tmp/output.txt 2>&1 en kijk in output.txt welke bestanden er allemaal geopend worden.

Oei, das mooie info, straks als ik thuis kom ff proberen!

halfgaar schreef op dinsdag 14 februari 2006 @ 23:56:
als eerst, in debian staan in /etc/default de configfiles voor de bootscripts. Opzich zou het daar niet in moeten staan.

Psies.

mdadm hoeft trouwens eigenlijk niet eens een configfile te hebben. Je kan hem gebruiken voor het maken van je array, maar het is niet nodig. Voor het starten helemaal niet zelfs.

I know. Maar das nou net het probleem. Als ik al "mijn" config files weg haal, krijg ik nog de melding dattie in de config file geen arrays kan vinden! Dat betekent impliciet dat hij nog ergens anders een config leest (denk ik dan), omdat zodra er een config gebruikt wordt, hij niet meer 'scant' naar arrays, maar strict de config volgt. En als daar dan niks in staat, sja...

Maar mij ben je onderhand wel kwijt... Ik heb ook weinig ervaring met mdadm. Ik ben nog "oldskool", met de raid2 tools... Het enige dat ik met mdadm heb hoeven doen is twee keer een broken disk vervangen. Ik denk dat ik eens een oude bak optrommel om eens met mdadm te spelen.

Same here. Ook ik was oldskool, maar ik moest maar eens om, dacht ik... raidtools2 er af, mdadm als enige er op, en sja, het werkte eerst perfect, alleen nu na een hoop hardware changes wat trubbels. Maar goed, ik kom er uiteindelijk wel uit, met wat hulp van her en der

Maar je array wil nog steeds niet autostarten?

Nope.. Straks het commando van Dawns_sister eens proberen, en kijken of ik daarmee verder kan komen.

En over cifs, waarom zou dat iets uitmaken voor je permission denied probleem? Tenminste, je hebt het toch wel over "Common Internet file system. Used for client/server communication within Microsoft® operating systems."

Nee, dat bedoel ik niet. Wilde alleen maar zeggen dat dat het enige was wat ik had veranderd in de kernel. Niet dat dat de oplossing zou zijn..... Ik weet wat CIFS is
Wilde het alleen graag in de kernel, omdat er 2003 machines draaien hier..

[UltraSub]

Ok... problem looks solved...
And the culprit was..... udev

Heb strace gebruikt, en ja, de enige file die werd geprobeerd te openen was /etc/mdadm/mdadm.conf.
File weg gehaald, kan niet starten. File helemaal opnieuw van scratch opgebouwd, array kan starten, zonder devices mee te geven, echter toen kreeg ik iedere keer: /dev/md0 not found. Ik denk, weer udev volgens mij, dus ik wat gezocht op Google, kom ik dit tegen:
http://lists.debian.org/debian-testing/2006/02/msg00018.html

Aha! Hijs dus niet eens nodig! Dus apt-get remove --purge udev, reboot, still nogo
/etc/default/mdadm autostart op true gezet, weer reboot, en hoezee... het werkt

Ik ga nou nog een rebootje doen, om te kijken of het ook zo blijft

/edit
Probleem blijft opgelost
* UltraSub happy...

[ Voor 4% gewijzigd door UltraSub op 15-02-2006 18:19 ]

[halfgaar]

Als jij autostart op true moet zetten in een configfile, dan is er in mijn mening nog steeds iets mis. De kernel moet dat doen, nog voordat init ook nog maar gestart wordt. Als hij dat niet zou doen, zou je ook niet kunnen booten van een md device. Verder beschouw ik het verwijderen van udev als een enorme kludge. Udev is namelijk wel de standaard van de toekomst, zo niet nu al.

Ik ben trouwens benieuwd als ik RAID in de kernel aanzet, of ik dan wel devices heb in /dev. Gentoo is meestal heel voorzienend in dit soort situaties.

[UltraSub]

Hmm ja.. Op zich zou de kernel ze automatisch moeten starten ja, mee eens. Ergens heb ik ook de indruk dat dat lukt nu, en dat ik weer te veel wijzigingen tegelijk heb gehad. Zal dit nog eens testen. Het totale gedrag van de array is wel compleet veranderd nu. Udev verwijderen een kludge? De standaard van de toekomst? Zal best. Ik ben echter van mening dat je dit soort shit alleen wilt op een desktop omgeving, met usb sticks ed. Op een server (ook nog eens fully text-only), is dit onzin imo. Of je even iets moeilijk wil maken zeg. Heb je de man pages van dat ding gezien? Ik ben voorlopig blij dat ik hem kwijt ben.