partman recipes and deprecation of ext2

[Ben Hutchings]

Hi all,

The ext2 filesystem uses 32-bit timestamps and will be unable to
represent timestamps beyond early 2038. It is now deprecated in Linux
for this reason.

As we're generally moving to 64-bit time times in the trixie release, I
think it's time to address this in partman, so far as possible.

Currently many of the partman recipes specify ext2 for the /boot
partition. In some cases I expect that this is necessary due to
limitations of older boot loaders. For mainstream architectures using
GRUB to boot, ext4 can be used for the /boot partition.

Should I start proposing specific changes or does someone else have
time to work on this?

Ben.

[Felix Miata]

Post by Ben Hutchings
The ext2 filesystem uses 32-bit timestamps and will be unable to
represent timestamps beyond early 2038. It is now deprecated in Linux
for this reason.
As we're generally moving to 64-bit time times in the trixie release, I
think it's time to address this in partman, so far as possible.
Currently many of the partman recipes specify ext2 for the /boot
partition. In some cases I expect that this is necessary due to
limitations of older boot loaders. For mainstream architectures using
GRUB to boot, ext4 can be used for the /boot partition.
Should I start proposing specific changes or does someone else have
time to work on this?

Last week I was under a misunderstanding that upgrading EXT2 filesystems to EXT4
would be a satisfactory solution to eventual 64 bit timestamp support necessity,
when it turns out some EXT4 filesystems suffer the same condition. EXT4 supported,
and supports, inode size 128, as does EXT2. I had quite a number of EXT2, as well
as having EXT4 configured with 128. Only after I managed to get most of my EXT2s
converted to EXT4 did I discover the 128 byte inodes on those converted from EXT2
to EXT4 do not support timestamps after January 2038. Furthermore, EXT4
filesystems with feature flex_bg cannot be converted to 256 byte inode size by
simply using e2fsck and tune2fs. So, all those already converted EXT2s need
another conversion, /and/ many more than not of my (much large quantity of) EXT4s
need complete reformats. :(

Simply switching to EXT4 for /boot/ won't go far enough. Small sizes of those
EXT4s suited to /boot/ use by default feature 128 byte inodes. Formatting those
may require explicit use of '-I 256', and/or a change to mke2fs.conf to prevent
small EXT4s from misfeaturing 128 byte inodes.

[j***@metztli.com]

Post by Felix Miata

Post by Ben Hutchings
The ext2 filesystem uses 32-bit timestamps and will be unable to
represent timestamps beyond early 2038. It is now deprecated in Linux
for this reason.
As we're generally moving to 64-bit time times in the trixie release, I
think it's time to address this in partman, so far as possible.
Currently many of the partman recipes specify ext2 for the /boot
partition. In some cases I expect that this is necessary due to
limitations of older boot loaders. For mainstream architectures using
GRUB to boot, ext4 can be used for the /boot partition.
Should I start proposing specific changes or does someone else have
time to work on this?

Last week I was under a misunderstanding that upgrading EXT2
filesystems to EXT4
would be a satisfactory solution to eventual 64 bit timestamp support necessity,
when it turns out some EXT4 filesystems suffer the same condition. EXT4 supported,
and supports, inode size 128, as does EXT2. I had quite a number of EXT2, as well
as having EXT4 configured with 128. Only after I managed to get most of my EXT2s
converted to EXT4 did I discover the 128 byte inodes on those converted from EXT2
to EXT4 do not support timestamps after January 2038. Furthermore, EXT4
filesystems with feature flex_bg cannot be converted to 256 byte inode size by
simply using e2fsck and tune2fs. So, all those already converted EXT2s need
another conversion, /and/ many more than not of my (much large quantity of) EXT4s
need complete reformats. :(
Simply switching to EXT4 for /boot/ won't go far enough. Small sizes of those
EXT4s suited to /boot/ use by default feature 128 byte inodes.
Formatting those
may require explicit use of '-I 256', and/or a change to mke2fs.conf to prevent
small EXT4s from misfeaturing 128 byte inodes.

Niltze [Hello], Mr. 'Team OS/2' peer -

Have you considered using JFS for your /boot partition(s)? Just a
suggestion, of course!
--
Best Professional Regards.

--
Jose R R
http://metztli.it
---------------------------------------------------------------------------------------------
OS/2 for SMP v2.11 with HPFS386 hack: https://vimeo.com/894930798
---------------------------------------------------------------------------------------------
Download Metztli Reiser4: Debian Bookworm w/ Linux 5.17.13-1 AMD64
---------------------------------------------------------------------------------------------
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
-------------------------------------------------------------------------------------------
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/

[Felix Miata]

...

Post by j***@metztli.com
Niltze [Hello], Mr. 'Team OS/2' peer -
Have you considered using JFS for your /boot partition(s)? Just a
suggestion, of course!

The "J" in JFS means journal…, correct? My use of EXT2 was intended originally due
to lack of need for journal on small file system with few files, rarely written
to, and infrequently read from. That situation hasn't materially changed. I've
never used JFS on Linux or OS/2. EXT4 with absent journal and 256 byte inodes will
do for the foreseeable future. :~D

[j***@metztli.com]

Post by Felix Miata
...

Post by j***@metztli.com
Niltze [Hello], Mr. 'Team OS/2' peer -
Have you considered using JFS for your /boot partition(s)? Just a
suggestion, of course!

The "J" in JFS means journal…, correct? My use of EXT2 was intended originally due
to lack of need for journal on small file system with few files, rarely written
to, and infrequently read from.

Indeed, until a crash leaves your EXT[x-y-z] /boot partition trashed but
you don't worry because you create frequent backups of those /boot
files/and or partition, right? ;-)

Post by Felix Miata
That situation hasn't materially changed. I've
never used JFS on Linux or OS/2.

OS/2 LVM enabled multiple JFS partitions and/or disks to be accessed as
a single letter drive:. Quite useful except that OS/2 LVM was not
compatible with GNU/Linux, i.e.,
'Accessing Data On OS/2 JFS Partitions With GNU/Linux Debian':
<
https://metztli.blog/Metztli-bits/accessing-data-on-os-2-jfs-partitions-with-gnu-linux-debian

Post by Felix Miata
EXT4 with absent journal and 256 byte inodes will
do for the foreseeable future. :~D

--
Best Professional Regards.

--
Jose R R
http://metztli.it
---------------------------------------------------------------------------------------------
OS/2 for SMP v2.11 with HPFS386 hack: https://vimeo.com/894930798
---------------------------------------------------------------------------------------------
Download Metztli Reiser4: Debian Bookworm w/ Linux 5.17.12-3 AMD64
---------------------------------------------------------------------------------------------
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
-------------------------------------------------------------------------------------------
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/

[Pascal Hambourg]

Post by Felix Miata
Last week I was under a misunderstanding that upgrading EXT2 filesystems to EXT4
would be a satisfactory solution to eventual 64 bit timestamp support necessity,

Upgrade of existing filesystems is outside of partman scope.

Post by Felix Miata
Simply switching to EXT4 for /boot/ won't go far enough. Small sizes of those
EXT4s suited to /boot/ use by default feature 128 byte inodes. Formatting those
may require explicit use of '-I 256', and/or a change to mke2fs.conf to prevent
small EXT4s from misfeaturing 128 byte inodes.

AFAICS /etc/mke2fs.conf already has "inode_size = 256" even for small
filesystems (except for hurd) in bookworm.

[Pascal Hambourg]

Hi Ben,

Post by Ben Hutchings
The ext2 filesystem uses 32-bit timestamps and will be unable to
represent timestamps beyond early 2038. It is now deprecated in Linux
for this reason.

What exactly is deprecated ? The ext2 standalone driver (which is
disabled in Debian kernels), ext2 support in the ext4 driver, or both ?

IIUC 64-bit timestamps require at least 256-byte inodes, and ext2
supports 256-byte inodes. Or am I missing something ?

Post by Ben Hutchings
As we're generally moving to 64-bit time times in the trixie release, I
think it's time to address this in partman, so far as possible.
Currently many of the partman recipes specify ext2 for the /boot
partition. In some cases I expect that this is necessary due to
limitations of older boot loaders. For mainstream architectures using
GRUB to boot, ext4 can be used for the /boot partition.

partman-auto currently has two kinds of recipes:
- those which always create a /boot partition (alpha, non-efi arm*,
hppa, mipsel, some powerpc and ppc64, sparc*)
- those which create an optional /boot partition only with LVM (default,
efi, some power-pc and ppc64, ppc64el, riscv64)

I guess that the first kind are for architectures which may use boot
loaders which do not support ext4, and the second kind could use ext4 or
$default_filesystem (used for the root partition in all recipes, default
is set to ext4 for linux in partman-base).

Post by Ben Hutchings
Should I start proposing specific changes or does someone else have
time to work on this?

I helped prepare the recent changes in partman-auto recipes and can help
implementing this change but I do not know about limitations of boot
loaders other than grub. As part of the recent changes, partman-auto now
includes a script which generates default recipes and recipes for
"current" architectures: amd64, armhf, arm64, ppc64el, riscv64. Updating
and running this script in the source tree should be the preferred way
of updating built-in recipes.

[Ben Hutchings]

Post by Pascal Hambourg
Hi Ben,

Post by Ben Hutchings
The ext2 filesystem uses 32-bit timestamps and will be unable to
represent timestamps beyond early 2038. It is now deprecated in Linux
for this reason.

What exactly is deprecated ? The ext2 standalone driver (which is
disabled in Debian kernels), ext2 support in the ext4 driver, or both ?

The ext2 standalone driver is deprecated. I assumed this meant that
extended timestamps are not allowed in the ext2 format, because
otherwise they could have been added to that driver.

Post by Pascal Hambourg
IIUC 64-bit timestamps require at least 256-byte inodes, and ext2
supports 256-byte inodes. Or am I missing something ?

[...]

No, it appears you are right and we don't need to change this.

(I do think it would be a good idea to use a more robust filesystem for
/boot anyway, but that's a separate issue.)

We do have a lingering problem of systems originally installed with
buster or earlier, that use 128-byte inodes. But I don't think there's
much we can do about that other than tell the affected users to
reinstall before 2038.

Ben.

[Holger Wansing]

Hi,

Post by Ben Hutchings
Hi all,
The ext2 filesystem uses 32-bit timestamps and will be unable to
represent timestamps beyond early 2038. It is now deprecated in Linux
for this reason.
As we're generally moving to 64-bit time times in the trixie release, I
think it's time to address this in partman, so far as possible.
Currently many of the partman recipes specify ext2 for the /boot
partition. In some cases I expect that this is necessary due to
limitations of older boot loaders. For mainstream architectures using
GRUB to boot, ext4 can be used for the /boot partition.
Should I start proposing specific changes or does someone else have
time to work on this?

There is also a MR on this, BTW:
<https://salsa.debian.org/installer-team/partman-auto/-/merge_requests/8>


Holger