Re: [PATCH] wic: Warn if an ext filesystem affected by the Y2038 problem is used

[Jan Kiszka <jan.kiszka@siemens.com>]

On 02.03.21 10:20, Henning Schild wrote:
> We usually try to not backport but bump the whole bitbake. There have
> been exceptions, but usually because maintainer did not enforce that,
> not because commits have been "super important".
> While this one looks good, i would say it does not justify such forking
> and will need to wait for the next bitbake version bump.
> 
> But feel free to bump all of bitbake, might be smooth or a significant
> amount of work.

s/bitbake/wic/g, I suspect...

Jan

> 
> Henning
> 
> Am Mon, 1 Mar 2021 16:18:23 +0100
> schrieb Florian Bezdeka <florian.bezdeka@siemens.com>:
> 
>> This is the backport for upstream (openembedded-core)
>> eecbe6255584 ("wic: Warn if an ext filesystem affected by the Y2038
>> problem is used")
>>
>> 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
>