From: Pintu Agarwal <pintu.ping@gmail.com> To: Phillip Lougher <phillip@squashfs.org.uk> Cc: open list <linux-kernel@vger.kernel.org>, sean@geanix.com, linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org Subject: Re: [RESEND]: Kernel 4.14: UBIFS+SQUASHFS: Device fails to boot after flashing rootfs volume Date: Sun, 23 May 2021 22:14:26 +0530 [thread overview] Message-ID: <CAOuPNLjBsm9YLtcb4SnqLYYaHPnscYq4captvCmsR7DthiWGsQ@mail.gmail.com> (raw) In-Reply-To: <486335206.6969995.1621485014357@webmail.123-reg.co.uk> On Thu, 20 May 2021 at 10:00, Phillip Lougher <phillip@squashfs.org.uk> 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
WARNING: multiple messages have this Message-ID (diff)
From: Pintu Agarwal <pintu.ping@gmail.com> To: Phillip Lougher <phillip@squashfs.org.uk> Cc: open list <linux-kernel@vger.kernel.org>, sean@geanix.com, linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org Subject: Re: [RESEND]: Kernel 4.14: UBIFS+SQUASHFS: Device fails to boot after flashing rootfs volume Date: Sun, 23 May 2021 22:14:26 +0530 [thread overview] Message-ID: <CAOuPNLjBsm9YLtcb4SnqLYYaHPnscYq4captvCmsR7DthiWGsQ@mail.gmail.com> (raw) In-Reply-To: <486335206.6969995.1621485014357@webmail.123-reg.co.uk> On Thu, 20 May 2021 at 10:00, Phillip Lougher <phillip@squashfs.org.uk> 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 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2021-05-23 16:44 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CAOuPNLjgpkBh9dnfNTdDcfk5HiL=HjjiB9o_=fjrm+0vP7Re2Q@mail.gmail.com> 2021-05-14 11:41 ` Kernel 4.14: SQUASHFS error: unable to read xattr id index table Pintu Agarwal 2021-05-14 11:41 ` Pintu Agarwal 2021-05-14 12:37 ` [RESEND]: " Pintu Agarwal 2021-05-14 21:50 ` Phillip Lougher 2021-05-14 21:50 ` Phillip Lougher 2021-05-17 11:34 ` Pintu Agarwal 2021-05-17 11:34 ` Pintu Agarwal 2021-05-20 4:30 ` Phillip Lougher 2021-05-20 4:30 ` Phillip Lougher 2021-05-23 16:44 ` Pintu Agarwal [this message] 2021-05-23 16:44 ` [RESEND]: Kernel 4.14: UBIFS+SQUASHFS: Device fails to boot after flashing rootfs volume Pintu Agarwal 2021-05-23 17:31 ` Sean Nyekjaer 2021-05-23 17:31 ` Sean Nyekjaer 2021-05-24 6:12 ` Pintu Agarwal 2021-05-24 6:12 ` Pintu Agarwal 2021-05-24 7:07 ` Phillip Lougher 2021-05-24 7:07 ` Phillip Lougher 2021-05-25 9:22 ` Pintu Agarwal 2021-05-25 9:22 ` Pintu Agarwal 2021-05-25 5:37 ` Sean Nyekjaer 2021-05-25 5:37 ` Sean Nyekjaer 2021-05-31 2:54 ` Pintu Agarwal 2021-05-31 2:54 ` Pintu Agarwal 2021-06-01 6:52 ` Sean Nyekjaer 2021-06-01 6:52 ` Sean Nyekjaer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAOuPNLjBsm9YLtcb4SnqLYYaHPnscYq4captvCmsR7DthiWGsQ@mail.gmail.com \ --to=pintu.ping@gmail.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=phillip@squashfs.org.uk \ --cc=sean@geanix.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.