spod NAND nie chce montować >sda5

[Gość s6s]

takie podstawowe pytanie: Graterlia nie chce montować partycji /dev/sda6 (sda5 to maksimum) kiedy znajduje się na NAND

podczas gdy chce to robić kiedy znajduje się na USB lub partycji hdd.

 

Jak sprawić żeby montowała /dev/sda6 spod NAND?

 

 

[tux]

Technicznie - jak wszystko jest OK - musi działać! Podaj szczegóły dlaczego coś u Ciebie nie działa.

[Gość s6s]

słuchaj, pewnie nie chcesz rozmowy na tym forum znowu o jfs, ale ja z tego korzystam na partycji "records" i mam totalnie jak najlepszą do tej pory przyjemność korzystania z tego fs. Po prostu ewentualne naprawy trwają chwilkę, dosłownie parę sekund, a partycja ma pół GB i prawie cała zapełniona.

 

Otóż stosuję ten skompilowany przez Ciebie kernel "monolityczny" kernel-jfs.tar.gz

http://forum.xunil.pl/index.php?topic=504.msg6200#msg6200

i on montuje partycję /dev/sda6 tylko kiedy Graterlię się uruchomi z USB, a jak z NAND to nie chce.

 

Inaczej mają się sprawy dla Twojej wersji kernela "modułowej"  kernel-jfs-mod_xfs-mod_reiserfs-mod.tar.gz

ona montuje jfs także i z NANDa.

 

Tak więc ten pierwszy post trzeba zmodyfikować, teraz widzę że to problem NIE w numerze partycji ale w JFS w połączeniu z  NAND.

 

Prosiłbym o pomoc, ponieważ ten modułowy Twój kernel ma wiele innych niepotrzebnych fs (xfs i reiserfs) co niepotrzebnie konsumuje cenne miejsce na NAND, poza tym nie wiem jak ładować moduł jfs na samym starcie systemu.

 

Prawdopodobnie Ty nie chcesz tu dyskusji jakkolwiek dotyczącej JFS to jak chcesz to  skasuj ten wątek, rozumiem że nie chcesz początkującym użytkownikom mieszać w głowach - albo przenieś go do jakiegoś działu "dla zaawansowanych i eksperymentujących" (jak nie ma tu takiego to przydałoby się go stworzyć, nieprawdaż?

 

Tym niemniej proszę o pomoc aby kernel monolityczny mógł montować jfs także i spod NAND (a nie tylko spod USB).

 

PS. Tamte próby ze znikaniem obrazu i skanowaniem robię z oryginalnym kernelem i partycją records na ext2 (mam obie właśnie dla prób)

 

[tux]

Jedno pytanie → do NAND to wgrał kernel? czy tylko /boot/ w NAND?

[Gość s6s]

całe drzewo z paczki

poleceniem tar -xvzf  paczka.tar.gz  -C /mnt/NAND

 

o to pytasz prawda? i pytasz o to czy nie brakuje tam modułów z /lib/modules/*.ko

tak?

 

zresztą powtarzam, ten kernel "modułowy" działa spod NAND,

oczywiście muszę z telnetu zrobić polecenie:

 

insmod  /lib/modules/jfs.ko

 

i jakoś nie bardzo wiem gdzie to umieścić ładnie aby się ładowało jeszcze przed sysfscheck.sh

 

 

[tux]

Nie. Pytam się czy wgrałeś kernel.img tam gdzie trzeba a nie do /boot na partycji z NAND.

[Gość s6s]

trochę nie kapuję o co pytasz...

 

jaki kernel.img?  to tylko w paczce oryginalnej przenaczonej na NAND i umieszczam to wraz z rootfs.img na penie (fat32) żeby z uboota wgrać do NAND

 

ale te paczki z jfs co zamieściłeś w http://forum.xunil.pl/index.php?topic=504.msg6200#msg6200

to nie zawierają żadnego pliku z rozszerzeniem .img

lecz zwykłe drzewo katalogu w tar.gz

 

 

czyli  uImage wędruje do /mnt/NAND/boot

a pliki *.ko do /mnt/NAND/lib/modules

 

oczywiście po wcześniejszym podmontowaniu:  mount -t jffs2 /dev/mtdblock0 /mnt/NAND

[tux]

Rusz głową trochę. z USB ładujesz plik kernel.img z /boot.

W NAND z /dev/mtdblock0 - chyba dla nBoxa się nie walnąłem. Sprawdź. rootfs jest chyba na /dev/mtdblock1

Jak jest to /dev/mtdblock0 to wydaj polecenie w konsoli:

dd if=kernel.img of=/dev/mtdblock0

 

[Gość s6s]

ale skąd Ci się wziął kernel.img?

 

[tux]

To jest to samo co uImage

[Gość s6s]

to ja uImage kopiuję z paczki zmodyfikowanego kernela po zamontowaniu

  mount -t jffs2 /dev/mtdblock0 /mnt/NAND

do /mnt/NAND/boot

 

trzeba jeszcze niezależnie gdzieś w drugie miejsce?

 

owszem nie bardzo rozumiem różnicę w podziale pamięci NAND pomiędzy Freeboxem a HYPERIONem tym z PTK...

 

[tux]

Ja nie mam teraz nBoxa pod łapą to nie napiszę dokładnie.

jest mtdblock0 i mtdblock1. Jedno urządzenie zamontujesz - drugie nie. To którego nie zamontujesz masz potraktować:

dd if=uImage of=/dev/....

 

Na więcej tłumaczenia póki co nie mam sił. To są podstawy i bez opanowania tego trudno komuś jest coś wyjaśnić. Póki co nie ma nikogo kto chciałby pociągnąć żłobek dla linuxa.

 

[Gość s6s]

tak ale to co piszesz to nie probelm z wiedzą linuksową ale z nBoksową,

ponieważ widać że trzeba wgrać uImage w dwa niezależne miejsca, tak?

 

w nBoksie montować do mtdblock0 da się,

czyli rozumiem że trzeba jeszcze SWOJĄ DROGĄ: dd if=uImage of=/dev/mtdblock1

 

tak?

 

To chociaż pokrótce wyjaśnij co siedzi w mtdblock0 a co w mtdblock1,

bo to trochę niezwykłe...

 

[tux]

u-boot się kłania. Przeanalizuj plik env. OK? Jak się uda to wszystko się wyjaśni i zaświta co trzeba.

[Gość s6s]

to czy też nie możnaby wykasować drugą cześć zawartości pliku "update" (tylko zatrzymać tę częśc która dotyczy kernel.img), a następnie wzrzucić na pena taki właśnie update oraz to zmodyfikowane uImage zmieniając nazwę na kernel.img (i tylko te pliki, bez rootfs.img)?

 

OK, to tylko takie "akademickie" pytanie ;)

ten plik update wydaje się tekstowy, ale tylko na pierwszy rzut oka bo rozpoczyna się od jakichś binarnych bajtów, poza tym po co aż tak kombinować - skopiowanie poleceniem dd wydaje się prostsze,

 

to więc jak rozumiem, jeżeli podmontowuje się do /dev/mtdblock0 a do mtdblock1 nie chce (jakiś "input/output error")

to znaczy uImage trzeba przesłać poleceniem dd do tego mtdblock1

czy zgadza się??

 

 

------------------

PS. rzeczywiście potrzeba by modyfikować plik update? Jak się wrzuci na pena tylko oryginalny update oraz plik kernel.img (bez rootfs.img) to nie wgra kernela? Rozumiem że pokaże błąd ale i tak wcześniej wgra kernel.img, prawda?

 

------------------

Tak, przed chwilą sprawdzone: działa!