From: Jan Kiszka <jan.kiszka@siemens.com>
To: Henning Schild <henning.schild@siemens.com>,
Anton Mikanovich <amikan@ilbers.de>,
vijai kumar <vijaikumar.kanagarajan@gmail.com>,
"florian.bezdeka@siemens.com" <florian.bezdeka@siemens.com>
Cc: "isar-users@googlegroups.com" <isar-users@googlegroups.com>,
"quirin.gylstorff@siemens.com" <quirin.gylstorff@siemens.com>
Subject: Re: [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems
Date: Thu, 11 Feb 2021 10:09:24 +0100 [thread overview]
Message-ID: <9b7b9865-2381-d2df-8495-4a208b82304f@siemens.com> (raw)
In-Reply-To: <20210211092338.293c5306@md1za8fc.ad001.siemens.net>
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 <amikan@ilbers.de>:
>
>> 01.02.2021 21:58, florian.bezdeka@siemens.com wrote:
>>> From: Florian Bezdeka <florian.bezdeka@siemens.com>
>>>
>>> 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
next prev parent reply other threads:[~2021-02-11 9:14 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-01 18:58 florian.bezdeka
2021-02-01 18:58 ` [RFC PATCH 1/2] wic-img: Forward warnings from wic to bitbake florian.bezdeka
2021-02-01 18:58 ` [RFC PATCH 2/2] wic: Warn if an ext filesystem affected by the Y2038 problem is used florian.bezdeka
2021-02-11 8:07 ` [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems Anton Mikanovich
2021-02-11 8:23 ` Henning Schild
2021-02-11 9:09 ` Jan Kiszka [this message]
2021-02-11 9:57 ` florian.bezdeka
2021-02-11 10:21 ` Henning Schild
2021-02-11 12:47 ` florian.bezdeka
2021-02-11 13:31 ` florian.bezdeka
2021-02-11 14:13 ` Henning Schild
2021-02-11 17:57 ` Jan Kiszka
2021-02-11 18:01 ` Henning Schild
2021-02-17 11:56 ` Baurzhan Ismagulov
2021-03-01 15:18 ` [PATCH] wic: Warn if an ext filesystem affected by the Y2038 problem is used Florian Bezdeka
2021-03-01 15:23 ` vijaikumar....@gmail.com
2021-03-01 15:38 ` florian.bezdeka
2021-03-01 15:58 ` vijaikumar....@gmail.com
2021-03-01 17:22 ` Jan Kiszka
2021-03-01 17:45 ` florian.bezdeka
2021-03-01 17:54 ` vijaikumar....@gmail.com
2021-03-02 9:20 ` Henning Schild
2021-03-02 10:12 ` Jan Kiszka
2021-03-27 7:20 ` [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems Jan Kiszka
2021-03-27 8:54 ` Florian Bezdeka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b7b9865-2381-d2df-8495-4a208b82304f@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=amikan@ilbers.de \
--cc=florian.bezdeka@siemens.com \
--cc=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=quirin.gylstorff@siemens.com \
--cc=vijaikumar.kanagarajan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox