From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6662301766535610368 Date: Tue, 26 Feb 2019 05:39:17 -0800 (PST) From: cedric_hombourger@mentor.com To: isar-users Message-Id: <0e1f08cc-2119-4677-9aff-16f5bf012950@googlegroups.com> In-Reply-To: <20190226133148.GC17750@iiotirae> References: <20190226133148.GC17750@iiotirae> Subject: Re: [andreas.r...@siemens.com: Re: Fwd: [PATCH 1/1] meta/ext4-img: refactor to fit current image creation methods] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_789_1369291565.1551188358043" X-Google-Token: EIWD1eMFl1OrF69bR4k0 X-Google-IP: 95.176.90.117 X-TUID: qck6r8iv/0pv ------=_Part_789_1369291565.1551188358043 Content-Type: multipart/alternative; boundary="----=_Part_790_775591355.1551188358044" ------=_Part_790_775591355.1551188358044 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Tuesday, February 26, 2019 at 2:33:28 PM UTC+1, Andreas Reichel wrote: > > > We (at least me) have no scenario where we really build update artifacts > with isar. One important question is, if the ext4 image is exactly the > size of its contents or if it is the final partition size. If it is > exactly the size of its contents only, it cannot be used as an update > artifact because the resulting rootfs would have 0 bytes free and likely > won't boot. > > postinstall steps can be used to "resize2fs" the file-system after it was installed > > So I would go Henning's way to extract the partition images... > > It sure works. I however don't see much harm in keeping the ext4_img class I would not expect much maintenance overhead there... > Also we already have wic dependencies like sfdisk etc installed, where > we can dump partition lists and use grep and dd. > > Andreas > > > Henning > > > > > Jan > > > > > > > > Date: Tue, 26 Feb 2019 13:12:18 +0100 > > From: Henning Schild > > > To: "[ext] Jan Kiszka" > > > CC: cedric_h...@mentor.com , isar-users < > isar-...@googlegroups.com >, > > Andreas Reichel > > > Subject: Re: [PATCH 1/1] meta/ext4-img: refactor to fit current image > > creation methods > > X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) > > > > Am Tue, 26 Feb 2019 12:56:20 +0100 > > schrieb "[ext] Jan Kiszka" >: > > > > > On 26.02.19 12:35, cedric_h...@mentor.com wrote: > > > > Hi Henning, > > > > > > > > One use-case on our side is the generation of SWUpdate image. Our > > > > helper class uses do_ext4_image to generate the file-system image > > > > we later embed into the .swu file > > > > > > Andreas, how do you address that scenario for upstream SWUpdate > > > support? > > > > I guess a valid way would be to have a task after do_wic which will > > extract all raw partitions if enabled. It is kind of stupid but if we > > can not change wic we better build around and reuse instead of > > reimplement. > > > > Henning > > > > > Jan > > > > > > > > Date: Tue, 26 Feb 2019 12:56:20 +0100 > > From: Jan Kiszka > > > To: cedric_h...@mentor.com , isar-users < > isar-...@googlegroups.com >, > > Andreas Reichel > > > Subject: Re: [PATCH 1/1] meta/ext4-img: refactor to fit current image > > creation methods > > User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) > > Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 > > > > On 26.02.19 12:35, cedric_h...@mentor.com wrote: > > > Hi Henning, > > > > > > One use-case on our side is the generation of SWUpdate > > > image. Our helper class uses do_ext4_image to generate the > > > file-system image we later embed into the .swu file > > > > Andreas, how do you address that scenario for upstream SWUpdate support? > > > > Jan > > > > -- > > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > > Corporate Competence Center Embedded Linux > > > -- > Andreas Reichel > Dipl.-Phys. (Univ.) > Software Consultant > > Andreas...@tngtech.com , +49-174-3180074 > TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring > Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller > Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082 > > > ----- End forwarded message ----- > > -- > Andreas Reichel > Dipl.-Phys. (Univ.) > Software Consultant > > Andreas...@tngtech.com , +49-174-3180074 > TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring > Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller > Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082 > > ------=_Part_790_775591355.1551188358044 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Tuesday, February 26, 2019 at 2:33:28 PM UTC+1,= Andreas Reichel wrote:

We = (at least me) have no scenario where we really build update artifacts
with isar. One important question is, if the ext4 image is exactly the
size of its contents or if it is the final partition size. If it is
exactly the size of its contents only, it cannot be used as an update
artifact because the resulting rootfs would have 0 bytes free and likel= y
won't boot.


postinstall steps can be used to "= ;resize2fs" the file-system after it was installed
=C2=A0

So I would go Henning&#= 39;s way to extract the partition images...


It sure works. I however don't see= much harm in keeping the ext4_img class
I would not expect much = maintenance overhead there...
=C2=A0
Also we already have wic dependencies like sfdisk etc= installed, where
we can dump partition lists and use grep and dd.

Andreas

> Henning
>=20
> > Jan
> >
>=20

> Date: Tue, 26 Feb 2019 13:12:18 +0100
> From: Henning Schild <henning...@siemens.com>
> To: "[ext] Jan Kiszka" <jan.k...@siemens.com>
> CC: cedric_h...@mentor.com, isar-users <isar-...@googlegroups.com= >,
> =C2=A0Andreas Reichel <Andreas...@tngtech.com>
> Subject: Re: [PATCH 1/1] meta/ext4-img: refactor to fit current im= age
> =C2=A0creation methods
> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
>=20
> Am Tue, 26 Feb 2019 12:56:20 +0100
> schrieb "[ext] Jan Kiszka" <jan.k...@siemens.com>:
>=20
> > On 26.02.19 12:35, cedric_h...@mentor.com wrote:
> > > Hi Henning,
> > >=20
> > > One use-case on our side is the generation of SWUpdate i= mage. Our
> > > helper class uses do_ext4_image to generate the file-sys= tem image
> > > we later embed into the .swu file =C2=A0
> >=20
> > Andreas, how do you address that scenario for upstream SWUpda= te
> > support?
>=20
> I guess a valid way would be to have a task after do_wic which wil= l
> extract all raw partitions if enabled. It is kind of stupid but if= we
> can not change wic we better build around and reuse instead of
> reimplement.
>=20
> Henning
>=20
> > Jan
> >=20
>=20

> Date: Tue, 26 Feb 2019 12:56:20 +0100
> From: Jan Kiszka <jan.k...@siemens.com>
> To: cedric_h...@mentor.com, isar-users <isar-...@googlegroups.com= >,
> =C2=A0Andreas Reichel <Andreas...@tngtech.com>
> Subject: Re: [PATCH 1/1] meta/ext4-img: refactor to fit current im= age
> =C2=A0creation methods
> User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1= .12)
> =C2=A0Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666
>=20
> On 26.02.19 12:35, cedric_h...@mentor.com wrote:
> > Hi Henning,
> >=20
> > One use-case on our side is the generation of SWUpdate
> > image. Our helper class uses do_ext4_image to generate the
> > file-system image we later embed into the .swu file
>=20
> Andreas, how do you address that scenario for upstream SWUpdate su= pport?
>=20
> Jan
>=20
> --=20
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux


--=20
Andreas Reichel
Dipl.-Phys. (Univ.)
Software Consultant

A= ndreas...@tngtech.com, +49-174-3180074
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring
Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller
Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082


----- End forwarded message -----

--=20
Andreas Reichel
Dipl.-Phys. (Univ.)
Software Consultant

A= ndreas...@tngtech.com, +49-174-3180074
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring
Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller
Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082

------=_Part_790_775591355.1551188358044-- ------=_Part_789_1369291565.1551188358043--