Re: wic missing squashfs

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

On 19.12.24 13:00, 'MOESSBAUER, Felix' via isar-users wrote:
> On Wed, 2024-12-18 at 11:12 -0800, Cedric Hombourger wrote:
>>
>>
>> Le mercredi 18 décembre 2024 à 11:09:35 UTC+1, MOESSBAUER, Felix a
>> écrit :
>>> On Tue, 2024-12-17 at 12:50 -0800, Cedric Hombourger wrote:
>>>>
>>>>
>>>> Le jeudi 5 décembre 2024 à 15:55:35 UTC+1, Uladzimir Bely a
>>>> écrit :
>>>>> On Thu, 2024-12-05 at 06:47 -0800, Stephen Ecker wrote:
>>>>>> I keep getting this error:
>>>>>>
>>>>>> | ERROR: A native program mksquashfs required to build the
>>>>>> image
>>>>>> was
>>>>>> not found (see details above).
>>>>>> |
>>>>>> | Please make sure wic-tools have squashfs-tools-native in
>>>>>> its
>>>>>> DEPENDS, build it with 'bitbake wic-tools' and try again.
>>>>>> |
>>>>>>
>>>>>> I have tried adding squashfs-tools-native to
>>>>>> WKS_FILE_DEPENDS,
>>>>>> but I
>>>>>> get the same error.  any thoughts?
>>>>>
>>>>> Hello.
>>>>>
>>>>> Try using IMAGER_INSTALL:wic += "squashfs-tools"
>>>>
>>>>
>>>> I have recently run into this (and did this in my layer)
>>>>
>>>> IMO the wic imager should pre-install packages for everything
>>>> file-
>>>> systems it supports / usable in .wks files. I was going to submit
>>>> a
>>>> patch along these lines so that I could get rid of this directive
>>>> in
>>>> my downstream layer. Should I? This would improve usability /
>>>> user-
>>>> experience if you ask me. 
>>>
>>> Hmm... I tend to disagree. Installing these tools takes time and
>>> increases the attack surface of the build itself. By that we
>>> basically
>>> penalize all users just because it makes things a bit easier for
>>> some.
>>
>>
>> attack surface? isn't the sbuild environment of the imager ephemeral?
>> moreover, users are encouraged to build within a (kas-)container,
>> this adds another line of defense
> 
> Yes, my concern is probably more of a theoretical nature. More packages
> always increases the risk, but here it probably can be neglected.
> 
>>
>> as for build-times, we can quantify but I believe it is negligible.
>> little gains but increased pains (for some at least)?  
> 
> If we can come up with a not too long list of packages that are
> convenient for imaging, this trade off also might be fine.
> 
>>
>> I believe we are reaching out to developers with varying levels of
>> knowledge and that's ok because some just want to focus on their
>> application development duties and do not care about the platform-
>> level stuff, yet they have to use the platform tools (bitbake / isar)
>> to get their job done. From that perspective, I would vote for
>> lowering the barrier of entry
> 
> Agree.
> 
>>  
>> of course one approach could be to add some pre-processing task where
>> we parse the wks file upfront to check file-systems that were
>> selected (possibly with some shortcuts to avoid re-implementing a
>> full wks parser in isar/meta/imagetypes*) but that sounds like adding
>> unnecessary complexity.
> 
> If the cost of including the packages is high, we likely need this. If
> not, it is just over engineering.
> 

I would recommend aligning with OE/yocto here, and it appears to me like
they demand quite a few tools by default:

https://github.com/openembedded/openembedded-core/blob/f642edb006a8c16dbe45681afe547eabfae17073/meta/classes-recipe/image_types_wic.bbclass#L112

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/e1f96419-fac8-4b21-bf7b-420f28a1ffb8%40siemens.com.