Ubuntu: packagekit cannot refresh cache whilst offline

[skluthe]

In the web interface when trying to check for updates I get "Cannot refresh cache whilst offline" meanwhile when I ssh into the machine I can run pkcon get-updates and it will show an update available.

This machine is running a reverse proxy and I can let you login to take a look. This happens on almost every 16.04 machine I have. Please let me know if you have any other information.

---

As a workaround you can create any NetworkManager connection, like this one:

 nmcli con add type dummy con-name fake ifname fake0 ip4 1.2.3.4/24 gw4 1.2.3.1

[skluthe]

Added another network interface and enabled it via network-manager and it's now working.

[martinpitt]

This is a known limitation with Ubuntu16.04's NetworkManager. If it is installed, it needs to manage at least one interface, otherwise it reports to the system that it's "offline". PackageKit queries this. This got fixed in later Ubuntu releases. There's not much we can do on the Cockpit side, I'm afraid.

[greenpoise]

I am running a clean 19.04 installation and I am getting this error. Cant find too much information about how to fix it. Last resort, post here and see if there is a solution. Otherwise on to the next one.

[martinpitt]

@greenpoise: I noticed that as well, I had to reintroduce the test workaround in commit ab3740d. I'm afraid I don't know a better workaround there either. Supposedly in your installation you have NetworkManager running, but it's not actually managing anything? (nmcli d) In a server install, Ubuntu uses networkd by default (via netplan).

[ipl-adm]

Had same error on clean debian9. In Applications was an error "Cannot refresh cache whilst offline".

[ipl-adm]

There is my settings for network-interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens18
iface ens18 inet static
        address 194.147.35.237/24
        gateway 194.147.35.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 77.88.8.8
        dns-search kvm.u30051

[mxwlsavard]

I'm running Ubuntu 19.04 server and not using Network Manager (as confirmed by running nmcli d):

$ nmcli d
DEVICE           TYPE       STATE         CONNECTION
wlx0007324c2ce7  wifi       disconnected  --
enp1s0           ethernet   unmanaged     --
lo               loopback   unmanaged     --
wg0              wireguard  unmanaged     --

so I just stopped Network Manager (sudo systemctl stop NetworkManager.service) and everything appears to be working still so I disabled it from starting again (sudo systemctl disable NetworkManager.service) and now I can check for updates in Cockpit!

[ghost]

(sudo systemctl stop NetworkManager.service) and everything appears to be working still so I disabled it from starting again (sudo systemctl disable NetworkManager.service) and now I can check for updates in Discover (Debian Linux) too!

[fersalme]

Hi, I did have the same problem on ubuntu 16.04.5 LTS and the message "offline errors when no using NetworkManager" from PackageKit. I saw the same problem on this post http://nicolasjolet.blogspot.com/2017/02/resolve-cannot-download-packages-whilst.html. So, I edited /etc/NetworkManager/NetworkManager.conf , on only this part [ifupdown] managed=false and I changed for [ifupdown] managed=true and restarted the service with sudo service NetworkManager restart. I fixed the problem and now I can check for updates!

[cinderblock]

EDIT: Note: This issue is a top hit for certain error strings that come up in more recent versions of Ubuntu. Just wanted to add some tips for future people that come across this.

Neither stopping NetworkManager nor setting managed=true (and restarting) worked for me with a very fresh install of Ubuntu 19.10.

I had to disable NetworkManager and do a full restart.

---

Update: Trying again, all it took was:

sudo systemctl disable network-manager.service
sudo systemctl stop network-manager.service

---

Update again:

It was some combination of disabling/stopping network-manager.service that made it work. I've had it where two simple commands worked. I've had it where I had to do a restart too.

[leedickey]

This seems to have returned for Ubuntu 20.04.

[edherpaulinelli]

This procedure worked very well on my Debian Buster - 10.3.

[ICarryTheDustOfAJourney]

After stopping network-manager, the network-tab in Cockpit remains blank.
After sudo service network-manager start, the network-tab comes back but updates aren't working.

Stopping network-manager is not really a good solution here
(Ubuntu Server 20.04)

[khushil]

On 19.10 this doesn't resolve the problem...

sudo systemctl disable network-manager.service
sudo systemctl stop network-manager.service

[Cu64]

I'm on Ubuntu Server 20.04. Stopping and disabling NetworkManager then reboot worked for me.

[HyderKhalil]

Also experiencing this error message on Ubuntu Server 20.04

[UnixNight]

Still happening on Ubuntu Server 20.04 although I do see my ethernet adapter as an unmanaged interface

[HyderKhalil]

I'm on Ubuntu Server 20.04. Stopping and disabling NetworkManager then reboot worked for me.

Worked for me too on 20.04 and Cockpit 215.

[bootrec]

I'm on Ubuntu Server 20.04. Stopping and disabling NetworkManager then reboot worked for me.

Worked for me too on 20.04 and Cockpit 215.

Confirmed for me as well.

[cinderblock]

Want to say "me too"? Great! Just click the 👍

Only 👉you👈 can prevent clutter fires in GitHub issue comments.

[Libitum]

Finally I found the solution for Ubuntu 20.04.
Yes "systemctl disable network-manager.service" works for this issue, but would cause the problem of Networking tab empty #14023 .
The root cause is that systemd-networkd is used by default instead of NetworkManager in Ubuntu 20.04 server. If we disable NM, the Networking tab would be empty; If we enable NM, "Cannot refresh cache whilst offline" would occur because NM actually managed nothing. So the best solution is that use NM instead of systemd-networkd:

# Change netplan config to use NM instead
# File path: /etc/netplan/50-cloud-init.yaml
network:
    version: 2
    renderer: NetworkManager    # This is the changed line. Default is networkd
    ethernets:
        eno1:      # This is different by hardware.
            dhcp4: true

# Then apply it
sudo netplan try   # This will disable systemd-networkd and enable network-manager.service

Then everything works.

[UnixNight]

Finally I found the solution for Ubuntu 20.04.
Yes "systemctl disable network-manager.service" works for this issue, but would cause the problem of Networking tab empty #14023 .
The root cause is that systemd-networkd is used by default instead of NetworkManager in Ubuntu 20.04 server. If we disable NM, the Networking tab would be empty; If we enable NM, "Cannot refresh cache whilst offline" would occur because NM actually managed nothing. So the best solution is that use NM instead of systemd-networkd:

# Change netplan config to use NM instead
# File path: /etc/netplan/50-cloud-init.yaml
network:
    version: 2
    renderer: NetworkManager    # This is the changed line. Default is networkd
    ethernets:
        eno1:      # This is different by hardware.
            dhcp4: true

# Then apply it
sudo netplan try   # This will disable systemd-networkd and enable network-manager.service

Then everything works.

I've done this change and now on reboot of my server, I no longer have networking unless I manually go in and sudo netplan try

Is there another step after to permanently commit the changes?

[Libitum]

@UnixNight Just try this:

systemctl enable network-manager.service
systemctl disable systemd-networkd.service

[Th3Whit3Wolf]

Guys I think this should have a wiki page or be displayed in a FAQ or something. IDK what percentage of cockpit users run Ubuntu but I feel like it has be a non insignificant amount and digging through github issues to find the solution to a common problem isn't a great user experience.

[wrogner]

See my remark above from May 1st.

Using NetworkManager you can use networking but software upgrades don't work (they require systemd networking).

Adding the dummy device requires the kernel to be compiled accordingly. This is not the case on ARM CPUs. (at least with Ubuntu downloadable images).

Anything suggested is a compromise and requires evaluation of the individual current demands.

(Stated otherwise: cockpit is broken by design)

[vvancreij]

Hi,

I have finally achieved cockpit updates working with networkd following https://cockpit-project.org/faq.html#error-message-about-being-offline procedure on a Raspberry Pi4 arm64 (3 RPIs v4 systems with Ubuntu 22.04 LTS). The procedure is as follows:

1. Update your system through command line.
2. Install linux-modules-extra-raspi (sudo apt install linux-modules-extra-raspi). These modules should provide necessary modules to activate dummy interfaces on arm architecture
3. Follow https://cockpit-project.org/faq.html#error-message-about-being-offline procedure

Hope this could help.

[wrogner]

Installing linux-modules-extra-raspi allows me to create a dummy device.
Both Software Updates and Networking work now
(I had Network manager deactivated, because my priorities lie in software maintenance)
Thank @vvancreij

[vvancreij]

Nice to hear that @wrogner !

[flipch]

I have tried the FAQ workaround on 22 Ubuntu, does not work. Gets past initial error but then mirrors are unavailable as it seems it's trying to use the dummy interface to reach the internet and not the real ones.

[wrogner]

@flipch : Do you want to share the initial error message and the ones you get now? Maybe add your architecture to give us something to think about.

see Martinpitt 23.1.2018: NetworkManager needs to at least manage one interface -> dummy
UnixNight 24.5.2020: describes the different behaviours
christian-schulze 9.12.2022: config file and nmcli settings -> create dummy device
wrogner 1.5.2023: above suggestions work only if kernel allows creation of dummy devices (Ubuntu for Pi does not)
vvancreij 23.11.2023: hints to linux-modules-extra-raspi to activate dummy devices -> works on Pi, sw-update and networking work

[mlavi]

Thanks @vvancreij, I confirmed your solution works on my Raspberry Pi 4b, so I've created a pull request to add this step to the FAQ.

@flipch I suggest you remove the dummy interface to confirm your hypothesis: sudo nmcli connection delete fake

[ozsmac]

So I've had this issue with cockpit for a while, and have tried following the steps in https://cockpit-project.org/faq.html#error-message-about-being-offline without success. For me it has been one step forward, then a few back with various issues with my machine (it is running AdGuard Home as a DNS black hole tool and also TailScale for remote access - this leads to issues with playing around with networking and DNS.

I suspect it is fair to say that many folks who are looking at cockpit, don't have a position of strength in Linux sysadmin, hence this challenge for basically all users of Ubuntu is somewhat more annoying as a result.

I'm not an expert, but I can find my way around. At this point I've given up getting cockpit to work at all, it's just not worth any further effort.

Shame, it is a useful tool, let's hope that a fix can be found for the core Ubuntu Linux issue.

[danielfaust]

@ozsmac This is not just a cockpit issue. I'm following this issue here because for me KDE Discover does not work as I'm tied to using networkd in netplan. The fake interface recommendation did not work for me.

[ozsmac]

Yep fully understand it's a core Ubuntu Linux issue, sadly however for many people this means Cockpit isn't worth installing. I can't find a work around, so I have no choice than to remove the packages :(

At this point it does become a Cockpit issue, if the underlying Ubuntu technology issue can't be addressed in over 4 years (ie so it works with default Ubuntu install), it's down to the Cockpit team to decide if another approach could be used.

[wrogner]

There are some workarounds: Create a managed dummy device, install dummy device proxy on Raspberry, ...

However, the pure ignorance towards a solution that is broken by design suggests that Cockpit is not the way to go.

As further indication, have a look at the plugins for Cockpit. Basic functionality is missing.

Back to Webmin that is.

[pietricello]

Same problem today in 2024 with Ubuntu Server 22.04 hosted (VPS).
After an afternoon trying suggested solutions here my experience:

1. dummy interface worked as well but personally i don't like having this on my system. Also related or not i don't know but it seems take a bit more ram consumption (it makes sense)
2. changing the renderer to NetworkManager in 50-cloud-init.yaml and disable networkd service works good.
   in this scenario there are not dummy interfaces. Cockpit is able to show infos about network interface as well as update the software. Remember to disable networkd.
   Manual update by cli is not affected and my internet services seems to work fine.
   But especially in case of hosted server (vps) be careful as it modify a crucial file usually managed by hosting company. If you are bold and adventurous at least (as i did) ensure you have another way except ssh to access the consolle.
   On top of this ensure to take a snapshot (if possible) of the working server so in the worst case you can roll back in one click.
   Then cross fingers and try. On top of all i think all the dispute above could be avoided as updating via cockpit is a "nice to have" but not essential. Cockpit itself (in case for some reasons you denied ssh) has embedded consolle so you can always update&upgrade manually.

[isyuricunha]

using this solution, works to me:

sudo systemctl disable network-manager.service
sudo systemctl stop network-manager.service
sudo reboot now

using ubuntu server 24.04

Edit: use this solution #8477 (comment)

[pietricello]

