Before April this year and last year, on the network system in mainland China, the [Download updates while installing Ubuntu] option in the Ubuntu installer was black and could be checked. But why has this option turned gray and cannot be checked since April this year? Whether downloading a new ISO image from the official website to remake the system disk, or changing the router’s DNS server to 1.1.1.1 and 8.8.8.8, or even connecting to a VPN node in London, UK, this option is still gray and cannot be checked. Does anyone know why this is? Additionally, if you exit the installer and use the trial mode, the browser can access the internet and search for information normally, but the installer still shows no network. This is very strange; whether using only IPv4, only IPv6, or both IPv4 and IPv6, the situation is the same.
The Ubuntu installer doesn’t just check if you have general internet access. It runs a specific, strict background health check to see if it can reach the official Ubuntu archive servers (archive.ubuntu.com).
Because of recent security updates and heavy global DDoS mitigation on Canonical’s infrastructure, their servers frequently block or drop connections coming from automated installer checks behind certain regional networks or commercial VPNs. Since the installer’s specific health-check loop times out or gets rejected, it assumes the update servers are unreachable and greys out the option to prevent the installation from freezing later.
Firefox works perfectly because it navigates the open web using standard web protocols. It isn’t trying to ping the restricted, heavily guarded Canonical package mirrors like the installer is. Your browser has a clean path to the rest of the world, but the installer is getting blocked at Canonical’s front door.
You can safely skip the option during the install. Once Ubuntu is fully installed and boots up for the first time, you just need to open the “Software & Updates” app, switch the download server from the “Main Server” to a local mirror (like TUNA or Aliyun), and run your updates normally.
If I want the installer to connect to the official Ubuntu archive server (archive.ubuntu.com) and the well-protected Canonical software package mirrors, can I connect using cellular data with a UK or Hong Kong SIM card?
I don’t think this will change anything. The issue is still likely to occur with the timeouts and ‘health check’ loops just not resolving. This is unfortunately because of the protections that’re in place. Just skip the “install updates while installing” step and then after the fact run a standard sudo apt update && sudo apt dist-upgrade -y to install all the updates.
Is it really that bad? Then wouldn’t it mean that during installation, the option to download updates can only be checked in the regional networks where the official Ubuntu archive servers and canonical package mirror servers are located, and other regions can’t check it!? Isn’t this DDoS protection too strict? It’s almost strict enough that only the internal network can access those two.
Contrary to my previous message, it seems this is more widespread than just for you in China.
I am based in the UK, and just did an install of Ubuntu 20.04 and 22.04 in a VM. I also see the option greyed out. So it looks like it affects ubiquity (the older installer) and subiquity - the newer flutter-based one. Not unexpected, given one was based on the knowledge of the other.
I’ll be honest, I never click that option, because all it does in the background is literally sudo apt update; sudo apt -d upgrade - which will almost never complete during the install, because the install is faster than all the updates downloading, so I do it after the install is finished.
The DDoS has created significant problems for users worldwide. I have two suggestions that you can try.
You asked about using cellular data. That does work for some people, although of course it would use a lot of your data. If you can afford that, and it won’t be too slow, by all means try it to see if it works for you.
There is another option to try on your normal broadband connection. Boot into your Live USB. Before you start the installer, connect to the internet, and do the following.
- Find the name of your active internet connection.
ip link show | grep -F BROADCAST | grep -Fv NO-CARRIER | cut --delimiter=: --field=2
This returns wlo1 or eno2 or something like that.
- Change the MTU to 1320. In the following comment, change wlo1 to whatever name you got in step 1.
sudo ip link set dev wlo1 mtu 1320
This should do the job. Start the installer and try again.
Let me know how it goes.
I have OCD, so I have to check this option. If I don’t check it, I feel very uncomfortable. This is really a bad thing
I’m sorry to hear that this is adversely affecting your ability to use the installer.
Is there some reason you’re installing 22.04? The newer 24.04 (and 26.04) use a beautiful new installer, which, in my testing, don’t even have that checkbox.
Test a project on a Git repository, this option specifies Ubuntu 22.04
Hi @popey,
Can you clarify the bit where you’re reproducing this with subiquity? I did some tests with 22.04.5, 24.04.4, and 26.04 desktop. Note that subiquity was first used on desktop as of 24.04, and on both 24.04.4 and 26.04 I see unattended-upgrades running as expected. I can reproduce the problem on 22.04.5 desktop (ubiquity based).
Are you seeing problems with updates on 24.04.x Popey? Or is this just a minor confusion on which installer is in use on 22.04.x?
It would be good to address the regression affecting ubiquity, at the moment I’m trying to understand if subiquity is also affected.
About the Ubiquity part - Ubiquity expects to retrieve connectivity-check.html and expects it to have md5 4589f42e1546aa47ca181e5d949d310b. Alas, this is not currently the case, so I would expect 100% of Ubiquity users to be unable to check the “Download Updates…” checkbox. I have recovered the original connectivity-check.html content and have a request open internally to restore connectivity-check.html to match 4589f42e1546aa47ca181e5d949d310b.
Note also that for updates to be available, other parts of the network check need to be happy, so even when this is fixed, if Ubiquity deems you to be offline the checkbox will probably be disabled.
Thanks for the bug report @wbtwcx
This part should be fixed now. start.ubuntu.com is due to be decommissioned so we should update the Ubiquity installer to not use that - perhaps connectivity-check.ubuntu.com is a better service/endpoint to use for this.
My mistake, it seems only ubiquity is affected. Apologies for the confusion.
When does it probably start? This can make me no longer feel uncomfortable because of OCD and unable to check all options
You’ll need to be patient. Bugs take time to fix, especially when there are higher-priority bugs especially security-related ones.
After setting the MTU of the cellular data interface on the soft router to 1320, I was able to check the option to update Ubuntu during installation. However, the time zone showed that I was in Chicago, which is strange because my IP is in London. When I chose the Shanghai time zone, not only did I go to Xinjiang, but several Shanghai time zone options also appeared. It’s really strange
There is another issue, which is that the newly installed Ubuntu desktop system will have a multi account login window after booting up. Except for the Ubuntu single account, which keeps prompting that it cannot connect to the server or the password account is incorrect and cannot log in, all other accounts can log in. Does this Ubuntu single account login function also fail?
I have never seen this in a new installation. A new installation generally has just one user, specifically the one that you specify during the Ubuntu installation process. I am terribly confused how you have multiple users on a fresh installation.
