系統啟動掛載根檔案系統時kernel panic
製作根檔案系統 kernel arm
2009-05-21 21:17
字型大小:
大大中中
小小這類問題很常見,先總體介紹一下解決思路。
能出現讓人激動的的控制台,那麼系統移植已經接近完成;但是不少人在最後一步出現問題。
要點如下:
1. 在正確的位置燒寫正確格式的檔案系統映象:
2. 核心支援這種檔案系統格式
3. 檔案系統的內容要完備
上面說得簡單,乙個個介紹。
1. 在正確的位置燒寫正確的檔案系統映象:
(a). 正確的位置
嵌入式開發中,常通過bootloader燒寫檔案系統映象,假設寫在flash的位址a處。
核心啟動時,顯然要從位址a處讀取檔案系統,核心是怎麼知道的呢?通過命令列引數,比如「root=/dev/mtdblock2 」。/dev/mtdblock2 又是怎麼和位址a對應上的呢?核心將flash劃分為
幾個分割槽,這是在**中固定的。/dev/mtdblock2是第3個分割槽,它的開始位址必須是a。
creating 3 mtd partitions on "nand 64mib 3,3v 8-bit":
0x00000000-0x00030000 : "bootloader"
0x00050000-0x00250000 : "kernel"
0x00250000-0x03ffc000 : "root"
對於上面的核心資訊,/dev/mtdblock2對應root分割槽,開始位址為0x00250000,使用bootloader寫檔案系統映象時,燒寫的位址必須是0x00250000
所以,要保證3點:① bootloader燒到位址a,② 位址a是核心某個分割槽的開始位址,③ 命令列引數「root=/dev/mtdblock*** 」是這個分割槽
(b). 正確格式的檔案系統映象
不同的bootloader支援的燒寫的檔案系統映象格式不同、使用的燒寫命令也可能不同,請注意這點。
另外,馬大哈們製作檔案系統映象時,使用的工具也不要弄錯了。
最後,請保證這個檔案系統映象是「真的燒寫了」,因為如果flash只是擦除而沒有燒寫,它也是「正確的、可以掛接的檔案系統」──有人碰到這個問題,我和他答非所問地折騰了很久。
2. 核心支援這種檔案系統格式
配置核心時選上要支援的檔案系統格式
1、2這兩個問題如果不能保證,核心啟動時會出現類似如下錯誤:
vfs: cannot open root device "mtdblock2" or unknown-block(2,0)
如果1、2能保證,就可以掛接上檔案系統,出現類似下面的字樣時,革命已經成功了80%:
vfs: mounted root (cramfs filesystem) readonly.
freeing init memory: 116k
3. 檔案系統的內容要完備
掛接檔案系統後,核心就會讀取、執行檔案系統中的某個檔案,通過它來啟動應用程式。這個檔案要麼通過命令列引數「init=***x」來指定,要麼取預設的檔案(下面說明)。
一般製作檔案系統映象時,都是在乙個目錄(假設目錄名為rootfs)下放好各種東西:bin/,sbin/,lib/等目錄,etc/fstab等檔案,然後將這個目錄製作為檔案系統映象。
可以想象,如果這個目錄中的東西不對、不全,即使製作出了檔案系統映象,也只是能識別出來,掛接上去;但是啟動不了──所謂啟動,不就是執行檔案系統中的程式嘛?
這時會有類似以下的錯誤:
failed to execute /linuxrc. attempting defaults...
kernel panic - not syncing: no init found. try passing init= option to kernel.
它說得很明顯,"failed to execute /linuxrc"──執行/linuxrc失敗:
它為什麼要執行/linuxrc,還不是因為你在命令列中加入了「init=/linuxrc」這個引數。
它為什麼會失敗?原因有二:
一、你製作檔案系統映象時,rootfs目錄下有linuxrc這個檔案嗎?
二、rootfs目錄的linuxrc檔案是正確的嗎?
請好好確定這兩點,大多數是沒有linuxrc檔案──linuxrc是busybox自動生成的,只要配置好就可以。
如果有linuxrc,那麼就是它無法執行了(解決方法在下面)。
不用linuxrc行不行?當然行!看看核心檔案init/main.c,有如下字樣:
run_init_process("/sbin/init");
run_init_process("/etc/init");
run_init_process("/bin/init");
run_init_process("/bin/sh");
panic("no init found. try passing init= option to kernel.");
就是說,它會依次嘗試執行/sbin/init、/etc/init、/bin/init、/bin/sh這些檔案,都失敗後才列印出錯資訊"no init found. try passing init= option to kernel."。
所以,出現這個出錯資訊時,就表明了沒有或是無法執行這些檔案:命令列引數「init=***x」來指定的***檔案、/sbin/init、/etc/init、/bin/init、/bin/sh。
一、請檢查你的rootfs目錄,看看這點些檔案是否存在
二、使用file命令看看它們是什麼檔案型別,是否可執行。
$ file linuxrc
linuxrc: symbolic link to `bin/busybox'
$ file bin/busybox
bin/busybox: elf 32-bit lsb executable, arm, version 1, for gnu/linux 2.4.3, dynamically linked (uses shared libs), stripped
注意了:如果bin/busybox 是乙個動態鏈結的檔案,還要把它用到的庫複製到rootfs中。唉,越說越複雜了。這些庫在交叉編譯工具的相應目錄下,如果不知道,查google,否則再發帖。
最後一點,檔案系統中各種配置檔案、dev目錄也要正確。出現問題時再在這個帖子中說吧。這樣寫下去真是沒完沒了。
回到這個帖子,它的核心列印資訊為:
vfs: mounted root (cramfs filesystem) readonly.
freeing init memory: 116k
failed to execute /linuxrc. attempting defaults...
kernel panic - not syncing: no init found. try passing init= option to kernel.
說明檔案系統掛接成功(vfs: mounted root (cramfs filesystem) readonly.);
還說明/linuxrc不存在或者不可執行(failed to execute /linuxrc. attempting defaults...);
但是樓主的意思是linuxrc已經有了,內容為:
#!/bin/sh
echo "mount /etc as ramfs"
/bin/mount -n -t ramfs ramfs /etc
/bin/cp -a /mnt/etc/* /etc
echo "re-create the /etc/mtab entries"
# re-create the /etc/mtab entries
/bin/mount -f -t cramfs -o remount,ro /dev/mtdblock/3 /
/bin/mount -f -t ramfs ramfs /etc
exec /sbin/init
它是乙個指令碼,它的執行依賴於/bin/sh,問題轉為:/bin/sh是否存在?是否可以執行?
用file命令看看它的型別、是否需要動態庫。
系統啟動掛載根檔案系統時Kernel panic
製作了根檔案系統,在啟動之後停在這裡了 net registered protocol family 1 net registered protocol family 17 vfs mounted root cramfs filesystem readonly.freeing init memory...
掛載NFS檔案系統啟動
1.在伺服器上啟動nfs服務 2.修改uboot啟動引數bootargs openjtag print bootcmd nand read.jffs2 0x30007fc0 kernel bootm 0x30007fc0 bootdelay 2 ethaddr 08 00 3e 26 0a 5b n...
分析Android 根檔案系統啟動
在android系統啟動時,核心引導引數上一般都會設定 init init 這樣的話,如果核心成功掛載了這個檔案系統之後,首先執行的就是這個根目錄下的init程式。這個程式所了什麼呢?我們只有rfsc read the ing source code init程式原始碼在android官方原始碼的s...