[Debian][boot-probleem] / op controller /boot op USB

[DJ-NaRRa]

Hallo,

ik stuit al een paar dagen op een probleem met het booten van een nieuwe installatie van Debian. ik ben steeds wel wat stapjes verder gekomen maar nu stuit ik op een probleem waar ik even niet meer zelf uit kom.

Kort geleden heb ik een zelf-bouw NAS geconfigureerd. eerst wilde ik een aparte IDE disk voor het OS tot iemand me aanraadde om een el cheapo sata controllertje te doen met een kleine SATA disk eraan voor / terwijl de /boot op een USB zou staan.

Nou zo gezegd zo gedaan. een SATA controllertje gekocht (pricewatch: Conceptronic CSATA2P) en een 1TB disk voor OS / download / par / repair. De reden dat ik niet gewoon de OS disk aansluit op een van de SATA poorten op mijn mobo is dat de controller sata-150 is terwijl de poorten op mijn mobo sata-300-/600 zijn. Dan zou ik dus 7 disks aan moeten sluiten op mijn mobo en 1 disk op de controller waardoor de hele raid op sata=150 draait

Nu stuit ik op het volgende probleem. mijn bios herkent uiteraard niet de pci-sata controller bij het opstarten en het ding heeft ook geen eigen bios. de installer van Debian herkende de 1TB disk voor het OS naast de raid array ( 8 x 2TB) prima tijdens de installer.

Ik heb / laten installeren op de 1TB disk en de /boot en GRUB op een USB stick die ik nog had. GRUB gaf me eerst een error 17 die ik kon ontwijken door de root(hd2,0) verwijzing te veranderen naar HD(0,0). De installer herkent de disks blijkbaar in een andere volgorde als GRUB.

Zodra initramfs zijn ding doet tijdens het booten krijgt GRUB mijn / niet gevonden en dan hangt het bootproces en soms krijg ik een kernel panic. ik heb ook een ubuntu live cd geprobeerd en daar ziet ubuntu alle disks (de 1tb os disk / de boot usb stick en mijn raid array).

Mijn linux kennis is redelijk beperkt op dit gebied. Ik heb proefgedraaid in een virtuele omgeving met Debian en de progsels die ik wil installeren maar dit gaan zo even buiten mijn directe kennis. Ik vermoed dat ik aparte drivers zal moeten compilen in de kernel en daar vanaf booten. Ik heb al wel docs gevonden hoe ik een kernel compile maar ik weet zo niet welke driver ik zou moeten compilen.

TLTR: moet ik een aparte kernel compilen voor dit probleem en zo ja met welke drivers of is er nog iets anders wat ik zou kunnen proberen?

[CAPSLOCK2000]

Je hoeft sowieso geen kernel te gaan compilen, bespaar jezelf die moeite. De installer ziet de disk, en die krijgt z'n info van de kernel, dus dat zit wel goed. Wel moet je misschien drivers toevoegen aan je initramfs zodat ze met de kernel mee geladen worden.

Grub is alleen de bootloader, zodra je kernel begint met laden speelt die geen rol meer. Er kunnen twee dingen fout gaan, grub geeft de verkeerde locatie voor / door aan de kernel, of de drivers voor die controller zitten niet in initramfs.

Het eerste is eenvoudig te controleren door in het grub boot menu te kijken.
Als daar niks mis mee is zou ik de installer of live cd booten, de disks mounten, chrooten en dat update-initramfs en grub-install draaien.
In deze post kun je wat aanwijzingen vinden: http://ubuntuforums.org/showthread.php?t=224351

[johnkeates]

Je initramfs heeft niet de juiste drivers. Verder heb je waarschijnlijk GRUB niet goed geconfigureerd en/of geeft GRUB niet de juiste parameters door aan de kernel.

/ op een SATA schijf en /boot op een USB Mass Storage apparaat is vrij eenvoudig. Als je het jezelf makkelijk wil maken installeer je gewoon Debian op de 1TB disk, en laat je de installer z'n gang gaan. Daarna kan je niet booten om dat je BIOS (want je hebt blijkbaar geen EFI) de controller niet kan initialiseren en/of de controller alleen met een addon ROM werkt om te booten. Om daar overheen te komen kan je dan het beste de SuperGRUB Boot CD gebruiken om toch te booten. Daarna, in Debian formatteer je de USB Mass Storage met ext2, kopieer je /boot naar je USB apparaat, en daarna rename je /boot naar /boot-old. Dan maak je een nieuwe map /boot, en remount je je USB Mass Storage op /boot. Daarna laat je grub even updaten, en dan werkt het. (Misschien nog even grub-install op je mass storage doen)

