Re: [regression] linux: Loop-mounted UDF ISOs no longer readable

[Zhao Mengmeng]

On 2024/12/21 03:49, Salvatore Bonaccorso wrote:
> Hi Jan, hi Zhao,
> 
> In Debian we got he following report, full quoted below from Daniel
> Reichelt, dass after updating to 6.1.115 (and later, confirmed up to
> 6.1.119), loop-mounted UDF ISOs are no longer readable:

Sorry to hear that...

>> Hi,
>>
>> in 6.1.112-1 I could loop-mount Windows Setup ISOs (downloaded from M$; hashes
>> are fine; 10/11, DE/EN don't seem to make any difference) and access their
>> content perfectly fine, i.e. share the /sources/ sub-directory via samba for
>> netinstall scenarios.
>>
>> Starting with 6.1.115-1, the ISOs can be mounted, the root-dir is accessible
>> and `stat $mntpt/sources` gives output as well. However `ls $mntpt/sources`
>> hangs and the kernel log is spammed with entries like
>>
>> ---------------8<-------------------------
>> 2024-12-11T14:53:19.616728+01:00 srv kernel: [182394.024828] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>> 2024-12-11T14:53:19.629970+01:00 srv kernel: [182394.038041] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>> 2024-12-11T14:53:19.641623+01:00 srv kernel: [182394.049714] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>> 2024-12-11T14:53:19.654841+01:00 srv kernel: [182394.062928] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>> 2024-12-11T14:53:19.666495+01:00 srv kernel: [182394.074615] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>> 2024-12-11T14:53:19.679747+01:00 srv kernel: [182394.087833] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>> 2024-12-11T14:53:19.691394+01:00 srv kernel: [182394.099510] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>> 2024-12-11T14:53:19.704646+01:00 srv kernel: [182394.112727] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>> 2024-12-11T14:53:19.716283+01:00 srv kernel: [182394.124400] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>> 2024-12-11T14:53:19.729539+01:00 srv kernel: [182394.137618] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>> 2024-12-11T14:53:19.741185+01:00 srv kernel: [182394.149279] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>> 2024-12-11T14:53:19.754422+01:00 srv kernel: [182394.162494] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>> 2024-12-11T14:53:19.766071+01:00 srv kernel: [182394.174159] UDF-fs: error (device loop3): udf_fiiter_advance_blk: extent after position 12272 not allocated in directory (ino 312)
>> 2024-12-11T14:53:19.779289+01:00 srv kernel: [182394.187375] UDF-fs: error (device loop3): udf_verify_fi: directory (ino 312) has too big (2088) entry at pos 12272
>> ---------------8<-------------------------
>>
>>
>> 6.1.119-1 shows the same behaviour.
>> Let me know if you need additional info.
> 
> We have not a full bisect, but Daniel confirmed already in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089698#22 some
> observations:
> 
>> OK:
>>   6.1.112-1
>> BAD:
>>   6.1.115-1
>>   6.1.119-1
>> OK again:
>>   6.3.1-1~exp1
>>   current trixie
>>   current sid
> 
> (current trixie is 6.11.10 based kernel, current sid is based on
> 6.12.5 kernel).
> 
> Dies this ring some bell to you?

I'll take a look at it. Will post it here if anything new founded.

> #regzbot introduced: v6.1.112..v6.1.115
> #regzbot monitor: https://bugs.debian.org/1089698
> 
> Regards,
> Salvatore