public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Florian Bezdeka <florian.bezdeka@siemens.com>,
	isar-users@googlegroups.com
Cc: henning.schild@siemens.com, ibr@radix50.net
Subject: Re: [PATCH] wic: Warn if an ext filesystem affected by the Y2038 problem is used
Date: Mon, 1 Mar 2021 18:22:43 +0100	[thread overview]
Message-ID: <581c68ac-3b56-206a-9898-7b7a21871ac1@siemens.com> (raw)
In-Reply-To: <20210301151823.64574-1-florian.bezdeka@siemens.com>

On 01.03.21 16:18, Florian Bezdeka wrote:
> This is the backport for upstream (openembedded-core)
> eecbe6255584 ("wic: Warn if an ext filesystem affected by the Y2038 problem is used")
> 

We need to sync to a specific commit of upstream, rather than expanding
the fork.

Jan

> We are getting closer and closer to the year 2038 where the 32 bit
> time_t overflow will happen. While products (= embedded systems) with an
> expected life time of 15 years are still save the situation may change
> if your system has to survive the next 20 years.
> 
> ext2 and ext3 filesystems are always affected by the time overflow, so
> let's warn the user if these filesystems are still being used.
> 
> If ext4 is affected depends on the inode size chosen during filesystem
> creation. At least 256 bytes are necessary to be safe. As ext4 is
> used very often (and partitions may be created small first and extended
> later) this might be an issue for many users.
> 
> Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
> ---
>  scripts/lib/wic/misc.py      |  1 +
>  scripts/lib/wic/partition.py | 15 +++++++--------
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/scripts/lib/wic/misc.py b/scripts/lib/wic/misc.py
> index 4b08d64..c4332d5 100644
> --- a/scripts/lib/wic/misc.py
> +++ b/scripts/lib/wic/misc.py
> @@ -26,6 +26,7 @@ logger = logging.getLogger('wic')
>  
>  # executable -> recipe pairs for exec_native_cmd
>  NATIVE_RECIPES = {"bmaptool": "bmap-tools",
> +                  "dumpe2fs": "e2fsprogs",
>                    "grub-mkimage": "grub-efi",
>                    "isohybrid": "syslinux",
>                    "mcopy": "mtools",
> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
> index 4a5a31e..e6bcc9e 100644
> --- a/scripts/lib/wic/partition.py
> +++ b/scripts/lib/wic/partition.py
> @@ -432,26 +432,25 @@ class Partition():
>              if part.mountpoint:
>                  args = [part.fstype, "mounted at %s" % part.mountpoint]
>              elif part.label:
> -                args = [part.fstype, "labeled %s" % part.label]
> +                args = [part.fstype, "labeled '%s'" % part.label]
>              elif part.part_name:
> -                args = [part.fstype, "in partition %s" % part.part_name]
> +                args = [part.fstype, "in partition '%s'" % part.part_name]
>              else:
> -                args = [part.fstype, ""]
> +                args = [part.fstype, "in partition %s" % part.num]
>              return err.format(*args)
>  
> -        ret, out = exec_native_cmd("dumpe2fs %s" % rootfs, native_sysroot)
> -
>          # ext2 and ext3 are always affected by the Y2038 problem
>          if self.fstype in ["ext2", "ext3"]:
>              logger.warn(get_err_str(self))
>              return
>  
> +        ret, out = exec_native_cmd("dumpe2fs %s" % rootfs, native_sysroot)
> +
>          # if ext4 is affected by the Y2038 problem depends on the inode size
> -        # Remember: inode size depends on the file system size
>          for line in out.splitlines():
>              if line.startswith("Inode size:"):
>                  size = int(line.split(":")[1].strip())
>                  if size < 256:
> -                    logger.warn("%s Inodes (of size %d) are too small." % \
> +                    logger.warn("%s Inodes (of size %d) are too small." %
>                                  (get_err_str(self), size))
> -                break
> \ No newline at end of file
> +                break
> 

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

  parent reply	other threads:[~2021-03-01 17:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-01 18:58 [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems 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
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 [this message]
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=581c68ac-3b56-206a-9898-7b7a21871ac1@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=florian.bezdeka@siemens.com \
    --cc=henning.schild@siemens.com \
    --cc=ibr@radix50.net \
    --cc=isar-users@googlegroups.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