[Touch-packages] [Bug 1881935] Re: Minimum inode size should be raised to 256 for forward compatibility (Y2038)
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: e2fsprogs (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1881935
Title:
Minimum inode size should be raised to 256 for forward compatibility
(Y2038)
Status in e2fsprogs package in Ubuntu:
Confirmed
Bug description:
mke2fs in all supported Ubuntu releases to date creates 'small' ext4
file systems with an inode size of 128. This is said to be
insufficient to store time stamps referring to year 2038 and later
(when the Unix epoch exceeds a signed 32-bit integer -
https://en.wikipedia.org/wiki/Year_2038_problem). When such file
systems are mounted by the kernel, such as a /boot file system created
by the Ubuntu 20.04.0 Desktop installer (ubiquity 20.04.15), the
kernel will warn about this fact:
kernel: ext4 filesystem being mounted at /boot supports timestamps
until 2038 (0x7fff)
Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953494
Admittedly, that's another 18 years, by when most systems installed
now will be no longer in use, or will have been reinstalled.
Also, on a /boot file system the 5.4.0-33-generic #37 Ubuntu (20.04) kernel
warned about this, I was able to
$ touch -t 203812312359 /tmp/test
and got
$ ls -l /tmp/test
-rw-r--r-- 1 root root 0 Dez 31 2038 /tmp/test
so this warning may not always apply, or patches may have been applied to
handle this situation more gracefully already.
Ubuntu 20.04 comes with e2fsprogs 1.45.5-2ubuntu1. Theodore Y. Ts'o
has submitted patches for Debian's 1.45.6-1 - but (strictly speaking
based on the changelog) these seem to be limited to documentation
changes.
Still, creating such file systems may seem undesirable in terms of
forward compatibility. I therefore suggest to change the minimum inode
size for mke2fs, as defined in /etc/mke2fs.conf, to 256 for all file
systems which do not already use this value (maybe with the exception
of floppies). That is, I suggest the following change to Ubuntu
20.04's /etc/mke2fs.conf:
Before change:
small = {
inode_size = 128
inode_ratio = 4096
}
After change:
small = {
inode_ratio = 4096
}
This assumes that the default inode size is already set to 256 further
above.
As a WORKAROUND, after backing up the file system (this command is not well
tested, according to the lead ext4 file system developer), users can unmount
the affected file system and run
tune2fs -I 256 /path/to/block_device
where /path/to/block_device should be replaced by the path to the block
device which contains the file system the kernel reports the warning for. For
example, for the file system mounted at /boot, the
findmnt /boot
command would return the block device path in the SOURCE column.
Please note I prefer not to use apport for this bug report, I believe it is
already sufficiently complete.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1881935/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1881935] Re: Minimum inode size should be raised to 256 for forward compatibility (Y2038)
It seems the default was fixed in upstream at
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/misc/mke2fs.conf.in?id=a23b50cdb55cb826b8745cbc37429c93f7b60c66
Also, it seems Ubuntu 22.04 has a version of e2fsprogs (1.46.5-2ubuntu1)
which includes this change. Thus I think this bug can be closed as
resolved.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1881935
Title:
Minimum inode size should be raised to 256 for forward compatibility
(Y2038)
Status in e2fsprogs package in Ubuntu:
Confirmed
Bug description:
mke2fs in all supported Ubuntu releases to date creates 'small' ext4
file systems with an inode size of 128. This is said to be
insufficient to store time stamps referring to year 2038 and later
(when the Unix epoch exceeds a signed 32-bit integer -
https://en.wikipedia.org/wiki/Year_2038_problem). When such file
systems are mounted by the kernel, such as a /boot file system created
by the Ubuntu 20.04.0 Desktop installer (ubiquity 20.04.15), the
kernel will warn about this fact:
kernel: ext4 filesystem being mounted at /boot supports timestamps
until 2038 (0x7fff)
Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953494
Admittedly, that's another 18 years, by when most systems installed
now will be no longer in use, or will have been reinstalled.
Also, on a /boot file system the 5.4.0-33-generic #37 Ubuntu (20.04) kernel
warned about this, I was able to
$ touch -t 203812312359 /tmp/test
and got
$ ls -l /tmp/test
-rw-r--r-- 1 root root 0 Dez 31 2038 /tmp/test
so this warning may not always apply, or patches may have been applied to
handle this situation more gracefully already.
Ubuntu 20.04 comes with e2fsprogs 1.45.5-2ubuntu1. Theodore Y. Ts'o
has submitted patches for Debian's 1.45.6-1 - but (strictly speaking
based on the changelog) these seem to be limited to documentation
changes.
Still, creating such file systems may seem undesirable in terms of
forward compatibility. I therefore suggest to change the minimum inode
size for mke2fs, as defined in /etc/mke2fs.conf, to 256 for all file
systems which do not already use this value (maybe with the exception
of floppies). That is, I suggest the following change to Ubuntu
20.04's /etc/mke2fs.conf:
Before change:
small = {
inode_size = 128
inode_ratio = 4096
}
After change:
small = {
inode_ratio = 4096
}
This assumes that the default inode size is already set to 256 further
above.
As a WORKAROUND, after backing up the file system (this command is not well
tested, according to the lead ext4 file system developer), users can unmount
the affected file system and run
tune2fs -I 256 /path/to/block_device
where /path/to/block_device should be replaced by the path to the block
device which contains the file system the kernel reports the warning for. For
example, for the file system mounted at /boot, the
findmnt /boot
command would return the block device path in the SOURCE column.
Please note I prefer not to use apport for this bug report, I believe it is
already sufficiently complete.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1881935/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1881935] Re: Minimum inode size should be raised to 256 for forward compatibility (Y2038)
This relatively simple to change the default inode size in all cases.
Look at /etc/mke2fs.conf, which is in the sources as
misc/mke2fs.conf.in. Find the lines where the inode_size is set to
128, and change it to be 256. (This might or might cause problems on
Hurd; since I'm not sure whether the GNU Hurd can support modern file
systems with 256 byte inodes. Heck, the GNU Hurd implementation doesn't
support journalling or extents last I checked.)
This will double the overhead of ext4 file systems, especially on small
file systems. This is why the default is set the way that it is. For
really tiny thumb drives (especially the cheap ones found in the
checkout aisle of the Micro Center), they are very likely to self-
destruct within a few months, never mind 18 years. And users might get
cranky if the amount of usable space is decreased.
It may be that for the installer, it will want to hard code the use of a
larger inode size, or specify a file system usage type hint via the -T
option which could trigger a different default in mke2fs.conf.This
is fundamentally a policy question, not a technical issue --- and
different distributions may have different opinions about what the
defaults should be; this is why we've made it easy to customize the
defaults should be in misc/mke2fs.conf.in in the sources, as opposed to
hard-coding it in the misc/mke2fs.c source file.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1881935
Title:
Minimum inode size should be raised to 256 for forward compatibility
(Y2038)
Status in e2fsprogs package in Ubuntu:
New
Bug description:
mke2fs in all supported Ubuntu releases to date creates 'small' ext4
file systems with an inode size of 128. This is said to be
insufficient to store time stamps referring to year 2038 and later
(when the Unix epoch exceeds a signed 32-bit integer -
https://en.wikipedia.org/wiki/Year_2038_problem). When such file
systems are mounted by the kernel, such as a /boot file system created
by the Ubuntu 20.04.0 Desktop installer (ubiquity 20.04.15), the
kernel will warn about this fact:
kernel: ext4 filesystem being mounted at /boot supports timestamps
until 2038 (0x7fff)
Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953494
Admittedly, that's another 18 years, by when most systems installed
now will be no longer in use, or will have been reinstalled.
Also, on a /boot file system the 5.4.0-33-generic #37 Ubuntu (20.04) kernel
warned about this, I was able to
$ touch -t 203812312359 /tmp/test
and got
$ ls -l /tmp/test
-rw-r--r-- 1 root root 0 Dez 31 2038 /tmp/test
so this warning may not always apply, or patches may have been applied to
handle this situation more gracefully already.
Ubuntu 20.04 comes with e2fsprogs 1.45.5-2ubuntu1. Theodore Y. Ts'o
has submitted patches for Debian's 1.45.6-1 - but (strictly speaking
based on the changelog) these seem to be limited to documentation
changes.
Still, creating such file systems may seem undesirable in terms of
forward compatibility. I therefore suggest to change the minimum inode
size for mke2fs, as defined in /etc/mke2fs.conf, to 256 for all file
systems which do not already use this value (maybe with the exception
of floppies). That is, I suggest the following change to Ubuntu
20.04's /etc/mke2fs.conf:
Before change:
small = {
inode_size = 128
inode_ratio = 4096
}
After change:
small = {
inode_ratio = 4096
}
This assumes that the default inode size is already set to 256 further
above.
As a WORKAROUND, after backing up the file system (this command is not well
tested, according to the lead ext4 file system developer), users can unmount
the affected file system and run
tune2fs -I 256 /path/to/block_device
where /path/to/block_device should be replaced by the path to the block
device which contains the file system the kernel reports the warning for. For
example, for the file system mounted at /boot, the
findmnt /boot
command would return the block device path in the SOURCE column.
Please note I prefer not to use apport for this bug report, I believe it is
already sufficiently complete.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1881935/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1881935] Re: Minimum inode size should be raised to 256 for forward compatibility (Y2038)
Actually this is not an installer issue, just indirectly.
** Package changed: ubiquity (Ubuntu) => e2fsprogs (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1881935
Title:
Minimum inode size should be raised to 256 for forward compatibility
(Y2038)
Status in e2fsprogs package in Ubuntu:
New
Bug description:
mke2fs in all supported Ubuntu releases to date creates 'small' ext4
file systems with an inode size of 128. This is said to be
insufficient to store time stamps referring to year 2038 and later
(when the Unix epoch exceeds a signed 32-bit integer -
https://en.wikipedia.org/wiki/Year_2038_problem). When such file
systems are mounted by the kernel, such as a /boot file system created
by the Ubuntu 20.04.0 Desktop installer (ubiquity 20.04.15), the
kernel will warn about this fact:
kernel: ext4 filesystem being mounted at /boot supports timestamps
until 2038 (0x7fff)
Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953494
Admittedly, that's another 18 years, by when most systems installed
now will be no longer in use, or will have been reinstalled.
Also, on a /boot file system the 5.4.0-33-generic #37 Ubuntu (20.04) kernel
warned about this, I was able to
$ touch -t 203812312359 /tmp/test
and got
$ ls -l /tmp/test
-rw-r--r-- 1 root root 0 Dez 31 2038 /tmp/test
so this warning may not always apply, or patches may have been applied to
handle this situation more gracefully already.
Ubuntu 20.04 comes with e2fsprogs 1.45.5-2ubuntu1. Theodore Y. Ts'o
has submitted patches for Debian's 1.45.6-1 - but (strictly speaking
based on the changelog) these seem to be limited to documentation
changes.
Still, creating such file systems may seem undesirable in terms of
forward compatibility. I therefore suggest to change the minimum inode
size for mke2fs, as defined in /etc/mke2fs.conf, to 256 for all file
systems which do not already use this value (maybe with the exception
of floppies). That is, I suggest the following change to Ubuntu
20.04's /etc/mke2fs.conf:
Before change:
small = {
inode_size = 128
inode_ratio = 4096
}
After change:
small = {
inode_ratio = 4096
}
This assumes that the default inode size is already set to 256 further
above.
As a WORKAROUND, after backing up the file system (this command is not well
tested, according to the lead ext4 file system developer), users can unmount
the affected file system and run
tune2fs -I 256 /path/to/block_device
where /path/to/block_device should be replaced by the path to the block
device which contains the file system the kernel reports the warning for. For
example, for the file system mounted at /boot, the
findmnt /boot
command would return the block device path in the SOURCE column.
Please note I prefer not to use apport for this bug report, I believe it is
already sufficiently complete.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1881935/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
