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.

--
Ben Hutchings
Experience is what causes a person to make new mistakes
instead of old ones.


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmcwA0sACgkQ57/I7JWG EQkWEg//bBwivQ/7deJoG7rbHMEbAjrh3f4tPN0ZCgCaG6cVR/KaCn01J/fDgVtH ejlCFwq0JoQypcvwPz4wo642CfI3RCG8uBIbY3mOmM2Gkr1pice9lJrjNdeO1pQj +wWXRVFthkGvpRarU7Qjtl53presANgn38cFKk5784a4aPcn7KnHM8eCdKCWqhXs qgFmTxnEDhXf/urHP5r0PneRy0N55mVfNEb7i7hnUWvx7wWb8AHKK1qnQx9RmdxY I2nUF+jWYzMrdOX/llV+fecARS/M7VHd5fBO7hP8IQgKCOfMed4VyhLts9GUD1se u0TcsHycIGn5QiAUryMWkfW37w4xKcURsi3JpR3M+aHM+/Khd/TKdd7PAk7q5TGu plGwwKrE2j3HWpTDm9UCCiVIzkfrekrZ8ivaRiY3A87eG3uhxB/o6PYOm+drO6Ks mrgBCdfQeOZi1RBSK11iOqd/+YubjwxoT9I3Y/LIbDJvFkxawpLiG7YGgia4IZX0 j7jKMkFE+ZDC+Sy8sKftQIihVhWyjgPzTlKTcelt4YVq+1Fu+KKpFeeltuEU7Qm6 k8cwgxjaSs9Tl8ZtRP1kLoQEFnzm1U952XGXSlvl5ETRLSMOPf5dinFEQANwJAT4 6Ri74vHKmHZQBvPHUtFcyZfMVPMWqYemkFAooT+pCYvwKvstOAc=
=dPo6
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ben Hutchings composed on 2024-11-10 01:50 (UTC+0100):

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.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

jose.r.r composed on 2024-11-09 19:12 (UTC-0800):

Felix Miata wrote:

...

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
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-11-09 17:43, Felix Miata wrote:

Ben Hutchings composed on 2024-11-10 01:50 (UTC+0100):

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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-11-09 19:30, Felix Miata wrote:

jose.r.r composed on 2024-11-09 19:12 (UTC-0800):

Felix Miata wrote:

...

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? ;-)

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

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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ben,

On 10/11/2024 at 01:50, Ben Hutchings wrote:

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 ?

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).

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/11/2024 at 02:43, Felix Miata wrote:

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2024-11-10 at 12:36 +0100, Pascal Hambourg wrote:

Hi Ben,

On 10/11/2024 at 01:50, Ben Hutchings wrote:

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.

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.

--
Ben Hutchings
Experience is what causes a person to make new mistakes
instead of old ones.


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmcw04QACgkQ57/I7JWG EQlGrxAAtcQeFPhgY69nVVTpMW/hCKuCw9iwVJEtoPx0V38oREdrJiuUDToAyxoT nRs2ZoGp2GfosGDR5Yu/ksim3JmYePd67ncJuQTPml36MG4ukAe5tMLbMgDzK9Gj 3uqK6AvhkDoIgFSXRAM2n7XOYjEaijWl7Q3iYfGV9J8zcqSBsaTiZO/W0hiHw52x C1Oi0n9zZBAbb3ugUW8Usm/nmuQ/NOUpjMMAVtqVpRunFjwvBA5t8g89dgOoWKl2 v4Ocxf/Liguu79/QQsC8RCLuaemy7ckyM1GMq5amaYSnmMprHDZo+lOTwKy8Rq9T 4Oi3eyen7k57OY37gWYGvC98+tK2CrPNZREwijvemHLQ8jtQX91enfB63XfYtaKl QiogsHGFxHMG8f8FrM7MDmRaljsmb6TDqdjelC0OvZDSU/RXAQjSrb9g0FEPBw2Y fUMBr9/TY3RSRk++KRDMTeu7bZZJ6inUUSHfUc9LLiBtFgLQ31qsaH5VKj/Gkayh J1iYpwNREzUdV/g2DL2yUQn9teQoOIHx8A+6YDU/0ggrf+SI8ZuQH51kQta73ED5 Xo/RxTdxSnvo7ZqrEtMLWzyHt0YsqOPJdbnH4MRfTxJh4mHN7dFDbhLO6FANvzad D0JLrKQAwzzeGWEu/fMlMLk3vGAR3pGsc4y0ygkfjaGUCVfB4hA=
=0a7g
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Am 10. November 2024 01:50:18 MEZ schrieb Ben Hutchings <ben@decadent.org.uk>: >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



--
Sent from /e/ OS on Fairphone3

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)