Samuel Thibault, le ven. 12 oct. 2018 03:27:47 +0200, a ecrit: > Samuel Thibault, le ven. 12 oct. 2018 03:02:32 +0200, a ecrit: > > Samuel Thibault, le ven. 12 oct. 2018 00:55:47 +0200, a ecrit: > > > Samuel Thibault, le ven. 12 oct. 2018 00:38:39 +0200, a ecrit: > > > > To be sure, I have installed a VM from scratch with stretch (default > > > > install, just not the graphical desktop task), created a chroot with > > > > pbuilder there, and ran in it, and got the issue there too... > > > > (actually I can't reproduce the issue with the stretch VM, I guess I > > read wrongly previously) > > > > > Doing the same with a VM with buster, I don't get the issue... I'll now > > > be able to check what differences there can be in the chroots. > > > > I dugged more and more... It seems the issue is... that my box hostname > > is "function"... > > Mmm, no, I have changed the hostname of my new "function" VM back to > something else than "function" and I still have the issue there. > > I have checked the chroot's dpkg -l, the environment, / is ext4 with > relatime in both case, the kernel is the same, I even used -cpu host > -smp 4 to expose the same CPU. What else?
I'm thinking... My chroots have a lib -> usr/lib symlink. Could it be that python somehow gets lost between /lib/python* and /usr/lib/python*, and dependending on e.g. inode number or directory order, we could have one way or the other? Right now I have two VMs with almost the same chroot (differences notably lie in .pyc files), one works, the other doesn't. When I mount the chroot of one on the other, the chroot behavior holds (i.e. the failing chroot keeps failing on the VM which produced a working chroot). Samuel