console-conf with wlan connection does not ever report ip via tty message, even though it does have ip

[Ian Johnson]

With a Raspberry Pi 4 4G and an arm64 UC20 installation with all beta channel snaps:

core20 20 852 latest/beta canonical✓ base
pi 20-1 76 20/beta canonical✓ gadget
pi-kernel 5.4.0-1020.22 210 20/beta canonical✓ kernel
snapd 2.47 9611 latest/beta canonical✓ snapd

Sometimes when booting up, console-conf on my serial tty will display the message:

```
Ubuntu Core 20 on <no ip address> (ttyS0)

You cannot log in until the system has an IP address. (Is there
supposed to be a DHCP server running on your network?)

Personalize your account at https://login.ubuntu.com.
```

infinitely, even though it does eventually get an IP address. I have tried pressing enter etc. on the console-conf screen and it does continue to show this message about no ip address.

This is not great for user experience because if the user is sitting at a monitor (or serial port) waiting for console-conf to tell them that they can login, then they will think their devices' networking is broken, when in fact it is working.

These are all the journald logs I have from a boot where this presented itself, and after enabling persistent logs, then I rebooted and the same thing happened: https://pastebin.ubuntu.com/p/km3ShfhJqz/

All the console-conf logs are attached

[Ian Johnson (anonymouse67)]

I note that this happens most frequently it seems when using only wlan on my Raspberry Pi 4, and on the first boot back into run mode after having booted into recover mode.

[Bugra Aydogar (bugraaydogar)]

According to my experience, the problem is independent of the network interface. It also occurs with eth0 with UC20.

[Michael Hudson-Doyle (mwhudson)]

Stuff like this is always a pain to debug of course. I can see *a* problem by staring at the code: we are supposed to check every 5s if an ip address has appeared and that's not happening. I'll proposed a PR for that imminently.

But pressing enter should trigger a re-check in that case and you say that doesn't help? Can someone recreate this, press enter well after the device really does have an address and then send me /var/log/console-conf and journald output?

[Bugra Aydogar (bugraaydogar)]

Even if I pressed enter several times(5-10), I end up with the same message. I attached all the logs that I have on my Rpi4. Personally, I could not find/see an informative message. In the meantime, I would like to add your PR(https://github.com/canonical/subiquity/pull/943/) to my system, but it is quite tricky since UC20 is read-only. Do you have any suggestion to pull your changes to my local system without waiting for your changes to be merged?

[Michael Hudson-Doyle (mwhudson)]

Thanks for the logs. Everything looks like it should be working :( Although I am a little confused by your logs: the timestamps in the journal are from May 03 but the timestamps in the console-conf logs are from April 30. Do you have any idea how that is happening? (Is the RTC unreliable on this system?) One of the things that we may be running into here is systemds unit restart limit, so can I get you to try something else: clear out /var/log/console-conf, boot the system, wait like 1 or 2 minutes, then press enter once? Then send the logs and journalctl -b output again?

[Ian Johnson (anonymouse67)]

@mwhudson note that the pi does not have a RTC, so time frequently will show up as incorrect when one first boots up

[Bugra Aydogar (bugraaydogar)]

As Ian mentioned, rpi does not have a RTC, this is the reason of the date/time problem.
In the meantime, I attached new logs. Do you know when your PR will be merged to master so that I can try with the logs that you have added. I'm afraid without getting extra logs, we will not be able to solve this.

[Michael Hudson-Doyle (mwhudson)]

Ah thanks, those logs make more sense. I'd missed a detail of how console-conf-wrapper that makes the bug I originally spotted more important than I'd realized -- basically the text to display is not being "recalculated" on each subsequent execution as it should be. So let's work on getting it into core20 edge at least.

[Michael Hudson-Doyle (mwhudson)]

https://github.com/canonical/subiquity/pull/949

[Ian Johnson (anonymouse67)]

FWIW, if you want to test changes out in the PR before it lands and gets fed into the pipeline and ends up in core20 edge what I usually do for this is to just take the python files that are changed in the PR and replace the same python files in the core20 snap with those and repack the core20 snap with that and build a UC20 image with the dangerous model assertion. Something like this:

```
sudo unsquashfs core20_rev.snap # needs to be done as root
sudo cp ~/git/subiquity/console_conf/cmd/write_login_details.py squashfs-root/usr/share/subiquity/console_conf/cmd/write_login_details.py
sudo snap pack squashfs-root --filename=core20-pr.snap
ubuntu-image snap --snap=core20-pr.snap ~/git/models/ubuntu-core-20-pi-arm64-dangerous.model
```

Note that you have to unpack/repack the core20 snap as root, and you also have to use the dangerous model assertion when building the image

[Bugra Aydogar (bugraaydogar)]

Thanks, Ian. I was too lazy to locally replace the snap.
Anyway, I just had time to check the fix. I can confirm that the suggested changes fix the problem.

[Michael Hudson-Doyle (mwhudson)]

So I think this should be fixed in the next build of core20. I'm not sure when this will happen though. (And sorry for taking so long to get around to looking into it!)

[Łukasz Zemczak (sil2100)]

Ok, I think this should be in core20 edge right now (version 20210520) as core20 now builds console-conf from the subiquity git trunk branch everytime the build runs. It should move automatically once testing is green.