Re: [RESEND]: Kernel 4.14: UBIFS+SQUASHFS: Device fails to boot after flashing rootfs volume

[Sean Nyekjaer]

On 23/05/2021 18.44, Pintu Agarwal wrote:
> On Thu, 20 May 2021 at 10:00, Phillip Lougher <phillip@xxxxxxxxxxxxxxx> wrote:
>>
> 
>> Then run it on your Squashfs image
>>
>> % unsquashfs <your image>
>>
>> If the image is uncorrupted, it will unpack the image into
>> "squashfs-root".  If it is corrupted it will give error
>> messages.
>>
> I have tried this and it seems with unsquashfs I am able to
> successfully extract it to "squashfs-root" folder.
> 
>> I have not used the MTD subsystem for more than 13 years, and so
>> this is best answered on linux-mtd.
> 
> Yes, I have already included the linux-mtd list here.
> Maybe MTD folks can share their opinion as well....
> That is the reason I have changed the subject as well.
> 
>> You appear to be running busybox, and this has both support for
>> "dd" and the "md5sum" checksum program.
>>
>> So do this
>>
>> % dd if=<your character device> of=img bs=1 count=<image size>
>>
>> Where <image size> is the size of the Squashfs image reported
>> by "ls -l" or "stat".  You need to get the exact byte count
>> right, otherwise the resultant checksum won't be right.
>>
>> Then run md5sum on the extracted "img" file.
>>
>> % md5sum img
>>
>> This will produce a checksum.
>>
>> You can then compare that with the result of "md5sum" on your
>> original Squashfs image before flashing (produced on the host
>> or the target).
>>
>> If the checksums differ then it is corrupted.
>>
> I have also tried that and it seems the checksum exactly matches.
> $ md5sum system.squash
> d301016207cc5782d1634259a5c597f9  ./system.squash
> 
> On the device:
> /data/pintu # dd if=/dev/ubi0_0 of=squash_rootfs.img bs=1K count=48476
> 48476+0 records in
> 48476+0 records out
> 49639424 bytes (47.3MB) copied, 26.406276 seconds, 1.8MB/s
> [12001.375255] dd (2392) used greatest stack depth: 4208 bytes left
> 
> /data/pintu # md5sum squash_rootfs.img
> d301016207cc5782d1634259a5c597f9  squash_rootfs.img
> 
> So, it seems there is no problem with either the original image
> (unsquashfs) as well as the checksum.
> 
> Then what else could be the suspect/issue ?
> If you have any further inputs please share your thoughts.
> 
> This is the kernel command line we are using:
> [    0.000000] Kernel command line: ro rootwait
> console=ttyMSM0,115200,n8 androidboot.hardware=qcom
> msm_rtb.filter=0x237 androidboot.console=ttyMSM0
> lpm_levels.sleep_disabled=1 firmware_class.path=/lib/firmware/updates
> service_locator.enable=1 net.ifnames=0 rootfstype=squashfs
> root=/dev/ubiblock0_0 ubi.mtd=30 ubi.block=0,0
> 
> These are few more points to be noted:
> a) With squashfs we are getting below error:
> [    4.603156] squashfs: SQUASHFS error: unable to read xattr id index table
> [...]
> [    4.980519] Kernel panic - not syncing: VFS: Unable to mount root
> fs on unknown-block(254,0)
> 
> b) With ubifs (without squashfs) we are getting below error:
> [    4.712458] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0,
> name "rootfs", R/O mode
> [...]
> UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node type (255 but expected 9)
> UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node at LEB
> 336:250560, LEB mapping status 1
> Not a node, first 24 bytes:
> 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> 
> c) While flashing "usrfs" volume (ubi0_1) there is no issue and device
> boots successfully.
> 
> d) This issue is happening only after flashing rootfs volume (ubi0_0)
> and rebooting the device.
> 
> e) We are using "uefi" and fastboot mechanism to flash the volumes.
Are you writing the squashfs into the ubi block device with uefi/fastboot?
> 
> f) Next I wanted to check the read-only UBI volume flashing mechanism
> within the Kernel itself.
> Is there a way to try a read-only "rootfs" (squashfs type) ubi volume
> flashing mechanism from the Linux command prompt ?
> Or, what are the other ways to verify UBI volume flashing in Linux ?
> 
> g) I wanted to root-cause, if there is any problem in our UBI flashing
> logic, or there's something missing on the Linux/Kernel side (squashfs
> or ubifs) or the way we configure the system.
> 
> Thanks,
> Pintu
> 

Have you had it to work? Or is this a new project?
If you had it to work, i would start bisecting...

/Sean