Als dat te moeilijk is, kan je ook gewoon houden wat je hebt, en naar UUID-based root device naming gaan. Dan kan je initramfs je schijf aan het FS UUID herkennen en mounten. Nu staat er waarschijnlijk iets van root=/dev/sdX terwijl je beter iets als root=UUID=fbb68e7a-947a-4dd9-a4e4-bb1c2202ee6b kan gebruiken. Daarvoor wel eerst je UUID vinden.

Squeeze heeft UUID naming standaard al, als je nu Lenny gebruikt, probeer Squeeze dan eens. Sid heeft het nieuwste, maar is ook een stuk minder stabiel.

Verder kan je ook eerst onderzoeken waarom je niet kan booten. Ik geef nu random informatie over wat het kan zijn en wat je dan zou kunnen doen, maar zonder eerst het echte probleem geidentificeerd te hebben is het lastig om te kijken wat er nu gedaan moet worden.

[deadinspace]

Voor de duidelijkheid, je hebt het nu dus over:

• /boot op een USB stick
• / op een 1.5TB disk aan je losse sata controller
• storage op 8x 2TB in RAID aan je onboard controller

?

Bij mij komt dan de vraag op: waarom je root filesystem ook niet op de RAID? In de huidige situatie heb je irritatie als je root disk eruit knalt, als die ook op RAID staat heb je dat probleem niet.

Alternatief: waarom /boot niet op de RAID disks (dus aan je onboard controller)? Dan heb je geen USB stick nodig.

Nog een alternatief: waarom je root disk niet aan de onboard controller hangen? Ok, daar heb je zelf al een opmerking over:

DJ-NaRRa schreef op dinsdag 23 november 2010 @ 22:41:
De reden dat ik niet gewoon de OS disk aansluit op een van de SATA poorten op mijn mobo is dat de controller sata-150 is terwijl de poorten op mijn mobo sata-300-/600 zijn. Dan zou ik dus 7 disks aan moeten sluiten op mijn mobo en 1 disk op de controller waardoor de hele raid op sata=150 draait

Ik denk niet dat je daar ook maar iets van gaat merken, want je schijven halen toch niet meer dan 150 MB/sec (ja, misschien vanuit de cache, maar die is verwaarloosbaar klein). Zou wel grappig zijn om te benchmarken though

Nu stuit ik op het volgende probleem. mijn bios herkent uiteraard niet de pci-sata controller bij het opstarten en het ding heeft ook geen eigen bios.

Heeft dat ding echt geen eigen BIOS? Da's volgensmij toch wel gebruikelijk. Kijk nog eens goed in je BIOS, vaak moet je iets als "boot other device" aanzetten oid, BIOSsen zijn nogal archaisch

Zodra initramfs zijn ding doet tijdens het booten krijgt GRUB mijn / niet gevonden en dan hangt het bootproces en soms krijg ik een kernel panic.

Volgensmij haal je hier wat dingen door elkaar, want het initramfs komt na GRUB
Kun je misschien wat preciezer omschrijven waar het misgaat in het bootproces?

Aangezien je het hebt over soms een kernel panic krijgen zou het kunnen dat de volgorde waarin je storage devices gevonden worden niet betrouwbaar is, waardoor hij telkens een ander device probeert te mounten als root filesystem.

Als dat het geval is, dan kan UUID-based mounting (waar johnkeates het ook al over heeft) uitkomst bieden.

(UUID-based mounting is sowieso beter vind ik, jammer dat dat pas default wordt in Squeeze)

Ik vermoed dat ik aparte drivers zal moeten compilen in de kernel en daar vanaf booten. Ik heb al wel docs gevonden hoe ik een kernel compile maar ik weet zo niet welke driver ik zou moeten compilen.

Zelf kernels compilen is iets van vroeger

Tegenwoordig worden alle drivers als module gecompiled, en de benodigde drivers worden in een initramfs gestopt dat tegelijk met de kernel geladen wordt. GRUB laadt dus zowel de kernel als een mini root filesystem van een paar MB in het geheugen, en de kernel boot van dit initramfs. Het initramfs bevat dan alle drivers (als modules) en tools om je daadwerkelijke root filesystem te vinden en te mounten.

