wic missing squashfs

[Stephen Ecker]

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?

[Uladzimir Bely]

Hello.

Try using IMAGER_INSTALL:wic += "squashfs-tools"

> --
> 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+...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/isar-users/2839131c-156b-4007-b424-854d267cb0abn%40googlegroups.com
> .

--
Best regards,
Uladzimir.

[Cedric Hombourger]

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. 

Thanks

Cedric

[MOESSBAUER, Felix]

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.

Best regards,
Felix

>
> Thanks
> Cedric
>
> >
> > > --
> > > 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+...@googlegroups.com.
> > > To view this discussion visit
> > > https://groups.google.com/d/msgid/isar-users/2839131c-156b-4007-b424-854d267cb0abn%40googlegroups.com
> >
> > > .
> >
> > --
> > Best regards,
> > Uladzimir.
> >
> >
> >

--
Siemens AG, Technology
Linux Expert Center

[Cedric Hombourger]

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

as for build-times, we can quantify but I believe it is negligible.

little gains but increased pains (for some at least)?  

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

 

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.

anyhow, that's my view of the matter.

[MOESSBAUER, Felix]

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.

Best regards,
Felix

[Roberto A. Foglietta]

On Thu, 19 Dec 2024 at 13:01, 'MOESSBAUER, Felix' via isar-users
<isar-...@googlegroups.com> wrote:
>
> On Wed, 2024-12-18 at 11:12 -0800, Cedric Hombourger wrote:
> >

> >
> > 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.
>

Dude, **over engineering**... seriously?

Making your {customers, comrades, girlfriend} happy in letting them
live a smooth life without begging for your support can be considered
"over engineering" or a form of?

Think about it, all the time you need. Twice before answering, seriously.

Best regards,
--
Roberto A. Foglietta
+49.176.274.75.661
+39.349.33.30.697

[Jan Kiszka]

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