Bug#987368: Installer fails at first menu "Choose language"
On Thu, Jun 10, 2021 at 12:11:05AM +0100, Steve McIntyre wrote:
>
>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.
Having experimented with exactly that, after a little bit of tweaking
I think I've fixed the bug. Previously I could reproduce this bug
readily, ~75% of the time on my local arm64 VM. With my new udpkg
build included, I've just run things through a dozen times in
succession with no problem encountered. I think that's good enough, so
I've pushed and uploaded a new udpkg into unstable.
Please check back in a couple of days with a daily build and validate
this fixes things for you too.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.
Reply to: