From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6704144668026732544 X-Received: by 2002:aa7:c2c8:: with SMTP id m8mr44955941edp.63.1560940127592; Wed, 19 Jun 2019 03:28:47 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:7807:: with SMTP id u7ls420849ejm.13.gmail; Wed, 19 Jun 2019 03:28:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqxdYUfh3TjME8XgFpAEiOhujXCulf3TwVTij+a8KnpQ8bQZkNM8FyMU39hIGBn4FVoEBI0s X-Received: by 2002:a17:906:6b53:: with SMTP id o19mr30469850ejs.27.1560940127096; Wed, 19 Jun 2019 03:28:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560940127; cv=none; d=google.com; s=arc-20160816; b=fqzATTr5a8/KhVy4m1Bx8F6wnrKNvNvqB2uFYicuiBY8/euLqrQLVXMXyk9X5BLpi3 96RZV6RB978LLaXPsq8X4FdMeE4Gi2SCRRxSHjzhsP10rhVhXwFRYx5tRgCctwhuCkq3 2sw+YxpZz3Z7XIOUxtPUz0HxnN+zaLv9LNvSSQZzguh9P0y3/E0fKDsR6kMpY7t7MSzD 4Tz8MLK4fio659JEsBSSLcsXGFiTCgH84A45SrDP/g9FaKOL7bwQQ9/gJ3O+4DdC0QIx JH5OOLkQEgchX6Xrr2LY1Jrj7gKkad97oeJfis2yna7GssWbeWKZyKvb8hlC+OHt6PEc NNZw== 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=DoyyxwL0kcnp6cVwZWVQP1+SWoOR2riPkoyFdak6lq8=; b=e0ZOsmwI83gwJwAl/IOVkp0ASqjJRP6VxPkV9Jsz5WVs2iUVlqO/tkEY+bG/KoOo/W 3EEuw3JlEwAUpO5CCOQegQwS1YgPSoAPOGDmkeAtOYMPzgGDCp2NAmNKYamx8VDd1YxZ 18+v/au2tY12FMnMw3zJCg17RAl+6dJPbuwbEjC7Y0Dney/G1WJpzLDfKlY/rW3vumzL cfBTJmx/bl041rGk7jXinsSzp9l3p79BE+UlHpyGepnWj6T/Hooo/cg6Uul+BCYMoYrm k3tj5X8bFZ3Ba+rCdHzdGMHnjD3So4tUMffQHYUta9PN9svhOTkqGNkGmw1TLcgBB+Se 1p6w== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 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 lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id z20si1012274edc.1.2019.06.19.03.28.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jun 2019 03:28:47 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@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 jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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 x5JASkQY006916 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Jun 2019 12:28:46 +0200 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x5JASki3025378; Wed, 19 Jun 2019 12:28:46 +0200 Subject: Re: [QUERY] wic running in buildchroot-target To: chombourger@gmail.com, isar-users References: From: Jan Kiszka Message-ID: Date: Wed, 19 Jun 2019 12:28:45 +0200 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 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: VFEMx/VaUS76 On 19.06.19 09:45, chombourger@gmail.com wrote: > Hello all, > > I am continuing my journey on the MIPS architecture. > I wanted to add wks files for my MIPS target (Creator Ci40) and do_wic_image failed: > > INFO: Creating image(s)... > > -rw-r--r-- 1 root root 697932185 Jun 18 13:34 > /tmp/development-image-mel-omni-img-creator-ci40.wic/tmp.wic.n3m8x3xo/rootfs_platforma.1.ext4 > Unsupported ioctl: cmd=0x0002 > Traceback (most recent call last): >   File "/home/chombourger/Projects/isar/scripts/lib/wic/filemap.py", line 40, > in get_block_size >     binary_data = fcntl.ioctl(file_obj, 2, struct.pack('I', 0)) > OSError: [Errno 89] Function not implemented > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): >   File "/home/chombourger/Projects/isar/scripts/lib/wic/filemap.py", line 103, > in __init__ >     self.block_size = get_block_size(self._f_image) >   File "/home/chombourger/Projects/isar/scripts/lib/wic/filemap.py", line 42, > in get_block_size >     raise IOError("Unable to determine block size") > OSError: Unable to determine block size > > wic appears to be running from buildchroot-target and therefore under > qemu--static > evidently mips does not implement the FIGETBSZ ioctl > > My options would be: > > (1) check if a more recent version of qemu does implement this ioctl > (2) add support for this ioctl in qemu-user Support for that IOCTL seems arch-independent, but maybe the qemu-user build was just missing some define: qemu/linux-user/ioctls.h /* emulated ioctl list */ ... #ifdef FIGETBSZ IOCTL(FIGETBSZ, IOC_R, MK_PTR(TYPE_LONG)) #endif But this is better discussed on qemu-devel. You are using qemu from buster already, right? > (3) work-around it in wic with something like: > > diff --git a/scripts/lib/wic/filemap.py b/scripts/lib/wic/filemap.py > index 080668e..1ce3ace 100644 > --- a/scripts/lib/wic/filemap.py > +++ b/scripts/lib/wic/filemap.py > @@ -40,8 +40,13 @@ def get_block_size(file_obj): >      # Get the block size of the host file-system for the image file by calling >      # the FIGETBSZ ioctl (number 2). > -    binary_data = ioctl(file_obj, 2, struct.pack('I', 0)) > -    return struct.unpack('I', binary_data)[0] > +    try: > +        binary_data = ioctl(file_obj, 2, struct.pack('I', 0)) > +        return struct.unpack('I', binary_data)[0] > +    except OSError as err: > +        if err.errno == os.errno.ENOSYS: > +            return 4096 > +        raise err >  class ErrorNotSupp(Exception): >      """ > > Ok. wic patches should go upstream first. We avoid patching it. > > But why are we running wic in buildchroot-target. Comments I have seen in the > code only say that it is a prerequisite but do not say why (I should probably > check git logs as well) > I wonder if it should run in buildchroot-host context instead (so we still use a > host environment we control) but avoid the overhead of qemu emulation for > DISTRO_ARCH != amd64 > > What are your thoughts? I do not remember all details, there might be technical difficulties, e.g. when you need to u-boot tools from a custom build, and that build is currently not generating native packages. But the killer argument is: CROSS_COMPILE is only optional. The default and production case is native (via qemu-user). Debian is not a fully cross-buildable distro, like most others. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux