Pakfire upgraded my system to core 192 without my express intent to make that upgrade.
I went to the IPFire/Pakfire screen in the Web GUI this evening and it showed that there were updates available for clamav and speedtest-cli. I clicked on the upgrade button to update those two addons and ended up with pakfire installing the core 192 update in addition to the updates for clamav and speedtest-cli.
Core 192 was not listed in the ‘Available Updates:’ box and should not have been installed.
I’m guessing that when the upgrade button is clicked pakfire does a refresh and then updates anything eligible and that if I had clicked on ‘Refresh list’ the update to core 192 would have shown up in the ‘Available Updates:’ box so I would have know that it would be updated.
But the system did not act as expected. I expected the two updates listed to be installed not to have the core 192 upgrade done.
The new build addons are often linked against updated libs of the core system so if there is an core update availbale you have to install it before you can install other addon upgrades.
@arne_f You make a good point, but I would have liked to have known that a core update was going to happen. I would have scheduled it differently.
I did some research and here’s how it looks like this happens:
Updates to some add-ons are published to the mirrors.
The nightly pakfire update runs and picks up the information for the published add-on updates.
Some time after the nightly pakfire update, the core release is published to the mirrors.
The system administrator accesses the Ipfire/Pakfire page and sees that add-on updates are available. The sysadmin does not see that the new core update is available because the core update was not published at the time that the nightly pakfire update ran and is not reflected in the local pakfire database.
Sysadmin clicks on the ‘Upgrade’ button to update the add-ons.
The pakfire upgrade finds both the add-on updates and the core update and upgrades all.
And that’s how you get an unexpected core upgrade.
So, maybe call this a very slow race condition.
Due to the timing involved, I think that there is a pretty small chance of others running into this issue. An upgrade would have to be run the day of a core update release before the next nightly pakfire update to see this.
Also, a ‘Refresh list’ before running the upgrade would update the local pakfire database so that the core update would be shown.
yes I agree that you might have fallen victim of a little race where the web UI was showing you what it had and package lists have just been updated in the same moment and therefore when you confirmed the proposed update of the packages, you also got the OS updated.
In some way, this is intentional. Not the race, but that you will always be on the latest version. This is security here, we really need you to be on the latest release at all times.
Sometimes people like to “wait a little” until the update has “matured enough”. But this is not cheese. The update won’t get better with time. We will never change an update after it has been released, there will just be more updates to follow. So there is very little point in waiting for a week or two, or even a month, and only update then.
A lot of good comments on the how, when and why of pakfire updates.
For the issue of being surprised by an update that’s not listed on the pakfire page, I propose the following solution:
When the upgrade icon is clicked, run ‘pakfire update’ and then display a confirmation page with the list of updates before proceeding with the updates.
This changes the window of time that a surprise update could occur from up to 24 hours between nightly pakfire updates or whatever interval between ‘Refresh list’ to the small amount of time between when the confirmation page is displayed and the upgrade icon is clicked. It does take about 10 seconds (on my system) to load the confirmation page, but a reasonable delay to know exactly what updates will occur and be able to confirm them.
This is also consistent with the install/remove operations for pakfire add-ons which ask for confirmation before proceeding.
With the current system, if there are no updates listed under ‘Available updates:’ and you click on the upgrade icon, the system will actually run a ‘pakfire upgrade’ with nothing to do. This doesn’t cause any problems per se, but adding a confirmation screen would allow a check to be performed so that ‘pakfire upgrade’ won’t run unless needed. (You can’t see it on the screenshot below, but the upgrade icon is disabled if ‘No updates available.’.)
I agree, @ms. However, there is the case that a potential bug or other issue may be in a new update and updating to it could make life uncomfortable for a sysadmin. I have 3 IPFire installations, but only one of them is mission critical. I typically update the other two right away and monitor the forums for any potential issues. If a week goes by and no one has flagged a serious flaw, then I upgrade the mission critical system. If such a flaw should occur, I’d rather be stable on the previous build until the next update which addresses the flaw is released.
Hmm, I am not against this, but I do think that it should not be necessary. The listing on the page before should already be the same that you are proposing for this new page, because when that little green button is being clicked, Pakfire does not pull the package lists again. It will just install what it knows is available right then and there.
So I assume that you just had a race of the package lists being refreshed just between loading the Pakfire page and clicking the button. That can still happen with this solution.
It should be and probably 999 times out of 1000 it will be.
When the IPFire/Pakfire page is loaded, it displays the current state of the local pakfire database from the last nightly update (assuming ‘Refresh list’ has not been done). Any updates published to the mirrors after this will not be shown on IPFire/Pakfire until the next nightly update (or ‘Refresh list’). Essentially, the IPFire/Pakfire page says, “Here’s what I know about from last midnight-ish.”
pakfire.cgi “knows” what is reflected in the local pakfire database.
‘pakfire upgrade’ “knows” what is reflected on the mirrors.
So in the case of the state where the local pakfire database is not current with recent updates to the mirrors, ‘pakfire upgrade’ “knows” more than pakfire.cgi and upgrades accordingly.
Edit: The proposed confirmation page does a ‘pakfire update’ before displaying the upgrade list.
It’s not a race between the loading of the IPFire/Pakfire page and the clicking of the upgrade button. It’s a race between when the last ‘pakfire update’ was done, when a new update was published to the mirrors, and the clicking of the button, which can be up to about a 24 hour window. It’s true that a race condition between the ‘pakfire update’ performed by the proposed confirmation page and the clicking of the button on the confirmation page can still happen with this solution, but presumably that would be a much smaller window.
Also, for consistency… I have the opportunity to review and confirm the installation or removal of an add-on, which I think is a good thing. It makes sense to me to have the same opportunity to review and confirm a core and/or add-on update.
No, pakfire upgrade should never update the package lists. That is why I am thinking that showing the status on the first page and having the button without any further confirmation should be enough.
pakfire update has to be trigged somewhere else to run an update of the package lists.
Okay, in that case… Should we think about a bigger overhaul of that page? Would you be up for that? From the top of my head, the icons have to go, there should be buttons. The whole UI is not very good any more. I am not thinking to make it super nice and flush, but we should consider fixing a couple of low-hanging fruits.
You can even submit a patch for this way before we get into the other stuff as it is an independent change and it will make the rest shorter and therefore easier to review.
These are the colour codes. There should be a --no-color option that is presumably missing. Adding that to all commands should fix it.
Yes. I am not sure the side-by-side view of installed/non-installed packages is any good. But I don’t really have an amazing idea how to improve this without having more meta data (e.g. a description for the package) available.
We have this data in IPFire 3, but that is not ready for prime-time, yet.
