From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6924371667242188800 X-Received: by 2002:a17:907:35d1:: with SMTP id ap17mr10032996ejc.79.1613066513632; Thu, 11 Feb 2021 10:01:53 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a50:fd14:: with SMTP id i20ls1312812eds.2.gmail; Thu, 11 Feb 2021 10:01:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJx/i4iS3dZ98RsSEN1bxil/gfC8v5+nK9soa8n6RVn57OPXC6bzQO+8e3FOtAkepb+pcIDQ X-Received: by 2002:aa7:d306:: with SMTP id p6mr9500979edq.185.1613066512713; Thu, 11 Feb 2021 10:01:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613066512; cv=none; d=google.com; s=arc-20160816; b=T7Jw5eCT56Ln7AToPfxSsX0mMdXHk1Nydvw9FrVTfH+kVXF78HSkJFulu2dEEJbdve 4k4fPszA8+vHLJQCipgwzwK0IDFkSZiZhtPJe/R5eA676tYO9VNBjyMInlp5Xpof7kZ+ /70sMxV4GbdWaqyKqTF7MvD7E0ayfCNBMkR3zeQ/c4VUaHUh08IzteDFzejymKZWCFHm qrMAjahsOCFHfOAo19+XKefpdRD3bsr7CZi5ZzPuHU2F67ZxEDXpNMrPkTjVqKc/r/rl kEzfek6CjZMG7DihSUOWbKp591tmgRWpa3tiqkOHhXVuz5jaLIMayV5AkCTOb95R9u7N GMAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=fDRYYkdAROF/BKFwTT8xSsnXwitYkNYNtVfKGkLlTwk=; b=oXfOWJv0KNygToyzXPaK4ZbbSDkCDkYcPfforwD+4QnDKFhJuaXZkx7o5cQHaafQXh A941Gp4sUeVu/R6R4zWYCZyGt40stpmqBRsbxt49d24UVwhyICOs8dobe1nbLexvIKuX ip969jA6ymuh6leRZwCVmvm4O+BSV5LsLuWFIwLD6tZqAr0knoO/sp0g7kamsGmm/OFR BKO18s4vePs2ru39N8I2pqcYsgYatzHOfjs5lQ9RO8spfXMuBH8ieljDunfmrDrEweJh QiLv+LWG/ytY5Yv1YJLQUWibt+4x9bv9KpNjam4jVSDtZbJQF6L4My5+XTsgo4sIbLdx Yq3g== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@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 jz19si488901ejb.0.2021.02.11.10.01.52 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2021 10:01:52 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@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 henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@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 gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 11BI1qWa027002 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Feb 2021 19:01:52 +0100 Received: from md1za8fc.ad001.siemens.net ([167.87.17.8]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 11BI1pp9020129; Thu, 11 Feb 2021 19:01:51 +0100 Date: Thu, 11 Feb 2021 19:01:50 +0100 From: Henning Schild To: "Bezdeka, Florian (T RDA IOT SES-DE)" , "amikan@ilbers.de" Cc: Jan Kiszka , "isar-users@googlegroups.com" , "vijaikumar.kanagarajan@gmail.com" , "Gylstorff, Quirin (T RDA IOT SES-DE)" Subject: Re: [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems Message-ID: <20210211190150.3674b416@md1za8fc.ad001.siemens.net> In-Reply-To: <5f187abe-0b77-5ba9-e5a5-3da5ce072b7e@siemens.com> References: <20210201185815.382326-1-florian.bezdeka@siemens.com> <491c833c-c35c-d130-e8e6-f31aee4204aa@ilbers.de> <20210211092338.293c5306@md1za8fc.ad001.siemens.net> <9b7b9865-2381-d2df-8495-4a208b82304f@siemens.com> <8f7c5554a0e8f4ef52526f84a90c418fd8d9c1d3.camel@siemens.com> <20210211112147.7d683a25@md1za8fc.ad001.siemens.net> <20210211151318.2eb38893@md1za8fc.ad001.siemens.net> <5f187abe-0b77-5ba9-e5a5-3da5ce072b7e@siemens.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: EnKFO24UnWch Am Thu, 11 Feb 2021 18:57:24 +0100 schrieb Jan Kiszka : > On 11.02.21 15:13, Henning Schild wrote: > > Am Thu, 11 Feb 2021 14:31:58 +0100 > > schrieb "Bezdeka, Florian (T RDA IOT SES-DE)" > > : > > > >> On Thu, 2021-02-11 at 12:47 +0000, [ext] > >> florian.bezdeka@siemens.com wrote: > >>> On Thu, 2021-02-11 at 11:21 +0100, Henning Schild wrote: > >>>> Am Thu, 11 Feb 2021 10:57:31 +0100 > >>>> schrieb "Bezdeka, Florian (T RDA IOT SES-DE)" > >>>> : > >>>> > >>>>> On Thu, 2021-02-11 at 10:09 +0100, Jan Kiszka wrote: > >>>>>> On 11.02.21 09:23, Henning Schild wrote: > >>>>>>> Hi all, > >>>>>>> > >>>>>>> i never got around to reviewing this. But did we just fork > >>>>>>> wic? These patches need to go into wic and we later > >>>>>>> backport them once they are accepted upstream. > >>>>>>> > >>>>>>> Maybe they are already ... did not check. > >>>>>>> > >>>>>>> When it comes to changing bitbake or wic, we should really > >>>>>>> not ... We have forks of some files, like the wic plugins > >>>>>>> and bitbake config, those are fine but should also stay > >>>>>>> very close to upstream. > >>>>>>> > >>>>>>> The recently applied patch from Vijai also violates that. > >>>>>>> Since the fork of the plugins was not updated with the wic > >>>>>>> bump and the repair just takes a few bits of what we > >>>>>>> probably should take. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> If you are referring to > >>>>>> https://groups.google.com/d/msgid/isar-users/20201126091750.28048-1-Vijaikumar_Kanagarajan%40mentor.com > >>>>>> That one was "only" patching an isar version, though I agree > >>>>>> that we should make sure to realign it with the original > >>>>>> plugins if we are now imbalanced. > >>>>>> > >>>>>> This one here is more critical as it changed a formerly > >>>>>> vanilla wic file. That should be fixed quickly. > >>>>>> > >>>>>> Florian, maybe you can propose a similar change to OE > >>>>>> upstream? In the meantime, is there a chance to move the > >>>>>> changes out of partition.py, to a file that is isar-specific? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> I guess the "RFC" tag of this series has been overlooked. It > >>>>> was not intended for merging (yet). Part one (forwarding wic > >>>>> warnings to bitbake) is a pure ISAR change and could be taken > >>>>> as is (if no further comments come up). > >>>> > >>>> I guess that calls for a revert. And for more attention on the > >>>> maintainers side. Florian, maybe you send a revert series. Not your fault but maybe your call. Henning > >>>>> Sorry for the long description of the series, but if you read > >>>>> closely I already mentioned that the second part should go to > >>>>> OE. I sent it out for feedback collection only. > >>>>> > >>>>> The upstreaming to OE will take some time due to internal > >>>>> clarifications. I never contributed to OE before, so some kind > >>>>> of approval process has to be followed first. > >>>>> > >>>>> At first glance there was no easy way moving the warnings from > >>>>> wic to ISAR. We would have to re-parse the wic template file > >>>>> again and check all the partitions afterwards. wic has all the > >>>>> necessary information at hand so I guess that's way easier. > >>>> > >>>> I guess it can be moved into a task after wic. Here one would > >>>> need to parse the partition table, which kind of sucks. "losetup" > >>>> or "kpartx" might help but will not work in kas-container setups > >>>> because they need root. > >>>> We once had patches allowing wic to retain all partition images > >>>> instead of throwing them away after disk assembly. Having a > >>>> switch for wic to say ... do those partitions ... later do the > >>>> disk would be generic, allow hooking in this and other things. > >>>> > >>>> Isar also has a class that creates ext4 images without, after > >>>> which such a check should also be done. > >>> > >>> Yes. But instead of spreading the warnings around it would be nice > >>> to have a single place where we could do the Y2038 checks. So > >>> maybe it should be a base feature of "image.bbclass"? Or > >>> ext4-img.bbclass should call wic instead of the mke2fs utilities > >>> directly? > >>> > >>> BTW: The name ext4-img.bbclass is kind of misleading. You could > >>> simply create ext{2,3} file systems by setting MKE2FS_ARGS to > >>> something like "-t ext2". > >>> > >>>> > >>>> Is ext4 the only fs we care about? We have some layers doing > >>>> ubifs, squashfs and all sorts of funny things. > >>> > >>> Up to now I cared about the filesystems supported by wic. So > >>> ext{2,3,4}, btrfs and squashfs. squashfs will overflow in 2106 > >>> (u32) and btrfs will "never" overflow (u64). > >>> > >>> ubifs is similar to btrfs, so not affected by Y2038. > >>> > >>>> > >>>> Maybe the kernel does warn "on device" so we could have a systemd > >>>> unit warning for all filesystems ... which would probably best > >>>> find its place in the kernel and or debian. > >>> > >>> At least for affected ext file systems the kernel will warn (on > >>> mount). But I considered that as "too late". > >> > >> To be more specific: Linux >= 5.4 warns. That's why I guess that > >> many projects did not realize that they are already affected by > >> the Y2038 problem because of older kernel versions. > > > > Which sounds like that warning needs backporting into the debian10 > > kernel and maybe cip. Not sure Isar is the best place, but a valid > > one that could help. > > > > Maybe mkfs could warn ... as well. > > > > Right, and we want such warnings seen at image *build time*, not only > on the target during runtime. That is the key idea behind this > instrumentation. > > Jan >