[PATCH] isar-bootstrap: Increase cache room

[PATCH] isar-bootstrap: Increase cache room

[Alexander Smirnov]

According to the man page for 'apt.conf', there are three variables:
 - Cache-Start: initial size of mmap cache room
 - Cache-Grow: gap for dynamic mmap cache growth
 - Cache-Limit: maximal cache size after growth

If dynamic resize of mmap region is not avaialbe, the apt uses
pre-allocated Cache-Start room [1] for mmap file.

Building Isar on one of the Debian host with kernel 3.4, I got the
following problem for 'qemuarm64-stretch' configuration:

8<--
Hit:1 http://security.debian.org stretch/updates InRelease
Ign:2 http://ftp.de.debian.org/debian stretch InRelease
Hit:3 http://ftp.de.debian.org/debian stretch-updates InRelease
Hit:4 http://ftp.de.debian.org/debian stretch Release
E: Dynamic MMap ran out of room. Please increase the size of APT::Cache-Start. Current value: 25165824. (man 5 apt.conf)
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
8<--

I have no information, why exactly the room could not be re-sized on this
system, but it would be better to increase the initial room size for apt.
This patch increases the default apt cache twice.

Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
---
 meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
index a38dd88..4cdefaa 100644
--- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
+++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
@@ -187,7 +187,9 @@ do_apt_update() {
 
     E="${@bb.utils.export_proxies(d)}"
     export DEBIAN_FRONTEND=noninteractive
-    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
+    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y \
+                                      -o APT::Cache-Start=50331648
+                                     
     sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get dist-upgrade -y \
                                       -o Debug::pkgProblemResolver=yes
 }
-- 
2.1.4

Re: [PATCH] isar-bootstrap: Increase cache room

[Alexander Smirnov]

On 05/07/2018 06:48 PM, Alexander Smirnov wrote:
> According to the man page for 'apt.conf', there are three variables:
>   - Cache-Start: initial size of mmap cache room
>   - Cache-Grow: gap for dynamic mmap cache growth
>   - Cache-Limit: maximal cache size after growth
> 
> If dynamic resize of mmap region is not avaialbe, the apt uses
> pre-allocated Cache-Start room [1] for mmap file.
> 
> Building Isar on one of the Debian host with kernel 3.4, I got the
> following problem for 'qemuarm64-stretch' configuration:
> 
> 8<--
> Hit:1 http://security.debian.org stretch/updates InRelease
> Ign:2 http://ftp.de.debian.org/debian stretch InRelease
> Hit:3 http://ftp.de.debian.org/debian stretch-updates InRelease
> Hit:4 http://ftp.de.debian.org/debian stretch Release
> E: Dynamic MMap ran out of room. Please increase the size of APT::Cache-Start. Current value: 25165824. (man 5 apt.conf)
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
> 8<--
> 
> I have no information, why exactly the room could not be re-sized on this
> system, but it would be better to increase the initial room size for apt.
> This patch increases the default apt cache twice.
> 

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657085

