From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6924371667242188800 X-Received: by 2002:a05:600c:4fcb:: with SMTP id o11mr4430860wmq.88.1613039211259; Thu, 11 Feb 2021 02:26:51 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:60c2:: with SMTP id u185ls2700657wmb.2.gmail; Thu, 11 Feb 2021 02:26:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJzowO0NmMilDQ1OH28TUwoucxnljjvCZY/+AndOxykAF33AacXc/woNE/Y+IONbf+m0KT67 X-Received: by 2002:a7b:cc0c:: with SMTP id f12mr4035657wmh.118.1613039210370; Thu, 11 Feb 2021 02:26:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613039210; cv=none; d=google.com; s=arc-20160816; b=GPopaVvS0so83d3aQqPs+CnckM0bXU99fA6nWCrRvgfRriAG+DMpDavT8uXMXMUeVl OqbUxzhCwXiRe5XW1xlI7s04kb5K3Vttu7lJXklpY/In3chGLS9wWD5GJle9BrjyMJ84 XkD6ctu4xiPBOz00ZHU7tZV8kUGEsRBsfzHm6p3UWkTjz/0gnmYB895J1JXQ4fGiadgD f9wVJtdveDoqD8MRkj6yOuyHpkHoOFsKORfd2qBrExuiVZ9GPDd9uqgzOym2Fo0K4eoI 0qYJRY9xuImyDEPT9vM0+m7m5UUiU1ECkp+qVDAuVa7uGNoXnSxiNl3p4ecze9VlzdOE C6qA== 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=yPvLy0l54IEw6yasaaz+AlcCouHgIB68irykcNYKPtA=; b=FVP0cx9dj6uJhBsit5lktsfJKdF6GNIiKBuvwrAYwzPGLtQVEFdYUy9m36inSfL803 BPSTTNE3vgoqzw5PUvsMKli9NHggx1SfYVNBUBRtIOJe3h1GwUbWajAZ2Mf/rwWfiHuk HeXvVauFjca4GcY5IHoBpVK9dRP7qNb+LLBYQ6ars15eqjnC+M7NkkKlJhYt6b/N9Gvy aRBiPV2tsUf6R5ABCU7CUMyLv5Z4t2RntYe5YL2UC9Mf6+Sf3vwh6t/LDz8/xX2ZWXti pe7mcP0RdhOA1TuSwnhQE0zTOGMvZ1zP2KxouKfOJfjOyIiJQ5ZUY30CoeE+Ix37Tslw V0NA== 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 v16si459012wmh.1.2021.02.11.02.26.50 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2021 02:26:50 -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 11BAQn7c026861 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Feb 2021 11:26:49 +0100 Received: from md1za8fc.ad001.siemens.net ([167.87.17.8]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 11BALmIx001381; Thu, 11 Feb 2021 11:21:48 +0100 Date: Thu, 11 Feb 2021 11:21:47 +0100 From: Henning Schild To: "Bezdeka, Florian (T RDA IOT SES-DE)" Cc: "amikan@ilbers.de" , "Kiszka, Jan (T RDA IOT)" , "vijaikumar.kanagarajan@gmail.com" , "isar-users@googlegroups.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: <20210211112147.7d683a25@md1za8fc.ad001.siemens.net> In-Reply-To: <8f7c5554a0e8f4ef52526f84a90c418fd8d9c1d3.camel@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> 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: MwdIdQzB7fIS 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fisar-users%2F20201126091750.28048-1-Vijaikumar_Kanagarajan%2540mentor.com&data=04%7C01%7Cde173c00-e982-4fda-8644-47edf4671d63%40ad011.siemens.com%7Cd67820e7b5d841cf320f08d8ce7372f9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637486342521796327%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YQM5jQg9YSx6f9FiuYaduPEccCnNspRle4ZH8ES0nH4%3D&reserved=0: > > 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. > 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. Is ext4 the only fs we care about? We have some layers doing ubifs, squashfs and all sorts of funny things. 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. Henning > > > 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. > > > > > > > > > > > >