Thanks Cyril, Frédéric - it feels like we're reaching a consensus that udpkg may not be multi-process safe (although, strictly speaking, I would say we haven't proven that yet).
The authors of multi-console support could be the best people to recommend a path forward, as they may have close knowledge of the level of testing and completion of the change. I've attempted to add them as subscribers to the bug although I expect that is opt-in and I'm not sure whether I added them correctly. Until any feedback from them, I'll mention a few possible routes that had occurred to me: - Backtracking: if we feel this is a problem that would likely affect and/or annoy a significant number of users, we could disable multi-console support for bullseye - Known-issue: if we feel the issue is serious but rare, we could indicate that it is a known problem (and perhaps prepare and document workarounds) - Scripting fix: we could perhaps adjust the installation scripts so that d-i runs in a single-process condition until after udpkg has completed, and only begin multiple debian-installer processes after that - Process-safety fix: in some sense an 'ideal' fix, we could add multi-process safety to udpkg, either by using careful rewriting or perhaps by using a lockfile or other safety mechanism(s) Some related factors to consider: - Do we advertise and support multi-process debian-installer support in our documentation? - Do we have availability of developer expertise for udpkg, including review and QA time? - Could/should the distance to a release date of Debian bullseye be a factor? Cheers, James On Mon, 31 May 2021 at 10:31, Frédéric Bonnard <fre...@debian.org> wrote: > > Hi Cyril/all, > sorry that the process takes long, but that was the only way to > reproduce that bug (which I think may not be specific to ppc64el) > without having Power hardware (and a LPAR/HMC setup). > > > Looking at that log, one sees two PIDs for main-menu (272 and 278), > > which could explain a very nice race condition: udpkg racing, one of > > them making the status file disappear from under the feet of the other > > one? > > My feeling is that this is exactly what's happening. > I tried touching the missing file and the installer was happy because > the called process (udpkg from what I remember) does not crash anymore > (one can try udpkg without status file and it will crash). > > > See also two /sbin/debian-installer processes getting started beforehand > > (one on /dev/hvc0, one on /dev/tty). > > Exactly. > > > It looks to me this is a clear problem on the debian-installer side (how > > it deals with multiple consoles, similar to #940028 as you mentioned > > initially), rather than some possible issues with emulation? > > To me, it's clearly not a qemu issue, since I have that issue on > physical machines too. I just went the emulation way to enable people > without hardware to reproduce the bug. It's more a race condition of > running two debian-installers (not sure now who is remove the status > file, probably udpkg ?). > > The point is that some work has already been done by several people on > those multiple consoles setup according to the git commits , and I guess > they will clearly get a grasp of what's going on. > > > F.