Als tijdens het booten dus een driver ontbreekt, dan moet die toegevoegd worden aan het initramfs. Maar ik vermoed dat dat niet het probleem is, de enige drivers die nodig zijn zijn volgensmij die van je filesystem(s) en je SATA controllers (zowel onboard als los), en die zitten er waarschijnlijk wel in.

[DJ-NaRRa]

Even wat antwoorden

@deadinspace:

Ja ik maak gebruik van de setup die je noemt in je lijstje, met het verschil dat ik een 1TB disk voor / gebruik. Maar dat is een klein detail. Nee de controller heeft zelf echt geen bios. het is een simpel kaartje van een euro of 15 in de BIOS van mijn mobo zit wel een optie bootable add-in cards maar die is leeg

Waarom ik de root niet op de raid zet? je bedoelt dan echt fysiek op de raid zelf of dat ik van alle disks een gigje of 10 afsnoep om op de eerste disk uit de array mijn / te zetten. Dat laatste kan in principe nog wel denk ik. de hele root op de raid array zetten ben ik niet zo'n voorstander van. Mocht er iets corrupt raken in de array door welke reden dan ook heb ik ook meteen geen OS meer om de boel eventueel te kunnen repareren.

Benchmarken doe ik wel als ik wat meer ervaring heb met linux maar is zeker wel een optie. Over de terminologie. idd ik vergis me in wat termen. GRUB doet het prima en toont netjes het menu. Na het aanpassen van de verwijzing op een andere hdd (de hd0,0 ipv 2,0) gaat de kernel gewoon laden. Waar het misgaat is het punt waar de root wordt gemount. het bootproces herkent alle schijven (incl. array) en dan nog één of twee losse schijven (ik denk dus de twee USB disk of een van de disks die aan de controller hangt, maar dit kan ik niet bewijzen). Ik krijg dan een "could not mount root filesystem" of een kernel panic. Soms hangt hij hierna gewoon waarna ik alleen nog naar de commandline kan gaan.

Het vermoeden wat je hebt over dat de disks in een andere volgorde gevonden worden als tijdens de installer is ook mijn vermoeden. Ik zie andere verwijzingen naar mijn raid devices (hda / hdb + sd[b-g]) terwijl de installer ze anders markeerde. Ik zou inderdaad UUID verwijzingen kunnen gebruiken maar ik ben er niet zo happig op om een niet stable release toe te vertrouwen aan mijn data.

@johnkeates:

Dat was eerst mijn insteek. echter SGD / SGD2 konden geen van beide de 1TB vinden die aan de controller hangt....Ik wil graag lenny gebruiken vanwege wat ik ook al reageer naar Deadinspace dat ik er niet happig op ben om een unstable kernel te gaan gebruiken op een bak die mijn data moet huisvesten.

@Capslock2000:

Ok dat vermoeden heb ik ook wel ergens. Mijn GRUB file nu:

code:

title        Debian GNU/Linux, kernel 2.6.26-2-686
root        (hd2,0)
kernel        /vmlinuz-2.6.26-2-686 root=/dev/sdg1 ro 
initrd        /initrd.img-2.6.26-2-686

title        Debian GNU/Linux, kernel 2.6.26-2-686 (single-user mode)
root        (hd2,0)
kernel        /vmlinuz-2.6.26-2-686 root=/dev/sdg1 ro single
initrd        /initrd.img-2.6.26-2-686

Ik denk dat ik eens ga testen met SDH1 / SDI1 om te zien of dat iets oplevert. Ik vermoed dat mijn raid array nu wordt gemount op hda / hdb en sd[b-g]. Maar de tekst gaat te snel voorbij om dit goed te kunnen zien en scrollen zit er niet in

Mocht dat niet werken ga ik even kijken of ik nog bepaalde drivers moet enablen in de initramfs.

@iedereen alvast bedankt voor de pointers. Ik laat weten of het is gelukt (als ik er vanavond nog aan toe kom).

[Kees]

DJ-NaRRa schreef op woensdag 24 november 2010 @ 11:03:

code:

title        Debian GNU/Linux, kernel 2.6.26-2-686
root        (hd2,0)
kernel        /vmlinuz-2.6.26-2-686 root=/dev/sdg1 ro 
initrd        /initrd.img-2.6.26-2-686

