I have a test env (on 159). Currently, the latest version is 162.
Can pakfire upgrade to 160 and stop?
From the pakfire command, <upgrade> will install the latest version of all paks.
Thanks.
I do not think is possible, or at least if it is, is not documented. I think you have to do it the hard way: backup the settings, install from scratch 160, restore the settings.
hi @anon42188109 @cfusco,
I also wondered if it is possible to upgrade to specific version and I consider that it makes sense.
Sometimes, adding a lag between an core update and its release in production for a customer seems to me to be an advantage, especially in the case of remote management.
I too am very interested in this option if it is possible…
Thanks.
No it is not possible to do.
The code looks at what the existing release is and then what the current latest release is and does an update from existing to current latest release.
I confirmed this by setting up a VM with Core Update 159 and it came up with Notice: There is a core update available from 159 to 162 and running it did the update to Core Update 162.
Changing it would require some significant modification of the code and I am not convinced that the Core Devs would support that work.
I would think that the simplest approach is to test it out on a test system (VM or physical) before running the update on the production machine(s).
I assume you made a typo – mine in the exact same setup upgraded to 162.
I could not stop it at 160. Command was: # pakfire upgrade 160
If the code needs significant mods, let’s table this for a future nice-to-have.
Thanks Paul, I have corrected the typo from 159 to 162 
My test was with the WUI and you could not select anything intermediate.
Hello,
Does latest pakfire allow us to upgrade to a specific version - via undocumented command line perhaps?
I need to bring an older machine to a specific version - matching the one where everything works so I can grab a backup from it and restore it to older machine.
pakfire --help
Usage: pakfire COMMAND [OPTIONS] [PACKAGE ...]
Manage IPFire add-on packages and updates.
PACKAGE:
one or more add-on package names
COMMAND:
install - install one or more packages
remove - remove one or more packages
update - update the pakfire database
upgrade - upgrade all packages to the latest version
list [installed | notinstalled | upgrade]
- display a list of installed, notinstalled,
upgradeable or all packages
info - display metadata for one or more packages
resolvedeps - display dependencies for one or more packages
status - display pakfire database status,
available updates and whether a reboot
is required to complete any upgrades
OPTIONS:
--no-colors - turn off colors
-y | --non-interactive - automatic yes to prompts
-f | --force - for the update command, force
a pakfire database update
Nothing has changed with regard to upgrading to a specific version. Pakfire will update to the current latest relesaed version if the repository is set to Stable and to the latest master repo if Testing is chosen and to the next repo if Unstable is selected.
There is no undocumented command line option. You can check this yourself by reading through the code for pakfire.cgi and pakfire
Here is the approach I would recommend if you want to install a specific Core Update rather than upgrading directly to the latest release.
The safest method is:
- Back up a working IPFire system (configuration and add-ons).
- Install the desired IPFire release from the corresponding ISO (or image).
- Install the required add-ons.
- Restore the backup.
There is also a manual upgrade procedure that I only use for testing purposes.
I do not recommend using this method on production systems, as it bypasses the normal Pakfire upgrade process.
It should only be used if you understand the implications and can recover the system if something goes wrong.
Example: upgrading from Core Update 184 to 185.
# Check the current Core Update
cat /opt/pakfire/db/core/mine
184
# Verify that the next Core Update package exists on the mirror.
# Example for x86_64:
# https://mirror1.ipfire.org/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-185.ipfire
cd /opt/pakfire/tmp
wget https://mirror1.ipfire.org/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-185.ipfire
gpg -d --batch --quiet --no-verbose --status-fd 2 --output - < core-upgrade-2.29-185.ipfire 2>/dev/null | tar x
./update.sh
# Only if update.sh completed successfully:
echo "185" > /opt/pakfire/db/core/mine
# Clean the temporary directory
cd
rm -rf /opt/pakfire/tmp/*
reboot
For other Core Updates, simply adjust the version numbers, package URL, and architecture as appropriate.
Thank you for providing that method.
I’ll test it
Your proposed method allows full control of the update process by reading and checking later the update.sh output.
A simple bash script can be used to automate the sequence of upgrade (I need to deploy 3 upgrades) along with saving the intermediary backups after each version + checks for main services seen to be changed by update.
An AI agent will do it faster than me and probably much better - reading hundreds of outputs generated by update script can be tiresome for me.
Appreciated!
You’re welcome!
One word of caution: I wouldn’t rely entirely on an AI agent for this kind of upgrade. It may help analyze the output, but I would still review each step manually before proceeding to the next Core Update.
Also, don’t forget to verify that your installed add-ons are compatible with Core Update you plan to upgrade. The procedure I described only upgrades the Core Update itself; it does not update the add-ons.
@pscar13 I wanted to take a moment to express my sincere gratitude for the detailed procedure you shared with me.
I followed your guidance step by step and successfully upgraded a test machine from Core Update 201 to Core Update 202 — manually, cleanly, and with full control over every stage of the process. The machine booted perfectly on the new kernel (6.18.32-ipfire), all services came up correctly, and most importantly, the Unbound DHCP Leases Bridge — which is the service I care most about — started without a single issue.
Your advice to capture the output via tee proved invaluable. Having a full log of the upgrade allowed me to review every step after the fact and confirm there were no hidden failures. That is the kind of detail that separates a good procedure from a great one, and it reflects the professional rigour one develops over a long career.
With CU202 confirmed stable on my test hardware, I now have a clear and confident path forward for my production box, which I need to hold at a known-good state until the Knot resolver ecosystem matures.
Merci beaucoup, and please accept the warmest regards
With respect and appreciation,
H&M
Details of test carried away:
pakfire list upgrade
Core-Update 2.29-x86_64
Release: 201 -> 203
Name: guardian
ProgVersion: 2.0.2
Release: 27
Installed: yes
Update available:
Version: 2.0.2 -> 2.0.2
Release: 27 -> 28
Name: htop
ProgVersion: 3.4.1
Release: 23
Installed: yes
Update available:
Version: 3.4.1 -> 3.5.1
Release: 23 -> 25
Name: iperf3
ProgVersion: 3.19
Release: 8
Installed: yes
Update available:
Version: 3.19 -> 3.21
Release: 8 -> 9
3 packages total.
bash update.sh 2>&1 | tee /var/log/core-update-202.log
echo "Exit code: ${PIPESTATUS[0]}"
...
...
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.18.32-ipfire
Found initrd image: /boot/initramfs-6.18.32-ipfire.img
Adding boot menu entry for UEFI Firmware Settings ...
Root filesystem isn't btrfs, skipping...
done
Exit code: 0
wc /var/log/core-update-202.log
9513 14412 619075 /var/log/core-update-202.log
AI analisys for /var/log/core-update-202.log follows
Full picture. Here’s the analysis:
Task 1 — Errors and Warnings
Real errors: 4, all expected and harmless pre-reboot
| Line | Message | Verdict |
|---|---|---|
| 9436 | modprobe: FATAL: Module nf_log_ipv4 not found in /lib/modules/6.18.7-ipfire |
Expected — old modules deleted, new kernel not loaded yet. Resolves on reboot. |
| 9437 | Warning: Extension owner revision 0 not supported, missing kernel module? |
Expected — same root cause, iptables can’t load netfilter extensions from deleted modules. |
| 9439–9442 | ipset cannot be destroyed: in use by kernel component (x2) |
Expected — live ipsets from running firewall can’t be flushed without the new kernel. Resolves on reboot. |
WARNs for Suricata, OpenVPN N2N Black2Silver not running — expected on a test machine with those services not configured/active.
Zero real errors. Log is clean.
Task 2 — Summary of CU202 changes
| Stage | What happened |
|---|---|
| Kernel removed | All of /lib/modules/6.18.7-ipfire/ wiped (~3700 lines of removed entries) |
| dnsmasq user/group | Deleted (was being retired in CU202) |
| unbound user/group | Created (uid/gid 103) — Unbound promoted to a dedicated system account |
| Perl cleanup | Net::IPv4Addr removed from site_perl |
| klogd removed | /usr/sbin/klogd deleted — kernel logging consolidated |
| Payload extracted | Lines 3709–9382: files.tar.xz fully extracted including new kernel 6.18.32-ipfire and all its modules |
| Services restarted | sysklogd, firewall, unbound, SSH, Apache, OpenVPN — all [OK] |
| dracut | Built initramfs-6.18.32-ipfire.img successfully |
| grub | Config regenerated — found vmlinuz-6.18.32-ipfire + initramfs-6.18.32-ipfire.img |
Task 3 — Pre-reboot status check + reboot verdict
Reboot is safe. Grub has the new kernel and initramfs registered. The 4 errors are purely a consequence of the old kernel still running — they disappear on boot into 6.18.32-ipfire.
Run this before rebooting to confirm the version file and boot entries are correct:
echo "=== Core version file ===" && cat /opt/pakfire/db/core/mine && \
echo && echo "=== Running kernel ===" && uname -r && \
echo && echo "=== New kernel on disk ===" && ls -lh /boot/vmlinuz-* /boot/initramfs-* && \
echo && echo "=== Grub sees new kernel ===" && grep -E "menuentry|linux|initrd" /boot/grub/grub.cfg | grep -v "^#" | head -20 && \
echo && echo "=== need_reboot flag ===" && ls -la /var/run/need_reboot 2>/dev/null && \
echo && echo "=== /opt/pakfire/tmp clean? ===" && ls /opt/pakfire/tmp/
If core/mine says 202 and grub shows 6.18.32-ipfire — reboot.
=== Core version file ===
201
=== Running kernel ===
6.18.7-ipfire
=== New kernel on disk ===
-rw------- 1 root root 48M Aug 3 17:41 /boot/initramfs-6.18.32-ipfire.img
-rw-r--r-- 1 root root 9.0M May 21 23:05 /boot/vmlinuz-6.18.32-ipfire
=== Grub sees new kernel ===
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
menuentry_id_option=""
export menuentry_id_option
menuentry 'IPFire 2.29 (x86_64) - core202 GNU/Linux' --class ipfire --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-4a8199de-0b47-4a03-8bb1-3a5a8c695356' {
linux /vmlinuz-6.18.32-ipfire root=UUID=4a8199de-0b47-4a03-8bb1-3a5a8c695356 ro rd.auto panic=10 console=ttyS0,115200n8
initrd /initramfs-6.18.32-ipfire.img
submenu 'Advanced options for IPFire 2.29 (x86_64) - core202 GNU/Linux' $menuentry_id_option 'gnulinux-advanced-4a8199de-0b47-4a03-8bb1-3a5a8c695356' {
menuentry 'IPFire 2.29 (x86_64) - core202 GNU/Linux, with Linux 6.18.32-ipfire' --class ipfire --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.18.32-ipfire-advanced-4a8199de-0b47-4a03-8bb1-3a5a8c695356' {
linux /vmlinuz-6.18.32-ipfire root=UUID=4a8199de-0b47-4a03-8bb1-3a5a8c695356 ro rd.auto panic=10 console=ttyS0,115200n8
initrd /initramfs-6.18.32-ipfire.img
menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' {
=== need_reboot flag ===
-rw-r--r-- 1 root root 0 Aug 3 17:41 /var/run/need_reboot
=== /opt/pakfire/tmp clean? ===
core-upgrade-2.29-202.ipfire files.tar.xz ROOTFILES update.sh
Everything is perfect — one thing missing: Step 5 was never done. core/mine still says 201 because you haven’t written the version file yet. The update ran clean, grub is ready, initramfs is built. Do it now:
echo "202" > /opt/pakfire/db/core/mine && \
cat /opt/pakfire/db/core/mine && \
rm -f /opt/pakfire/tmp/* && \
reboot
That was AI reply …
More analysis from my AI agent - I gave it the boot log from the APU machine
Textbook clean boot. CU202 is up and running on the APU2.
What the boot log tells us
| Service | Status | Note |
|---|---|---|
| Kernel | 6.18.32-ipfire |
New kernel ✓ |
| Filesystems | all clean | fsck passed ✓ |
| green0 | a.b.100.d |
✓ |
| red0 | a.b.10.c |
✓ |
| Unbound DNS | [OK] |
✓ |
| Unbound DHCP Leases Bridge | [OK] |
KEY — this is what might give you hard time in CU203 |
| DHCP Server | [OK] |
✓ |
| Guardian | [OK] |
✓ |
| OpenVPN RW | [OK] |
✓ |
| WireGuard | [OK] |
✓ |
| apcupsd | [OK] |
✓ |
| SSH | [OK] |
✓ |
| Apache | [OK] |
✓ |
One non-critical failure:
setfont: Unable to load such font [FAIL]— console font loading cosmetic issue, happens on APU2 (serial console, no VGA framebuffer). Zero functional impact.
One expected warning:
OpenVPN N2N 'primary2test' not enabled [WARN]— not configured on test machine.
Status after manual upgrade:
pakfire list upgrade
Core-Update 2.29-x86_64
Release: 202 -> 203
Name: guardian
ProgVersion: 2.0.2
Release: 27
Installed: yes
Update available:
Version: 2.0.2 -> 2.0.2
Release: 27 -> 28
Name: htop
ProgVersion: 3.4.1
Release: 23
Installed: yes
Update available:
Version: 3.4.1 -> 3.5.1
Release: 23 -> 25
Name: iperf3
ProgVersion: 3.19
Release: 8
Installed: yes
Update available:
Version: 3.19 -> 3.21
Release: 8 -> 9
You’re welcome! I’m glad it worked.
The credit also goes to you for taking the time to prepare and verify each step.
The pakfire-manual add-on is public: New add-on: pakfire-manual