Missed :-(

> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
> ---
>   meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
> index a38dd88..4cdefaa 100644
> --- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
> +++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
> @@ -187,7 +187,9 @@ do_apt_update() {
>   
>       E="${@bb.utils.export_proxies(d)}"
>       export DEBIAN_FRONTEND=noninteractive
> -    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
> +    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y \
> +                                      -o APT::Cache-Start=50331648
> +
>       sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get dist-upgrade -y \
>                                         -o Debug::pkgProblemResolver=yes
>   }
> 

-- 
With best regards,
Alexander Smirnov

ilbers GmbH
Baierbrunner Str. 28c
D-81379 Munich
+49 (89) 122 67 24-0
http://ilbers.de/
Commercial register Munich, HRB 214197
General manager: Baurzhan Ismagulov

Re: [PATCH] isar-bootstrap: Increase cache room

[Henning Schild]

Am Mon, 7 May 2018 18:57:36 +0300
schrieb Alexander Smirnov <asmirnov@ilbers.de>:

> On 05/07/2018 06:48 PM, Alexander Smirnov wrote:
> > According to the man page for 'apt.conf', there are three variables:
> >   - Cache-Start: initial size of mmap cache room
> >   - Cache-Grow: gap for dynamic mmap cache growth
> >   - Cache-Limit: maximal cache size after growth
> > 
> > If dynamic resize of mmap region is not avaialbe, the apt uses
> > pre-allocated Cache-Start room [1] for mmap file.
> > 
> > Building Isar on one of the Debian host with kernel 3.4, I got the
> > following problem for 'qemuarm64-stretch' configuration:
> > 
> > 8<--
> > Hit:1 http://security.debian.org stretch/updates InRelease
> > Ign:2 http://ftp.de.debian.org/debian stretch InRelease
> > Hit:3 http://ftp.de.debian.org/debian stretch-updates InRelease
> > Hit:4 http://ftp.de.debian.org/debian stretch Release
> > E: Dynamic MMap ran out of room. Please increase the size of
> > APT::Cache-Start. Current value: 25165824. (man 5 apt.conf) qemu:
> > uncaught target signal 11 (Segmentation fault) - core dumped
> > Segmentation fault 8<--
> > 
> > I have no information, why exactly the room could not be re-sized
> > on this system, but it would be better to increase the initial room
> > size for apt. This patch increases the default apt cache twice.
> >   
> 
> 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657085
> 
> Missed :-(

What is your conclusion from that link and what does it mean for the
patch?

I do not like adding magic numbers and changing the default config,
especially if the whole reason is to work around a problem only found
on outdated build hosts (3.4 really?)

If this patch needs to go in, it is missing the cleanup step.

Henning

> > Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
> > ---
> >   meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
> > b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb index
> > a38dd88..4cdefaa 100644 ---
> > a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb +++
> > b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb @@ -187,7
> > +187,9 @@ do_apt_update() { 
> >       E="${@bb.utils.export_proxies(d)}"
> >       export DEBIAN_FRONTEND=noninteractive
> > -    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
> > +    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y \
> > +                                      -o APT::Cache-Start=50331648
> > +
> >       sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get dist-upgrade
> > -y \ -o Debug::pkgProblemResolver=yes
> >   }
> >   
> 

Re: [PATCH] isar-bootstrap: Increase cache room

[Alexander Smirnov]

Hi,

On 05/07/2018 07:31 PM, Henning Schild wrote:
> Am Mon, 7 May 2018 18:57:36 +0300
> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> 
>> On 05/07/2018 06:48 PM, Alexander Smirnov wrote:
>>> According to the man page for 'apt.conf', there are three variables:
>>>    - Cache-Start: initial size of mmap cache room
>>>    - Cache-Grow: gap for dynamic mmap cache growth
>>>    - Cache-Limit: maximal cache size after growth
>>>
>>> If dynamic resize of mmap region is not avaialbe, the apt uses
>>> pre-allocated Cache-Start room [1] for mmap file.
>>>
>>> Building Isar on one of the Debian host with kernel 3.4, I got the
>>> following problem for 'qemuarm64-stretch' configuration:
>>>
>>> 8<--
>>> Hit:1 http://security.debian.org stretch/updates InRelease
>>> Ign:2 http://ftp.de.debian.org/debian stretch InRelease
>>> Hit:3 http://ftp.de.debian.org/debian stretch-updates InRelease
>>> Hit:4 http://ftp.de.debian.org/debian stretch Release
>>> E: Dynamic MMap ran out of room. Please increase the size of
>>> APT::Cache-Start. Current value: 25165824. (man 5 apt.conf) qemu:
>>> uncaught target signal 11 (Segmentation fault) - core dumped
>>> Segmentation fault 8<--
>>>
>>> I have no information, why exactly the room could not be re-sized
>>> on this system, but it would be better to increase the initial room
>>> size for apt. This patch increases the default apt cache twice.
>>>    
>>
>> 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657085
>>
>> Missed :-(
> 
> What is your conclusion from that link and what does it mean for the
> patch?
> 

This just the information I found about dynamic cache increasing. 
Sometimes it could not work. Another fact is that increasing of 
Cache-Limit doesn't help, so seems that mremap really doesn't work.

> I do not like adding magic numbers and changing the default config,
> especially if the whole reason is to work around a problem only found
> on outdated build hosts (3.4 really?)

I'm not 100% sure that kernel 3.4 is the source of the problem. Tried to 
investigate, but for now without results.

But if you try to google line:

   E: Dynamic MMap ran out of room. Please increase the size of 
APT::Cache-Start

There will be tons of search results, so such problem occurred not only 
on my host.


The man page says:

...on systems with a lot of configured sources it should be increased...

so for me it makes sense to increase this room even if there is only one 
problem report. It doesn't break anything.

We can't require Isar users to always have up-to-dated host systems. If 
this patch makes all Isar users with old kernels happy, it's probably 
good for Isar in general :-)

> 
> If this patch needs to go in, it is missing the cleanup step.
> 

Sorry, what do you mean here by cleanup step?

Alex

> Henning
> 
>>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
>>> ---
>>>    meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4 +++-
>>>    1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb index
>>> a38dd88..4cdefaa 100644 ---
>>> a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb +++
>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb @@ -187,7
>>> +187,9 @@ do_apt_update() {
>>>        E="${@bb.utils.export_proxies(d)}"
>>>        export DEBIAN_FRONTEND=noninteractive
>>> -    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
>>> +    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y \
>>> +                                      -o APT::Cache-Start=50331648
>>> +
>>>        sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get dist-upgrade
>>> -y \ -o Debug::pkgProblemResolver=yes
>>>    }
>>>    
>>
> 

-- 
With best regards,
Alexander Smirnov

ilbers GmbH
Baierbrunner Str. 28c
D-81379 Munich
+49 (89) 122 67 24-0
http://ilbers.de/
Commercial register Munich, HRB 214197
General manager: Baurzhan Ismagulov

Re: [PATCH] isar-bootstrap: Increase cache room

[Henning Schild]

Am Mon, 7 May 2018 19:48:16 +0300
schrieb Alexander Smirnov <asmirnov@ilbers.de>:

> Hi,
> 
> On 05/07/2018 07:31 PM, Henning Schild wrote:
> > Am Mon, 7 May 2018 18:57:36 +0300
> > schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >   
> >> On 05/07/2018 06:48 PM, Alexander Smirnov wrote:  
> >>> According to the man page for 'apt.conf', there are three
> >>> variables:
> >>>    - Cache-Start: initial size of mmap cache room
> >>>    - Cache-Grow: gap for dynamic mmap cache growth
> >>>    - Cache-Limit: maximal cache size after growth
> >>>
> >>> If dynamic resize of mmap region is not avaialbe, the apt uses
> >>> pre-allocated Cache-Start room [1] for mmap file.
> >>>
> >>> Building Isar on one of the Debian host with kernel 3.4, I got the
> >>> following problem for 'qemuarm64-stretch' configuration:
> >>>
> >>> 8<--
> >>> Hit:1 http://security.debian.org stretch/updates InRelease
> >>> Ign:2 http://ftp.de.debian.org/debian stretch InRelease
> >>> Hit:3 http://ftp.de.debian.org/debian stretch-updates InRelease
> >>> Hit:4 http://ftp.de.debian.org/debian stretch Release
> >>> E: Dynamic MMap ran out of room. Please increase the size of
> >>> APT::Cache-Start. Current value: 25165824. (man 5 apt.conf) qemu:
> >>> uncaught target signal 11 (Segmentation fault) - core dumped
> >>> Segmentation fault 8<--
> >>>
> >>> I have no information, why exactly the room could not be re-sized
> >>> on this system, but it would be better to increase the initial
> >>> room size for apt. This patch increases the default apt cache
> >>> twice. 
> >>
> >> 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657085
> >>
> >> Missed :-(  
> > 
> > What is your conclusion from that link and what does it mean for the
> > patch?
> >   
> 
> This just the information I found about dynamic cache increasing. 
> Sometimes it could not work. Another fact is that increasing of 
> Cache-Limit doesn't help, so seems that mremap really doesn't work.
> 
> > I do not like adding magic numbers and changing the default config,
> > especially if the whole reason is to work around a problem only
> > found on outdated build hosts (3.4 really?)  
> 
> I'm not 100% sure that kernel 3.4 is the source of the problem. Tried
> to investigate, but for now without results.
> 
> But if you try to google line:
> 
>    E: Dynamic MMap ran out of room. Please increase the size of 
> APT::Cache-Start
> 
> There will be tons of search results, so such problem occurred not
> only on my host.
> 
> 
> The man page says:
> 
> ...on systems with a lot of configured sources it should be
> increased...
> 
> so for me it makes sense to increase this room even if there is only
> one problem report. It doesn't break anything.

Oh yes it breaks the fact that we do not need to care about the value.
If you hardcode one today you might be setting half the default after
the next apt-update. ... because it is a magic number and not

set(get()*2)

> We can't require Isar users to always have up-to-dated host systems.
> If this patch makes all Isar users with old kernels happy, it's
> probably good for Isar in general :-)

Sure, but there is a cost ... see previous point.
 
> > 
> > If this patch needs to go in, it is missing the cleanup step.
> >   
> 
> Sorry, what do you mean here by cleanup step?

Sorry, misread the patch. I thought it placed a file in the rootfs.

Henning

> Alex
> 
> > Henning
> >   
> >>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
> >>> ---
> >>>    meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4 +++-
> >>>    1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
> >>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb index
> >>> a38dd88..4cdefaa 100644 ---
> >>> a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb +++
> >>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb @@ -187,7
> >>> +187,9 @@ do_apt_update() {
> >>>        E="${@bb.utils.export_proxies(d)}"
> >>>        export DEBIAN_FRONTEND=noninteractive
> >>> -    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
> >>> +    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y \
> >>> +                                      -o
> >>> APT::Cache-Start=50331648 +
> >>>        sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get dist-upgrade
> >>> -y \ -o Debug::pkgProblemResolver=yes
> >>>    }
> >>>      
> >>  
> >   
> 

Re: [PATCH] isar-bootstrap: Increase cache room

[Alexander Smirnov]

On 05/07/2018 08:12 PM, Henning Schild wrote:
> Am Mon, 7 May 2018 19:48:16 +0300
> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> 
>> Hi,
>>
>> On 05/07/2018 07:31 PM, Henning Schild wrote:
>>> Am Mon, 7 May 2018 18:57:36 +0300
>>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
>>>    
>>>> On 05/07/2018 06:48 PM, Alexander Smirnov wrote:
>>>>> According to the man page for 'apt.conf', there are three
>>>>> variables:
>>>>>     - Cache-Start: initial size of mmap cache room
>>>>>     - Cache-Grow: gap for dynamic mmap cache growth
>>>>>     - Cache-Limit: maximal cache size after growth
>>>>>
>>>>> If dynamic resize of mmap region is not avaialbe, the apt uses
>>>>> pre-allocated Cache-Start room [1] for mmap file.
>>>>>
>>>>> Building Isar on one of the Debian host with kernel 3.4, I got the
>>>>> following problem for 'qemuarm64-stretch' configuration:
>>>>>
>>>>> 8<--
>>>>> Hit:1 http://security.debian.org stretch/updates InRelease
>>>>> Ign:2 http://ftp.de.debian.org/debian stretch InRelease
>>>>> Hit:3 http://ftp.de.debian.org/debian stretch-updates InRelease
>>>>> Hit:4 http://ftp.de.debian.org/debian stretch Release
>>>>> E: Dynamic MMap ran out of room. Please increase the size of
>>>>> APT::Cache-Start. Current value: 25165824. (man 5 apt.conf) qemu:
>>>>> uncaught target signal 11 (Segmentation fault) - core dumped
>>>>> Segmentation fault 8<--
>>>>>
>>>>> I have no information, why exactly the room could not be re-sized
>>>>> on this system, but it would be better to increase the initial
>>>>> room size for apt. This patch increases the default apt cache
>>>>> twice.
>>>>
>>>> 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657085
>>>>
>>>> Missed :-(
>>>
>>> What is your conclusion from that link and what does it mean for the
>>> patch?
>>>    
>>
>> This just the information I found about dynamic cache increasing.
>> Sometimes it could not work. Another fact is that increasing of
>> Cache-Limit doesn't help, so seems that mremap really doesn't work.
>>
>>> I do not like adding magic numbers and changing the default config,
>>> especially if the whole reason is to work around a problem only
>>> found on outdated build hosts (3.4 really?)
>>
>> I'm not 100% sure that kernel 3.4 is the source of the problem. Tried
>> to investigate, but for now without results.
>>
>> But if you try to google line:
>>
>>     E: Dynamic MMap ran out of room. Please increase the size of
>> APT::Cache-Start
>>
>> There will be tons of search results, so such problem occurred not
>> only on my host.
>>
>>
>> The man page says:
>>
>> ...on systems with a lot of configured sources it should be
>> increased...
>>
>> so for me it makes sense to increase this room even if there is only
>> one problem report. It doesn't break anything.
> 
> Oh yes it breaks the fact that we do not need to care about the value.
> If you hardcode one today you might be setting half the default after
> the next apt-update. ... because it is a magic number and not
> 
> set(get()*2)

Unfortunately this option is not get-able. It's defined as member of 
class in source code, which is initialized on class creation. There is 
no getter function to request this variable later.

8<--
apt-pkg/pkgcachegen.cc:

map_filesize_t const MapStart = _config->FindI("APT::Cache-Start", 
24*1024*1024);
...
return new DynamicMMap(*CacheF, Flags, MapStart, MapGrow, MapLimit);
8<--

Anyway, I noticed that build fails later on any 'apt' call in 
'buildchroot' and 'image' for this configuration.

I was wrong with kernel version, it's 3.16 - the standard Jessie kernel. 
So for now, I'd like to drop this patch and add supported hosts matrix 
to Isar. This workaround could be described here.

Alex

> 
>> We can't require Isar users to always have up-to-dated host systems.
>> If this patch makes all Isar users with old kernels happy, it's
>> probably good for Isar in general :-)
> 
> Sure, but there is a cost ... see previous point.
>   
>>>
>>> If this patch needs to go in, it is missing the cleanup step.
>>>    
>>
>> Sorry, what do you mean here by cleanup step?
> 
> Sorry, misread the patch. I thought it placed a file in the rootfs.
> 
> Henning
> 
>> Alex
>>
>>> Henning
>>>    
>>>>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
>>>>> ---
>>>>>     meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4 +++-
>>>>>     1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
>>>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb index
>>>>> a38dd88..4cdefaa 100644 ---
>>>>> a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb +++
>>>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb @@ -187,7
>>>>> +187,9 @@ do_apt_update() {
>>>>>         E="${@bb.utils.export_proxies(d)}"
>>>>>         export DEBIAN_FRONTEND=noninteractive
>>>>> -    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
>>>>> +    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y \
>>>>> +                                      -o
>>>>> APT::Cache-Start=50331648 +
>>>>>         sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get dist-upgrade
>>>>> -y \ -o Debug::pkgProblemResolver=yes
>>>>>     }
>>>>>       
>>>>   
>>>    
>>
> 

-- 
With best regards,
Alexander Smirnov

ilbers GmbH
Baierbrunner Str. 28c
D-81379 Munich
+49 (89) 122 67 24-0
http://ilbers.de/
Commercial register Munich, HRB 214197
General manager: Baurzhan Ismagulov

Re: [PATCH] isar-bootstrap: Increase cache room

[Henning Schild]

Am Tue, 8 May 2018 10:56:55 +0300
schrieb Alexander Smirnov <asmirnov@ilbers.de>:

> On 05/07/2018 08:12 PM, Henning Schild wrote:
> > Am Mon, 7 May 2018 19:48:16 +0300
> > schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >   
> >> Hi,
> >>
> >> On 05/07/2018 07:31 PM, Henning Schild wrote:  
> >>> Am Mon, 7 May 2018 18:57:36 +0300
> >>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >>>      
> >>>> On 05/07/2018 06:48 PM, Alexander Smirnov wrote:  
> >>>>> According to the man page for 'apt.conf', there are three
> >>>>> variables:
> >>>>>     - Cache-Start: initial size of mmap cache room
> >>>>>     - Cache-Grow: gap for dynamic mmap cache growth
> >>>>>     - Cache-Limit: maximal cache size after growth
> >>>>>
> >>>>> If dynamic resize of mmap region is not avaialbe, the apt uses
> >>>>> pre-allocated Cache-Start room [1] for mmap file.
> >>>>>
> >>>>> Building Isar on one of the Debian host with kernel 3.4, I got
> >>>>> the following problem for 'qemuarm64-stretch' configuration:
> >>>>>
> >>>>> 8<--
> >>>>> Hit:1 http://security.debian.org stretch/updates InRelease
> >>>>> Ign:2 http://ftp.de.debian.org/debian stretch InRelease
> >>>>> Hit:3 http://ftp.de.debian.org/debian stretch-updates InRelease
> >>>>> Hit:4 http://ftp.de.debian.org/debian stretch Release
> >>>>> E: Dynamic MMap ran out of room. Please increase the size of
> >>>>> APT::Cache-Start. Current value: 25165824. (man 5 apt.conf)
> >>>>> qemu: uncaught target signal 11 (Segmentation fault) - core
> >>>>> dumped Segmentation fault 8<--
> >>>>>
> >>>>> I have no information, why exactly the room could not be
> >>>>> re-sized on this system, but it would be better to increase the
> >>>>> initial room size for apt. This patch increases the default apt
> >>>>> cache twice.  
> >>>>
> >>>> 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657085
> >>>>
> >>>> Missed :-(  
> >>>
> >>> What is your conclusion from that link and what does it mean for
> >>> the patch?
> >>>      
> >>
> >> This just the information I found about dynamic cache increasing.
> >> Sometimes it could not work. Another fact is that increasing of
> >> Cache-Limit doesn't help, so seems that mremap really doesn't work.
> >>  
> >>> I do not like adding magic numbers and changing the default
> >>> config, especially if the whole reason is to work around a
> >>> problem only found on outdated build hosts (3.4 really?)  
> >>
> >> I'm not 100% sure that kernel 3.4 is the source of the problem.
> >> Tried to investigate, but for now without results.
> >>
> >> But if you try to google line:
> >>
> >>     E: Dynamic MMap ran out of room. Please increase the size of
> >> APT::Cache-Start
> >>
> >> There will be tons of search results, so such problem occurred not
> >> only on my host.
> >>
> >>
> >> The man page says:
> >>
> >> ...on systems with a lot of configured sources it should be
> >> increased...
> >>
> >> so for me it makes sense to increase this room even if there is
> >> only one problem report. It doesn't break anything.  
> > 
> > Oh yes it breaks the fact that we do not need to care about the
> > value. If you hardcode one today you might be setting half the
> > default after the next apt-update. ... because it is a magic number
> > and not
> > 
> > set(get()*2)  
> 
> Unfortunately this option is not get-able. It's defined as member of 
> class in source code, which is initialized on class creation. There
> is no getter function to request this variable later.
> 
> 8<--
> apt-pkg/pkgcachegen.cc:
> 
> map_filesize_t const MapStart = _config->FindI("APT::Cache-Start", 
> 24*1024*1024);
> ...
> return new DynamicMMap(*CacheF, Flags, MapStart, MapGrow, MapLimit);
> 8<--
> 
> Anyway, I noticed that build fails later on any 'apt' call in 
> 'buildchroot' and 'image' for this configuration.
> 
> I was wrong with kernel version, it's 3.16 - the standard Jessie
> kernel. So for now, I'd like to drop this patch and add supported
> hosts matrix to Isar. This workaround could be described here.

I guess one could make such a workaround depending on "apt-get
--version", to prevent it from causing undesired things in versions
it is not for.

Henning

> Alex
> 
> >   
> >> We can't require Isar users to always have up-to-dated host
> >> systems. If this patch makes all Isar users with old kernels
> >> happy, it's probably good for Isar in general :-)  
> > 
> > Sure, but there is a cost ... see previous point.
> >     
> >>>
> >>> If this patch needs to go in, it is missing the cleanup step.
> >>>      
> >>
> >> Sorry, what do you mean here by cleanup step?  
> > 
> > Sorry, misread the patch. I thought it placed a file in the rootfs.
> > 
> > Henning
> >   
> >> Alex
> >>  
> >>> Henning
> >>>      
> >>>>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
> >>>>> ---
> >>>>>     meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4 +++-
> >>>>>     1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
> >>>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb index
> >>>>> a38dd88..4cdefaa 100644 ---
> >>>>> a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb +++
> >>>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb @@ -187,7
> >>>>> +187,9 @@ do_apt_update() {
> >>>>>         E="${@bb.utils.export_proxies(d)}"
> >>>>>         export DEBIAN_FRONTEND=noninteractive
> >>>>> -    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
> >>>>> +    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y \
> >>>>> +                                      -o
> >>>>> APT::Cache-Start=50331648 +
> >>>>>         sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get
> >>>>> dist-upgrade -y \ -o Debug::pkgProblemResolver=yes
> >>>>>     }
> >>>>>         
> >>>>     
> >>>      
> >>  
> >   
> 

Re: [PATCH] isar-bootstrap: Increase cache room

[Alexander Smirnov]

On 05/08/2018 11:56 AM, Henning Schild wrote:
> Am Tue, 8 May 2018 10:56:55 +0300
> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> 
>> On 05/07/2018 08:12 PM, Henning Schild wrote:
>>> Am Mon, 7 May 2018 19:48:16 +0300
>>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
>>>    
>>>> Hi,
>>>>
>>>> On 05/07/2018 07:31 PM, Henning Schild wrote:
>>>>> Am Mon, 7 May 2018 18:57:36 +0300
>>>>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
>>>>>       
>>>>>> On 05/07/2018 06:48 PM, Alexander Smirnov wrote:
>>>>>>> According to the man page for 'apt.conf', there are three
>>>>>>> variables:
>>>>>>>      - Cache-Start: initial size of mmap cache room
>>>>>>>      - Cache-Grow: gap for dynamic mmap cache growth
>>>>>>>      - Cache-Limit: maximal cache size after growth
>>>>>>>
>>>>>>> If dynamic resize of mmap region is not avaialbe, the apt uses
>>>>>>> pre-allocated Cache-Start room [1] for mmap file.
>>>>>>>
>>>>>>> Building Isar on one of the Debian host with kernel 3.4, I got
>>>>>>> the following problem for 'qemuarm64-stretch' configuration:
>>>>>>>
>>>>>>> 8<--
>>>>>>> Hit:1 http://security.debian.org stretch/updates InRelease
>>>>>>> Ign:2 http://ftp.de.debian.org/debian stretch InRelease
>>>>>>> Hit:3 http://ftp.de.debian.org/debian stretch-updates InRelease
>>>>>>> Hit:4 http://ftp.de.debian.org/debian stretch Release
>>>>>>> E: Dynamic MMap ran out of room. Please increase the size of
>>>>>>> APT::Cache-Start. Current value: 25165824. (man 5 apt.conf)
>>>>>>> qemu: uncaught target signal 11 (Segmentation fault) - core
>>>>>>> dumped Segmentation fault 8<--
>>>>>>>
>>>>>>> I have no information, why exactly the room could not be
>>>>>>> re-sized on this system, but it would be better to increase the
>>>>>>> initial room size for apt. This patch increases the default apt
>>>>>>> cache twice.
>>>>>>
>>>>>> 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657085
>>>>>>
>>>>>> Missed :-(
>>>>>
>>>>> What is your conclusion from that link and what does it mean for
>>>>> the patch?
>>>>>       
>>>>
>>>> This just the information I found about dynamic cache increasing.
>>>> Sometimes it could not work. Another fact is that increasing of
>>>> Cache-Limit doesn't help, so seems that mremap really doesn't work.
>>>>   
>>>>> I do not like adding magic numbers and changing the default
>>>>> config, especially if the whole reason is to work around a
>>>>> problem only found on outdated build hosts (3.4 really?)
>>>>
>>>> I'm not 100% sure that kernel 3.4 is the source of the problem.
>>>> Tried to investigate, but for now without results.
>>>>
>>>> But if you try to google line:
>>>>
>>>>      E: Dynamic MMap ran out of room. Please increase the size of
>>>> APT::Cache-Start
>>>>
>>>> There will be tons of search results, so such problem occurred not
>>>> only on my host.
>>>>
>>>>
>>>> The man page says:
>>>>
>>>> ...on systems with a lot of configured sources it should be
>>>> increased...
>>>>
>>>> so for me it makes sense to increase this room even if there is
>>>> only one problem report. It doesn't break anything.
>>>
>>> Oh yes it breaks the fact that we do not need to care about the
>>> value. If you hardcode one today you might be setting half the
>>> default after the next apt-update. ... because it is a magic number
>>> and not
>>>
>>> set(get()*2)
>>
>> Unfortunately this option is not get-able. It's defined as member of
>> class in source code, which is initialized on class creation. There
>> is no getter function to request this variable later.
>>
>> 8<--
>> apt-pkg/pkgcachegen.cc:
>>
>> map_filesize_t const MapStart = _config->FindI("APT::Cache-Start",
>> 24*1024*1024);
>> ...
>> return new DynamicMMap(*CacheF, Flags, MapStart, MapGrow, MapLimit);
>> 8<--
>>
>> Anyway, I noticed that build fails later on any 'apt' call in
>> 'buildchroot' and 'image' for this configuration.
>>
>> I was wrong with kernel version, it's 3.16 - the standard Jessie
>> kernel. So for now, I'd like to drop this patch and add supported
>> hosts matrix to Isar. This workaround could be described here.
> 
> I guess one could make such a workaround depending on "apt-get
> --version", to prevent it from causing undesired things in versions
> it is not for.

The problem occurred inside stretch chroot, while host kernel is from 
jessie. So there should be check for pair: apt version - kernel version: 
  if kernel is old, apt is new - then fallback to array-based cache.

Does this look like a hack for you, or not? :-)

Alex

> 
> Henning
> 
>> Alex
>>
>>>    
>>>> We can't require Isar users to always have up-to-dated host
>>>> systems. If this patch makes all Isar users with old kernels
>>>> happy, it's probably good for Isar in general :-)
>>>
>>> Sure, but there is a cost ... see previous point.
>>>      
>>>>>
>>>>> If this patch needs to go in, it is missing the cleanup step.
>>>>>       
>>>>
>>>> Sorry, what do you mean here by cleanup step?
>>>
>>> Sorry, misread the patch. I thought it placed a file in the rootfs.
>>>
>>> Henning
>>>    
>>>> Alex
>>>>   
>>>>> Henning
>>>>>       
>>>>>>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
>>>>>>> ---
>>>>>>>      meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4 +++-
>>>>>>>      1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
>>>>>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb index
>>>>>>> a38dd88..4cdefaa 100644 ---
>>>>>>> a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb +++
>>>>>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb @@ -187,7
>>>>>>> +187,9 @@ do_apt_update() {
>>>>>>>          E="${@bb.utils.export_proxies(d)}"
>>>>>>>          export DEBIAN_FRONTEND=noninteractive
>>>>>>> -    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
>>>>>>> +    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y \
>>>>>>> +                                      -o
>>>>>>> APT::Cache-Start=50331648 +
>>>>>>>          sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get
>>>>>>> dist-upgrade -y \ -o Debug::pkgProblemResolver=yes
>>>>>>>      }
>>>>>>>          
>>>>>>      
>>>>>       
>>>>   
>>>    
>>
> 

-- 
With best regards,
Alexander Smirnov

ilbers GmbH
Baierbrunner Str. 28c
D-81379 Munich
+49 (89) 122 67 24-0
http://ilbers.de/
Commercial register Munich, HRB 214197
General manager: Baurzhan Ismagulov

Re: [PATCH] isar-bootstrap: Increase cache room

[Henning Schild]

Am Tue, 8 May 2018 12:07:55 +0300
schrieb Alexander Smirnov <asmirnov@ilbers.de>:

> On 05/08/2018 11:56 AM, Henning Schild wrote:
> > Am Tue, 8 May 2018 10:56:55 +0300
> > schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >   
> >> On 05/07/2018 08:12 PM, Henning Schild wrote:  
> >>> Am Mon, 7 May 2018 19:48:16 +0300
> >>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >>>      
> >>>> Hi,
> >>>>
> >>>> On 05/07/2018 07:31 PM, Henning Schild wrote:  
> >>>>> Am Mon, 7 May 2018 18:57:36 +0300
> >>>>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >>>>>         
> >>>>>> On 05/07/2018 06:48 PM, Alexander Smirnov wrote:  
> >>>>>>> According to the man page for 'apt.conf', there are three
> >>>>>>> variables:
> >>>>>>>      - Cache-Start: initial size of mmap cache room
> >>>>>>>      - Cache-Grow: gap for dynamic mmap cache growth
> >>>>>>>      - Cache-Limit: maximal cache size after growth
> >>>>>>>
> >>>>>>> If dynamic resize of mmap region is not avaialbe, the apt uses
> >>>>>>> pre-allocated Cache-Start room [1] for mmap file.
> >>>>>>>
> >>>>>>> Building Isar on one of the Debian host with kernel 3.4, I got
> >>>>>>> the following problem for 'qemuarm64-stretch' configuration:
> >>>>>>>
> >>>>>>> 8<--
> >>>>>>> Hit:1 http://security.debian.org stretch/updates InRelease
> >>>>>>> Ign:2 http://ftp.de.debian.org/debian stretch InRelease
> >>>>>>> Hit:3 http://ftp.de.debian.org/debian stretch-updates
> >>>>>>> InRelease Hit:4 http://ftp.de.debian.org/debian stretch
> >>>>>>> Release E: Dynamic MMap ran out of room. Please increase the
> >>>>>>> size of APT::Cache-Start. Current value: 25165824. (man 5
> >>>>>>> apt.conf) qemu: uncaught target signal 11 (Segmentation
> >>>>>>> fault) - core dumped Segmentation fault 8<--
> >>>>>>>
> >>>>>>> I have no information, why exactly the room could not be
> >>>>>>> re-sized on this system, but it would be better to increase
> >>>>>>> the initial room size for apt. This patch increases the
> >>>>>>> default apt cache twice.  
> >>>>>>
> >>>>>> 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657085
> >>>>>>
> >>>>>> Missed :-(  
> >>>>>
> >>>>> What is your conclusion from that link and what does it mean for
> >>>>> the patch?
> >>>>>         
> >>>>
> >>>> This just the information I found about dynamic cache increasing.
> >>>> Sometimes it could not work. Another fact is that increasing of
> >>>> Cache-Limit doesn't help, so seems that mremap really doesn't
> >>>> work. 
> >>>>> I do not like adding magic numbers and changing the default
> >>>>> config, especially if the whole reason is to work around a
> >>>>> problem only found on outdated build hosts (3.4 really?)  
> >>>>
> >>>> I'm not 100% sure that kernel 3.4 is the source of the problem.
> >>>> Tried to investigate, but for now without results.
> >>>>
> >>>> But if you try to google line:
> >>>>
> >>>>      E: Dynamic MMap ran out of room. Please increase the size of
> >>>> APT::Cache-Start
> >>>>
> >>>> There will be tons of search results, so such problem occurred
> >>>> not only on my host.
> >>>>
> >>>>
> >>>> The man page says:
> >>>>
> >>>> ...on systems with a lot of configured sources it should be
> >>>> increased...
> >>>>
> >>>> so for me it makes sense to increase this room even if there is
> >>>> only one problem report. It doesn't break anything.  
> >>>
> >>> Oh yes it breaks the fact that we do not need to care about the
> >>> value. If you hardcode one today you might be setting half the
> >>> default after the next apt-update. ... because it is a magic
> >>> number and not
> >>>
> >>> set(get()*2)  
> >>
> >> Unfortunately this option is not get-able. It's defined as member
> >> of class in source code, which is initialized on class creation.
> >> There is no getter function to request this variable later.
> >>
> >> 8<--
> >> apt-pkg/pkgcachegen.cc:
> >>
> >> map_filesize_t const MapStart = _config->FindI("APT::Cache-Start",
> >> 24*1024*1024);
> >> ...
> >> return new DynamicMMap(*CacheF, Flags, MapStart, MapGrow,
> >> MapLimit); 8<--
> >>
> >> Anyway, I noticed that build fails later on any 'apt' call in
> >> 'buildchroot' and 'image' for this configuration.
> >>
> >> I was wrong with kernel version, it's 3.16 - the standard Jessie
> >> kernel. So for now, I'd like to drop this patch and add supported
> >> hosts matrix to Isar. This workaround could be described here.  
> > 
> > I guess one could make such a workaround depending on "apt-get
> > --version", to prevent it from causing undesired things in versions
> > it is not for.  
> 
> The problem occurred inside stretch chroot, while host kernel is from 
> jessie. So there should be check for pair: apt version - kernel
> version: if kernel is old, apt is new - then fallback to array-based
> cache.
> 
> Does this look like a hack for you, or not? :-)

Adding the magic-number argument is the real hack. The clearer we can
pin that down to a specific setup, the better. So check the
architecture and temperature as well, if it helps ;).

Henning

> Alex
> 
> > 
> > Henning
> >   
> >> Alex
> >>  
> >>>      
> >>>> We can't require Isar users to always have up-to-dated host
> >>>> systems. If this patch makes all Isar users with old kernels
> >>>> happy, it's probably good for Isar in general :-)  
> >>>
> >>> Sure, but there is a cost ... see previous point.
> >>>        
> >>>>>
> >>>>> If this patch needs to go in, it is missing the cleanup step.
> >>>>>         
> >>>>
> >>>> Sorry, what do you mean here by cleanup step?  
> >>>
> >>> Sorry, misread the patch. I thought it placed a file in the
> >>> rootfs.
> >>>
> >>> Henning
> >>>      
> >>>> Alex
> >>>>     
> >>>>> Henning
> >>>>>         
> >>>>>>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
> >>>>>>> ---
> >>>>>>>      meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4
> >>>>>>> +++- 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git
> >>>>>>> a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
> >>>>>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb index
> >>>>>>> a38dd88..4cdefaa 100644 ---
> >>>>>>> a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb +++
> >>>>>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb @@
> >>>>>>> -187,7 +187,9 @@ do_apt_update()
> >>>>>>> { E="${@bb.utils.export_proxies(d)}" export
> >>>>>>> DEBIAN_FRONTEND=noninteractive
> >>>>>>> -    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
> >>>>>>> +    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
> >>>>>>> \
> >>>>>>> +                                      -o
> >>>>>>> APT::Cache-Start=50331648 +
> >>>>>>>          sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get
> >>>>>>> dist-upgrade -y \ -o Debug::pkgProblemResolver=yes
> >>>>>>>      }
> >>>>>>>            
> >>>>>>        
> >>>>>         
> >>>>     
> >>>      
> >>  
> >   
> 

Re: [PATCH] isar-bootstrap: Increase cache room

[Alexander Smirnov]

On 05/08/2018 12:22 PM, Henning Schild wrote:
> Am Tue, 8 May 2018 12:07:55 +0300
> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> 
>> On 05/08/2018 11:56 AM, Henning Schild wrote:
>>> Am Tue, 8 May 2018 10:56:55 +0300
>>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
>>>    
>>>> On 05/07/2018 08:12 PM, Henning Schild wrote:
>>>>> Am Mon, 7 May 2018 19:48:16 +0300
>>>>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
>>>>>       
>>>>>> Hi,
>>>>>>
>>>>>> On 05/07/2018 07:31 PM, Henning Schild wrote:
>>>>>>> Am Mon, 7 May 2018 18:57:36 +0300
>>>>>>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
>>>>>>>          
>>>>>>>> On 05/07/2018 06:48 PM, Alexander Smirnov wrote:
>>>>>>>>> According to the man page for 'apt.conf', there are three
>>>>>>>>> variables:
>>>>>>>>>       - Cache-Start: initial size of mmap cache room
>>>>>>>>>       - Cache-Grow: gap for dynamic mmap cache growth
>>>>>>>>>       - Cache-Limit: maximal cache size after growth
>>>>>>>>>
>>>>>>>>> If dynamic resize of mmap region is not avaialbe, the apt uses
>>>>>>>>> pre-allocated Cache-Start room [1] for mmap file.
>>>>>>>>>
>>>>>>>>> Building Isar on one of the Debian host with kernel 3.4, I got
>>>>>>>>> the following problem for 'qemuarm64-stretch' configuration:
>>>>>>>>>
>>>>>>>>> 8<--
>>>>>>>>> Hit:1 http://security.debian.org stretch/updates InRelease
>>>>>>>>> Ign:2 http://ftp.de.debian.org/debian stretch InRelease
>>>>>>>>> Hit:3 http://ftp.de.debian.org/debian stretch-updates
>>>>>>>>> InRelease Hit:4 http://ftp.de.debian.org/debian stretch
>>>>>>>>> Release E: Dynamic MMap ran out of room. Please increase the
>>>>>>>>> size of APT::Cache-Start. Current value: 25165824. (man 5
>>>>>>>>> apt.conf) qemu: uncaught target signal 11 (Segmentation
>>>>>>>>> fault) - core dumped Segmentation fault 8<--
>>>>>>>>>
>>>>>>>>> I have no information, why exactly the room could not be
>>>>>>>>> re-sized on this system, but it would be better to increase
>>>>>>>>> the initial room size for apt. This patch increases the
>>>>>>>>> default apt cache twice.
>>>>>>>>
>>>>>>>> 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657085
>>>>>>>>
>>>>>>>> Missed :-(
>>>>>>>
>>>>>>> What is your conclusion from that link and what does it mean for
>>>>>>> the patch?
>>>>>>>          
>>>>>>
>>>>>> This just the information I found about dynamic cache increasing.
>>>>>> Sometimes it could not work. Another fact is that increasing of
>>>>>> Cache-Limit doesn't help, so seems that mremap really doesn't
>>>>>> work.
>>>>>>> I do not like adding magic numbers and changing the default
>>>>>>> config, especially if the whole reason is to work around a
>>>>>>> problem only found on outdated build hosts (3.4 really?)
>>>>>>
>>>>>> I'm not 100% sure that kernel 3.4 is the source of the problem.
>>>>>> Tried to investigate, but for now without results.
>>>>>>
>>>>>> But if you try to google line:
>>>>>>
>>>>>>       E: Dynamic MMap ran out of room. Please increase the size of
>>>>>> APT::Cache-Start
>>>>>>
>>>>>> There will be tons of search results, so such problem occurred
>>>>>> not only on my host.
>>>>>>
>>>>>>
>>>>>> The man page says:
>>>>>>
>>>>>> ...on systems with a lot of configured sources it should be
>>>>>> increased...
>>>>>>
>>>>>> so for me it makes sense to increase this room even if there is
>>>>>> only one problem report. It doesn't break anything.
>>>>>
>>>>> Oh yes it breaks the fact that we do not need to care about the
>>>>> value. If you hardcode one today you might be setting half the
>>>>> default after the next apt-update. ... because it is a magic
>>>>> number and not
>>>>>
>>>>> set(get()*2)
>>>>
>>>> Unfortunately this option is not get-able. It's defined as member
>>>> of class in source code, which is initialized on class creation.
>>>> There is no getter function to request this variable later.
>>>>
>>>> 8<--
>>>> apt-pkg/pkgcachegen.cc:
>>>>
>>>> map_filesize_t const MapStart = _config->FindI("APT::Cache-Start",
>>>> 24*1024*1024);
>>>> ...
>>>> return new DynamicMMap(*CacheF, Flags, MapStart, MapGrow,
>>>> MapLimit); 8<--
>>>>
>>>> Anyway, I noticed that build fails later on any 'apt' call in
>>>> 'buildchroot' and 'image' for this configuration.
>>>>
>>>> I was wrong with kernel version, it's 3.16 - the standard Jessie
>>>> kernel. So for now, I'd like to drop this patch and add supported
>>>> hosts matrix to Isar. This workaround could be described here.
>>>
>>> I guess one could make such a workaround depending on "apt-get
>>> --version", to prevent it from causing undesired things in versions
>>> it is not for.
>>
>> The problem occurred inside stretch chroot, while host kernel is from
>> jessie. So there should be check for pair: apt version - kernel
>> version: if kernel is old, apt is new - then fallback to array-based
>> cache.
>>
>> Does this look like a hack for you, or not? :-)
> 
> Adding the magic-number argument is the real hack. The clearer we can
> pin that down to a specific setup, the better. So check the
> architecture and temperature as well, if it helps ;).

No magic numbers, the parameter: -o APT::Cache-Fallback="1" works as well.

So, thing like:

if target=stretch and uname=old; then
    apt-fallback=1
fi

would be OK from your POV?

Alex

> 
> Henning
> 
>> Alex
>>
>>>
>>> Henning
>>>    
>>>> Alex
>>>>   
>>>>>       
>>>>>> We can't require Isar users to always have up-to-dated host
>>>>>> systems. If this patch makes all Isar users with old kernels
>>>>>> happy, it's probably good for Isar in general :-)
>>>>>
>>>>> Sure, but there is a cost ... see previous point.
>>>>>         
>>>>>>>
>>>>>>> If this patch needs to go in, it is missing the cleanup step.
>>>>>>>          
>>>>>>
>>>>>> Sorry, what do you mean here by cleanup step?
>>>>>
>>>>> Sorry, misread the patch. I thought it placed a file in the
>>>>> rootfs.
>>>>>
>>>>> Henning
>>>>>       
>>>>>> Alex
>>>>>>      
>>>>>>> Henning
>>>>>>>          
>>>>>>>>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
>>>>>>>>> ---
>>>>>>>>>       meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4
>>>>>>>>> +++- 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git
>>>>>>>>> a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
>>>>>>>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb index
>>>>>>>>> a38dd88..4cdefaa 100644 ---
>>>>>>>>> a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb +++
>>>>>>>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb @@
>>>>>>>>> -187,7 +187,9 @@ do_apt_update()
>>>>>>>>> { E="${@bb.utils.export_proxies(d)}" export
>>>>>>>>> DEBIAN_FRONTEND=noninteractive
>>>>>>>>> -    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
>>>>>>>>> +    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
>>>>>>>>> \
>>>>>>>>> +                                      -o
>>>>>>>>> APT::Cache-Start=50331648 +
>>>>>>>>>           sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get
>>>>>>>>> dist-upgrade -y \ -o Debug::pkgProblemResolver=yes
>>>>>>>>>       }
>>>>>>>>>             
>>>>>>>>         
>>>>>>>          
>>>>>>      
>>>>>       
>>>>   
>>>    
>>
> 

-- 
With best regards,
Alexander Smirnov

ilbers GmbH
Baierbrunner Str. 28c
D-81379 Munich
+49 (89) 122 67 24-0
http://ilbers.de/
Commercial register Munich, HRB 214197
General manager: Baurzhan Ismagulov

Re: [PATCH] isar-bootstrap: Increase cache room

[Henning Schild]

Am Tue, 8 May 2018 12:27:01 +0300
schrieb Alexander Smirnov <asmirnov@ilbers.de>:

> On 05/08/2018 12:22 PM, Henning Schild wrote:
> > Am Tue, 8 May 2018 12:07:55 +0300
> > schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >   
> >> On 05/08/2018 11:56 AM, Henning Schild wrote:  
> >>> Am Tue, 8 May 2018 10:56:55 +0300
> >>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >>>      
> >>>> On 05/07/2018 08:12 PM, Henning Schild wrote:  
> >>>>> Am Mon, 7 May 2018 19:48:16 +0300
> >>>>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >>>>>         
> >>>>>> Hi,
> >>>>>>
> >>>>>> On 05/07/2018 07:31 PM, Henning Schild wrote:  
> >>>>>>> Am Mon, 7 May 2018 18:57:36 +0300
> >>>>>>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >>>>>>>            
> >>>>>>>> On 05/07/2018 06:48 PM, Alexander Smirnov wrote:  
> >>>>>>>>> According to the man page for 'apt.conf', there are three
> >>>>>>>>> variables:
> >>>>>>>>>       - Cache-Start: initial size of mmap cache room
> >>>>>>>>>       - Cache-Grow: gap for dynamic mmap cache growth
> >>>>>>>>>       - Cache-Limit: maximal cache size after growth
> >>>>>>>>>
> >>>>>>>>> If dynamic resize of mmap region is not avaialbe, the apt
> >>>>>>>>> uses pre-allocated Cache-Start room [1] for mmap file.
> >>>>>>>>>
> >>>>>>>>> Building Isar on one of the Debian host with kernel 3.4, I
> >>>>>>>>> got the following problem for 'qemuarm64-stretch'
> >>>>>>>>> configuration:
> >>>>>>>>>
> >>>>>>>>> 8<--
> >>>>>>>>> Hit:1 http://security.debian.org stretch/updates InRelease
> >>>>>>>>> Ign:2 http://ftp.de.debian.org/debian stretch InRelease
> >>>>>>>>> Hit:3 http://ftp.de.debian.org/debian stretch-updates
> >>>>>>>>> InRelease Hit:4 http://ftp.de.debian.org/debian stretch
> >>>>>>>>> Release E: Dynamic MMap ran out of room. Please increase the
> >>>>>>>>> size of APT::Cache-Start. Current value: 25165824. (man 5
> >>>>>>>>> apt.conf) qemu: uncaught target signal 11 (Segmentation
> >>>>>>>>> fault) - core dumped Segmentation fault 8<--
> >>>>>>>>>
> >>>>>>>>> I have no information, why exactly the room could not be
> >>>>>>>>> re-sized on this system, but it would be better to increase
> >>>>>>>>> the initial room size for apt. This patch increases the
> >>>>>>>>> default apt cache twice.  
> >>>>>>>>
> >>>>>>>> 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657085
> >>>>>>>>
> >>>>>>>> Missed :-(  
> >>>>>>>
> >>>>>>> What is your conclusion from that link and what does it mean
> >>>>>>> for the patch?
> >>>>>>>            
> >>>>>>
> >>>>>> This just the information I found about dynamic cache
> >>>>>> increasing. Sometimes it could not work. Another fact is that
> >>>>>> increasing of Cache-Limit doesn't help, so seems that mremap
> >>>>>> really doesn't work.  
> >>>>>>> I do not like adding magic numbers and changing the default
> >>>>>>> config, especially if the whole reason is to work around a
> >>>>>>> problem only found on outdated build hosts (3.4 really?)  
> >>>>>>
> >>>>>> I'm not 100% sure that kernel 3.4 is the source of the problem.
> >>>>>> Tried to investigate, but for now without results.
> >>>>>>
> >>>>>> But if you try to google line:
> >>>>>>
> >>>>>>       E: Dynamic MMap ran out of room. Please increase the
> >>>>>> size of APT::Cache-Start
> >>>>>>
> >>>>>> There will be tons of search results, so such problem occurred
> >>>>>> not only on my host.
> >>>>>>
> >>>>>>
> >>>>>> The man page says:
> >>>>>>
> >>>>>> ...on systems with a lot of configured sources it should be
> >>>>>> increased...
> >>>>>>
> >>>>>> so for me it makes sense to increase this room even if there is
> >>>>>> only one problem report. It doesn't break anything.  
> >>>>>
> >>>>> Oh yes it breaks the fact that we do not need to care about the
> >>>>> value. If you hardcode one today you might be setting half the
> >>>>> default after the next apt-update. ... because it is a magic
> >>>>> number and not
> >>>>>
> >>>>> set(get()*2)  
> >>>>
> >>>> Unfortunately this option is not get-able. It's defined as member
> >>>> of class in source code, which is initialized on class creation.
> >>>> There is no getter function to request this variable later.
> >>>>
> >>>> 8<--
> >>>> apt-pkg/pkgcachegen.cc:
> >>>>
> >>>> map_filesize_t const MapStart =
> >>>> _config->FindI("APT::Cache-Start", 24*1024*1024);
> >>>> ...
> >>>> return new DynamicMMap(*CacheF, Flags, MapStart, MapGrow,
> >>>> MapLimit); 8<--
> >>>>
> >>>> Anyway, I noticed that build fails later on any 'apt' call in
> >>>> 'buildchroot' and 'image' for this configuration.
> >>>>
> >>>> I was wrong with kernel version, it's 3.16 - the standard Jessie
> >>>> kernel. So for now, I'd like to drop this patch and add supported
> >>>> hosts matrix to Isar. This workaround could be described here.  
> >>>
> >>> I guess one could make such a workaround depending on "apt-get
> >>> --version", to prevent it from causing undesired things in
> >>> versions it is not for.  
> >>
> >> The problem occurred inside stretch chroot, while host kernel is
> >> from jessie. So there should be check for pair: apt version -
> >> kernel version: if kernel is old, apt is new - then fallback to
> >> array-based cache.
> >>
> >> Does this look like a hack for you, or not? :-)  
> > 
> > Adding the magic-number argument is the real hack. The clearer we
> > can pin that down to a specific setup, the better. So check the
> > architecture and temperature as well, if it helps ;).  
> 
> No magic numbers, the parameter: -o APT::Cache-Fallback="1" works as
> well.
> 
> So, thing like:
> 
> if target=stretch and uname=old; then
>     apt-fallback=1
> fi
> 
> would be OK from your POV?

Yes.

Henning

> Alex
> 
> > 
> > Henning
> >   
> >> Alex
> >>  
> >>>
> >>> Henning
> >>>      
> >>>> Alex
> >>>>     
> >>>>>         
> >>>>>> We can't require Isar users to always have up-to-dated host
> >>>>>> systems. If this patch makes all Isar users with old kernels
> >>>>>> happy, it's probably good for Isar in general :-)  
> >>>>>
> >>>>> Sure, but there is a cost ... see previous point.
> >>>>>           
> >>>>>>>
> >>>>>>> If this patch needs to go in, it is missing the cleanup step.
> >>>>>>>            
> >>>>>>
> >>>>>> Sorry, what do you mean here by cleanup step?  
> >>>>>
> >>>>> Sorry, misread the patch. I thought it placed a file in the
> >>>>> rootfs.
> >>>>>
> >>>>> Henning
> >>>>>         
> >>>>>> Alex
> >>>>>>        
> >>>>>>> Henning
> >>>>>>>            
> >>>>>>>>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
> >>>>>>>>> ---
> >>>>>>>>>       meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4
> >>>>>>>>> +++- 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>>>>>
> >>>>>>>>> diff --git
> >>>>>>>>> a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
> >>>>>>>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb index
> >>>>>>>>> a38dd88..4cdefaa 100644 ---
> >>>>>>>>> a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb +++
> >>>>>>>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb @@
> >>>>>>>>> -187,7 +187,9 @@ do_apt_update()
> >>>>>>>>> { E="${@bb.utils.export_proxies(d)}" export
> >>>>>>>>> DEBIAN_FRONTEND=noninteractive
> >>>>>>>>> -    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update
> >>>>>>>>> -y
> >>>>>>>>> +    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update
> >>>>>>>>> -y \
> >>>>>>>>> +                                      -o
> >>>>>>>>> APT::Cache-Start=50331648 +
> >>>>>>>>>           sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get
> >>>>>>>>> dist-upgrade -y \ -o Debug::pkgProblemResolver=yes
> >>>>>>>>>       }
> >>>>>>>>>               
> >>>>>>>>           
> >>>>>>>            
> >>>>>>        
> >>>>>         
> >>>>     
> >>>      
> >>  
> >   
> 

Re: [PATCH] isar-bootstrap: Increase cache room

[Claudius Heine]

Hi Alex,

On 2018-05-07 17:48, Alexander Smirnov wrote:
> According to the man page for 'apt.conf', there are three variables:
>   - Cache-Start: initial size of mmap cache room
>   - Cache-Grow: gap for dynamic mmap cache growth
>   - Cache-Limit: maximal cache size after growth
> 
> If dynamic resize of mmap region is not avaialbe, the apt uses
> pre-allocated Cache-Start room [1] for mmap file.
> 
> Building Isar on one of the Debian host with kernel 3.4, I got the
> following problem for 'qemuarm64-stretch' configuration:
> 
> 8<--
> Hit:1 http://security.debian.org stretch/updates InRelease
> Ign:2 http://ftp.de.debian.org/debian stretch InRelease
> Hit:3 http://ftp.de.debian.org/debian stretch-updates InRelease
> Hit:4 http://ftp.de.debian.org/debian stretch Release
> E: Dynamic MMap ran out of room. Please increase the size of APT::Cache-Start. Current value: 25165824. (man 5 apt.conf)
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
> 8<--
> 
> I have no information, why exactly the room could not be re-sized on this
> system, but it would be better to increase the initial room size for apt.
> This patch increases the default apt cache twice.
> 
> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
> ---
>   meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
> index a38dd88..4cdefaa 100644
> --- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
> +++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
> @@ -187,7 +187,9 @@ do_apt_update() {
>   
>       E="${@bb.utils.export_proxies(d)}"
>       export DEBIAN_FRONTEND=noninteractive
> -    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
> +    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y \
> +                                      -o APT::Cache-Start=50331648
> +

If this is needed, then it might be better to set this option in a 
apt-preferences file with the "DISTRO_APT_PREFERENCES" variable.

Cheers,
Claudius

>       sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get dist-upgrade -y \
>                                         -o Debug::pkgProblemResolver=yes
>   }
> 

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

Re: [PATCH] isar-bootstrap: Increase cache room

[Claudius Heine]

On 2018-05-14 10:54, [ext] Claudius Heine wrote:
> Hi Alex,
> 
> On 2018-05-07 17:48, Alexander Smirnov wrote:
>> According to the man page for 'apt.conf', there are three variables:
>>   - Cache-Start: initial size of mmap cache room
>>   - Cache-Grow: gap for dynamic mmap cache growth
>>   - Cache-Limit: maximal cache size after growth
>>
>> If dynamic resize of mmap region is not avaialbe, the apt uses
>> pre-allocated Cache-Start room [1] for mmap file.
>>
>> Building Isar on one of the Debian host with kernel 3.4, I got the
>> following problem for 'qemuarm64-stretch' configuration:
>>
>> 8<--
>> Hit:1 http://security.debian.org stretch/updates InRelease
>> Ign:2 http://ftp.de.debian.org/debian stretch InRelease
>> Hit:3 http://ftp.de.debian.org/debian stretch-updates InRelease
>> Hit:4 http://ftp.de.debian.org/debian stretch Release
>> E: Dynamic MMap ran out of room. Please increase the size of 
>> APT::Cache-Start. Current value: 25165824. (man 5 apt.conf)
>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>> Segmentation fault
>> 8<--
>>
>> I have no information, why exactly the room could not be re-sized on this
>> system, but it would be better to increase the initial room size for apt.
>> This patch increases the default apt cache twice.
>>
>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
>> ---
>>   meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb 
>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
>> index a38dd88..4cdefaa 100644
>> --- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
>> +++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
>> @@ -187,7 +187,9 @@ do_apt_update() {
>>       E="${@bb.utils.export_proxies(d)}"
>>       export DEBIAN_FRONTEND=noninteractive
>> -    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
>> +    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y \
>> +                                      -o APT::Cache-Start=50331648
>> +
> 
> If this is needed, then it might be better to set this option in a 
> apt-preferences file with the "DISTRO_APT_PREFERENCES" variable.

Ah, sorry. I was wrong. I meant setting this is isar-apt.conf.

> 
> Cheers,
> Claudius
> 
>>       sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get dist-upgrade -y \
>>                                         -o Debug::pkgProblemResolver=yes
>>   }
>>
> 

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

