Minęło trochę czasu, od kiedy pierwszy raz siadłem nad Anacondą. Przedstawiam zatem postęp w pracach - wiele się nie zmieniło, ale parę rzeczy pozmieniałem.
Wstępne uwagi - Anaconda do zbudowania wymaga kilkunastu przeniesionych z RedHata lub podbitych przeze mnie pakietów. W tym kudzu, które kategorycznie odmawia zbudowania się za pomocą gcc4. Póki co, pozostaje praca na gcc w wersji 3.x.
Największym bólem jest konieczność każdorazowego przebudowania pakietów Anacondy, przy choćby najdrobniejszej modyfikacji skryptów basha czy Perla wchodzących w jej skład. Z drugiej strony jest to jedną z większych zalet Anacondy na tle innych instalatorów - do zbudowania instalatora używa pakietów RPM, a nie bieżącej zawartości systemu. Między innymi używa własnych pakietów RPM, więc te przebudowuję średnio kilkanaście razy na godzinę - na szczęście prace idą do przodu.
Dużo problemów przysparza mi obecnie kernel. Poprawiłem Anacondę, żeby wypakowywała dodatkowe paczki (pcmcia), bo użycie kernel24-BOOT w grę nie wchodzi - choćby podsystemy SerialATA zmieniły zasadniczo swoje działanie od czasów 2.4 i instalacja ze starego jądra spowoduje zgon systemu przy bootowaniu nowego (to co kiedyś było /dev/hdX, teraz nazywa się /dev/sdX). Martwi mnie spory rozmiar initrd budowanego przez Anacondę z naszego 2.6.11 - ma około 8 MB, czyli sporo więcej niż pozwala bez problemu załadować kernel.
Anaconda radzi sobie z wygenerowaniem obrazu isolinuksa
Po zbootowaniu obrazu wygenerowanego przez Anacondę, pojawia się bootsplash isolinuksa. Proszę o wybaczenie, ale nie miałem czasu malować logo PLD, więc jest taki - nazwijmy to - placeholder
.
Na tym etapie do zbootowania niezbędne jest dopisanie do kernela parametru ramdisk_size (ze względu na wspomniane kolosalne initrd):
boot: linux ramdisk_size=10000
Po tym zaczyna się zwykła procedure bootowania dystrybucyjnego jądra, umiera ona jednak przy próbie podmontowania roota:
Kernel panic przy próbie montowania roota
Niestety, nie mam czasu teraz debugować tego dalej. Do głowy przychodzą mi dwie opcje: albo nasz kernel nie ma wkompilowanej obsługi cramfs (a za ładowanie modułów odpowiedzialny jest initrd, co jest nieco kłopotliwe w sytuacji, gdy on sam spakowany jest cramfs) albo ja coś skopałem na etapie generowania vmlinuz/initrd.
Jeśli to możliwe, to prosiłbym o kontakt kogoś lepiej zaprzyjaźnionego z naszym jądrem, najlepiej kogoś, kto używał już dystrybucyjnych kerneli do generowania bootowalnych płyt. Wolałbym uniknąć sytuacji, kiedy do zbudowania instalatora PLD będzie potrzebne jądro Fedory, a na moim notebooku kompilacja kernela trwa około dwóch godzin, więc nie chcę robić tego na oślep.
Update: wrzuciłem aktualny screen, kernel wykłada się teraz na montowaniu roota.
krzymam kciuki :)
Informacyjnie tylko: nasz tekstowy instalator tez uzywa paczek RPM do zbudowania, a nie biezacego systemu :) RAM dysk 10000? W teorii powinno przy tej wielkosci starczyc 16 MB RAM. Ciekawe. Installer Fedory o ile mnie pamiec nie myli nie ruszy na mniej niz 32 a moze i 64 :)
16 raczej nie wystarczy - pierwszy ramdysk zjada samo initrd. Oprócz tego trzeba jeszcze załadować busyboksa, pythona i (później) rpm.
nawet tekstowa instalacja debiana wymaga >=32 M wiec co tu mowiec o fedorze ;)
Jak sobie przypomne, ze czulem sie winny tych wszystkich biednych userow ktorzy juz nie beda mogli z instalatora PLD skorzystac… :-) (bo zwiekszylem wymagania z 8 do 12 MB)
e nie przeadzajmy :) o wymaganiach instalatorwo pisalem jakis czas temu na liste :)
Wiem. Tez pisalem :)
wiem, tez czytalem :P ale tak btw to proponuje eot, bo sie robi zbyt oftopikowo i zasmiecamy tu patrysowi joga :)
Po tym zaczyna się zwykła procedure bootowania dystrybucyjnego jądra, umiera ona jednak przy próbie podmontowania roota:
[ciach]
Update: wrzuciłem aktualny screen, kernel wykłada się teraz na montowaniu roota.
Zadanie: znajdź zmianę wprowadzoną przez update :P
Wcześniej był screen wykładania się na montowaniu initrd.
anaconda wymaga do uruchomienia się w trybie tekstowym 64 MB RAMU-u :)
A czemu anakonda? może lepiej zająć się instalatorem mandagory? jest (podobno) w całości w perlu.
Jeszcze chyba YaST byłby dobrym wyjściem, tylko nie orientuje się w koncu czy go udostępnili na OpenSource czy, nie. Bo mieli.