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. 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