Re: [PATCH] isar-bootstrap: Increase cache room

[Alexander Smirnov]

Hi,

On 05/14/2018 12:11 PM, Claudius Heine wrote:
> On 2018-05-14 10:54, [ext] Claudius Heine wrote:
>> Hi Alex,
>>
>> On 2018-05-07 17:48, Alexander Smirnov wrote:
>>> According to the man page for 'apt.conf', there are three variables:
>>>   - Cache-Start: initial size of mmap cache room
>>>   - Cache-Grow: gap for dynamic mmap cache growth
>>>   - Cache-Limit: maximal cache size after growth
>>>
>>> If dynamic resize of mmap region is not avaialbe, the apt uses
>>> pre-allocated Cache-Start room [1] for mmap file.
>>>
>>> Building Isar on one of the Debian host with kernel 3.4, I got the
>>> following problem for 'qemuarm64-stretch' configuration:
>>>
>>> 8<--
>>> Hit:1 http://security.debian.org stretch/updates InRelease
>>> Ign:2 http://ftp.de.debian.org/debian stretch InRelease
>>> Hit:3 http://ftp.de.debian.org/debian stretch-updates InRelease
>>> Hit:4 http://ftp.de.debian.org/debian stretch Release
>>> E: Dynamic MMap ran out of room. Please increase the size of 
>>> APT::Cache-Start. Current value: 25165824. (man 5 apt.conf)
>>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>>> Segmentation fault
>>> 8<--
>>>
>>> I have no information, why exactly the room could not be re-sized on 
>>> this
>>> system, but it would be better to increase the initial room size for 
>>> apt.
>>> This patch increases the default apt cache twice.
>>>
>>> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
>>> ---
>>>   meta/recipes-core/isar-bootstrap/isar-bootstrap.bb | 4 +++-
>>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb 
>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
>>> index a38dd88..4cdefaa 100644
>>> --- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
>>> +++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.bb
>>> @@ -187,7 +187,9 @@ do_apt_update() {
>>>       E="${@bb.utils.export_proxies(d)}"
>>>       export DEBIAN_FRONTEND=noninteractive
>>> -    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y
>>> +    sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get update -y \
>>> +                                      -o APT::Cache-Start=50331648
>>> +
>>
>> If this is needed, then it might be better to set this option in a 
>> apt-preferences file with the "DISTRO_APT_PREFERENCES" variable.
> 
> Ah, sorry. I was wrong. I meant setting this is isar-apt.conf.
> 

This option is needed only for isar build and should be dropped from 
target rootfs, because target rootfs has correct versions of apt and 
kernel. So please see v2 version of this patch: I've added the temporary 
conf file which is removed during rootfs creation. I found this easier 
than 'sedding' isar-apt.conf.

Alex

>>
>> Cheers,
>> Claudius
>>
>>>       sudo -E chroot "${ROOTFSDIR}" /usr/bin/apt-get dist-upgrade -y \
>>>                                         -o Debug::pkgProblemResolver=yes
>>>   }
>>>
>>
>