From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6798056846333575168 X-Received: by 2002:a19:8982:: with SMTP id l124mr1704978lfd.151.1582796535748; Thu, 27 Feb 2020 01:42:15 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6512:104a:: with SMTP id c10ls265341lfb.6.gmail; Thu, 27 Feb 2020 01:42:15 -0800 (PST) X-Google-Smtp-Source: ADFU+vtf+Jhx8x65XKKnXbJGwrn3PX1VzsdeOGe978+/G+RhbnvdyD9seWdnZzX2jyEu9iziHKT+ X-Received: by 2002:a05:6512:1095:: with SMTP id j21mr1761555lfg.124.1582796534974; Thu, 27 Feb 2020 01:42:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582796534; cv=none; d=google.com; s=arc-20160816; b=X3CrgWKXE/xZhluZJrQGc6XVDKg061UszlrL/SOt+wPwsklPJzkzxaIbhZ4e4rrpFt T3yeu4WouIQvfXq8idYGKMMa7sibmRt9JwEB1RH3vDU9YcngdOtqb2ffGBWK7pIt+2HB wH+0/DCbGT19QijHN/VnsJu0RMxf++CLKyM63ieyjB/9YNHdUmIWsfqsoY5X/ZEIvRS+ tftG6pQp0J6szvsgXCDnNcfZ1lK/GWooM6ErcPyo5AShWrGXZiRNtRUxQp4pM8SLQpip BPP8kDxsANcZqimEIz9vLN0NzBC4agK7nF20DZsidXpvD1Jiq4PrgHkwCP3ZGtGYNK5/ Besw== 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:to:subject; bh=uKrTPVDMBrSKR5cKw6Oaxk5tF7B4eVrHHB+f544s4kI=; b=ZiW3enn/Vyqk7GFE5bwFUhkdlRT/0APnE5ko5zmGCCFErYXLHIG+kXSFNh+iBGe0Ht 2IElBBCkVdB9yBNMtcnICZ/dYyeRwtn+B/EHHQGiaixLrfWHazAWPBHoUCeoDUjJ3n1A 4ExDuotdCAaRP+pOA6QI0ZVsYVsjfIhP4CqkJajt4FnfNbHKTWBJviYMUo3Otbew3w7F 19GQXJCg1c7aF9nvusBpnoHQQuSa4i+71Ck47x5VxfEPRkcj1fdNrZ1CCZVLrXYpKCDj TLR+kFc0oOC/Qp+kTsBO2d8mPH+1j94o7fZS4AI1MZIfMixV6diGWkX77WjlISodFFiD Svyg== 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 v17si215930lfp.5.2020.02.27.01.42.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2020 01:42:14 -0800 (PST) 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 01R9gE6u030614 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Feb 2020 10:42:14 +0100 Received: from [167.87.8.234] ([167.87.8.234]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 01R9gDOj019372; Thu, 27 Feb 2020 10:42:13 +0100 Subject: Re: Bug mcopy (wic) when creating bootpartition To: benbrenson89@googlemail.com, isar-users References: <9a605191-9af0-41d6-a414-75970acac66c@googlegroups.com> From: Jan Kiszka Message-ID: <809cd26c-9cca-3647-59be-d0f2c2f71020@siemens.com> Date: Thu, 27 Feb 2020 10:42:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <9a605191-9af0-41d6-a414-75970acac66c@googlegroups.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: 4q7tQjVspqPA On 27.02.20 10:32, benbrenson89 via isar-users wrote: > Hi guys, > > I have encountered a bug related to mcopy during wic image generation. > > I digged a bit deeper into the problem and it turns out that mcopy is > not able to copy folders recursive. It just silently skips the content > of those folders. > > When running mcopy within the buildchroot-host, these folders where > properly copied. > > My question now: > > Wic is running in the buildchroot of the target architecture, but I > don't get why it has to be done in there? > May it be possible to switch the wic image generation into the > host-buildchroot, or are there any other requirements for the current > environment which I miss here? Running always in the target environment reduces variations because we have to do that anyway when cross-compiling is disabled (which is default and recommended for production build). Can you extract the problem to something that can be tested separately? What is your target architecture? What is the qemu-user-static version you are effectively using? Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux