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