Bug#987368: Installer fails at first menu "Choose language"
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. steve@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
Reply to: