Pakfire slow over serial console

odongarma · 11 November 2025 14:58

First i give a big thank you for the latest core!

it works perfect!

I have a strange “feeling”:

i am runnig the pakfire upgrade over the serial console.

this works perfect but the downloads of the core update files feels really slow.

i have the feeling this is slowed because of the slow progress rendering over the serial console?

i am on 300 Mbit fiber so a 100 MB download should be done in seconds but in my setup it take several minutes.

is this a thing or do i start seeing things??

11:02:58	pakfire:	DOWNLOAD FINISHED: ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-198.ipfire
11:02:58	pakfire:	DOWNLOAD INFO: Signature of core-upgrade-2.29-198.ipfire is fine.
11:02:56	pakfire:	DOWNLOAD INFO: File received. Start checking signature…
11:02:55	pakfire:	DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
11:01:03	pakfire:	DOWNLOAD INFO: ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-198.ipfire has size of 60046479 bytes
11:01:02	pakfire:	DOWNLOAD INFO: Host: mirror.clarkson.edu (HTTPS) - File: ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-198.ipfire

if i “wget” the file, it took 19 seconds…

Greetz

tphz · 11 November 2025 16:07

Why not use SSH?

odongarma · 11 November 2025 16:55

For daily use ssh into the ipfire box for sure.

But for update purposes i recommend the “live” terminal to see all messages on the console and not to loose the connection to the box in any case.

Spotting messages during the whole boot process can came in handy from time to time.

Call me crazy but i like this level of “control”

As I said, it is not a problem at all, but my inner monk would like to know is my educated guess somehow correct.

Greetz

current_user · 11 November 2025 20:56

seems to be a bad choice of for the download

was the wget with the exact same link

let us see if the coredevteam confirms
that there is no difference using ssh or serial

and for pakfire via serial

odongarma · 12 November 2025 06:14

It was the exact same url i am wgeting..

It is not a big deal i am just curious

i greped the log files:

Greetz

bonnietwin · 14 November 2025 13:38

I have run some tests on a physical device to see if I could replicate what you are seeing.

I installed CU197 on the device and then I ran the update to CU198 from the console command line with pakfire upgrade

Log showed the following

12:41:40 pakfire:  DOWNLOAD STARTED: paks/core-upgrade-2.29-198.ipfire
12:41:40 pakfire:  MIRROR INFO: 24 servers found in list
12:41:40 pakfire:  DOWNLOAD INFO: Host: mirror.cedia.org.ec (HTTPS) - File: ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-198.ipfire
12:41:42 pakfire:  DOWNLOAD INFO: ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-198.ipfire has size of 60046479 bytes
12:42:15 pakfire:  DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
12:42:16 pakfire:  DOWNLOAD INFO: File received. Start checking signature...
12:42:18 pakfire:  DOWNLOAD INFO: Signature of core-upgrade-2.29-198.ipfire is fine.
12:42:18 pakfire:  DOWNLOAD FINISHED: ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-198.ipfire

The download time was 38 seconds.

I then re-installed CU197 on the same system and ran the update via the WUI and got the following log

13:11:59 pakfire:  DOWNLOAD STARTED: paks/core-upgrade-2.29-198.ipfire
13:11:59 pakfire:  MIRROR INFO: 24 servers found in list
13:11:59 pakfire:  DOWNLOAD INFO: Host: mirrors.ocf.berkeley.edu (HTTPS) - File: ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-198.ipfire
13:11:59 pakfire:  DOWNLOAD INFO: ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-198.ipfire has size of 60046479 bytes
13:12:08 pakfire:  DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
13:12:09 pakfire:  DOWNLOAD INFO: File received. Start checking signature...
13:12:11 pakfire:  DOWNLOAD INFO: Signature of core-upgrade-2.29-198.ipfire is fine.
13:12:11 pakfire:  DOWNLOAD FINISHED: ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-198.ipfire

The download time was 12 seconds.

A bit faster but note that the mirror was different. First time was a mirror from ecuador and the second time from USA. The routing paths could easily make a difference in the download times, especially as there was a 18 minute gap between the two tests due to the full installation step.

So I then did another fresh install of CU197 on the device and then ran the update again but with the mirror defined as mirrors.ocf.berkeley.edu again. Logs showed

14:13:29 pakfire:  DOWNLOAD STARTED: paks/core-upgrade-2.29-198.ipfire
14:13:29 pakfire:  DOWNLOAD INFO: Host: mirrors.ocf.berkeley.edu (HTTPS) - File: /ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-198.ipfire
14:13:30 pakfire:  DOWNLOAD INFO: /ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-198.ipfire has size of 60046479 bytes
14:13:41 pakfire:  DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
14:13:42 pakfire:  DOWNLOAD INFO: File received. Start checking signature...
14:13:44 pakfire:  DOWNLOAD INFO: Signature of core-upgrade-2.29-198.ipfire is fine.
14:13:44 pakfire:  DOWNLOAD FINISHED: /ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-198.ipfire

giving a download time of 15 seconds. This compares very similarly with the WUI time with the same mirror of 12 seconds and especially as there was a gap of 58 minutes between the two tests with the same mirror due to the full installation step plus I had to go and work on some other stuff.

So from my perspective I don’t see any big difference between the pakfire upgrade download via the console command line or the WUI.

Just as a confirmation, when you say you are using the console is this via hdmi for the screen and usb for the keyboard or are you using the serial console.

If the latter then I could believe that there might be an impact but I am not currently able to test this and if the WUI is faster for you then that seems fine as the WUI is the intended upgrade route. The console approach for pakfire is there to be availabe as a backup route if something goes wrong with the WUI access.

odongarma · 14 November 2025 14:22

Adolf, thank you so much for your time and investigations!

As I said, this is not problem at all i am just curious to know!

I am using a headless APU, so no hdmi! This is plan old RS232ing into the box..

I never messed with the pakfire mirrors, but for me (located in Germany) is a mirror in Japan really strange to be choosen by pakfire.

For my further personal tests I pinned the pakfire mirror now fix to the gwdg mirror, which is in Germany too.

Greetz to all the ipfire members

bbitsch · 14 November 2025 14:27

If you use an APU system, could you please answer following questions.

Which CU do you use?
Is IPS enabled?

bonnietwin · 14 November 2025 14:46

I am not sure why you think it is strange.

This ensures that all the mirror volunteers get any load on them distributed and not concentrated on the mirrors where the biggest population of IPFire users is.

With the internet and our mirrors being worldwide, I have to say that I have not seen any issue with download speeds of the upgrade packages or addons.

Having a range of mirrors that has distributed usage also ensures that if there is some downtime on a mirror the system just moves to the next available one. I have seen that occur in updates where a mirror did not respond but the change to the new mirror just kicked in automatically with very little time impact.

Then you might have an impact, although I am not familiar enough with the serial interface to know that definitively. In that case you will have to just live with a slower download or use the WUI pakfire for the updates/upgrades.
The logs that are shown in the pakfire window are the same logs that you see in the console window.

If you want to see how the reboot goes then you can always run the upgrade via the WUI and then go and look at the serial interface for the reboot. You should be able to do that with the same laptop for both.

odongarma · 14 November 2025 14:53

IPS is disabled and was never used.

i am on CU 198. (from 189 in one go on last Saturday )