Package: dracut-install Followup-For: Bug #1079443 X-Debbugs-Cc: tj.iam...@proton.me
I've managed to set up a gdb-multilib debug session and have been single-stepping through the glibc fts_* code that seems to be affected. As Chris has found that xfs file-system doesn't seem to be affected but ext4 is (the host file-system, not the file-system created by debvm) that confuses the issue somewhat since the reproducers also work on a several different kernel versions. I'm using a mainline build of v6.10.6 amd64; Chris reported 6.1.0-23-arm64. In my debug case the setup is in two terminals. I execute dracut-install directly using qemu (rather than in the chroot) in order to be able to do: debian/debvm$ base=$PWD/debvm.fs; qemu-arm-static -g 9999 -L $base $base/usr/lib/dracut/dracut-install -D $base/var/tmp/ --kerneldir $base/lib/modules/6.10.6-armmp --firmwaredirs $base/lib/firmware/updates/6.10.6-armmp:$base/lib/firmware/updates:$base/lib/firmware/6.10.6-armmp:$base/lib/firmware --debug -m =drivers/block I fetched the glibc source so gdb can use it: $ cd /srv/NAS/Sunny/SourceCode/glibc $ dget -x http://deb.debian.org/debian/pool/main/g/glibc/glibc_2.39-7.dsc In the second terminal, in the dracut-ng base directory, I do: dracut-ng$ gdb-multiarch -ex "directory /srv/NAS/Sunny/SourceCode/glibc/glibc-2.39" -ex "file /srv/NAS/Sunny/SourceCode/debian/debvm/debvm.fs/usr/lib/dracut/dracut-install" -ex "set sysroot /srv/NAS/Sunny/SourceCode/debian/debvm/debvm.fs" -ex "target remote localhost:9999" -ex "break install_modules" -ex "break fts_open" -ex "break fts_build if sp->fts_path[2] != 'y'" That last conditional breakpoint is to avoid it stopping for all nodes at or under "/sys/devices/platform". Then using 'c' to fast-forward to the useful points, looking for the ".../kernel/drivers/block" in sp->fts_path (gdb) p *sp $8 = {fts_cur = 0x400160f8, fts_child = 0x0, fts_array = 0x0, fts_dev = 1792, fts_path = 0x40012450 "/srv/NAS/Sunny/SourceCode/debian/debvm/debvm.fs/lib/modules/6.10.6-armmp/kernel/drivers/block", fts_rfd = 0, fts_pathlen = 4352, fts_nitems = 0, fts_compar = 0x0, fts_options = 15} >From here the loop that I believe should be iterating over the files and sub-dirs via calling __readdir() does zero iterations due to __readdir() presumably returning NULL and setting an error code. I've not yet traced into that; that's for another day I think. The loop: https://codesearch.debian.net/show?file=glibc_2.39-7%2Fio%2Ffts.c&line=723#L723
