Bug#1080207: lxde and lxqt bookworm live images fail to install without network

On Tue, Sep 03, 2024 at 10:20:37PM +0200, Roland Clobus wrote:
>> Hello Steve, list,
>> 
>> On 31/08/2024 19:47, Steve McIntyre wrote:
>> > Found in testing of the 12.7.0 live images.
>> > 
>> > Doing a live installation using calamares from either of these images
>> > fails if no network is available.
>> 
>> That is an openQA-scenario that I have been working on, but did not
>> complete yet.
>
>That scenario is now active in openQA.
>Trixie and sid appear not to be affected.

ACK.

>> > Running /usr/sbin/bootloader-config fails to install the appropriate
>> > grub packages and times out after 600 seconds.
>
>[snip]
>
>> > Sequence of issues:
>> > 
>> > 1. /etc/apt/sources.list for the image has deb.debian.org listed above
>> >     the on-media packages. Has that changed in live-build?
>> 
>> The 11.4 image (built with live-wrapper) only has deb.debian.org in
>> /etc/apt/sources.list
>> There is no difference in content of sources.list between the 12.6.0 and
>> 12.7.0 live images.
>> 
>> Interestingly, the order in sources.list appears to matter.
>> I've recently manually tested a sid gnome image with Calamares without
>> network and all lines in sources.list are attempted, until one works.
>> Here in the 12.7.0 lxde image, if the local repository is mentioned
>> first, the installation of grub-efi-amd64 happens in a few seconds, no
>> network access is being attempted.

Yes, I would expect that to be the case.

>> Changing the order doesn't work for the Calamares installer, Calamares
>> creates its own variant of this file when installing.

Bah.

>> > 2. Connman is running a DNS server on 127.0.0.1, which apt uses to
>> >     look up deb.debian.org
>> > 3. That DNS server does not fail if no network is available. Instead,
>> >     it hangs.
>> 
>> This is a new regression. It should have failed quickly.
>
>It turns out that 12.6 was slow as well but just made it within the 600
>seconds limit, so this is not a regression as I first thought.

Hmmm. I don't remember seeing this at all when we tested 12.6. I'd
have expected testers to mention a long delay here.

>In that case, there is no need to rush things, and we can try to fix it for
>the 12.8 release.

Sure, that's all we can do at this point. There's at least an obvious
workaround here - just connect to a network.