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. st...@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.