Re: ISAR schroot mountpoints when running in container

[Jan Kiszka <jan.kiszka@siemens.com>]

On 01.07.22 12:30, Bezdeka, Florian wrote:
> On Fri, 2022-07-01 at 13:23 +0300, Uladzimir Bely wrote:
>> In the email from Friday, 1 July 2022 12:11:42 +03 user Moessbauer, Felix 
>> wrote:
>>> Hi,
>>>
>>> as we now have sbuild in ISAR next, first users stumble upon issues when
>>> running the kas docker image in the gitlab-ci. This requires additional
>>> mountpoints, as the schroot itself uses overlayfs and stacking two
>>> overlayfs is not possible. By that, you have to mount the overlay from the
>>> host.
>>>
>>> The kas-container script already has support for that, but it lacks
>>> documentation on how to configure this manually. In short: The following
>>> mountpoint has to be added (as RW): /var/lib/schroot/union/overlay
>>>
>>> As this is neither an ISAR issue, nor a KAS issue per-se, I send this to
>>> both lists.
>>>
>>
>> Hello.
>>
>> Yes, this overlayfs-over-overlayfs issue can be solved by something like 
>>
>> `volumes = ["/path/to/overlay:/var/lib/schroot/union/overlay"]`
>>
>> placed to `/etc/gitlab-runner/config.toml`, as mentioned in 'sbuild' series 
>> cover-letter
> 
> Oh no. That's going to kill a lot of gitlab-ci setups. Even kas-
> container based environments (often used as local development
> environment) will need adjustments. Uncool.
> 
> Anyway, I will try to look into the kas-container script. Let's hope
> there is a simple solution for adding one more mount.
> 

When designing that, we should also have an eye on the optimization of
mapping build/tmp/ onto a tmpfs mount inside the container.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux