[Buildroot] [PATCH] configs/raspberrypi3_defconfig: fix filesystem size
leon.anavi at konsulko.com
Mon Jul 2 16:35:10 UTC 2018
On 2.07.2018 19:17, Yann E. MORIN wrote:
> Ricardo, All,
> On 2018-07-02 00:50 -0300, Ricardo Martincoski spake thusly:
>> On Sun, Jul 01, 2018 at 06:28 AM, Leon Anavi wrote:
>>> On 1.07.2018 12:22, Yann E. MORIN wrote:
>>>> On 2018-06-30 21:11 +0200, Yann E. MORIN spake thusly:
>>>>> On 2018-06-30 21:03 +0300, Leon Anavi spake thusly:
>>>>>> Thank you for the feedback. I have experienced this issue while building
>>>>>> branch master on Ubuntu 16.04. As discussed in the IRC channel on Friday
>>>>>> the same issue has been reproduced in the CI, Job #78257653 triggered by
>>>>>> Thomas Petazzoni: https://gitlab.com/buildroot.org/buildroot/-/jobs/78257653
>>>> Could you please provide a bit more details on your buildsystem: what is
>>>> the filesystem you use to build?
>>> The filesystem of my build machine is ext4. More details about the
>>> Ubuntu version:
>>> Distributor ID: Ubuntu
>>> Description: Ubuntu 16.04.4 LTS
>>> Release: 16.04
>>> Codename: xenial
>> I reproduced the error here:
>> system: Ubuntu 18.04 LTS
>> filesystem: ext4
>> commit: 78af2a6362 (the same from the CI build mentioned above)
>> wrapped error message:
>> Copying files into the device: __populate_fs: Could not allocate block in ext2
>> filesystem while writing file "busybox"
> I also was ultimately able toreproduce on my machine.
> What pwuzzles me is that a did a build that was successful. Then I
> cleaned and did a rebuilt form scratch and it failed. And the failing
> file is never the same, which leads me to think it depends a lot of the
> order of files as returned by readdir()...
> And in any way, the size is already approaching the limit, so it does
> make sense to increase it.
>> From the CI url mentioned above it seems the same occurs also in the GitLab
>> runners, so I started a few builds. Note: please trust the log and ignore the
>> job status, all jobs failed when uploading artifacts, probably my mistake in the
>> hacked .gitlab-ci.yml.
>> 2018.05  ok
>> 2018.05  ok
>> 2018.05-140-g8b0fd3cb49  fail
>> 2018.05-240-g43ebb35e9b  fail
>> 2018.05-340-g9f26e91cc5  fail
>> 2018.05-440-gc0d19a2083  fail
>> 2018.05-505-g78af2a6362  fail
>> 2018.05-559-g855295b658  fail
>>  https://gitlab.com/buildroot.org/buildroot/-/jobs/71910855
>>  https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/78670469
>>  https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/78670740
>>  https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/78671047
>>  https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/78671078
>>  https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/78671235
>>  https://gitlab.com/buildroot.org/buildroot/-/jobs/78257653
>>  https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/78670542
> OK, so what is weird is that we all noticed different failing files or
> directories (busybox for Ricardo, shm for me, others for Leon), while
> the Gitlab-CI runners all failed on nfs_check, whether on Ricardo's or
> the main Buildroot jobs...
> Anyway, as I said; let's increase the size.
Thank you very much for the deep investigation and for sharing the
results. I hope that by merging my patch for increasing the size this
issue will not affect anyone in future.
> Yann E. MORIN.
More information about the buildroot