[U-Boot] Kernel panic - not syncing: VFS: Unable to mount rootfs on unknown-block (1, 0)
Stefano Babic
sbabic at denx.de
Fri Mar 2 10:03:31 UTC 2018
Hi Zoran,
On 26/02/2018 11:57, Zoran S wrote:
> Hello Stefano,
>
>> If it canot be mounted, the cause is in the most of cases in a missing
>> configuration in kernel, like initrd not supported, missing compression
>> type, and so on.
>
> After some investigation, I found that you were correct, most likely.
> I did this investigation on two similar platforms, in two different
> environments (since one is corporate one, with some firewalls around,
> another is outside of the reach, simply it hangs on the open net, my
> private setup). Just to be sure that I excluded all the corporate
> security influences.
>
> I used the off shelf kernel for BBB (BeagleBone Black), using YOCTO
> Project (Rocko release) to compile form the scratch, with assurance
> that this kernel is set correctly (configuration wise).
>
> After several days of testing (since my U-Boot skills are a bit rusty,
> so I assumed I am scripting wrong), I have concluded that I have a
> correct U-Boot setup, but that the kernel image is not set correctly
> (as you suggested), since I tested it with at least 5 differently
> compiled ramdisks.
>
> I found one BBB kernel on Linaro site (this one is Debian one, Linux
> beaglebone 4.9.0-4-armmp #1 SMP Debian 4.9.65-3 (2017-12-03) armv7l
> GNU/Linux), and tried it with minimal setup (have no idea what/how
> .config looks like), including ramdiskfs-es (I tested it with several
> ones, all compiled in the same YOCTO Rocko package) and DTB from the
> same.
>
> It worked for me from the very first time (on both setups).
>
ok - this confirms that the defconfig for kernel in Yocto build does not
contain enough to start from ramdisk.
> Conclusion is: Something in .config is wrong. What? This needs some
> serious investigation, since I think the failed one is also set to use
> ramdisk.
Usually, some of these are missing:
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
Of course, not all of them can be necessary, I am just speculating.
I would also check (but they should be on) the CONFIG_DECOMPRESS_*
options and if not, you could turn them on.
>
> I would like to thank you for the hint.
You're welcoime,
Best regards,
Stefano
>
> Best Regards,
> Zoran Stojsavljevic
> _______
>
> On Wed, Feb 21, 2018 at 5:31 PM, Stefano Babic <sbabic at denx.de> wrote:
>> Hi Zoran,
>>
>> On 21/02/2018 11:45, Zoran S wrote:
>>> Hello to U-Boot list,
>>>
>>> I have encountered an interesting problem which I do not entirely
>>> understand. I am trying to boot MLO and u-boot.bin from the SD Card,
>>> and rest from the initramfs.
>>>
>>> I tried several initramfs images, and so far I am always failing on
>>> the same place:
>>> [ 2.135533] No filesystem could mount root, tried:
>>> [ 2.135541] ext2
>>> [ 2.140682]
>>> [ 2.144262] Kernel panic - not syncing: VFS: Unable to mount root
>>> fs on unknown-block(1,0)
>>> [ 2.153034] ---[ end Kernel panic - not syncing: VFS: Unable to
>>> mount root fs on unknown-block(1,0)
>>>
>>> I have tried mostly .gz images (cpio.gz and ext2.gz). Does not help.
>>> Even does not with ext2.gz after YOCTO is done. In order to do it
>>> correctly, I MUST to add U-Boot header, and I do this with the
>>> following command:
>>>
>>> mkimage -n 'Ramdisk Image' -A arm -O linux -T ramdisk -C gzip -d
>>> initramfs.ext2.gz initramfs.uImage
>>>
>>> And the image I actually supply is: initramfs.uImage
>>>
>>> Then, the following happens:
>>>
>>> => run netloadfdt
>>> link up on port 0, speed 100, full duplex
>>> Using cpsw device
>>> TFTP from server 192.168.15.2; our IP address is 192.168.15.20
>>> Filename 'am335x-boneblack.dtb'.
>>> Load address: 0x88000000
>>> Loading: ###
>>> 697.3 KiB/s
>>> done
>>> Bytes transferred = 35016 (88c8 hex)
>>> => run netloadimage
>>> link up on port 0, speed 100, full duplex
>>> Using cpsw device
>>> TFTP from server 192.168.15.2; our IP address is 192.168.15.20
>>> Filename 'zImage'.
>>> Load address: 0x82000000
>>> Loading: #################################################################
>>> #################################################################
>>> #################################################################
>>> #################################################################
>>> ########################
>>> 772.5 KiB/s
>>> done
>>> Bytes transferred = 4161160 (3f7e88 hex)
>>> => tftp 0x88080000 initramfs.uImage
>>> link up on port 0, speed 100, full duplex
>>> Using cpsw device
>>> TFTP from server 192.168.15.2; our IP address is 192.168.15.20
>>> Filename 'initramfs.uImage'.
>>> Load address: 0x88080000
>>> Loading: #################################################################
>>> #################################################################
>>>
>>> [snap]
>>>
>>> #######################################################
>>> 767.6 KiB/s
>>> done
>>> Bytes transferred = 46599246 (2c70c4e hex)
>>> => dhcp
>>> link up on port 0, speed 100, full duplex
>>> BOOTP broadcast 1
>>> DHCP client bound to address 192.168.15.159 (21 ms)
>>> => run ramboot
>>> Booting from ramdisk ...
>>> ## Loading init Ramdisk from Legacy Image at 88080000 ...
>>> Image Name: Ramdisk Image
>>> Created: 2018-02-21 9:46:15 UTC
>>> Image Type: ARM Linux RAMDisk Image (gzip compressed)
>>> Data Size: 46599182 Bytes = 44.4 MiB
>>> Load Address: 00000000
>>> Entry Point: 00000000
>>> Verifying Checksum ... OK
>>> ## Flattened Device Tree blob at 88000000
>>> Booting using the fdt blob at 0x88000000
>>> Loading Ramdisk to 8d38f000, end 8ffffc0e ... OK
>>> Loading Device Tree to 8d383000, end 8d38e8c7 ... OK
>>>
>>> Starting kernel ...
>>>
>>> [ 0.000000] Booting Linux on physical CPU 0x0
>>> [ 0.000000] Linux version 4.13.8-jumpnow (oe-user at oe-host) (gcc
>>> version 7.2.0 (GCC)) #1 Tue Jan 9 15:37:12 CET 2018
>>> [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
>>> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>>> instruction cache
>>> [ 0.000000] OF: fdt: Machine model: TI AM335x BeagleBone Black
>>> [ 0.000000] Memory policy: Data cache writeback
>>> [ 0.000000] cma: Reserved 16 MiB at 0x9f000000
>>> [ 0.000000] CPU: All CPU(s) started in SVC mode.
>>> [ 0.000000] AM335X ES2.1 (sgx neon)
>>> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
>>> Total pages: 130048
>>>
>>> Please, note the Kernal Command line in the log!
>>> [ 0.000000] Kernel command line: console=ttyO0,115200n8
>>> root=/dev/ram0 rw rootfstype=ext2 <<======================== Kernel
>>> Command Line
>>>
>>> [SNAP]
>>>
>>> [ 1.770469] omap_voltage_late_init: Voltage driver support not added
>>> [ 1.777510] ThumbEE CPU extension supported.
>>> [ 1.791397] mmcblk0: mmc0:59b4 USD 1.87 GiB
>>> [ 1.801349] mmcblk0: p1 p2
>>> [ 1.868955] mmc1: new high speed MMC card at address 0001
>>> [ 1.876511] mmcblk1: mmc1:0001 MMC04G 3.60 GiB
>>> [ 1.882230] mmcblk1boot0: mmc1:0001 MMC04G partition 1 2.00 MiB
>>> [ 1.890172] mmcblk1boot1: mmc1:0001 MMC04G partition 2 2.00 MiB
>>> [ 1.896948] mmcblk1rpmb: mmc1:0001 MMC04G partition 3 128 KiB
>>> [ 1.906237] mmcblk1: p1 p2
>>> [ 1.925804] tps65217 0-0024: TPS65217 ID 0xe version 1.2
>>> [ 1.932470] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
>>> [ 1.948789] omap_rtc 44e3e000.rtc: setting system clock to
>>> 2017-12-04 18:09:58 UTC (1512410998)
>>> [ 1.963613] List of all partitions:
>>> [ 1.967311] 0100 16384 ram0
>>> [ 1.967322] (driver?)
>>> [ 1.973831] 0101 16384 ram1
>>> [ 1.973840] (driver?)
>>> [ 1.980294] 0102 16384 ram2
>>> [ 1.980303] (driver?)
>>> [ 1.986703] 0103 16384 ram3
>>> [ 1.986711] (driver?)
>>> [ 1.993144] 0104 16384 ram4
>>> [ 1.993153] (driver?)
>>> [ 1.999582] 0105 16384 ram5
>>> [ 1.999590] (driver?)
>>> [ 2.005991] 0106 16384 ram6
>>> [ 2.005999] (driver?)
>>> [ 2.012428] 0107 16384 ram7
>>> [ 2.012437] (driver?)
>>> [ 2.018903] 0108 16384 ram8
>>> [ 2.018911] (driver?)
>>> [ 2.025313] 0109 16384 ram9
>>> [ 2.025321] (driver?)
>>> [ 2.031776] 010a 16384 ram10
>>> [ 2.031785] (driver?)
>>> [ 2.038304] 010b 16384 ram11
>>> [ 2.038312] (driver?)
>>> [ 2.044804] 010c 16384 ram12
>>> [ 2.044812] (driver?)
>>> [ 2.051344] 010d 16384 ram13
>>> [ 2.051352] (driver?)
>>> [ 2.057871] 010e 16384 ram14
>>> [ 2.057879] (driver?)
>>> [ 2.064371] 010f 16384 ram15
>>> [ 2.064379] (driver?)
>>> [ 2.070912] b300 1960960 mmcblk0
>>> [ 2.070922] driver: mmcblk
>>> [ 2.078079] b301 131072 mmcblk0p1 46a788a5-01
>>> [ 2.078088]
>>> [ 2.085214] b302 1828863 mmcblk0p2 46a788a5-02
>>> [ 2.085222]
>>> [ 2.092652] b308 3776512 mmcblk1
>>> [ 2.092663] driver: mmcblk
>>> [ 2.099840] b309 98304 mmcblk1p1 00000000-01
>>> [ 2.099849]
>>> [ 2.106975] b30a 3677184 mmcblk1p2 00000000-02
>>> [ 2.106984]
>>> [ 2.114160] b320 128 mmcblk1rpmb
>>> [ 2.114169] (driver?)
>>> [ 2.121235] b318 2048 mmcblk1boot1
>>> [ 2.121244] (driver?)
>>> [ 2.128401] b310 2048 mmcblk1boot0
>>> [ 2.128410] (driver?)
>>> [ 2.135533] No filesystem could mount root, tried:
>>> [ 2.135541] ext2
>>> [ 2.140682]
>>> [ 2.144262] Kernel panic - not syncing: VFS: Unable to mount root
>>> fs on unknown-block(1,0)
>>> [ 2.153034] ---[ end Kernel panic - not syncing: VFS: Unable to
>>> mount root fs on unknown-block(1,0)
>>>
>>> What could be the (list of) problem(s) here?
>>
>>
>> I do not see how you start the kernel. Anyway, it shopuld be something
>> like "bootz 0x82000000 0x88000000 0x88080000". This is enough for U-Boot
>> to pass the offset for ramdisk to kernel.
>>
>> If it canot be mounted, the cause is in the most of cases in a missing
>> configuration in kernel, like initrd not supported, missing compression
>> type, and so on.
>>
>> Best regards,
>> Stefano
>>
>>
>> --
>> =====================================================================
>> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
>> =====================================================================
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
More information about the U-Boot
mailing list