I am currently working on a Linux distribution created with buildroot for an ARM device. The file system is JFFS2. I am booting with Das U-Boot.

I am able to successfully boot exactly once. My initial boot is successful and I am able to login to Linux and do things one would expect via command line. The second boot produces a kernel panic.

I have compared the Kernel memory before and after initial boot and it is exactly identical.

My conclusion is that something in the file system changes upon initial boot that causes a kernel panic.

Here is the relevant excerpt from my boot (I pasted extra to provide context of where the boot fails, but only the last six lines are likely important):

cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver usbserial
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial support registered for generic
usbcore: registered new interface driver ftdi_sio
usbserial: USB Serial support registered for FTDI USB Serial Device
usbcore: registered new interface driver pl2303
usbserial: USB Serial support registered for pl2303
mousedev: PS/2 mouse device common for all mice
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
atmel_nand 40000000.nand: PMECC: Too many errors
VFS: Cannot open root device "mtdblock1" or unknown-block(31,1): error -5
Please append a correct "root=" boot option; here are the available partitions:
1f00            8192 mtdblock0  (driver?)
1f01          253952 mtdblock1  (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1)

Uboot config My U-Boot printenv looks like this:

bootargs=mem=128M console=ttyS0,115200 mtdparts=atmel_nand:8M(bootstrap/uboot/kernel)ro,-(rootfs) root=/dev/mtdblock1 rw rootfstype=jffs2
bootcmd=nand read 0x22000000 0x200000 0x300000; bootm 0x22000000

So my question would be if someone could help me understand what would cause a second boot to fail where the first boot succeeds. Has anybody seen this? Maybe someone has experience with a similar situation that could at least point out what might be happening here.

P.S. I can provide additional information if needed. I am trying to abstract the details that are not important, but am more than willing to add more if it helps.

  • Have you specified the right root device? Isn't mtdblock0 for uboot, mtdblock1 ubootenv, mtdblock2 for the kernel and then the rootfs on another?
    – ott--
    Commented Mar 24, 2015 at 22:10
  • Thank you for your inquiry, @ott. I updated the post with my U-Boot printenv. To answer your question, in this case mtdblock1 is the right mount point. This is why the first boot is successful. This printenv is actually a copy of Atmel's original bootargs, except I use jffs2 instead of ubi.
    – Terry
    Commented Mar 25, 2015 at 17:09

1 Answer 1


You can try put bootargs in read only:

bootargs=mem=128M console=ttyS0,115200 mtdparts=atmel_nand:8M(bootstrap/uboot/kernel)ro,-(rootfs) root=/dev/mtdblock1 ro rootfstype=jffs2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .