From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6662301766535610368 X-Received: by 2002:a17:906:3744:: with SMTP id e4mr342253ejc.3.1551188008922; Tue, 26 Feb 2019 05:33:28 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:32c1:: with SMTP id k1ls3254833ejk.9.gmail; Tue, 26 Feb 2019 05:33:28 -0800 (PST) X-Google-Smtp-Source: AHgI3IZ8q0HR1ejafuwttxfiZWq3nl66FIf7khFJcHyKPpE7xN04pmflgY21D2NDYPpaSLIm7Sne X-Received: by 2002:a17:906:938b:: with SMTP id l11mr716475ejx.8.1551188008282; Tue, 26 Feb 2019 05:33:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551188008; cv=none; d=google.com; s=arc-20160816; b=HBlbymumO0ji6Mmxu/Z2djGL/zWAY1oCUITwI4BmtYHrgLVV7iSTIBTiaEnk0TNCEw bvSxhbnJ8NpKrP9ksNlsCwfH5562s+k3KJHTXvZSe7Lbs4wXqhXOez8mY3Alaq6QWMSP hNcV0w3fiJtaIdSSPcT69rRioU7hP5tK2q5UJ62qXDyK4hXHAaXQ32vdGkv6p8mSwdTR ZktfR8pDr19zMBud75nCjTd3DULcUoqHNb1v+fwaf+FS9LWgPBhTn7vgzL9JXRCSdbR0 pAt5YQw0zk2QQXsghSeIS8UmgFXBWzRIa8YI8vxqw6xobhJsBRhbq9p4sFjhFIP1phS3 AT2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:content-disposition:content-description:mime-version :message-id:subject:to:from:date; bh=RtdRVds3B1U5DuqTRxbc1/2BfnO6Acs0a3/7xe5YFKI=; b=t2CO4xKo0DsZF7t968qftiE98NyVNoB7rH+NDMBa/ych2gB0DwGypN7Caa37mbohF5 gac9BvtuMKRaW/OsWZbGJcGh56NneIdlGFndLZXRwUm1DIGTkvKTze8hs1Cd81wxifmM DLirtUVVHcLOXcbxyfshAfEjUIxPHV6ZzDQ6CAgN+A6q+d66NcNaop1teeJjKMJTR28A CZflwN1Ldtj+R5rqy7IQUdLirVOqYdgwzeMIEx9ac2Ai+erFEIpaHd63OcvOze2wNob0 yW8/ERH26XXQqyG3V3PlsWHZZtACpb0tVUjwKraPaNNVaYk+pyGOC769fXVdea5aa0Vk I3YQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of andreas.reichel.ext@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=andreas.reichel.ext@siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id a7si308605edb.1.2019.02.26.05.33.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 05:33:28 -0800 (PST) Received-SPF: pass (google.com: domain of andreas.reichel.ext@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of andreas.reichel.ext@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=andreas.reichel.ext@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id x1QDXSHp003278 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Feb 2019 14:33:28 +0100 Received: from iiotirae (golem.ppmd.siemens.net [139.25.69.17]) by mail1.sbs.de (8.15.2/8.15.2) with SMTP id x1QDXRo5010639; Tue, 26 Feb 2019 14:33:27 +0100 Date: Tue, 26 Feb 2019 14:31:48 +0100 From: Andreas Reichel To: isar-users@googlegroups.com, jan.kiszka@siemens.com, henning.schild@siemens.com, cedric_hombourger@mentor.com Subject: [andreas.reichel.ext@siemens.com: Re: Fwd: [PATCH 1/1] meta/ext4-img: refactor to fit current image creation methods] Message-ID: <20190226133148.GC17750@iiotirae> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: message Content-Disposition: inline User-Agent: Mutt/1.11.3 (2019-02-01) X-TUID: 1nEvxfXdTfiR > > Am Tue, 26 Feb 2019 12:56:20 +0100 > schrieb "[ext] Jan Kiszka" : > > > On 26.02.19 12:35, cedric_hombourger@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? > 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. > 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. > Once upon a time, where wic kept the .p1, .p2 etc files... but wic was patched to remove them. I had suggested an upstream patch two years ago which was not accepted by the maintainers. They said if we really need the partition files, we should work our own way around it. This said, it is no bad idea to reextract the partition files again out of the wic image. This is also because we extract what really would be flashed and wic already adapted sizes, etc... So I would go Henning's way to extract the partition images... 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_hombourger@mentor.com, isar-users , > 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_hombourger@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_hombourger@mentor.com, isar-users , > 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_hombourger@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.Reichel@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.Reichel@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