From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6924371667242188800 X-Received: by 2002:aa7:c843:: with SMTP id g3mr7522106edt.228.1613034867549; Thu, 11 Feb 2021 01:14:27 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6402:1432:: with SMTP id c18ls4420330edx.0.gmail; Thu, 11 Feb 2021 01:14:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJwiwzCXvXS1eZWSe7pEvkZrTyEEGi7GmHXSjgGKh3qmRm903gCkPTT4T6kk0FETSjva7IIp X-Received: by 2002:a50:cc4d:: with SMTP id n13mr7264846edi.337.1613034866538; Thu, 11 Feb 2021 01:14:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613034866; cv=none; d=google.com; s=arc-20160816; b=TcKVnR+Dj95txdBsb7RJtS8waO0BQ/1lDrunHHAQK/o5+QZAzq8flUUmRaP2s8VNqx GTWiSx84M9iLu9HlHyo8oyhvp3phlUggD3vWjCguXcq56l0TzqgbS5VDXgwqN9yz2COL yMbHZsXbJzzjDEnxGXDYkUaWsDBdv2Inj2E3y5OFQmzmf1tf7rCaMKlPyaA1vAJ0JJVF jXy3F+e5/HU/vpXtdyGkDY5FDIaAr7z9Hm5R139xtVglDHc5q0RSuZJoXe9a0/Tp3GwS ymyT3yi+WqBQXGLYeR0lQBhQAQglmUa4gItK9FYKcheNuejxM0YQQGlfG3q+nf8+vs8D caRA== 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=2R50DetS9zv05vAesRBCiqbRYmSOu9YJP7ozHtkzZRQ=; b=ttdfuSVtsizrge8CMc522uCc1j5ZpQu4qe7Y5rahvWNxyukca/24hSkhvMM4G5aCGC 4l6tfMxdB8QoKXmNkzY9scoXCwBR8M7wBuDfztc7fNoRgr17iuLmv9QfxPswMCXLKu3h d4H+9cyuLEollaU8nyxlQ2P+JK+AUrnhDZ/q/PsRAB1wWugqRrPXLIiCSxN73+iu/1fp CFlQBf+3vHEfyyIuyWuGFU8XO/ntJFh73SzAP7y0d13TEHIwyFeH+m2cQbGV6a9j0IIw e/tvgHia2hHn5uapTmx0ZGg7KpOrQ914pw2+xGmuKR/Z4MeaTCc949c2ssivuHwUZKcc GjXw== 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 c14si259801edr.4.2021.02.11.01.14.26 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2021 01:14:26 -0800 (PST) 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 mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 11B9EP7Z018753 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Feb 2021 10:14:25 +0100 Received: from [139.22.42.110] ([139.22.42.110]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 11B99Ob3030028; Thu, 11 Feb 2021 10:09:24 +0100 Subject: Re: [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems To: Henning Schild , Anton Mikanovich , vijai kumar , "florian.bezdeka@siemens.com" Cc: "isar-users@googlegroups.com" , "quirin.gylstorff@siemens.com" References: <20210201185815.382326-1-florian.bezdeka@siemens.com> <491c833c-c35c-d130-e8e6-f31aee4204aa@ilbers.de> <20210211092338.293c5306@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: <9b7b9865-2381-d2df-8495-4a208b82304f@siemens.com> Date: Thu, 11 Feb 2021 10:09:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210211092338.293c5306@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: yrCRQbBDkCoD 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? Jan > 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. >> > -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux