Re: Bug#1106070: linux-image-6.12.29-amd64: loop device cannot mount live squashfs any more

Cyril Brulebois <[email protected]> Mon, 19 May 2025 12:53:41 +0200

Newsgroups	gmane.linux.debian.devel.quality-assurance,gmane.linux.debian.ports.amd64,gmane.linux.debian.devel.boot
Organization	Debian
Message-ID	<[email protected]>

Hi,

[ Quoting in full for debian-boot@'s benefit ]

Roland Clobus <[email protected]> (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: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=6af973a3b8dfd2faefdc
    Signed-off-by: Lizhi Xu <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

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 ([email protected])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

signature.asc (application/pgp-signature, 833 B)