Re: [PATCH RESEND] initramfs: cleanup incomplete rootfs

From: David Engraf
Date: Tue Feb 12 2019 - 07:12:55 EST

On 12.02.19 at 11:43, Andy Shevchenko wrote:
On Mon, Feb 11, 2019 at 2:40 PM David Engraf <david.engraf@xxxxxxxxx> wrote:
On 11.02.19 at 12:40, Andy Shevchenko wrote:
On Mon, Feb 11, 2019 at 10:49 AM David Engraf <david.engraf@xxxxxxxxx> wrote:
On 11.02.19 at 08:56, David Engraf wrote:
On 09.02.19 at 11:35, Andy Shevchenko wrote:
On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko
<andy.shevchenko@xxxxxxxxx> wrote:
On Tue, Oct 30, 2018 at 5:22 PM David Engraf
<david.engraf@xxxxxxxxx> wrote:

In my case I have got "Junk in compressed archive". I don't know (I
would check if needed) which exact condition I got since there are
three places with this message. The file itself smaller than the size
passed through bootparam. So, when decomression is finished
(successfully!) we still have a garbarge in the memory which is not
related to archive. Message per se is okay to have, though I consider
this non-fatal.

I can reproduce this special case. The unpacking decompresses the whole
size instead of checking the archive size. I will have a look how to get
the real archive size.

I did some checks and manually increased the initramfs size but I always
get the following kernel panic:

We need to be on the same page here.
There are two sizes of initramfs compressed archive:
1) actual file size;
2) what is declared by boot loader and provided via boot parameters.

In my case I have the 2) bigger than the actual file size.
Kernel decompresses the initramfs, prints an error that there is junk,
which is understandable and continues to run init, etc.

Ok got it. When the memory behind the actual file size is clear (0x0)
the decompression doesn't complain and just ignores the padding. Any
other data will be interpreted as a new archive and thus you'll see the
error message.


Is it possible for you to fill the padding after the actual file size
with 0x00 ?

Not sure. This is boot loader realm. Even if I patch U-Boot, not every
boot loader will guarantee this.
So, it's fragile to rely on data being 0x00 after actual archive.

The problem is that the kernel expects another archive if there are data left. If these data do not contain a valid magic the kernel prints an error message which is correct.

I could make this error not critical and keep the rootfs, but it's still an error and unexpected. You're using a modified bootloader which reports a size larger than the file itself. Other bootloader will use the file size and report the correct size to the kernel. So this workaround is required by your setup only.

@Andrew: What do you think about that? Shall I create a workaround for the special case?

Best regards
- David