Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #91015 > unrolled thread

Bug#1126710: linux-image-6.18.5+deb14-amd64: unable to mount existing XFS V4 filesystem because kernel CONFIG_XFS_SUPPORT_V4 is not set

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1126710: linux-image-6.18.5+deb14-amd64: unable to mount existing XFS V4 filesystem because kernel CONFIG_XFS_SUPPORT_V4 is not set 10dmar10 <10dmar10@gmail.com> - 2026-01-31 10:20 +0100
    Bug#1126710: linux-image-6.18.5+deb14-amd64: unable to mount existing XFS V4 filesystem because kernel CONFIG_XFS_SUPPORT_V4 is not set Salvatore Bonaccorso <carnil@debian.org> - 2026-01-31 11:10 +0100
    Bug#1126710: linux-image-6.18.5+deb14-amd64: unable to mount existing XFS V4 filesystem because kernel CONFIG_XFS_SUPPORT_V4 is not set 10dmar10 <10dmar10@gmail.com> - 2026-01-31 12:30 +0100
      Bug#1126710: linux-image-6.18.5+deb14-amd64: unable to mount existing XFS V4 filesystem because kernel CONFIG_XFS_SUPPORT_V4 is not set Ben Hutchings <ben@decadent.org.uk> - 2026-02-04 18:20 +0100
        Bug#1126710: linux-image-6.18.5+deb14-amd64: unable to mount existing XFS V4 filesystem because kernel CONFIG_XFS_SUPPORT_V4 is not set 10dmar10 <10dmar10@gmail.com> - 2026-02-05 10:20 +0100
        Bug#1126710: linux-image-6.18.5+deb14-amd64: unable to mount existing XFS V4 filesystem because kernel CONFIG_XFS_SUPPORT_V4 is not set Joe Rayhawk <jrayhawk@fairlystable.org> - 2026-07-14 15:20 +0200

#91015 — Bug#1126710: linux-image-6.18.5+deb14-amd64: unable to mount existing XFS V4 filesystem because kernel CONFIG_XFS_SUPPORT_V4 is not set

Package: src:linux
Version: 6.18.5-1
Severity: normal
X-Debbugs-Cc: 10dmar10@gmail.com

Dear Maintainer,

linux-image-6.18.5+deb14-amd64 seems to be unable to mount existing legacy XFS V4 filesystems
reporting:

XFS (...): Depricated V4 format (crc=0) not supported by kernel.

reason seems to be a missing setting
>  cat /boot/config-6.18.5+deb14-amd64 | grep CONFIG_XFS_SUPPORT_V4
# CONFIG_XFS_SUPPORT_V4 is not set


this setting was recently still enabled:

XFS (sda3): Deprecated V4 format (crc=0) will not be supported after September 2030.

> cat /boot/config-6.17.13+deb14-amd64 | grep CONFIG_XFS_SUPPORT_V4
CONFIG_XFS_SUPPORT_V4=y


while no longer used by default, XFS V4 support is still useful for accessing
legacy XFS V4 file systems as long as kernel supports it.




-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: H410M S2H V3
product_version: Default string
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends International, LLC.
bios_version: F10b
board_vendor: Gigabyte Technology Co., Ltd.
board_name: H410M S2H V3
board_version: Default string

** Configuration for modprobe:
blacklist arkfb
blacklist aty128fb
blacklist atyfb
blacklist radeonfb
blacklist cirrusfb
blacklist cyber2000fb
blacklist kyrofb
blacklist matroxfb_base
blacklist mb862xxfb
blacklist neofb
blacklist pm2fb
blacklist pm3fb
blacklist s3fb
blacklist savagefb
blacklist sisfb
blacklist tdfxfb
blacklist tridentfb
blacklist vt8623fb
blacklist microcode
blacklist sp5100_tco
options snd_pcsp index=-2
options cx88_alsa index=-2
options snd_atiixp_modem index=-2
options snd_intel8x0m index=-2
options snd_via82xx_modem index=-2
options i915 modeset=1
options radeon modeset=1
options bonding max_bonds=0
options dummy numdummies=0
options ifb numifbs=0

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Comet Lake-S 6c Host Bridge/DRAM Controller [8086:9b53] (rev 03)
	DeviceName: Onboard - Other
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:5000]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: <access denied>
	Kernel driver in use: skl_uncore

00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 03) (prog-if 00 [Normal decode])
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:5000]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 120
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 4000-4fff [size=4K] [16-bit]
	Memory behind bridge: 50400000-504fffff [size=1M] [32-bit]
	Prefetchable memory behind bridge: 4080000000-41ffffffff [size=6G] [32-bit]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA+ VGA16+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:14.0 USB controller [0c03]: Intel Corporation Tiger Lake-H USB 3.2 Gen 2x1 xHCI Host Controller [8086:43ed] (rev 11) (prog-if 30 [XHCI])
	DeviceName: Onboard - Other
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:5007]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 139
	Region 0: Memory at 4000100000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

00:14.2 RAM memory [0500]: Intel Corporation Tiger Lake-H Shared SRAM [8086:43ef] (rev 11)
	DeviceName: Onboard - Other
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Region 0: Memory at 4000114000 (64-bit, non-prefetchable) [size=16K]
	Region 2: Memory at 400011a000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

00:16.0 Communication controller [0780]: Intel Corporation Tiger Lake-H Management Engine Interface [8086:43e0] (rev 11)
	DeviceName: Onboard - Other
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:1c3a]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 137
	Region 0: Memory at 4000119000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: mei_me
	Kernel modules: mei_me

00:17.0 SATA controller [0106]: Intel Corporation Device [8086:43d2] (rev 11) (prog-if 01 [AHCI 1.0])
	DeviceName: Onboard - SATA
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:b005]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 123
	Region 0: Memory at 50500000 (32-bit, non-prefetchable) [size=8K]
	Region 1: Memory at 50503000 (32-bit, non-prefetchable) [size=256]
	Region 2: I/O ports at 5050 [size=8]
	Region 3: I/O ports at 5040 [size=4]
	Region 4: I/O ports at 5020 [size=32]
	Region 5: Memory at 50502000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <access denied>
	Kernel driver in use: ahci
	Kernel modules: ahci

00:1c.0 PCI bridge [0604]: Intel Corporation Tiger Lake-H PCI Express Root Port #5 [8086:43bc] (rev 11) (prog-if 00 [Normal decode])
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:5001]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 121
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: [disabled] [16-bit]
	Memory behind bridge: 50300000-503fffff [size=1M] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1d.0 PCI bridge [0604]: Intel Corporation Device [8086:43b2] (rev 11) (prog-if 00 [Normal decode])
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:5001]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin C routed to IRQ 122
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: 3000-3fff [size=4K] [16-bit]
	Memory behind bridge: 50200000-502fffff [size=1M] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1f.0 ISA bridge [0601]: Intel Corporation H510 LPC/eSPI Controller [8086:4388] (rev 11)
	DeviceName: Onboard - Other
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:5001]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0

00:1f.3 Audio device [0403]: Intel Corporation Device [8086:f0c8] (rev 11) (prog-if 00 [HDA compatible])
	DeviceName: Onboard - Sound
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:a184]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 32, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 141
	Region 0: Memory at 4000110000 (64-bit, non-prefetchable) [size=16K]
	Region 4: Memory at 4000000000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_soc_avs, snd_hda_intel

00:1f.4 SMBus [0c05]: Intel Corporation Tiger Lake-H SMBus Controller [8086:43a3] (rev 11)
	DeviceName: Onboard - Other
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:5001]
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at 4000118000 (64-bit, non-prefetchable) [size=256]
	Region 4: I/O ports at efa0 [size=32]
	Kernel driver in use: i801_smbus
	Kernel modules: i2c_i801

00:1f.5 Serial bus controller [0c80]: Intel Corporation Tiger Lake-H SPI Controller [8086:43a4] (rev 11)
	DeviceName: Onboard - Other
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Region 0: Memory at 50504000 (32-bit, non-prefetchable) [size=4K]

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] (rev ef) (prog-if 00 [VGA controller])
	Subsystem: Sapphire Technology Limited Radeon RX 570 Pulse ITX 4GB [1da2:e343]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 142
	Region 0: Memory at 4100000000 (64-bit, prefetchable) [size=4G]
	Region 2: Memory at 4080000000 (64-bit, prefetchable) [size=2M]
	Region 4: I/O ports at 4000 [size=256]
	Region 5: Memory at 50400000 (32-bit, non-prefetchable) [size=256K]
	Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: amdgpu
	Kernel modules: amdgpu

01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] [1002:aaf0] (prog-if 00 [HDA compatible])
	Subsystem: Sapphire Technology Limited Device [1da2:aaf0]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 140
	Region 0: Memory at 50460000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

02:00.0 Non-Volatile memory controller [0108]: Sandisk Corp SanDisk Ultra 3D / WD Blue SN570 NVMe SSD (DRAM-less) [15b7:501a] (prog-if 02 [NVM Express])
	Subsystem: Sandisk Corp SanDisk Ultra 3D / WD Blue SN570 NVMe SSD (DRAM-less) [15b7:501a]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at 50300000 (64-bit, non-prefetchable) [size=16K]
	Region 4: Memory at 50304000 (64-bit, non-prefetchable) [size=256]
	Capabilities: <access denied>
	Kernel driver in use: nvme
	Kernel modules: nvme

03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 16)
	Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet [1458:e000]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: I/O ports at 3000 [size=256]
	Region 2: Memory at 50204000 (64-bit, non-prefetchable) [size=4K]
	Region 4: Memory at 50200000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: r8169
	Kernel modules: r8169


** USB devices:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 046d:c01e Logitech, Inc. MX518 Optical Mouse
Bus 001 Device 003: ID 041e:3274 Creative Technology, Ltd Sound Blaster Play! 4
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub


-- System Information:
Debian Release: forky/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.17.13+deb14-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-6.18.5+deb14-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.150
ii  kmod                                    34.2-2+b1
ii  linux-base                              4.15
ii  linux-base-6.18.5+deb14-amd64           6.18.5-1

Versions of packages linux-image-6.18.5+deb14-amd64 recommends:
pn  apparmor  <none>

Versions of packages linux-image-6.18.5+deb14-amd64 suggests:
pn  debian-kernel-handbook  <none>
pn  firmware-linux-free     <none>
ii  grub-pc                 2.14~git20250718.0e36779-2
pn  linux-doc-6.18          <none>

Versions of packages linux-image-6.18.5+deb14-amd64 is related to:
ii  firmware-amd-graphics      20251111-1
pn  firmware-atheros           <none>
pn  firmware-bnx2              <none>
pn  firmware-bnx2x             <none>
pn  firmware-brcm80211         <none>
pn  firmware-cavium            <none>
pn  firmware-cirrus            <none>
pn  firmware-intel-graphics    <none>
pn  firmware-intel-misc        <none>
pn  firmware-intel-sound       <none>
pn  firmware-ipw2x00           <none>
pn  firmware-ivtv              <none>
pn  firmware-iwlwifi           <none>
pn  firmware-libertas          <none>
pn  firmware-marvell-prestera  <none>
pn  firmware-mediatek          <none>
ii  firmware-misc-nonfree      20251111-1
pn  firmware-myricom           <none>
pn  firmware-netronome         <none>
pn  firmware-netxen            <none>
pn  firmware-nvidia-graphics   <none>
pn  firmware-qcom-soc          <none>
pn  firmware-qlogic            <none>
ii  firmware-realtek           20251111-1
pn  firmware-samsung           <none>
pn  firmware-siano             <none>
pn  firmware-ti-connectivity   <none>
pn  xen-hypervisor             <none>

-- no debconf information

[toc] | [next] | [standalone]

#91018

Hi,

On Sat, Jan 31, 2026 at 10:08:25AM +0100, 10dmar10 wrote:
> Package: src:linux
> Version: 6.18.5-1
> Severity: normal
> X-Debbugs-Cc: 10dmar10@gmail.com
> 
> Dear Maintainer,
> 
> linux-image-6.18.5+deb14-amd64 seems to be unable to mount existing legacy XFS V4 filesystems
> reporting:
> 
> XFS (...): Depricated V4 format (crc=0) not supported by kernel.
> 
> reason seems to be a missing setting
> >  cat /boot/config-6.18.5+deb14-amd64 | grep CONFIG_XFS_SUPPORT_V4
> # CONFIG_XFS_SUPPORT_V4 is not set
> 
> 
> this setting was recently still enabled:
> 
> XFS (sda3): Deprecated V4 format (crc=0) will not be supported after September 2030.
> 
> > cat /boot/config-6.17.13+deb14-amd64 | grep CONFIG_XFS_SUPPORT_V4
> CONFIG_XFS_SUPPORT_V4=y
> 
> 
> while no longer used by default, XFS V4 support is still useful for accessing
> legacy XFS V4 file systems as long as kernel supports it.

This is correct, the default was changed in upstream with f69260511c69
("xfs: disable deprecated features by default in Kconfig") and I
believe we should follow that within the forky release cycle. 

Thus for forky I do not think we should diverge here from the default
and re-enable deprecated features, but probably we should document it
at least in the release notes so that people upgrading from trixie to
forky are awaere that V4 filesystems will not be supported anymore.

A NEWS entry in the packaging itself might be a good idea as well.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#91019

Am 31.01.26 um 11:02 schrieb Salvatore Bonaccorso:
 > Hi,
 >
 > On Sat, Jan 31, 2026 at 10:08:25AM +0100, 10dmar10 wrote:
 >> Package: src:linux
 >> Version: 6.18.5-1
 >> Severity: normal
 >> X-Debbugs-Cc: 10dmar10@gmail.com
 >>
 >> Dear Maintainer,
 >>
 >> linux-image-6.18.5+deb14-amd64 seems to be unable to mount existing legacy 
XFS V4 filesystems
 >> reporting:
 >>
 >> XFS (...): Depricated V4 format (crc=0) not supported by kernel.
 >>
 >> reason seems to be a missing setting
 >>>   cat /boot/config-6.18.5+deb14-amd64 | grep CONFIG_XFS_SUPPORT_V4
 >> # CONFIG_XFS_SUPPORT_V4 is not set
 >>
 >>
 >> this setting was recently still enabled:
 >>
 >> XFS (sda3): Deprecated V4 format (crc=0) will not be supported after 
September 2030.
 >>
 >>> cat /boot/config-6.17.13+deb14-amd64 | grep CONFIG_XFS_SUPPORT_V4
 >> CONFIG_XFS_SUPPORT_V4=y
 >>
 >>
 >> while no longer used by default, XFS V4 support is still useful for accessing
 >> legacy XFS V4 file systems as long as kernel supports it.
 >
 > This is correct, the default was changed in upstream with f69260511c69
 > ("xfs: disable deprecated features by default in Kconfig") and I
 > believe we should follow that within the forky release cycle.
 >
 > Thus for forky I do not think we should diverge here from the default
 > and re-enable deprecated features, but probably we should document it
 > at least in the release notes so that people upgrading from trixie to
 > forky are awaere that V4 filesystems will not be supported anymore.
 >
 > A NEWS entry in the packaging itself might be a good idea as well.
 >
 > Regards,
 > Salvatore

Hi,

I wrote this bug report because I assumed the release interval for forky as 2027 
-2030, which is within the kernel removal date for XFS V4 feature in 2030.

Enabling CONFIG_XFS_SUPPORT_V4 would allow to continue running otherwise 
perfectly fine existing legacy XFS V4 filesystems without unnecessary breaking 
anything within forky's release cycle...

[toc] | [prev] | [next] | [standalone]

#91071

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2026-01-31 at 12:26 +0100, 10dmar10 wrote:
> Am 31.01.26 um 11:02 schrieb Salvatore Bonaccorso:
>  > Hi,
>  >
>  > On Sat, Jan 31, 2026 at 10:08:25AM +0100, 10dmar10 wrote:
[...]
>  >> while no longer used by default, XFS V4 support is still useful for accessing
>  >> legacy XFS V4 file systems as long as kernel supports it.
>  >
>  > This is correct, the default was changed in upstream with f69260511c69
>  > ("xfs: disable deprecated features by default in Kconfig") and I
>  > believe we should follow that within the forky release cycle.
>  >
>  > Thus for forky I do not think we should diverge here from the default
>  > and re-enable deprecated features, but probably we should document it
>  > at least in the release notes so that people upgrading from trixie to
>  > forky are awaere that V4 filesystems will not be supported anymore.
>  >
>  > A NEWS entry in the packaging itself might be a good idea as well.
>  >
>  > Regards,
>  > Salvatore
> 
> Hi,
> 
> I wrote this bug report because I assumed the release interval for forky as 2027 
> -2030, which is within the kernel removal date for XFS V4 feature in 2030.

Debian stable releases are supported for 5 years on the most popular
architectures.  So for forky this should be 2027-2032.

> Enabling CONFIG_XFS_SUPPORT_V4 would allow to continue running otherwise 
> perfectly fine existing legacy XFS V4 filesystems without unnecessary breaking 
> anything within forky's release cycle...

Those filesystems must be quite old at this point, since v5 appears to
have been the default for new filesystems since xfsprogs 3.2.3 and
Debian 9 "stretch".  And they do need to be upgraded at some point due
to the upstream EOL (and later, Y2038).  How much would we gain by
putting it off another 2 years?

I agree with Salvatore that this just needs to be documented.

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular.
                                                      - Adlai Stevenson

[toc] | [prev] | [next] | [standalone]

#91079

Am 04.02.26 um 18:10 schrieb Ben Hutchings:
> On Sat, 2026-01-31 at 12:26 +0100, 10dmar10 wrote:
>> Am 31.01.26 um 11:02 schrieb Salvatore Bonaccorso:
>>   > Hi,
>>   >
>>   > On Sat, Jan 31, 2026 at 10:08:25AM +0100, 10dmar10 wrote:
> [...]
>>   >> while no longer used by default, XFS V4 support is still useful for accessing
>>   >> legacy XFS V4 file systems as long as kernel supports it.
>>   >
>>   > This is correct, the default was changed in upstream with f69260511c69
>>   > ("xfs: disable deprecated features by default in Kconfig") and I
>>   > believe we should follow that within the forky release cycle.
>>   >
>>   > Thus for forky I do not think we should diverge here from the default
>>   > and re-enable deprecated features, but probably we should document it
>>   > at least in the release notes so that people upgrading from trixie to
>>   > forky are awaere that V4 filesystems will not be supported anymore.
>>   >
>>   > A NEWS entry in the packaging itself might be a good idea as well.
>>   >
>>   > Regards,
>>   > Salvatore
>>
>> Hi,
>>
>> I wrote this bug report because I assumed the release interval for forky as 2027
>> -2030, which is within the kernel removal date for XFS V4 feature in 2030.
> 
> Debian stable releases are supported for 5 years on the most popular
> architectures.  So for forky this should be 2027-2032.
> 
>> Enabling CONFIG_XFS_SUPPORT_V4 would allow to continue running otherwise
>> perfectly fine existing legacy XFS V4 filesystems without unnecessary breaking
>> anything within forky's release cycle...
> 
> Those filesystems must be quite old at this point, since v5 appears to
> have been the default for new filesystems since xfsprogs 3.2.3 and
> Debian 9 "stretch".  And they do need to be upgraded at some point due
> to the upstream EOL (and later, Y2038).  How much would we gain by
> putting it off another 2 years?
> 
> I agree with Salvatore that this just needs to be documented.
> 
> Ben.
> 

Hi,

my point is not about "How much would we gain by putting it off another 2 
years?", but about not loosing an existing reliably working capability for 
another 4 years. AFAIK the only significant change between V4 and V5 XFS is crc 
for metadata scrubbing...

[toc] | [prev] | [next] | [standalone]

#93345

[Multipart message — attachments visible in raw view] — view raw

Quoting Ben Hutchings (2026-02-04 09:10:36)
> On Sat, 2026-01-31 at 12:26 +0100, 10dmar10 wrote:
> > Am 31.01.26 um 11:02 schrieb Salvatore Bonaccorso:
> >  > Hi,
> >  >
> >  > On Sat, Jan 31, 2026 at 10:08:25AM +0100, 10dmar10 wrote:
> [...]
> >  >> while no longer used by default, XFS V4 support is still useful for accessing
> >  >> legacy XFS V4 file systems as long as kernel supports it.
> >  >
> >  > This is correct, the default was changed in upstream with f69260511c69
> >  > ("xfs: disable deprecated features by default in Kconfig") and I
> >  > believe we should follow that within the forky release cycle.
> >  >
> >  > Thus for forky I do not think we should diverge here from the default
> >  > and re-enable deprecated features, but probably we should document it
> >  > at least in the release notes so that people upgrading from trixie to
> >  > forky are awaere that V4 filesystems will not be supported anymore.
> >  >
> >  > A NEWS entry in the packaging itself might be a good idea as well.
> 
> > Enabling CONFIG_XFS_SUPPORT_V4 would allow to continue running otherwise 
> > perfectly fine existing legacy XFS V4 filesystems without unnecessary breaking 
> > anything within forky's release cycle...
> 
> Those filesystems must be quite old at this point, since v5 appears to
> have been the default for new filesystems since xfsprogs 3.2.3 and
> Debian 9 "stretch".  And they do need to be upgraded at some point due
> to the upstream EOL (and later, Y2038).  How much would we gain by
> putting it off another 2 years?

"Why break 7 year old filesystems in 4 years when we can break them
today?" is a bizarre sentiment, especially when using upstream support
involves a one-line change and nobody has written an upgrade path yet.

Please let your users use upstream support.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web