Hi,
[ Quoting in full for debian-boot@'s benefit ]
Roland Clobus <
rclobus@rclobus.nl> (2025-05-19):
Hello maintainers of the kernel,
The new kernel (6.12.29) has a modified behaviour (compared to
6.12.27) for the loop device.
This causes the Debian live images (for sid) to fail to boot.
The change happened between 20250518T201633Z and 20250519T021902Z, which matches the upload of 6.12.29 (https://tracker.debian.org/news/1646619/accepted-linux-signed-amd64-612291-source-into-unstable/)
at 20250518T230426Z.
To reproduce:
* Download the daily live image from https://openqa.debian.net/tests/396941/asset/iso/smallest-build_sid_20250519T021902Z.iso
* Boot into the live image (the first boot option)
* Result: an initramfs shell (instead of a live system) -> FAIL
* Try: `losetup -r /dev/loop1 /run/live/medium/live/filesystem.squashfs`
* Result: `failed to set up loop device: invalid argument` -> FAIL
* Try: `cp /run/live/medium/live/filesystem.squashfs /`
* Try: `losetup -r /dev/loop2 /filesystem.squashfs`
* Result: `loop2: detected capacity change from 0 to 1460312` -> PASS
It appears that the loopback device cannot be used any more with the mount /run/live/medium (which is on /dev/sr0).
I've verified: the md5sum of the squashfs file is OK.
The newer kernel is not in trixie yet.
Skimming over the upstream changes between .27 and .29, maybe this one?
loop: Add sanity check for read/write_iter
[ Upstream commit f5c84eff634ba003326aa034c414e2a9dcb7c6a7 ]
Some file systems do not support read_iter/write_iter, such as selinuxfs
in this issue.
So before calling them, first confirm that the interface is supported and
then call it.
It is releavant in that vfs_iter_read/write have the check, and removal
of their used caused szybot to be able to hit this issue.
Fixes: f2fed441c69b ("loop: stop using vfs_iter__{read,write} for buffered I/O")
Reported-by:
syzbot+6af973a3b8dfd2faefdc@syzkaller.appspotmail.com
Closes:
https://syzkaller.appspot.com/bug?extid=6af973a3b8dfd2faefdc
Signed-off-by: Lizhi Xu <
lizhi.xu@windriver.com>
Reviewed-by: Christoph Hellwig <
hch@lst.de>
Link:
https://lore.kernel.org/r/20250428143626.3318717-1-lizhi.xu@windriver.com
Signed-off-by: Jens Axboe <
axboe@kernel.dk>
Signed-off-by: Sasha Levin <
sashal@kernel.org>
New checks, about the baking file, returning EINVAL…
I have no idea about any of this works, but checking something about
read and *write*, when we're dealing with /dev/sr0… should an option
be added somewhere to be explicit about the source's being read-only?
- 184b147b9f7f07577567a80fcc9314f2bd0b0b00 (6.12.y):
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=184b147b9f7f07577567a80fcc9314f2bd0b0b00
- f5c84eff634ba003326aa034c414e2a9dcb7c6a7 (mainline):
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f5c84eff634ba003326aa034c414e2a9dcb7c6a7
Cheers,
--
Cyril Brulebois (
kibi@debian.org) <
https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmgrDa4ACgkQ/5FK8MKz VSBgmxAAr8xZxHkTwPTiWOiCKD9l0yQM5x++DxlMZcRkySpAnCLk9XGwrByne7Wz Bv6B6zoH34n9ft7SkrL2CO1iElB7FU+Hn1LdKmqDL+k+pacRGSbDT9VIiswTr2ab is0i0C9lKp/0Wl1GQ2gQXjKeAwiVGnk/RbhKVFrhEVw5kGsiRjVRhGaqveh3U0+1 SHHo8N0fCw9mZ1InAY2oyO2FCmuoQBgJjJZlcAU2qpznQRV3kwQj15409lYhcSHv UCFs3gK07A9zYWyqgUiNfaHFSmkisf7PiMd0OfiVgRh3YnuXm3ruy5QssHiZ2tTM IaR7+/RT6GbpnxDPGCwd5WpNqHk4QrRbSt7CNFEzjfZWZ0OmKH5tJNRmATuDotas 5ybyqrxYtS5AiyKmyv0swuVAlQpeiD0N3B92aAjo/Q7+4H//3y688uqdX6SG/SJv 4eBCbKGWNumZevDrfGCZpLzXAqwadkHhbG+ArzKdccnZiocIhAO5N3OgG91rIYTL T8xKeyRGlaWAK2pbwHvgjS960wcD9sFSoC17xAlW69eQ8FaUk5z2tG8IFKkR9AvS 2KQrvh4BCugXVGsjAf8n4KAVAhHHqW7mpTKpMvCnC8OXBNjdpfkT0cMvJvLCGnul NRg2z2K3+Y7MasnzVz1LV8vphadt2PyJFqWoX7oDNIFb9DB3/4g=
=CFzp
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
*