title        Debian GNU/Linux, kernel 2.6.26-2-686 (single-user mode)
root        (hd2,0)
kernel        /vmlinuz-2.6.26-2-686 root=/dev/sdg1 ro single
initrd        /initrd.img-2.6.26-2-686

Tijdens het booten komen je disks voorbij, ziet hij uberhaubt wel die rootdisk dan? If so, aangezien je het over 8 disks hebt, is het waarschijnlijk dat je:
usb: sda,
andere disks: sdb,c,d,e,f,g,h,i
root disk: sdj > vervang root=/dev/sdg1 door /dev/sdj1, en al dat ook niet werkt, /dev/sdb1, en ga naar UUID zo snel als je kan

[DJ-NaRRa]

Kees schreef op woensdag 24 november 2010 @ 11:53:
[...]

Tijdens het booten komen je disks voorbij, ziet hij uberhaubt wel die rootdisk dan? If so, aangezien je het over 8 disks hebt, is het waarschijnlijk dat je:
usb: sda,
andere disks: sdb,c,d,e,f,g,h,i
root disk: sdj > vervang root=/dev/sdg1 door /dev/sdj1, en al dat ook niet werkt, /dev/sdb1, en ga naar UUID zo snel als je kan

Dat is dus het vreemde. Hij ziet een van mijn onboard Sata controllers als hda/hdb (in de installer was het hde / hdf). ik heb geen pata devices meer uiteraard. ik moet nog even kijken welke kabels dit precies zijn zodat ik ze kan labelen

In de installer zag hij de devices als volgt:
HDE-F 2tb disk van raid
SDA USB met debian ellny netinst
SDB USB waarop ik de boot wilde uitvoeren
SDC-F 2tb disk van raid
SDG 1TB aan controller
SDH-I 2tb disk van raid

Ik vermoed (maar kan dit niet bevestigen omdat de tekst vrij rap voorbij komt tijdens het booten) dat de volgorde als volgt is:

HDA-B disk van raid
SDA /boot
SDB-G disk van raid
SDH of USB of 1TB disk
SDI of USB of 1TB disk

Is het zo dat Lenny compleet geen UUID support of is er een manier om dit te enablen? en hoe "stable" is de squeeze kernel. Is het volgens jullie verantwoord om toch deze kernel te draaien op een NAS? Overigens staat er niet echt heel belangrijke data op en de belangrijke data staat komt straks op de OS disk te staan en in een RAID1 / online (en op de bronnen waar de data vandaan komt) dus ik kan naar hartelust wat aanklooien.

[CAPSLOCK2000]

DJ-NaRRa schreef op woensdag 24 november 2010 @ 12:28:
Dat is dus het vreemde. Hij ziet een van mijn onboard Sata controllers als hda/hdb (in de installer was het hde / hdf). ik heb geen pata devices meer uiteraard. ik moet nog even kijken welke kabels dit precies zijn zodat ik ze kan labelen

Niet te veel waarde hechten aan die namen. hda vs sda zegt eigenlijk niks meer tegenwoordig.

<knip>

Is het zo dat Lenny compleet geen UUID support of is er een manier om dit te enablen? en hoe "stable" is de squeeze kernel. Is het volgens jullie verantwoord om toch deze kernel te draaien op een NAS? Overigens staat er niet echt heel belangrijke data op en de belangrijke data staat komt straks op de OS disk te staan en in een RAID1 / online (en op de bronnen waar de data vandaan komt) dus ik kan naar hartelust wat aanklooien.

Lenny zou met UUIDs moeten kunnen werken. Geef eens het commando 'blkid' . Dat laat de ID's zien van alles wat in je systeem hangt. Die info kun je vervolgens aan grub / fstab voeren.

De kernel van Squeeze is hardstikke stabiel, ik denk zelfs stabieler dan die van Lenny.

(Een aantal Linux-leveranciers hebben besloten om samen 1 kernel te pakken en daar dan al hun energie op te richten. Squeeze gebruikt die versie (2.6.32)). Prive draai ik al mijn systemen op Squeeze of nieuwer. Squeeze gaat binnenkort uitkomen en ik denk dat je er veilig voor kan kiezen. Er is weer een hoop aan de installer verbeterd (oa UUIDS als default) dus misschien werkt het wel out-of-the-box.

[DJ-NaRRa]

Hij bleek dus sde1 te vinden als die 1tb aan de controller en de sdh1 als de usbstick. (lekker logisch....) uiteraard veel fails en warnings tijdens het booten maar nadat ik fstab een schop onder zijn hol had gegeven zag het er al beter uit.

Ik ga toch nog even Squeeze proberen. niet omdat het out-of-the box zou werken, maar omdat ik toch eerst wat wil experimenteren met de raid array voordat ik er sowieso live data op ga zetten.

Bedankt voor de tips iedereen!

Deze mag wat mij betreft dicht!

[deadinspace]

DJ-NaRRa schreef op woensdag 24 november 2010 @ 11:03:
Ja ik maak gebruik van de setup die je noemt in je lijstje, met het verschil dat ik een 1TB disk voor / gebruik. Maar dat is een klein detail. Nee de controller heeft zelf echt geen bios. het is een simpel kaartje van een euro of 15 in de BIOS van mijn mobo zit wel een optie bootable add-in cards maar die is leeg

Owja, 1TB. En elke uitbreidingskaart heeft een BIOS nodig om van te booten, dus die "bootable add-in cards" optie zal waarschijnlijk alleen wat doen als je kaarten met een BIOS hebt.

Waarom ik de root niet op de raid zet? je bedoelt dan echt fysiek op de raid zelf of dat ik van alle disks een gigje of 10 afsnoep om op de eerste disk uit de array mijn / te zetten. Dat laatste kan in principe nog wel denk ik. de hele root op de raid array zetten ben ik niet zo'n voorstander van. Mocht er iets corrupt raken in de array door welke reden dan ook heb ik ook meteen geen OS meer om de boel eventueel te kunnen repareren.

Beiden zijn een optie, afhankelijk van je eigen wensen.

Wat je bijvoorbeeld zou kunnen doen: een RAID-1 van de eerste 10GB (ofzo) van elke schijf, plus een RAID-5 van de rest van elke schijf. Dat kost je 70G van je RAID-5 array, maar op die manier heb je wel je OS op _elke_ disk staan, dus is elke individuele disk genoeg om te booten. Je hebt dan ook geen aparte /boot nodig, want GRUB kan rechstreeks van RAID-1 booten.

Ik zou inderdaad UUID verwijzingen kunnen gebruiken maar ik ben er niet zo happig op om een niet stable release toe te vertrouwen aan mijn data.

Ik ben er vrij zeker van dat Lenny gewoon UUID-based mounting kan gebruiken hoor. Het is alleen niet default in Lenny, maar wel in Squeeze

Voor wat betreft het toevertrouwen van je data aan een niet-stable release: Het is wel zo dat Squeeze nu frozen is, en daarmee dus richting release gaat. Maar ik kan me goed voorstellen dat je liever de kat uit de boom kijkt

[DJ-NaRRa]

deadinspace schreef op woensdag 24 november 2010 @ 23:06:

Beiden zijn een optie, afhankelijk van je eigen wensen.

Wat je bijvoorbeeld zou kunnen doen: een RAID-1 van de eerste 10GB (ofzo) van elke schijf, plus een RAID-5 van de rest van elke schijf. Dat kost je 70G van je RAID-5 array, maar op die manier heb je wel je OS op _elke_ disk staan, dus is elke individuele disk genoeg om te booten. Je hebt dan ook geen aparte /boot nodig, want GRUB kan rechstreeks van RAID-1 booten.

Dat zou ik in principe nog wel eens kunnen proberen en benchmarken. Ik denk dat het wel ten koste gaat van de performance als het OS leest en schrijft naar dezelfde disks als de raid6 die er dan op draait. Maar leuk om eens uit te proberen.

[deadinspace]

DJ-NaRRa schreef op donderdag 25 november 2010 @ 10:16:
Dat zou ik in principe nog wel eens kunnen proberen en benchmarken. Ik denk dat het wel ten koste gaat van de performance als het OS leest en schrijft naar dezelfde disks als de raid6 die er dan op draait. Maar leuk om eens uit te proberen.

Hangt er van af wat je met je root-disk wil doen. Als je die ook als scratch-space gebruikt wel; dat wil zeggen, als je bijvoorbeeld iets downloadt en unrart op je root disk, en de files daarna verplaatst naar je RAID-6, dan ga je dat wel merken qua performance, omdat dan van dezelfde disks veel gelezen en geschreven moet worden.

Als je op die RAID-1 echt alleen het OS zet, dan zal het wel meevallen over het algemeen; zo gek veel wordt er niet gelezen/geschreven van/naar je root disk normaalgesproken.