Re: Overview over my outstanding patches

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

On 2018-05-24 16:50, Claudius Heine wrote:
> Hi Jan,
> 
> On 2018-05-24 15:38, Jan Kiszka wrote:
>> On 2018-05-24 15:34, [ext] Claudius Heine wrote:
>>> Hi,
>>>
>>> On 2018-05-24 11:21, [ext] Claudius Heine wrote:
>>>> Hi Alex,
>>>>
>>>> On 2018-05-14 15:47, Alexander Smirnov wrote:
>>>>> Remaining:
>>>>> ==========
>>>>>    - meta-isar/isar-image-base: added removal of qemu-*-static
>>>>> binaries:
>>>>>
>>>>> Here is the question about case, when user wants to install
>>>>> qemu-user-static package to target rootfs.
>>>>
>>>> If the user wants to install qemu-user-static to the image, apt
>>>> overwrites the one already there and then the linux kernel complains
>>>> about infinite symlink since it wants to execute the new foreign
>>>> 'qemu-*-static' binary with the foreign 'qemu-*-static' binary on
>>>> and on.
>>>>
>>>> Installing qemu-user-static is simply forbidden until qemu-debootstrap
>>>> changes the deployment path and binfmt settings to avoid this conflict.
>>>
>>> With Hennings help we further investigated this. The binfmt_misc flag
>>> 'F' would prevent this issue [1]. So installing qemu-user-static could
>>> be possible if that flag is used.
>>
>> Do we have that under our control, or would we have to patch the
>> upstream binfmt debian package to tune that flag?
> 
> I have to investigate that. On my sid debian host that flag was set.
> I think I can see this in the diff between the /var/lib/binfmts/qemu-arm
> from the kas container and my host:
> 
> --- kas-qemu-arm    2018-05-24 16:48:31.998958282 +0200
> +++ /var/lib/binfmts/qemu-arm    2018-05-22 15:02:13.580660019 +0200
> @@ -7,3 +7,4 @@
> 
>  yes
> 
> +yes
> 
> I suppose this yes is were the 'F' flag is set. Currently I don't know
> how those files are generated. I can take a look into it.

There is the binfmt-support package, and its update-binfmts seems to set
that stuff.

Jan