Kernel panic oe build 75

Products Support HiKey 960
#1 
  Booting `CE Reference Platform (HiKey960 rpb)'

Loading driver at 0x000B7E2B000 EntryPoint=0x000B8A8F280
Loading driver at 0x000B7E2B000 EntryPoint=0x000B8A8F280 
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[    0.334704] dmi: Firmware registration failed.
[    1.396596] Kirin-pcie f4000000.kirin_pcie_rc: Link Fail
[    1.678713] ufshcd-hi3660 ff3b0000.ufs: ufshcd_read_desc_param: Failed reading descriptor. desc_id 0 param_offset 0 buff_len 31 ret 0
[    1.690809] ufshcd-hi3660 ff3b0000.ufs: ufs_get_device_info: Failed reading Device Desc. err = -22
[    1.699774] ufshcd-hi3660 ff3b0000.ufs: ufs_advertise_fixup_device: Failed getting device info. err = -22
[    1.727876] ufshcd-hi3660 ff3b0000.ufs: ufshcd_find_max_sup_active_icc_level: Regulator capability was not set, actvIccLevel=0
[    2.014274] EXT4-fs (sdd10): couldn't mount as ext3 due to feature incompatibilities
[    2.022766] EXT2-fs (sdd10): error: couldn't mount because of unsupported optional features (240)
[    2.032336] F2FS-fs (sdd10): Can't find valid F2FS filesystem in 1th superblock
[    2.039814] F2FS-fs (sdd10): Can't find valid F2FS filesystem in 2th superblock
[    2.047151] F2FS-fs (sdd10): Can't find valid F2FS filesystem in 1th superblock
[    2.054488] F2FS-fs (sdd10): Can't find valid F2FS filesystem in 2th superblock
[    2.062728] EXT4-fs (sdd10): couldn't mount as ext3 due to feature incompatibilities
[    2.071479] EXT2-fs (sdd10): error: couldn't mount because of unsupported optional features (240)
[    2.083205] F2FS-fs (sdd10): Can't find valid F2FS filesystem in 1th superblock
[    2.091061] F2FS-fs (sdd10): Can't find valid F2FS filesystem in 2th superblock
[    2.098392] F2FS-fs (sdd10): Can't find valid F2FS filesystem in 1th superblock
[    2.105710] F2FS-fs (sdd10): Can't find valid F2FS filesystem in 2th superblock
[    2.113130] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,58)
[    2.121489] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S              4.9.0-139822-gdfd2f77 #1
[    2.129929] Hardware name: HiKey960 (DT)
[    2.133849] Call trace:
[    2.136302] [<ffff000008088420>] dump_backtrace+0x0/0x1a0
[    2.141700] [<ffff0000080885d4>] show_stack+0x14/0x20
[    2.146754] [<ffff0000083a0254>] dump_stack+0x94/0xb8
[    2.151804] [<ffff000008165b38>] panic+0x114/0x27c
[    2.156597] [<ffff000008ce11b4>] mount_block_root+0x208/0x25c
[    2.162341] [<ffff000008ce1324>] mount_root+0x11c/0x134
[    2.167564] [<ffff000008ce1474>] prepare_namespace+0x138/0x180
[    2.173396] [<ffff000008ce0d6c>] kernel_init_freeable+0x224/0x248
[    2.179492] [<ffff0000088f72f8>] kernel_init+0x10/0x100
[    2.184715] [<ffff000008082e80>] ret_from_fork+0x10/0x50
[    2.190025] SMP: stopping secondary CPUs
[    2.194152] Kernel Offset: disabled
[    2.197637] Memory Limit: none
[    2.200691] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,58)

seems like partition issue, but i recon i have properly flashed the system, userdata, cache and boot partition

build 71 works fine, seems to be an issue in the rootfs file. I used the lava-desktop image for both the builds. MD5 checked

uefi from uefi-staging 13

#2

Yes, the error means that the kernel does not recognised the filesystem is has found in /dev/sdd10. Either the filesystem is damaged or it was not installed in /dev/sdd10 (unfortunately it is not trivial to map fastboot names such as ‘system’ or ‘rootfs’ to the partition numbers).

You mentioned build #71, are you able to take the system from broken to working by swapping the rootfs (maybe called ‘system’ rather than ‘rootfs’) with fastboot and leaving the others the same? Same question for ‘boot’… in other words can you debug by getting some clues by combining bits of #71 and bits of #75?

#3

ran 71_boot with 71_root/system works
ran 75_boot with 71_root/system works
ran 71_boot with 75_root/system doesn’t work
ran 75_boot with 75_root/system doesn’t work

the issue seems to be with 75 root and now even with 76 root

#4

the issue seems to be only with the rpb-desktop-image-lava-hikey960-20170722144217-76.rootfs image for both 75 and 76

#5

Weird… do you use the .ext4.gz or the .img.gz?

#6

.img.gz for every test

#7

Did the fastboot command to flash the #75/#76 version report any errors (either via fastboot or the serial port). Both appear to be valid filesystem images but the #71 version is ~4.5gb whilst the #75+ version is ~5gb… it might be that the #75 version needs an alternative partition table…

#8

it did a sort of interface error kind of a thing because it was random and could just have been just my usb hub, but restarting the flash process, it completed successfully. also AFAIK it gave the error on 71 as well so not specific to 75+

#9

Basically I’ve not tried OE on this platform but normally I would not expect to see filesystem images change size unless the previous size was suboptimal (e.g. filesystem image was too small for partition) or the default partition table gets changed.

Perhaps boot with #71 and to a bit of analysis with fdisk or lsblk to find out how big the various partitions actually are on your board?

#10

ok so afaik here is the breakdown
first lsblk
root@hikey960:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdd 8:48 0 29.8G 0 disk
|-sdd2 8:50 0 12M 0 part
|-sdd9 8:57 0 2M 0 part
|-sdd7 8:55 0 64M 0 part
|-sdd5 8:53 0 256M 0 part
|-sdd12 8:60 0 1M 0 part
|-sdd3 8:51 0 6M 0 part
|-sdd10 8:58 0 4.6G 0 part /
|-sdd1 8:49 0 1M 0 part
|-sdd8 8:56 0 16M 0 part
|-sdd6 8:54 0 1M 0 part
|-sdd13 8:61 0 24.1G 0 part
|-sdd4 8:52 0 12M 0 part
-sdd11 8:59 0 784M 0 part sdb 8:16 0 4M 0 disk sdc 8:32 0 8M 0 disk -sdc1 8:33 0 7M 0 part
sda 8:0 0 4M 0 disk
root@hikey960:~#

now sdd10 is our “system” where the rootfs is flashed at 4.6GB so yes the 75+ builds exceed that and probably cause issues. But the emmc is 32GB, the remaining is in sdd13 with 24GB free space.

now since the oe builds do not have a separate ptable.img, they endup using aosp ptable that distributes 4.6 gb to system/root and 24gb to userdata like any other smartphone running android.

For now it’s not an issue since desktop doesn’t work anyways because hdmi is not yet supported, but the proper solution would be to have a separate ptable.img for oe/linux

#11

Another common temporary solution is to burn the rootfs into the (large) userdata partition rather than the (small) system partition!

Either way, this does confirm the image is caused by the OE filesystem image changing size.

#12

yes, i was able to boot 76 desktop flashed on sda13/userdata/24gb partition but i had to edit the grub cmd line that’s all…

#13

Little follow up experiment, of cource ends up in kernel panic, didn’t expect it to work…

734×499 23.6 KB