As for above issue still persist in a "normal" cockpit installation even at today (July 2024). I start to think it's not about linux as mentioned, just cockpit team does not take care about this.
Thank you isyuricunha but today i'm working on a more serious and complicated Oracle Cloud instance and i don't have (or maybe i cannot) have an effective consolle access before ssh as i have on other vps provider.
In this scenario i won't attempt to change anything in a production environment on network side.
I rather prefer to use it for monitoring purposes and web-ssh. I prefer a simple command via ssh/web-ssh rather than play with cloud network interfaces :-(

[thejordanprice]

using this solution, works to me:

sudo systemctl disable network-manager.service sudo systemctl stop network-manager.service sudo reboot now

using ubuntu server 24.04

This fixed the issue for me.

Ubuntu 24.04 LTS

[garrett]

I start to think it's not about linux as mentioned, just cockpit team does not take care about this

As mentioned above multiple times, this is a bug lower in the stack specifically on Ubuntu systems. Cockpit itself cannot fix it; it relies on the provider of the distribution to fix this problem in their network stack (using netplan + networkmanager at the same time and also with packagekit). This same bug has also caused issues in other parts of the system outside of Cockpit too, such as KDE Discover (for example).

Apologies, but we'd like this fixed too.

[pietricello]

Thank you for your comment Garret. I wanna believe you , just seems so strange how come a so huge community (Linux/Ubuntu) after years does nothing to solve it. No problem.
By the way: on my Ubuntu 22.04LTS running on Oracle Cloud (arm) network-manager.service is not installed so i cannot follow the above workaround. Probably this implementation (Linux Oracle firmware) as also something different at kernel level. Also , for readers, i'm speaking about a VM (kubernetes) so this can also make the difference.

[isyuricunha]

Thank you for your comment Garret. I wanna believe you , just seems so strange how come a so huge community (Linux/Ubuntu) after years does nothing to solve it. No problem. By the way: on my Ubuntu 22.04LTS running on Oracle Cloud (arm) network-manager.service is not installed so i cannot follow the above workaround. Probably this implementation (Linux Oracle firmware) as also something different at kernel level. Also , for readers, i'm speaking about a VM (kubernetes) so this can also make the difference.

Pietricello,

Are you unable to install the network-manager.service? As far as I know, Unix/Linux systems, especially those from Oracle/RedHat/Debian, should be able to install it. Cockpit depends on some dependencies from the network-manager.service, so I believe your best chance is to install it.

You don't need to use it, just have it installed so that Cockpit can use the necessary dependencies. Moreover, you won't have any security breaches because of this, and it won't interfere with your current network configurations.

[pietricello]

sudo systemctl disable network-manager.service sudo systemctl stop network-manager.service

Sorry but i read is "sudo systemctl disable network-manager.service sudo systemctl stop network-manager.service " it means, as far as i know, that service has to be installed and enabled prior to stop/disable it :-) I will try to install it then.

[manihindrich]

Finally I found the solution for Ubuntu 20.04.
Yes "systemctl disable network-manager.service" works for this issue, but would cause the problem of Networking tab empty #14023 .
The root cause is that systemd-networkd is used by default instead of NetworkManager in Ubuntu 20.04 server. If we disable NM, the Networking tab would be empty; If we enable NM, "Cannot refresh cache whilst offline" would occur because NM actually managed nothing. So the best solution is that use NM instead of systemd-networkd:

# Change netplan config to use NM instead
# File path: /etc/netplan/50-cloud-init.yaml
network:
    version: 2
    renderer: NetworkManager    # This is the changed line. Default is networkd
    ethernets:
        eno1:      # This is different by hardware.
            dhcp4: true

# Then apply it
sudo netplan try   # This will disable systemd-networkd and enable network-manager.service

Then everything works.

I've done this change and now on reboot of my server, I no longer have networking unless I manually go in and sudo netplan try

Is there another step after to permanently commit the changes?

I have Ubuntu 22.04.4

Unlike the other solutions here, I was able to download updates thanks to this one. Thank you for that.

But during the OS boot there was an error with the network that was not there before and it is also reported by Cockpit:

[isyuricunha]

Finally I found the solution for Ubuntu 20.04.
Yes "systemctl disable network-manager.service" works for this issue, but would cause the problem of Networking tab empty #14023 .
The root cause is that systemd-networkd is used by default instead of NetworkManager in Ubuntu 20.04 server. If we disable NM, the Networking tab would be empty; If we enable NM, "Cannot refresh cache whilst offline" would occur because NM actually managed nothing. So the best solution is that use NM instead of systemd-networkd:

# Change netplan config to use NM instead
# File path: /etc/netplan/50-cloud-init.yaml
network:
    version: 2
    renderer: NetworkManager    # This is the changed line. Default is networkd
    ethernets:
        eno1:      # This is different by hardware.
            dhcp4: true

# Then apply it
sudo netplan try   # This will disable systemd-networkd and enable network-manager.service

Then everything works.

I've done this change and now on reboot of my server, I no longer have networking unless I manually go in and sudo netplan try
Is there another step after to permanently commit the changes?

I have Ubuntu 22.04.4

