Re: Kernel 4.14: SQUASHFS error: unable to read xattr id index table

Re: Kernel 4.14: SQUASHFS error: unable to read xattr id index table

[Pintu Agarwal]

Hi,

This is regarding the squashfs mount failure that I am getting on my
device during boot time.
I just wanted to know if someone else has come across this issue, or
this issue is already fixed, or this is altogether a different issue?

Here are more details:
Kernel: 4.14.170 ; Qualcomm chipset (arm32 bit)
Platform: busybox
Storage: NAND 512MB
Filesystem: ubifs + squashfs
ubi0 : with 5 volumes (rootfs, usrfs, others)
Kernel command line: ro rootwait console=ttyMSM0,115200,n8
rootfstype=squashfs root=/dev/mtdblock34 ubi.mtd=30,0,30 ....

Background:
We are using ubifs filesystem with squashfs for rootfs (as ready only).
First we tried to flash "usrfs" (data) volume (ubi0_1) and it worked
fine (with device booting successfully).

Next we are trying to flash "rootfs" volume (ubi0_0) now. The volume
flashing is successful but after that when we reboot the system we are
getting below errors.

Logs:
[....]
[    4.589340] vreg_conn_pa: dis▒[    4.602779] squashfs: SQUASHFS
error: unable to read xattr id index table
[...]
[    4.964083] No filesystem could mount root, tried:
[    4.964087]  squashfs
[    4.966255]
[    4.973443] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(31,34)

-----------
[    4.246861] ubi0: attaching mtd30
[    4.453241] ubi0: scanning is finished
[    4.460655] ubi0: attached mtd30 (name "system", size 216 MiB)
[    4.460704] ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes
[    4.465562] ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096
[    4.472483] ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192
[    4.479295] ubi0: good PEBs: 864, bad PEBs: 0, corrupted PEBs: 0
[    4.486067] ubi0: user volume: 5, internal volumes: 1, max. volumes
count: 128
[    4.492311] ubi0: max/mean erase counter: 4/0, WL threshold: 4096,
image sequence number: 1
[    4.499333] ubi0: available PEBs: 0, total reserved PEBs: 864, PEBs
reserved for bad PEB handling: 60

So, we just wanted to know if this issue is related to squashfs or if
there is some issue with our volume flashing.
Note: We are using fastboot mechanism to support UBI volume flashing.

Observation:
Recently I have seen some squashfs changes related to similar issues
(xattr) so I wanted to understand if these changes are relevant to our
issue or not ?

Age           Commit message(Expand)                                 Author
2021-03-30    squashfs: fix xattr id and id lookup sanity checks
Phillip Lougher
2021-03-30    squashfs: fix inode lookup sanity checks
Sean Nyekjaer
2021-02-23    squashfs: add more sanity checks in xattr id lookup
Phillip Lougher
2021-02-23    squashfs: add more sanity checks in inode lookup
Phillip Lougher
2021-02-23    squashfs: add more sanity checks in id lookup
Phillip Lougher

Please let us know your opinion about this issue...
It will help us to decide whether the issue is related to squashfs  or not.


Thanks,
Pintu

[RESEND]: Kernel 4.14: SQUASHFS error: unable to read xattr id index table

[Pintu Agarwal]

Hi,

This is regarding the squashfs mount failure that I am getting on my
device during boot time.
I just wanted to know if someone else has come across this issue, or
this issue is already fixed, or this is altogether a different issue?

Here are more details:
Kernel: 4.14.170 ; Qualcomm chipset (arm32 bit)
Platform: busybox
Storage: NAND 512MB
Filesystem: ubifs + squashfs
ubi0 : with 5 volumes (rootfs, usrfs, others)
Kernel command line: ro rootwait console=ttyMSM0,115200,n8
rootfstype=squashfs root=/dev/mtdblock34 ubi.mtd=30,0,30 ....

Background:
We are using ubifs filesystem with squashfs for rootfs (as ready only).
First we tried to flash "usrfs" (data) volume (ubi0_1) and it worked
fine (with device booting successfully).

Next we are trying to flash "rootfs" volume (ubi0_0) now. The volume
flashing is successful but after that when we reboot the system we are
getting below errors.

Logs:
[....]
[    4.589340] vreg_conn_pa: dis▒[    4.602779] squashfs: SQUASHFS
error: unable to read xattr id index table
[...]
[    4.964083] No filesystem could mount root, tried:
[    4.964087]  squashfs
[    4.966255]
[    4.973443] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(31,34)

-----------
[    4.246861] ubi0: attaching mtd30
[    4.453241] ubi0: scanning is finished
[    4.460655] ubi0: attached mtd30 (name "system", size 216 MiB)
[    4.460704] ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes
[    4.465562] ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096
[    4.472483] ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192
[    4.479295] ubi0: good PEBs: 864, bad PEBs: 0, corrupted PEBs: 0
[    4.486067] ubi0: user volume: 5, internal volumes: 1, max. volumes
count: 128
[    4.492311] ubi0: max/mean erase counter: 4/0, WL threshold: 4096,
image sequence number: 1
[    4.499333] ubi0: available PEBs: 0, total reserved PEBs: 864, PEBs
reserved for bad PEB handling: 60

So, we just wanted to know if this issue is related to squashfs or if
there is some issue with our volume flashing.
Note: We are using fastboot mechanism to support UBI volume flashing.

Observation:
Recently I have seen some squashfs changes related to similar issues
(xattr) so I wanted to understand if these changes are relevant to our
issue or not ?

Age           Commit message(Expand)                                 Author
2021-03-30    squashfs: fix xattr id and id lookup sanity checks
Phillip Lougher
2021-03-30    squashfs: fix inode lookup sanity checks
Sean Nyekjaer
2021-02-23    squashfs: add more sanity checks in xattr id lookup
Phillip Lougher
2021-02-23    squashfs: add more sanity checks in inode lookup
Phillip Lougher
2021-02-23    squashfs: add more sanity checks in id lookup
Phillip Lougher

Please let us know your opinion about this issue...
It will help us to decide whether the issue is related to squashfs  or not.


Thanks,
Pintu

Re: [RESEND]: Kernel 4.14: SQUASHFS error: unable to read xattr id index table

[Phillip Lougher]

> On 14/05/2021 13:37 Pintu Agarwal <pintu.ping@gmail.com> wrote:
> 
>  
> Hi,
> 
> This is regarding the squashfs mount failure that I am getting on my
> device during boot time.
> I just wanted to know if someone else has come across this issue, or
> this issue is already fixed, or this is altogether a different issue?
> 
> Here are more details:
> Kernel: 4.14.170 ; Qualcomm chipset (arm32 bit)
> Platform: busybox
> Storage: NAND 512MB
> Filesystem: ubifs + squashfs
> ubi0 : with 5 volumes (rootfs, usrfs, others)
> Kernel command line: ro rootwait console=ttyMSM0,115200,n8
> rootfstype=squashfs root=/dev/mtdblock34 ubi.mtd=30,0,30 ....
> 
> Background:
> We are using ubifs filesystem with squashfs for rootfs (as ready only).
> First we tried to flash "usrfs" (data) volume (ubi0_1) and it worked
> fine (with device booting successfully).
> 
> Next we are trying to flash "rootfs" volume (ubi0_0) now. The volume
> flashing is successful but after that when we reboot the system we are
> getting below errors.
> 
> Logs:
> [....]
> [    4.589340] vreg_conn_pa: dis▒[    4.602779] squashfs: SQUASHFS
> error: unable to read xattr id index table
> [...]
> [    4.964083] No filesystem could mount root, tried:
> [    4.964087]  squashfs
> [    4.966255]
> [    4.973443] Kernel panic - not syncing: VFS: Unable to mount root
> fs on unknown-block(31,34)
> 
> -----------
> [    4.246861] ubi0: attaching mtd30
> [    4.453241] ubi0: scanning is finished
> [    4.460655] ubi0: attached mtd30 (name "system", size 216 MiB)
> [    4.460704] ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes
> [    4.465562] ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096
> [    4.472483] ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192
> [    4.479295] ubi0: good PEBs: 864, bad PEBs: 0, corrupted PEBs: 0
> [    4.486067] ubi0: user volume: 5, internal volumes: 1, max. volumes
> count: 128
> [    4.492311] ubi0: max/mean erase counter: 4/0, WL threshold: 4096,
> image sequence number: 1
> [    4.499333] ubi0: available PEBs: 0, total reserved PEBs: 864, PEBs
> reserved for bad PEB handling: 60
> 
> So, we just wanted to know if this issue is related to squashfs or if
> there is some issue with our volume flashing.
> Note: We are using fastboot mechanism to support UBI volume flashing.
> 
> Observation:
> Recently I have seen some squashfs changes related to similar issues
> (xattr) so I wanted to understand if these changes are relevant to our
> issue or not ?
> 
> Age           Commit message(Expand)                                 Author
> 2021-03-30    squashfs: fix xattr id and id lookup sanity checks
> Phillip Lougher
> 2021-03-30    squashfs: fix inode lookup sanity checks
> Sean Nyekjaer
> 2021-02-23    squashfs: add more sanity checks in xattr id lookup
> Phillip Lougher
> 2021-02-23    squashfs: add more sanity checks in inode lookup
> Phillip Lougher
> 2021-02-23    squashfs: add more sanity checks in id lookup
> Phillip Lougher
> 
> Please let us know your opinion about this issue...
> It will help us to decide whether the issue is related to squashfs  or not.
> 
> 
> Thanks,
> Pintu

Your kernel (4.14.170) was released on 5 Feb 2020, and so it won't
contain any of the above commits. The xattr -id code in 4.14.170,
was last updated in May 2011, and so it is much more likely the
problem is elsewhere.

The xattr id index table is written to the end of the Squashfs filesystem,
and it is the first table read on mounting.

As such this is the error you will receive if the Squashfs filesystem
has been truncated in some way. This is by far the most likely reason
for the error.

So you need to check if the Squashfs filesystem image is truncated or
corrupted in some way. This could obviously have happened before
writing to the flash, during writing or afterwards. It could also be
being truncated at read time. The cause could be faulty hardware or
software at any point in the I/O path, at any point in the processs.

So, you need to double check everything at each of the above stages.

1. Check the Squashfs filesystem for correctness before writing it to
the flash. You can run Unsquashfs on the image and see if it reports
any errors.

2. You need to check the filesystem for integrity after writing it to
the flash. Compute a checksum, and compare it with the original
checksum.

In that way you can pinpoint the cause of the truncation/corruption.
But, this is unlikely to be a Squashfs issue, and more likely
truncation/corruption caused by something else.

Phillip

Re: [RESEND]: Kernel 4.14: SQUASHFS error: unable to read xattr id index table

[Pintu Agarwal]

On Sat, 15 May 2021 at 03:21, Phillip Lougher <phillip@squashfs.org.uk> wrote:
>
> Your kernel (4.14.170) was released on 5 Feb 2020, and so it won't
> contain any of the above commits. The xattr -id code in 4.14.170,
> was last updated in May 2011, and so it is much more likely the
> problem is elsewhere.
>
Okay this seems to be UBI volume flashing issue then. I will also try
with non-squashfs image (just ubifs).
See the result in the end.

> The xattr id index table is written to the end of the Squashfs filesystem,
> and it is the first table read on mounting.
>
Okay this gives me a clue that there are some corruptions while
writing the leftover blocks in the end.

> 1. Check the Squashfs filesystem for correctness before writing it to
> the flash. You can run Unsquashfs on the image and see if it reports
> any errors.
>
Can you give me some pointers on how to use unsquashfs ? I could not
find any unsquashfs command on my device.
Do we need to do it on the device or my Ubuntu PC ? Are there some
commands/utility available on ubuntu ?

> 2. You need to check the filesystem for integrity after writing it to
> the flash. Compute a checksum, and compare it with the original
> checksum.
>
Can you also guide me with an example, how to do this as well ?

BTW, I also tried "rootfs" volume flashing using "ubifs" image (non
squashfs). Here are the results.
a) With ubifs image also, the device is not booting after flashing the volume.
b) But I can see that the "rootfs" volume could be mounted, but later
gives some other errors during read_node.

These are the boot up errors logs:
{{{
[ 4.600001] vreg_conn_pa: dis▒[ 4.712458] UBIFS (ubi0:0): UBIFS:
mounted UBI device 0, volume 0, name "rootfs", R/O mode
[ 4.712520] UBIFS (ubi0:0): LEB size: 253952 bytes (248 KiB),
min./max. I/O unit sizes: 4096 bytes/4096 bytes
[ 4.719823] UBIFS (ubi0:0): FS size: 113008640 bytes (107 MiB, 445
LEBs), journal size 9404416 bytes (8 MiB, 38 LEBs)
[ 4.729867] UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
[ 4.740400] UBIFS (ubi0:0): media format: w4/r0 (latest is w5/r0),
UUID xxxxxxxxx-xxxxxxxxxx, small LPT model
[ 4.748587] VFS: Mounted root (ubifs filesystem) readonly on device 0:16.
[ 4.759033] devtmpfs: mounted
[ 4.766803] Freeing unused kernel memory: 2048K
[ 4.805035] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node type
(255 but expected 9)
[ 4.805097] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node at
LEB 336:250560, LEB mapping status 1
[ 4.812401] Not a node, first 24 bytes:
[ 4.812413] 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 ........................
}}}

Seems like there is some corruption in the first 24 bytes ??


Thanks,
Pintu

Re: [RESEND]: Kernel 4.14: SQUASHFS error: unable to read xattr id index table

[Phillip Lougher]

> On 17/05/2021 12:34 Pintu Agarwal <pintu.ping@gmail.com> wrote:
> 
>  
> On Sat, 15 May 2021 at 03:21, Phillip Lougher <phillip@squashfs.org.uk> wrote:
> >
> > Your kernel (4.14.170) was released on 5 Feb 2020, and so it won't
> > contain any of the above commits. The xattr -id code in 4.14.170,
> > was last updated in May 2011, and so it is much more likely the
> > problem is elsewhere.
> >
> Okay this seems to be UBI volume flashing issue then. I will also try
> with non-squashfs image (just ubifs).
> See the result in the end.
> 
> > The xattr id index table is written to the end of the Squashfs filesystem,
> > and it is the first table read on mounting.
> >
> Okay this gives me a clue that there are some corruptions while
> writing the leftover blocks in the end.
> 
> > 1. Check the Squashfs filesystem for correctness before writing it to
> > the flash. You can run Unsquashfs on the image and see if it reports
> > any errors.
> >
> Can you give me some pointers on how to use unsquashfs ? I could not
> find any unsquashfs command on my device.
> Do we need to do it on the device or my Ubuntu PC ? Are there some
> commands/utility available on ubuntu ?
> 

You should run Unsquashfs on the host Ubuntu PC to verify
the integrity of the Squashfs image before transferring and
flashing.

Unsquashfs is in the squashfs-tools package on Ubuntu.  To install
run as root

% apt-get install squashfs-tools

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.

 
> > 2. You need to check the filesystem for integrity after writing it to
> > the flash. Compute a checksum, and compare it with the original
> > checksum.
> >
> Can you also guide me with an example, how to do this as well ?

I have not used the MTD subsystem for more than 13 years, and so
this is best answered on linux-mtd.  There may be some specfic
UBI/MTD tools available now to do integrity checking.

But failing that, and presuming you have character device access
to the flashed partition, you can "dd" the image out of the flash
into a file, and then run a checksum program against it.

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.

> 
> BTW, I also tried "rootfs" volume flashing using "ubifs" image (non
> squashfs). Here are the results.
> a) With ubifs image also, the device is not booting after flashing the volume.
> b) But I can see that the "rootfs" volume could be mounted, but later
> gives some other errors during read_node.
> 
> These are the boot up errors logs:
> {{{
> [ 4.600001] vreg_conn_pa: dis▒[ 4.712458] UBIFS (ubi0:0): UBIFS:
> mounted UBI device 0, volume 0, name "rootfs", R/O mode
> [ 4.712520] UBIFS (ubi0:0): LEB size: 253952 bytes (248 KiB),
> min./max. I/O unit sizes: 4096 bytes/4096 bytes
> [ 4.719823] UBIFS (ubi0:0): FS size: 113008640 bytes (107 MiB, 445
> LEBs), journal size 9404416 bytes (8 MiB, 38 LEBs)
> [ 4.729867] UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
> [ 4.740400] UBIFS (ubi0:0): media format: w4/r0 (latest is w5/r0),
> UUID xxxxxxxxx-xxxxxxxxxx, small LPT model
> [ 4.748587] VFS: Mounted root (ubifs filesystem) readonly on device 0:16.
> [ 4.759033] devtmpfs: mounted
> [ 4.766803] Freeing unused kernel memory: 2048K
> [ 4.805035] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node type
> (255 but expected 9)
> [ 4.805097] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node at
> LEB 336:250560, LEB mapping status 1
> [ 4.812401] Not a node, first 24 bytes:
> [ 4.812413] 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 ........................
> }}}
> 
> Seems like there is some corruption in the first 24 bytes ??
> 

This implies there is corruption being introduced at the MTD level or
below.

Phillip

> 
> Thanks,
> Pintu

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

[Pintu Agarwal]

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

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

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

[Pintu Agarwal]

On Sun, 23 May 2021 at 23:01, Sean Nyekjaer <sean@geanix.com> 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

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

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

[Phillip Lougher]

> On 24/05/2021 07:12 Pintu Agarwal <pintu.ping@gmail.com> wrote:
> 
>  
> On Sun, 23 May 2021 at 23:01, Sean Nyekjaer <sean@geanix.com> 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
> 
> 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.

Phillip

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

[Pintu Agarwal]

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

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

[Sean Nyekjaer]

On 24/05/2021 08.12, Pintu Agarwal wrote:
> On Sun, 23 May 2021 at 23:01, Sean Nyekjaer <sean@geanix.com> 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

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

[Pintu Agarwal]

On Tue, 25 May 2021 at 11:07, Sean Nyekjaer <sean@geanix.com> wrote:
> We are writing our rootfs with this command:
> ubiupdatevol /dev/ubi0_4 rootfs.squashfs
>
> 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.
>
Dear Sean, thank you so much for this suggestion.
Just a final help I need here.

For future experiment purposes, I am trying to setup my qemu-arm
environment using ubifs/squashfs and "nandsim" module.
I already have a working setup for qemu-arm with busybox/initramfs.
Now I wanted to prepare ubifs/squashfs based busybox rootfs which I
can use for booting the mainline kernel.
Is it possible ?
Are there already some pre-built ubifs images available which I can
use for my qemu-arm ?
Or, please guide me how to do it ?

I think it is more convenient to do all experiments with "nandsim"
instead of corrupting the actual NAND hardware.
If you have any other suggestions please let me know.


Thanks,
Pintu

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

[Sean Nyekjaer]

On 31/05/2021 04.54, Pintu Agarwal wrote:
> On Tue, 25 May 2021 at 11:07, Sean Nyekjaer <sean@geanix.com> wrote:
>> We are writing our rootfs with this command:
>> ubiupdatevol /dev/ubi0_4 rootfs.squashfs
>>
>> 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.
>>
> Dear Sean, thank you so much for this suggestion.
> Just a final help I need here.
> 
> For future experiment purposes, I am trying to setup my qemu-arm
> environment using ubifs/squashfs and "nandsim" module.
> I already have a working setup for qemu-arm with busybox/initramfs.
> Now I wanted to prepare ubifs/squashfs based busybox rootfs which I
> can use for booting the mainline kernel.
> Is it possible ?> Are there already some pre-built ubifs images available which I can
> use for my qemu-arm ?
> Or, please guide me how to do it ?
> 
> I think it is more convenient to do all experiments with "nandsim"
> instead of corrupting the actual NAND hardware.
> If you have any other suggestions please let me know.
> 
> 
> Thanks,
> Pintu
> 
Hi,


I have not used qemu with nandsim :(
I would prefer testing on the actual hardware.

We have used Labgrid in the past for that.

/Sean