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
Attachment:
signature.asc
Description: PGP signature