[Core 164] Can't upgrade to 164 - ntpdate error

When using pakfire I cant refresh list.
In systemlog I see this:
04:40:00 ipfire: ntpdate error

I have tried to change to testing but same error.
I have seen somewhere that IPfire cant connect.

How could I fix this error?

Hi,

this means IPFire fails to retrieve the current time from the global pool of NTP servers.

Where was that exactly? Please post a screenshot of the message, and briefly describe your setup and how IPFire is connected to the internet.

Well, if you have general connectivity issues, this won’t help indeed.

Thanks, and best regards,
Peter Müller

1 Like

I have change time servers but IPfire still cant upgrade time.

Hi,

sorry, this is not how support works here.

Earlier, I asked for logs and more detailed information. Without these, I am unable to help you, and will therefore not spending any more time on your issue unless you provided these.

Regards,
Peter Müller

2 Likes

Sorry I cant get the message where it show it cant connect.
I search for logfile that could help.

@neggard

Hi, have you tried to restart or stop then start ntp service ?
[root@ipfire ~]# /etc/rc.d/init.d/ntp
Usage: /etc/rc.d/init.d/ntp {start|stop|restart|status}

Hi,

all right, let’s try to figure this out:

@neggard, could you please post screenshots of

here? That would help to understand your setup, and see what’s wrong with it.

Thanks, and best regards,
Peter Müller

Thanks for help everyone.
I couldn’t get it working so I reinstall IPfire.

Guess what…It dont work.

But I find out what the problem was.
The DNS servers I was assign by my internet service provider was broken.

I can ping my service providers dns by ping but why does IPfire say it’s broken?

I am presuming that it is showing broken on the WUI DNS servers menu page after having pressed the Check DNS servers button.

If that is the case then put the mouse pointer over the red broken notice and after a short wait a short message about the problem will be shown.

You can then look in the unbound logs for more details.

2 Likes

DNSSEC not supported.

Thanks @bonnietwin for help.

Hi,

ouch, what ISP is that? At the very least they could just pass on DNSSEC information to IPFire… :expressionless:

However, DNSSEC support is mandatory for IPFire. Please have a look at this list of publicly available DNS resolvers, and pick a few of them for your IPFire. Choose DNS over TLS servers, since DoT cannot be tampered with (who knows what your ISP is doing besides stripping DNSSEC information?!) and is better in terms of privacy.

Thanks, and best regards,
Peter Müller

3 Likes

Hi there, I am having the same trouble upgrading from 163. I could not tell if any or you had a solution to this or not. If you did, please kindly share your solution here. Many thanks!

Bo

To help understand your setup and what might be wrong with it could you please provide the information specified in this earlier post in this thread.

https://community.ipfire.org/t/core-164-cant-upgrade-to-164-ntpdate-error/7433/7

1 Like

Login to GUI on IPfire.
Menu - Network - Domain Name System
Press add.
IP=8.8.8.8
Or whatever DNS you want.

Remove the old ones.

Now you can update.

1 Like

Hi,

it is also a good idea to enable DNS over TLS (DoT), so no network component can tamper with your DNS traffic (i.e. to strip DNSSEC signatures) in any way. A list of public DNS resolvers supporting DoT can be retrieved here.

If DNS works, the clock of your IPFire machine is synced (i.e. NTP is working properly), and you can establish HTTPS connections to pakfire.ipfire.org, I would expect the upgrading procedure to work fine.

Thanks, and best regards,
Peter Müller

1 Like

Daniel, after removing the non-google dns entries, the update still ended with a failure. The system msg was - core-update-164: ERROR cannot update because not enough free space on root.

I thought it was a matter of removing old backups using the UI. Strangely, that did not seem to increase the available disk space! /dev/vda3 still sat at 97%. I even went to folder /var/ipfire/backup to ensure any additional backups were gone.

Any ideas?

Please login, run df -h and post the results.

You’ll see something like this:

[root@ipfire ~] # df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.9G  4.0K  1.9G   1% /dev
tmpfs           2.0G   12K  2.0G   1% /dev/shm
tmpfs           2.0G  648K  2.0G   1% /run
/dev/sda4        14G  8.5G  4.4G  67% /
/dev/sda1       110M   47M   55M  46% /boot
/dev/sda2        32M  270K   32M   1% /boot/efi
/var/lock       8.0M   20K  8.0M   1% /var/lock
/dev/sdb1       229G   91G  127G  42% /mnt/ssd
[root@ipfire ~] # 

Hi John, here is the output after I removed most all backup files…

[root@ipfire backup]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        2.0G     0  2.0G   0% /dev
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           2.0G  440K  2.0G   1% /run
/dev/vda3       2.0G  1.8G   59M  97% /
/dev/vda1        59M   36M   20M  65% /boot
/dev/vda4       2.5G  531M  1.9G  23% /var
/var/lock       8.0M   12K  8.0M   1% /var/lock

You have an obsolecent installation, having separate /var. That was discontinued a couple of years ago.

You are also running as a VM, which is deprecated for “production” environments and can give networking issues, if not well configured…

It would be advisable to ensure that you have the latest backup downloaded to your client PC, then do a fresh install of core 167. The various issues with core`167 have been fixed in the current ISO/XZ files. Also advisable to install to hardware, rather than VM.

4 Likes

Hi,

I am sorry, but as @rodneyp already pointed out, you will unfortunately have to re-install IPFire. Despite our efforts to keep the distribution as slim as possible, especially parts like the kernel and linux-firmware have grown bigger and bigger over time, eventually exceeding the limit of 2 GBytes older IPFire installations allocated to the root partition.

“Deprecated” might be a bit too harsh, but it is definitely recommended against running IPFire in a VM for productive purposes, primarily due to security and performance considerations.

Sorry to disappoint, and best regards,
Peter Müller

4 Likes