public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "vijaikumar....@gmail.com" <vijaikumar.kanagarajan@gmail.com>
To: isar-users <isar-users@googlegroups.com>
Subject: Re: [PATCH] wic: Warn if an ext filesystem affected by the Y2038 problem is used
Date: Mon, 1 Mar 2021 07:58:06 -0800 (PST)	[thread overview]
Message-ID: <03ba323b-d1f3-4315-b596-f9fa93622e29n@googlegroups.com> (raw)
In-Reply-To: <eec7371ea10cba9c957e39e28f8eacee72c2a890.camel@siemens.com>


[-- Attachment #1.1: Type: text/plain, Size: 4402 bytes --]



On Monday, March 1, 2021 at 9:08:26 PM UTC+5:30 florian...@siemens.com 
wrote:

> On Mon, 2021-03-01 at 07:23 -0800, vijaikumar....@gmail.com wrote: 
> > 
> > 
> > On Monday, March 1, 2021 at 8:49:34 PM UTC+5:30 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") 
> > > 
> > 
> > 
> > I believe we could uprev wic to a version that includes this patch, 
> > instead of cherry-picking this. 
>
> It's not a cherry-pick because the RFC series has already been merged 
> into ISAR before it was merged upstream. It's a real backport.  
>

As I see, these are the missing pieces of the RFC patch which got merged 
recently.
The backport is actually spread across 2 commits.

Maybe we could modify the commit message to reflect that.

Thanks,
Vijai Kumar K


> wic of ISAR and upstream (openembedded-core) have diverged, so just 
> picking the recent upstream version would overwrite all the changes 
> that were never upstreamed. I can't even test that, so someone else has 
> to do that. 
>
> > 
> > Thanks, 
> > Vijai Kumar K 
> >   
> > > 
> > > 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...@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 
> > > -- 
> > > 2.29.2 
> > > 
>
>

[-- Attachment #1.2: Type: text/html, Size: 5815 bytes --]

  reply	other threads:[~2021-03-01 15:58 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 [this message]
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=03ba323b-d1f3-4315-b596-f9fa93622e29n@googlegroups.com \
    --to=vijaikumar.kanagarajan@gmail.com \
    --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