[U-Boot] Kernel panic - not syncing: VFS: Unable to mount rootfs on unknown-block (1, 0)
Stefano Babic
sbabic at denx.de
Sat Mar 3 12:09:53 UTC 2018
Hi Zoran,
On 03/03/2018 08:18, Zoran S wrote:
> Hello Stefano,
>
> This, what you wrote here is very correct assumption.
>
> CONFIG_BLK_DEV_INITRD=y <<===== To have Block device initramfs/rootfs
> CONFIG_RD_GZIP=y <<===== To have initramfs/rootfs in .gz format
> CONFIG_RD_BZIP2=y <<===== To have initramfs/rootfs in .bz2 format
> CONFIG_RD_LZMA=y <<====== To have initramfs/rootfs in .7z format
> CONFIG_RD_XZ=y <<===== To have initramfs/rootfs in .xz format
> CONFIG_RD_LZO=y
> CONFIG_RD_LZ4=y
>
> (I unsubscribed from u-boot list since every day there are gazillions
> of patches @ - you guys can reconsider to create one special mailing
> list for only U-Boot patches).
>
This was already discussed - and rejected, too. In fact, this
constraints people to switch over and over from one ML to the other one,
and this makes things worse as better. We have also discussed to have
one ML per each subsystem, but we miss then the overview on the project.
U-Boot is not like the kernel where such split makes sense.
We all received thousands of e-mails each day - I need for my work, near
U-Boot ML, several kernel MLs (MTD, input, ARM, .....) and several other
MLs from other projects. I just tell you that I cannot manage this
amount of traffic without help, and I use "imapfilter" on my server to
sort all incoming patches and put them in separate folders before my
e-mailer is checking them.
Best regards,
Stefano
> Thank you,
> Zoran
> _______
>
> On Fri, Mar 2, 2018 at 11:03 AM, Stefano Babic <sbabic at denx.de> wrote:
>> 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