From: Pintu Agarwal <pintu.ping@gmail.com>
To: Phillip Lougher <phillip@squashfs.org.uk>
Cc: Sean Nyekjaer <sean@geanix.com>,
open list <linux-kernel@vger.kernel.org>,
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: Tue, 25 May 2021 14:52:06 +0530 [thread overview]
Message-ID: <CAOuPNLgrwnqv_=Ux5SeY3XTDG2b0=ntRbciWVshhaVwJYFEZ3g@mail.gmail.com> (raw)
In-Reply-To: <877196209.4648525.1621840046695@webmail.123-reg.co.uk>
On Mon, 24 May 2021 at 12:37, Phillip Lougher <phillip@squashfs.org.uk> wrote:
>
> > 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
> >
> > 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
>
> Three perhaps obvious questions here:
>
> 1. As an experimental system, are you using a vanilla (unmodified)
> Linux kernel, or have you made modifications. If so, how is it
> modified?
>
> 2. What is the difference between "rootfs" and "userdata"?
> Have you written exactly the same Squashfs image to "rootfs"
> and "userdata", and has it worked with "userdata" and not
> worked with "rootfs".
>
> So far it is unclear whether "userdata" has worked because
> you've written different images/data to it.
>
> In other words tell us exactly what you're writing to "userdata"
> and what you're writing to "rootfs". The difference or non-difference
> may be significant.
>
> 3. The rounding up to a whole 196 blocks should not be a problem.
> The problem is, obviously, if it is rounding down to 195 blocks,
> where the tail end of the Squashfs image will be lost.
>
> Remember this is exactly what the Squashfs error is saying, the image
> has been truncated.
>
> You could try adding a lot of padding to the end of the Squashfs image
> (Squashfs won't care), so it is more than the effective block size,
> and then writing that, to prevent any rounding down or truncation.
>
Just wanted to share the Good news that the ubi volume flashing is
working now :)
First I have created a small read-only volume (instead of rootfs) and
tried to write to it and then compared the checksum.
Initially when I checked, the checksum was not matching and when I
compared the 2 images I found there were around 8192 blocks containing
FF data at the end of each erase block.
After the fix, this time the checksum matches exactly.
/data/pintu # md5sum test-vol-orig.img
6a8a185ec65fcb212b6b5f72f0b0d206 test-vol-orig.img
/data/pintu # md5sum test-vol-after.img
6a8a185ec65fcb212b6b5f72f0b0d206 test-vol-after.img
Once this is working, I tried with rootfs volume, and this time the
device is booting fine :)
The fix is related to the data-len and data-offset calculation in our
volume write code.
[...]
size += data_offset;
[...]
ubi_block_write(....)
buf_size -= (size - data_offset);
offset += (size - data_offset);
[...]
In the previous case, we were not adding and subtracting the data_offset.
The Kernel command line we are using is this:
[ 0.000000] Kernel command line: ro rootwait
console=ttyMSM0,115200,n8 [..skip..] rootfstype=squashfs
root=/dev/mtdblock34 ubi.mtd=30,0,30 [...skip..]
Hope, this parameters are fine (no change here).
Thank you Phillip and Sean for your help.
Phillip I think this checksum trick really helped me in figuring out
the root cause :)
Glad to work with you...
Thanks,
Pintu
next prev parent reply other threads:[~2021-05-25 9:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAOuPNLjgpkBh9dnfNTdDcfk5HiL=HjjiB9o_=fjrm+0vP7Re2Q@mail.gmail.com>
[not found] ` <CAOuPNLh_0Q9w96GKT-ogC0BBcEHgo=Hv3+c=JBcas2VgqDiyaw@mail.gmail.com>
2021-05-14 12:37 ` [RESEND]: Kernel 4.14: SQUASHFS error: unable to read xattr id index table Pintu Agarwal
2021-05-14 21:50 ` Phillip Lougher
2021-05-17 11:34 ` Pintu Agarwal
2021-05-20 4:30 ` Phillip Lougher
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-24 6:12 ` Pintu Agarwal
2021-05-24 7:07 ` Phillip Lougher
2021-05-25 9:22 ` Pintu Agarwal [this message]
2021-05-25 5:37 ` Sean Nyekjaer
2021-05-31 2:54 ` Pintu Agarwal
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='CAOuPNLgrwnqv_=Ux5SeY3XTDG2b0=ntRbciWVshhaVwJYFEZ3g@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).