On 24/05/2021 08.12, Pintu Agarwal wrote: > On Sun, 23 May 2021 at 23:01, Sean Nyekjaer <sean@xxxxxxxxxx> wrote: >> > >>> 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. > >> >> Have you had it to work? Or is this a new project? >> If you had it to work, i would start bisecting... >> > > No, this is still experimental. > Currently we are only able to write to ubi volumes but after that > device is not booting (with rootfs volume update). > However, with "userdata" it is working fine. > > I have few more questions to clarify. > > a) Is there a way in kernel to do the ubi volume update while the > device is running ? > I tried "ubiupdatevol" but it does not seem to work. > I guess it is only to update the empty volume ? > Or, maybe I don't know how to use it to update the live "rootfs" volume We are writing our rootfs with this command: ubiupdatevol /dev/ubi0_4 rootfs.squashfs > > b) How to verify the volume checksum as soon as we finish writing the > content, since the device is not booting ? > Is there a way to verify the rootfs checksum at the bootloader or > kernel level before mounting ? > > c) We are configuring the ubi volumes in this way. Is it fine ? > [rootfs_volume] > mode=ubi > image=.<path>/system.squash > vol_id=0 > vol_type=dynamic > vol_name=rootfs > vol_size=62980096 ==> 60.0625 MiB > > Few more info: > ---------------------- > Our actual squashfs image size: > $ ls -l ./system.squash > rw-rr- 1 pintu users 49639424 ../system.squash > > after earse_volume: page-size: 4096, block-size-bytes: 262144, > vtbl-count: 2, used-blk: 38, leb-size: 253952, leb-blk-size: 62 > Thus: > 49639424 / 253952 = 195.46 blocks > > This then round-off to 196 blocks which does not match exactly. > Is there any issue with this ? > > If you have any suggestions to debug further please help us... > > > Thanks, > Pintu > Please understand the differences between the UBI and UBIFS. UBI(unsorted block image) and UBIFS(UBI File System). I think you want to write the squashfs to the UBI(unsorted block image). Can you try to boot with a initramfs, and then use ubiupdatevol to write the rootfs.squshfs. /Sean
