Argh... Minor thing: James, please don't top-post on Debian lists. It breaks conversation threads, particularly when others are doing inline quoting.
On Sun, Jun 06, 2021 at 10:08:09PM +0100, James Addison wrote: >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. I saw nothing here, I'm afraid. But I do read debian-boot when I have the time. >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) Looking at the history in this bug, things are not working as we hoped when we added the multi-console support. When I initially worked with Wookey on this, we didn't see errors like this at all in testing. That's not to say that there's *not* a problem here, but maybe other changes made since then have caused it to be uncovered. Multi-console support is a significant improvement for a number of non-x86 users. This is particularly the case for those with arm64 systems where the firmware might default to the primary console being a serial port but the user doesn't even know that. We wanted to be able to start d-i on all the likely-looking consoles (serial *and* tty *and* graphical), allowing the user to interact with the one they preferred. In our testing, I don't remember ever seeing udpkg invocations racing against each other like this. But in my own testing for d-i Bullseye RC2 in an arm64 VM here I've just seen this exact problem myself so it's clearly a thing! I'm looking at udpkg now to see what I can do there. I'm hoping that it might be a reasonably quick fix use filesytem-based locking around status file updates. -- Steve McIntyre, Cambridge, UK. st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer