Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition
Thanks Bastian, I was able to reproduce this only with dracut, using a virtual machine I tried both dracut and initramfs. There seems to be a different problem at play indeed: mag 22 21:44:12 rosebud systemd-journald[358]: Journal started mag 22 21:44:12 rosebud systemd-journald[358]: Runtime Journal (/run/log/journal/022ce7df193548d6ab2007cb814f1d04) is 8.0M, max 640.1M, 632.1M free. mag 22 21:44:12 rosebud systemd-modules-load[359]: Inserted module 'msr' mag 22 21:44:12 rosebud systemd-modules-load[359]: Inserted module 'bfq' mag 22 21:44:12 rosebud dracut-cmdline[387]: dracut-dracut-060+5-8 mag 22 21:44:12 rosebud dracut-cmdline[387]: Using kernel command line parameters: rd.driver.pre=btrfs rd.luks.uuid=luks-13bd3015-55c4-40d3- a805-4d5f2b90ac1f root=/dev/mapper/root rootfstype=btrfs rootflags=rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=608,su bvol=/rootfs,subvol=rootfs BOOT_IMAGE=/vmlinuz-6.8.9-amd64 root=UUID=6fd6a999-b02d-4856-8412-64dff369d45f ro rootflags=subvol=rootfs rd.luks.name=13bd3015-55c4-40d3-a805- 4d5f2b90ac1f=root rd.luks.allow-discards quiet splash mag 22 21:44:12 rosebud systemd[1]: Starting systemd-tmpfiles- setup.service - Create Volatile Files and Directories... mag 22 21:44:12 rosebud systemd[1]: Started systemd-journald.service - Journal Service. mag 22 21:44:12 rosebud dracut-cmdline[444]: //lib/dracut/hooks/cmdline/00-parse-root.sh: line 28: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby- uuid\x2f6fd6a999-b02d-4856-8412-64dff369d45f.sh: Read-only file system mag 22 21:44:12 rosebud dracut-cmdline[387]: //lib/dracut/hooks/cmdline/00-parse-root.sh: line 38: /lib/dracut/hooks/emergency/80-\x2fdev\x2fdisk\x2fby-uuid\x2f6fd6a999- b02d-4856-8412-64dff369d45f.sh: Read-only file system mag 22 21:44:12 rosebud systemd[1]: Finished systemd-tmpfiles- setup.service - Create Volatile Files and Directories. mag 22 21:44:12 rosebud systemd-escape[471]: Input 'root' is not an absolute file system path, escaping is likely not going to be reversible. mag 22 21:44:12 rosebud dracut-cmdline[387]: //lib/dracut/hooks/cmdline/30-parse-crypt.sh: line 169: /lib/dracut/hooks/initqueue/finished/90-crypt.sh: Read-only file system mag 22 21:44:12 rosebud dracut-cmdline[387]: //lib/dracut/hooks/cmdline/30-parse-crypt.sh: line 126: /lib/dracut/hooks/emergency/90-crypt.sh: Read-only file system mag 22 21:44:12 rosebud systemd[1]: Finished dracut-cmdline.service - dracut cmdline hook. mag 22 21:44:12 rosebud systemd[1]: Starting dracut-pre-udev.service - dracut pre-udev hook... ... mag 22 21:44:16 rosebud dracut-initqueue[752]: rm: cannot remove '/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby- uuid\x2f09CB-D388.sh': Read-only file system mag 22 21:44:16 rosebud dracut-initqueue[754]: rm: cannot remove '/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby- uuid\x2f469f76d8-6293-4fd4-ad46-180c7bd186f4.sh': Read-only file system I apologize for the confusion. I kindly ask you to close this bug as invalid. Thanks again, Matteo Il giorno dom, 19/05/2024 alle 21.24 +0200, Bastian Blank ha scritto: > Control: tags -1 moreinfo > Control: severity -1 important > > On Sat, May 18, 2024 at 10:25:14PM +0200, Matteo Settenvini wrote: > > booting kernel 6.8.9-1 with dracut, systemd, and btrfs as the root > > device fails > > to mount the root partition. I just tried the kernel from sid and > > it seems indeed \ > > affected. The 6.7 kernel from trixie is instead booting fine even > > after > > regenerating all initrds. > > Please provide proper error messages. > > Also dracut is not the default option, so please check with > initramfs-tools as well. > > Bastian
Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition
TWIMC, the problem systemd is facing due to the removal of a obsolete option (that might or might not lead to the problem this bug is about) was finally properly reported upstream now – and from the first reply is sounds like a workaround is likely to be expected: https://lore.kernel.org/all/ZkxZT0J-z0GYvfy8@gardel-login/
Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition
Control: tags -1 moreinfo Control: severity -1 important On Sat, May 18, 2024 at 10:25:14PM +0200, Matteo Settenvini wrote: > booting kernel 6.8.9-1 with dracut, systemd, and btrfs as the root device > fails > to mount the root partition. I just tried the kernel from sid and it seems > indeed \ > affected. The 6.7 kernel from trixie is instead booting fine even after > regenerating all initrds. Please provide proper error messages. Also dracut is not the default option, so please check with initramfs-tools as well. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition
On Sat, 18 May 2024 22:25:14 +0200 Matteo Settenvini wrote: > > booting kernel 6.8.9-1 with dracut, systemd, and btrfs as the root device > fails > to mount the root partition. I just tried the kernel from sid and it seems > indeed \ > affected. The 6.7 kernel from trixie is instead booting fine even after > regenerating all initrds. > > According to bl...@debian.org, this is likely due to > https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66 Would be great to know what the actual problem is. Are there any error messages from systemd or the kernel? The upstream bug (https://github.com/systemd/systemd/pull/32892 ) about this also does not state what goes wrong (either in general or certain situations). Such details would likely be needed to convince the btrfs upstream devs to revert the change or apply a workaround -- especially as I'm pretty sure there are already a lot of btrfs systems with systemd and 6.8 (release upstream 2+ month ago and regularly used in Arch, Fedora and Tumbleweed for weeks now) out there and working just fine (including the Fedora machine one I write from). Thorsten
Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition
Control: reassign -1 src:linux Control: severity -1 grave On Sun, 19 May 2024 15:25:06 +0200 Salvatore Bonaccorso wrote: > Control: reassign -1 src:systemd > > On Sat, May 18, 2024 at 10:25:14PM +0200, Matteo Settenvini wrote: > > Package: src:linux > > Version: 6.8.9-1 > > Severity: important > > Tags: upstream > > > > Dear Maintainer, > > > > booting kernel 6.8.9-1 with dracut, systemd, and btrfs as the root device fails > > to mount the root partition. I just tried the kernel from sid and it seems indeed \ > > affected. The 6.7 kernel from trixie is instead booting fine even after > > regenerating all initrds. > > > > According to bl...@debian.org, this is likely due to > > https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66 > > > > See https://lwn.net/Articles/973997/ > > The deprecation was there for a while indeed and dropped by upstream > for 6.8-rc1. But it looks systemd is adressing this with > > https://github.com/systemd/systemd/commit/e3828d7103a99a15a1e947ba3063294ead590631 > > As we wont apply a local Debian patch unless upstream Linux decides to > facilitate this by adding a noop option back, then I think it's best > to reassign this bug to systemd and close it once the above change is > applied. Sorry, but I am reassigning back and bumping severity to stop migration, as this is a kernel regression, as a stable userspace interface was removed, which breaks booting existing systems. Hence I am quite sure the new kernel should not move to testing for the time being. We might (or might not, still to be seen, given detecting mount options that a kernel support is an absolute mess and it risks breaking booting with the LTS kernels) put in a workaround in userspace in a while, but this really should be reverted in the kernel. If mount options are no longer required, they should simply remain as no-ops. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition
Control: reassign -1 src:systemd On Sat, May 18, 2024 at 10:25:14PM +0200, Matteo Settenvini wrote: > Package: src:linux > Version: 6.8.9-1 > Severity: important > Tags: upstream > > Dear Maintainer, > > booting kernel 6.8.9-1 with dracut, systemd, and btrfs as the root device > fails > to mount the root partition. I just tried the kernel from sid and it seems > indeed \ > affected. The 6.7 kernel from trixie is instead booting fine even after > regenerating all initrds. > > According to bl...@debian.org, this is likely due to > https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66 > > See https://lwn.net/Articles/973997/ The deprecation was there for a while indeed and dropped by upstream for 6.8-rc1. But it looks systemd is adressing this with https://github.com/systemd/systemd/commit/e3828d7103a99a15a1e947ba3063294ead590631 As we wont apply a local Debian patch unless upstream Linux decides to facilitate this by adding a noop option back, then I think it's best to reassign this bug to systemd and close it once the above change is applied. Regards, Salvatore
Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition
Package: src:linux Version: 6.8.9-1 Severity: important Tags: upstream Dear Maintainer, booting kernel 6.8.9-1 with dracut, systemd, and btrfs as the root device fails to mount the root partition. I just tried the kernel from sid and it seems indeed \ affected. The 6.7 kernel from trixie is instead booting fine even after regenerating all initrds. According to bl...@debian.org, this is likely due to https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66 See https://lwn.net/Articles/973997/ Cheers, Matteo Settenvini -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: System manufacturer product_name: System Product Name product_version: System Version chassis_vendor: Default string chassis_version: Default string bios_vendor: American Megatrends Inc. bios_version: 5003 board_vendor: ASUSTeK COMPUTER INC. board_name: ROG STRIX X570-E GAMING board_version: Rev X.0x ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] Subsystem: ASUSTeK Computer Inc. Device [1043:87c0] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] DeviceName: Onboard IGD Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61) Subsystem: ASUSTeK Computer Inc. Device [1043:87c0] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 02:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:57a3] (prog-if 00 [Normal decode]) Subsystem: ASUSTeK Computer Inc. Device [1043:87c0] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 02:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:57a3] (prog-if 00 [Normal decode]) Subsystem: ASUSTeK Computer Inc. Device [1043:87c0] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Ker