From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6842309179660566528 X-Received: by 2002:a2e:9bc4:: with SMTP id w4mr5524485ljj.391.1593422041100; Mon, 29 Jun 2020 02:14:01 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:8592:: with SMTP id b18ls443427lji.0.gmail; Mon, 29 Jun 2020 02:14:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx2GFwibLmDE08IJAYTizCgMKCZTar104QO7vP6Cvo2tNq+I+cMQEhOcjZWe+MZHXYNGM0T X-Received: by 2002:a2e:8e6d:: with SMTP id t13mr8028309ljk.309.1593422040009; Mon, 29 Jun 2020 02:14:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593422040; cv=none; d=google.com; s=arc-20160816; b=AP/Q/nGpgoxd4vPA/GErsCkQj3LnOI8SUqgD4V3LoVWhI3S4KXrfw9SRZS9UHX24Or HxM3l7AUjarRQIPU9QJn/sE77bWiYCyyRhkfZxjyW1HER8vpkL5XT4ta2C/uVp2ayOac 3Mf2uNwzfhHnxlZm0luRgRSqnl7I70vqVLvWwcSBlO41Zj+c8/vGKS+2z898WBK4eLgE EvRIIddB77dq2RMkpildVw1z2X1ddj+YZoqtag696SIp816+RAOmRx6jBpOX42/bmnNW jA8LPPybfaUdpcMT7b3lmTutFENMjgsGlCOLQWGf458ZN176ehKwLvjLz5kDRYeOyT/O txYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=W5Fmg4DlMZFfNLuBy21xPlHLQN/KNjok26TcC/sqjtA=; b=sjq4A2aYKcPFVt1UhThGar1Rum6B+/JS61kPB0vCZvn4YeEKWKvcqjU+vKVL9HRtZ2 bc+lDpkRaXrI1WkYSuX1OmyDQeamvzhTZHbQfetSpz1mkfiTPsD2q0ZyFp2e72AHjXJs vvgGudEqnWSO6VQP4WSkyNN+9cdXTiXuT3z7sDfD4ZDGFO8x/dZAJpqgkHfijWLkxJ/B bvATh//85RERBd2eWrhok9o8X0XKZZ4XPEJ46z9bUhs1cTlZqdkN7XmGjLFJMLSSlrnn NCrvpSqB0lT3oU7xCyK6RCbkQaXLJuUN9N4PzC8zkoED8vfbA80Y9EWAQGS7awf9ZZT9 zozA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id u11si2220473lfl.4.2020.06.29.02.13.59 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 02:13:59 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 05T9Dwkr013851 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 29 Jun 2020 11:13:58 +0200 Received: from [167.87.50.192] ([167.87.50.192]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 05T9DvMk015152; Mon, 29 Jun 2020 11:13:58 +0200 Subject: Re: [PATCH] image: Run copy_boot_files after rootfs postprocessing To: Claudius Heine , Harald Seiler , Henning Schild Cc: isar-users@googlegroups.com References: <20200625153351.3402179-1-hws@denx.de> <20200625184822.236ff069@md1za8fc.ad001.siemens.net> <91ce92c15d267e4836ab4d9de2870bc8e6f6dfa1.camel@denx.de> <5a86e555-416e-d788-2655-003403f1d190@siemens.com> <98c4dd24-b450-b9c3-ca6d-79996e3ab8ae@denx.de> From: Jan Kiszka Message-ID: Date: Mon, 29 Jun 2020 11:13:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <98c4dd24-b450-b9c3-ca6d-79996e3ab8ae@denx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: 5P607H8Ex947 On 29.06.20 11:04, Claudius Heine wrote: > Hi Jan, > > On 26/06/2020 11.12, Jan Kiszka wrote: >>>>>> Maybe you can point out an issue in isar itself, or explain how you >>>>>> got >>>>>> into this situation? We can then see if your change is generic enough >>>>>> for upstream. You could also provide the error-case from your layer as >>>>>> an upstream feature, if that is generic enough. >>>> >>>> I think this patch addresses an issue in isar itself.  There is no >>>> reason >>>> for copy_boot_files() to run before the postprocessing does.  I've >>>> checked >>>> through the git history and the reason this relationship was introduced >>>> was a bigger refactor of the task dependency chain.  It does not seem to >>>> be intentionally this way from what I can tell. >>>> >>>> The other way around makes more sense, in my opinion.  As stated in the >>>> commit message, postprocessing might do an update to the initramfs (as >>>> seen above) and this change needs to be reflected in the deployed >>>> initramfs as well, instead of silently only living in the version >>>> that is >>>> part of the rootfs. >>>> >>>> I also checked all existing postprocessing commands and did not see any >>>> that assume to be run after the boot files have been deployed. >>> >>> Its been a while when I implemented this, but I also thought of the >>> scenario where someone would like to 'minimize' a image via the root fs >>> postprocessing by deleting everything that is not needed, and that could >>> possible include the kernel + initramfs, if those are stored somewhere >>> else outside the root file system. So the idea was, IIRC, to move the >>> kernel and initrd to the deploy dir, out of harms way, before >>> postprocessing does its rootfs manipulation. >>> >>> So by ordering the copy_boot_files behind the root fs post processing, >>> you might break other layers that rely on this ordering and have such >>> 'minimization' procedures, that remove the kernel package and specific >>> files. >>> >>> We don't have such 'minimization' stuff in upstream isar, since it >>> pretty much breaks apt and dpkg, but if you do image based update, you >>> might not care. >> >> I think the problem with this pattern is elsewhere: We should not >> install stuff on the rootfs in the first place that shall not end up in >> the rootfs. > > Not sure if I understand you correctly. Do you mean that minimization in > the rootfs postprocess should not be done and instead the things that > get removed there should just not be installed? > > To be concrete, one thing that might be removed is 'apt' and 'dpkg' > itself. The only way how you can setup a root file system without it is > if you would install it using a package management from outside the root > file system. > > While this would be the cleanest approach, and might even be supported > (See RootDir in apt.conf(5)), that would mean pretty massive changes to > Isar. If you can avoid installing, you do not need to remove things again for shrinking. That's what I meant here. Obviously, you can't avoid apt or dpkg in the first place, so that shrinking pattern would remain different. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux