From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6924371667242188800 X-Received: by 2002:a17:906:fca1:: with SMTP id qw1mr6824913ejb.130.1613031820613; Thu, 11 Feb 2021 00:23:40 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:907:162c:: with SMTP id hb44ls2442837ejc.5.gmail; Thu, 11 Feb 2021 00:23:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJznJYoqXY9UFaYoR1H40FnCOUo+nRCrbonw3Gc9NEAy0vFyPEubqsPsb3kdoY+FB28UQr+W X-Received: by 2002:a17:906:c10a:: with SMTP id do10mr7278841ejc.543.1613031819689; Thu, 11 Feb 2021 00:23:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613031819; cv=none; d=google.com; s=arc-20160816; b=jBskRkSdA6mrB+adA2W3k3jmQiGG+aSeEQBees1rDgehDBwZteYY3i3efwW8bOgz+u Pfn9SsCx3C8GREoYsx8GuMgbG+SwR0XJ3xY1umj5byASkQKKTsQOZH6AxiEXad8UubQ1 ouhg62i7bIVIQSrkoBQzH4ITGWbjFw/cDaIhqmLpMljTv2sV2G2lpCTB/2F5IEdT5F5U PSoNNmJxktKK8/hOLfuDr17eWaikf70VdE1iONbO7e75XebxlP5la/FKArkqN/LRepXM uIbnnt0G2E/1z50mw8xV+U75Y2qY4siJzkL+byJ0cKpnaP2kt8qx1l3NzqJPMLC+zZMk W32g== 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=9eiQ3ijCq72wIo4bQdbMKwNSb62859QPgND0af7qIyE=; b=ds2mYFDITEGVFLgNMo0ee9Vy7gnKytKgoJx3Yi6VdsMnOoajJyI3wVfjYZ9uWHHcvf xrIXO224ekMURzVdBRbnNcastegWvLAJByTWTeyErwFDgRjypKqPg5J7BZNgdoqKzvlx UOXEVMFRvArNeaOvcA2/hGsUAXq+hrZrlB4ImCdCUu7tTwpJSl70hl8jS02rTWHTXHjs UIgkDCtLot/Q0Zn9ilJWL3E++qAs0dHJrqGCr+dAmX52WmZtRRR9Nf1B8ki6mD60eUSw fQXeQnim8bdNBTKiwzKtneI1Y0HPNJDhMf6RyY/OlCCfSGQKHMZsV3hvf+Qu04P6TfWu aLhA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 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 lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id z69si126445ede.1.2021.02.11.00.23.39 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2021 00:23:39 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@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 henning.schild@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=henning.schild@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 lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 11B8Ndmg017207 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Feb 2021 09:23:39 +0100 Received: from md1za8fc.ad001.siemens.net ([167.87.17.8]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 11B8NcLH029243; Thu, 11 Feb 2021 09:23:38 +0100 Date: Thu, 11 Feb 2021 09:23:38 +0100 From: Henning Schild To: Anton Mikanovich Cc: "florian.bezdeka@siemens.com" , "isar-users@googlegroups.com" , "quirin.gylstorff@siemens.com" , "jan.kiszka@siemens.com" Subject: Re: [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems Message-ID: <20210211092338.293c5306@md1za8fc.ad001.siemens.net> In-Reply-To: <491c833c-c35c-d130-e8e6-f31aee4204aa@ilbers.de> References: <20210201185815.382326-1-florian.bezdeka@siemens.com> <491c833c-c35c-d130-e8e6-f31aee4204aa@ilbers.de> 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: N/vvMbDmKb86 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. Henning Am Thu, 11 Feb 2021 11:07:52 +0300 schrieb Anton Mikanovich : > 01.02.2021 21:58, florian.bezdeka@siemens.com wrote: > > From: Florian Bezdeka > > > > Hi ISAR developers, > > > > this series is the summary of a nice journey through the file system > > jungle regarding Y2038 problem. It all began with a warning which is > > reported by kernels >= 5.4: > > > > ext4 filesystem being mounted at (mountpoint) supports timestamps > > until 2038 (0x7fffffff) > > > > I guess that most ISAR layers are using the Debian kernels, so that > > warning was not recognized yet or at least not very often. > > > > When reading this warning I was surprised. Shouldn't a modern file > > system like ext4 be Y2038-safe? As it turned out it depends on the > > inode size if an ext4 file system is safe or not. So why was the > > inode size not sufficient in my case? > > > > The inode size is chosen during file system generation and depends > > on the size of the file system that is going to be created. For > > details let's have a look at `man mke2fs`: > > > > -T usage-type[,...] > > Specify how the filesystem is going to be used, so that mke2fs > > can choose optimal filesystem parameters for that use. The usage > > types that are supported are defined in the configuration file > > /etc/mke2fs.conf. The user may specify one or more usage types > > using a comma separated list. > > > > If this option is is not specified, mke2fs will pick a single > > default usage type based on the size of the filesystem to be > > created. If the filesystem size is less than 3 megabytes, > > mke2fs will use the filesystem type floppy. If the filesystem size > > is greater than or equal to 3 but less than 512 megabytes, mke2fs(8) > > will use the filesystem type small. > > > > The relevant parts from /etc/mke2fs.conf: > > [fs_types] > > ... > > small = { > > blocksize = 1024 > > inode_size = 128 > > inode_ratio = 4096 > > } > > ... > > > > So whenever you create an ext4 file system with less than 512MB in > > size you will end up with 128 byte inodes and your file system is > > not Y2038-safe. > > > > The ISAR part: > > ext4 may often be used in combination with the expand-on-first-boot > > recipe / feature. So whenever creating a small partition (e.g. > > inside a wic file) and extending it later may result in a Y2038 > > affected ext4 file system. > > > > That is exactly what happened to me and I would like to make sure > > that all other ISAR users are aware of this situation. > > > > Valid workarounds found so far: > > - Tell wic that an partition will grow: > > Add `--mkfs-extraopts "-T ext4"` to your wic partition > > definition > > - Set the inode size to 256 (for small ext4 partitions) > > Add `--mkfs-extraopts "-I 256"` to your wic partition definition > > > > The upstream part: > > None of the following patches has been sent to any upstream (OE) > > mailing lists yet but hopefully that will happen soon. So far: Any > > comments welcome! > > > > Best regards, > > Florian > > > > Florian Bezdeka (2): > > wic-img: Forward warnings from wic to bitbake > > wic: Warn if an ext filesystem affected by the Y2038 problem is > > used > > > > meta/classes/wic-img.bbclass | 20 ++++++++++++++----- > > scripts/lib/wic/partition.py | 38 > > ++++++++++++++++++++++++++++++++++++ 2 files changed, 53 > > insertions(+), 5 deletions(-) > Applied to next, thanks. >