LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Engraf <david.engraf@sysgo.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND] initramfs: cleanup incomplete rootfs
Date: Mon, 11 Feb 2019 09:49:51 +0100	[thread overview]
Message-ID: <28139206-7fed-e00e-8f52-47e68655963d@sysgo.com> (raw)
In-Reply-To: <744e7bcb-9315-0283-67c5-c2cb2d094251@sysgo.com>

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@linux-foundation.org> wrote:
>>> On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko 
>>> <andy.shevchenko@gmail.com> wrote:
>>>> On Tue, Oct 30, 2018 at 5:22 PM David Engraf 
>>>> <david.engraf@sysgo.com> wrote:
>>>>>
>>>>> Unpacking an external initrd may fail e.g. not enough memory. This 
>>>>> leads
>>>>> to an incomplete rootfs because some files might be extracted already.
>>>>> Fixed by cleaning the rootfs so the kernel is not using an incomplete
>>>>> rootfs.
>>>>
>>>> This breaks my setup where I have U-boot provided more size of
>>>> initramfs than needed. This allows a bit of flexibility to increase or
>>>> decrease initramfs compressed image without taking care of bootloader.
>>>> The proper solution is to do this if we sure that we didn't get enough
>>>> memory, otherwise I can't consider the error fatal to clean up rootfs.
>>>
>>> OK, thanks.  Maybe David can suggest a fix - I'll queue up a revert
>>> meanwhile.
>>>
>>> I don't really understand the failure.  Why does an oversized initramfs
>>> cause unpack_to_rootfs() to fail?
>>
>> 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:

Kernel panic - not syncing: junk in compressed archive
---[ end Kernel panic - not syncing: junk in compressed archive

The panic was not introduced by my patch. Could you please check if you 
get a panic as well or is your rootfs just empty?

I also had a look at the decompression in unpack_to_rootfs(). This 
function already ensures unpacking only the real size of the archive. 
But it is called in a loop, thus it unpacks the first archive and then 
tries to unpack the reset of the data which are garbage in my case.
Is it intended to allow extracting multiple archives as rootfs? If not 
we could remove the loop and unpack only the first archive. Otherwise we 
could ignore errors when the first archive was extracted without errors.

Best regards
- David


  reply	other threads:[~2019-02-11  8:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-22 13:40 [PATCH] " David Engraf
2018-10-30 15:18 ` [PATCH RESEND] " David Engraf
2019-02-08 19:45   ` Andy Shevchenko
2019-02-08 22:08     ` Andrew Morton
2019-02-09 10:35       ` Andy Shevchenko
2019-02-11  7:56         ` David Engraf
2019-02-11  8:49           ` David Engraf [this message]
2019-02-11 11:40             ` Andy Shevchenko
2019-02-11 12:40               ` David Engraf
2019-02-12 10:43                 ` Andy Shevchenko
2019-02-12 12:12                   ` David Engraf
2019-02-12 13:50                     ` Andy Shevchenko
2019-02-15 20:13                       ` Andy Shevchenko
2019-02-12  0:56         ` Andrew Morton
2019-02-12  8:04           ` David Engraf

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=28139206-7fed-e00e-8f52-47e68655963d@sysgo.com \
    --to=david.engraf@sysgo.com \
    --cc=akpm@linux-foundation.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=luc.vanoostenryck@gmail.com \
    --cc=pombredanne@nexb.com \
    --subject='Re: [PATCH RESEND] initramfs: cleanup incomplete rootfs' \
    /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

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