Unlike the other solutions here, I was able to download updates thanks to this one. Thank you for that.

But during the OS boot there was an error with the network that was not there before and it is also reported by Cockpit:

Try this:

Create /etc/NetworkManager/conf.d/10-globally-managed-devices.conf:
sudo nano /etc/NetworkManager/conf.d/10-globally-managed-devices.conf

Copy/past/write this content:

[keyfile]
 unmanaged-devices=none

Now, set up a fake network interface:
sudo nmcli con add type dummy con-name fake ifname fake0 ip4 1.2.3.4/24 gw4 1.2.3.1

Now, restart your server/desktop!

This is really annoying but it is as it is even you could find a explanation that says:
Ubuntu uses two different network stacks which don’t play so well together.

PS: This works on wireless and cable. And, tbh, this solution works on my all servers (small and big).

[manihindrich]

Thanks @isyuricunha, I'll look into it. BTW I solved it yesterday by creating a second config for the default network settings and just switching :)

[isyuricunha]

Thanks @isyuricunha, I'll look into it. BTW I solved it yesterday by creating a second config for the default network settings and just switching :)

Nice, buddy.

[beankylla]

I start to think it's not about linux as mentioned, just cockpit team does not take care about this

As mentioned above multiple times, this is a bug lower in the stack specifically on Ubuntu systems. Cockpit itself cannot fix it; it relies on the provider of the distribution to fix this problem in their network stack (using netplan + networkmanager at the same time and also with packagekit). This same bug has also caused issues in other parts of the system outside of Cockpit too, such as KDE Discover (for example).

Apologies, but we'd like this fixed too.

is there a ticket open for this that everyone here could push? that might help get traction to it. I'm guessing amount of requests on tickets might influence slightly devs?

[garrett]

These were supposed to fix the problem on PackageKit's end:

• Issue: Network Manager unmanaged interface causes packagekit to conclude its off-line incorrectly PackageKit/PackageKit#336
• PR: wait until online to activate systemd service PackageKit/PackageKit#506

As the problem is still happening, there's probably still something in Ubuntu that is having an issue.

It appears it's even a problem that affects "Ubuntu Software", their own home-grown replacement for GNOME Software, according to: https://danielbkr.net/ubuntu-software-thinks-it-is-offline-using-netplan-to-manage-networking/

There's a bug filed for this problem with KDE Plasma in Ubuntu on Launchpad @ https://bugs.launchpad.net/ubuntu/+source/plasma-discover/+bug/1945030 (The change listed in the PR at the top of this comment was supposed to have fixed it, and it seemed like it did for some, but it's apparently still an issue there too.)

And others:

• https://bugs.launchpad.net/ubuntu/+source/plasma-discover/+bug/2036801
• https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1946196
• https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1943189

The correct place to find and file bugs against Ubuntu-specific problems is @ https://bugs.launchpad.net/ubuntu — although it's been filed and fixed somewhat in various places, but not all, so I guess it needs to be filed there again?

[Bunch8]

Has anyone been able to get Cockpit working reliably without errors on Ubuntu Server 24.04?

I have spun up dozens of virtual machines to test different solutions that were offered on the internet, from fake networks to modifying all kinds of yaml files but I still get the following error in Cockpit:

Here are the steps I used to get to this point from a fresh ubuntu-24.04.1-live-server-amd64.iso.

sudo apt update
sudo apt ugrade
reboot
sudo apt install network-manager

Switch from systemd.networkd to NetworkManager.

sudo nano 01-netcfg.yaml
network:
version: 2
renderer: NetworkManager

Ubuntu complaining that permissions are too broad. Fix with:

sudo chmod 600 /etc/netplan/01-netcfg.yaml

sudo netplan generate
sudo netplan apply
sudo systemctl enable NetworkManager.service
sudo systemctl restart NetworkManager.service
reboot

Slow boot - hang on NetworkManager wait and systemd-networkd wait. Fix:

sudo nano /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service

Add timeout argument for 5 seconds.

ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --timeout=5

Check status of both network managers. Both are enabled and active:

systemctl status systemd-networkd.service
systemctl status NetworkManager

sudo apt install cockpit
sudo apt install cockpit-pcp
reboot

Boot speed is fast now. Check with:

systemd-analyze blame

Note that proper indentations were made for the text files but it's not displaying properly on Github.

The Cockpit tabs that used to show "cannot refresh cache whilst offline" (Services, Applications, Software Updates) are working as they should but I am concerned that the systemd-netword-wait-online service error may cause problems later on. I want to get an Ubuntu server running Cockpit without errors so I can clone it to have a quick start for new server projects.

I had previously used virt-manager and it was very easy to install and running error free but I saw a Youtube video by Tom at Lawrence Systems talk about the nice Cockpit interface and wanted to give it a try.

How can I get rid of the error without disabling networkd?

Thanks!

[wrogner]

@Bunch8
I have not gone through the trouble of any of your steps.
In Ubuntu 22.04 I had to install linux-modules-extra-raspi and set up a dummy device to get NetworkManager to manage this device. That way, both networkd and NetworkManager coexisted (see my posts above)

In Ubuntu 24.04 even on a Raspberry Pi, adding a dummy device was possible (kernel compiled accordingly).

So here are the steps that effectively worked:

sudo apt install cockpit
sudo ufw allow 9090/tcp comment cockpit

# goto overview / Performance
#install cockpit-pcp
sudo apt install cockpit-pcp

# sudo vi /etc/NetworkManager/conf.d/10-globally-managed-devices.conf
[keyfile]
unmanaged-devices=none

sudo nmcli con add type dummy con-name fake ifname fake0 ip4 1.2.3.4/24 gw4 1.2.3.1
# if ifstate does not exist
sudo touch /run/network/ifstate

-> generates a 90-NM-*.yaml file in /etc/netplan
I override this with a netplan.yaml that sets up my network using networkd as the renderer.

I did this both on a Raspberry Pi as well as an Intel-based server. Both software update and network management work.

I considered this to be fixed and closed. Hope this post helps illuminate (and is working on all installations).

[Bunch8]

Thanks wrogner for your reply.
Additonal information: I'm using the minimal installation of ubuntu-24.04-live-server-amd64.iso

I followed your steps and have the same problems as before.

1. sudo ufw allow 9090/tcp comment cockpit. ERROR: no firewall. The minimal install doesn't have ufw but this is not important for now.
2. sudo touch /run/network/ifstate. ERROR: touch: cannot touch '/run/network/ifstate': No such file or directory
3. slow boot. > 2 minutes. I fixed this by adding ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --timeout=5
4. systemd-networkd-wait-online.service. ERROR: Failed to start

I was running Ubuntu Server 24.04 on virtual machines but tried it on another computer on bare metal, AMD Ryzen 2700 8C/16T. Same errors occur as the VM.

How did you solve slow boot time and systemd-networkd-wait-online.service failed to start error?

Some more system details:

Both NetworkManager and networkd seem to be running fine:

Contents of netplan yaml file:

Cockpit Services and Software updates seem to be working fine.

Ubuntu 24 will be with us for several years so I think it would be useful to have a step-by-step installation procedure for Cockpit for Ubuntu noobs.

Anyone have any ideas? Thanks in advance.

[wrogner]

Hi @Bunch8 ,

My mistake: I activate ufw right after install but forgot to mention this fact. (A system without proper port protection is not acceptable in my opinion)

You seem to have missed to install the dummy network device (see your screenshot of networkctl and systemctl):

sudo nmcli con add type dummy con-name fake ifname fake0 ip4 1.2.3.4/24 gw4 1.2.3.1

In my case, the fake device is unmanaged but exists.

xxx@neptune:~$ networkctl
IDX LINK  TYPE     OPERATIONAL SETUP     
  1 lo    loopback carrier     unmanaged
  2 eth0  ether    routable    configured
  3 wlan0 wlan     routable    configured
  4 fake0 ether    routable    unmanaged

4 links listed.
xxx@neptune:~$

If this (fake0 or anything you chose) device exists, NetworkManager has something to play with that is not required for the server to function. So it does not block boot time. No need to fiddle with timeouts.

In your .yaml file, the renderer for the dummy device needs to be NetworkManager. (I have two yaml files, one for my networkd rendered network and one for the fake device rendered by NetworkManager - last gets generated by nmcli)

For details:

https://cockpit-project.org/faq.html#error-message-about-being-offline

sudo apt install linux-modules-extra-raspi

is not required in Ubuntu 24.04 anymore.

My suggestion for you:

• Revert the renderer in your .yaml file for the fake device to NetworkManager
• Remove the timeout (see your step 3.)
• Set the startup sequence in your netplan to first configure fake0 with NetworkManager, then your network devices with networkd (I used 90-NM-... and 99-nd-...)
• Reboot and time

I would like to hear from your experiment.