New FreeBSD pkgbase-update(8) Tool

pkgbase — it was supposed to be beautiful, easy, and wonderful, but it’s a disaster. I thought the goal of introducing this mechanism was to improve the update process—not just within a single release, but also for upgrades to other FreeBSD releases. How could such an option be overlooked during the tool's design phase?The old solution was the best. It worked perfectly because it *always* worked. The only drawback was updating configuration files, which could be an ordeal for beginners. I am disappointed. The direction in which the system is evolving is getting worse and worse.

vermaden, excellent work. The script should be implemented in the base system.
 
Yampress said:
pkgbase — it was supposed to be beautiful, easy, and wonderful, but it’s a disaster. I thought the goal of introducing this mechanism was to improve the update process—not just within a single release, but also for upgrades to other FreeBSD releases. How could such an option be overlooked during the tool's design phase?The old solution was the best. It worked perfectly because it *always* worked. The only drawback was updating configuration files, which could be an ordeal for beginners. I am disappointed. The direction in which the system is evolving is getting worse and worse.
Click to expand...
You're too quick to dismiss this concept. It's just that the (official) tool isn't written for the moment. That will come for sure. Maybe it will be integrated in freebsd-update itself. In the meantime, you have the pkgbase upgrade instructions as complex as they may be. Or use the Vermaden tool.
 
I am looking forward to the official method of upgrading from 15.x to 16.0. I wonder if we're getting "do a freebsd-update to 16 followed by a pkgbasify" or "you must do pkgbasify on 15 first then pkg upgrade".
 
grandpa said:
Looking forward to using this in the future. Maybe add a question if user wants to sync with quarterly or latest?
Click to expand...
That's independant unless you move from a RELEASE to a STABLE or a CURRENT version where you can fall in a trap if you chose the latest RELEASE repos before.

Latest and quarterly things concern ports and ports-kmods repos, not the base repo. You add a file in /usr/local/etc/pkg/repos/ if you want the latest repos. No change compared to freebsd-update fashion.
 
vermaden well done... the lack of a tool like this is why I'm still using freebsd-update on 15.1. A suggestion to help further reduce the gap between freebsd-update and pkg - add automatic boot environment snapshots to every update and upgrade. My preference would be for this to happen silently every time, but others may wish for a prompt to confirm. Either way... that particular feature of freebsd-update has saved my bacon, and it absolutely belongs in any future update tool.
 
...and still no equivalent to freebsd-updates' "fetch", "updatesready" and most importantly "rollback" commands for pkgbase.
So I guess it's safe to assume it won't get these features before it is forced upon everyone. So we end up with something utterly inconvenient and incomplete that requires wrapper scripts to be even remotely usable for basic tasks to replace something that wasn't broken. Do we really need to adopt such a "design philosophy" from linux-land?
 
When was `pkgbase` introduced? An update tool should have been prepared and rolled out at the same time. What’s happening now is a complete joke. First, we create something that doesn’t fully work and isn’t well thought out, and then we scramble to come up with a workaround. It’s an absolute farce. This isn’t moving toward improvement and better usability. Has anyone here used Debian? You just change an entry in a system configuration file, run two commands, and the system is updated. That’s how it works for many Linux distributions: a minor configuration change followed by an update using just two commands.
 
Personally, the rollback feature never had a real use for me. The few times I tried it, it failed, leaving a more or less instable system. But, I suppose it does work sometimes, especially when you are on UFS.

I think that before to do a tool, the FreeBSD team is waiting for bugs / improvements on the pkgbase system. It's the way I see the process.
 
Emrion said:
Personally, rollback feature never had a real use for me. The few times I tried it, it fails, leaving a more or less instable system. But, I suppose it does work sometimes, especially when you are on UFS.

I think that before to do a tool, the FreeBSD team is waiting for bugs / improvments on the pkgbase system. It's the way I see the process.
Click to expand...
I used it a few times on embedded systems (i.e. UFS) where no BEs are available and it always saved my butt every time and spared me from some tedious nightshifts. Introducing a 'replacement' and dropping such a game-changing feature that absolutely sets FreeBSD apart from pretty much any other OS is madness... (especially if that replacement can't even handle the primary task of the tool it replaces in a sane way)
 
Yampress said:
The only drawback was updating configuration files, which could be an ordeal for beginners. I am disappointed. The direction in which the system is evolving is getting worse and worse.
Click to expand...
I haven't updated an OS in years (but can respect others doing it longer-term and OSs supporting it), but I'm kind-of curious why wiping and redeploying isn't a quicker consideration before gambling.

Clean OS install ensures the updated OS installs good, and gives a nice opportunity to glance at config files :D (maybe there's old conf for a fix not needed anymore, or maybe something's deprecated for the new version that would have been a potential interruption/troubleshooting step during the OS/etc upgrades; can figure that out per-software vs during a bulk operation :p)
 
sko said:
(especially if that replacement can't even handle the primary task of the tool it replaces in a sane way)
Click to expand...
pkgbase is not a tool, it's a means to update a FreeBSD system. You compare wrong things. For the moment, no one is forced to use pkgbase (I don't, except for testings). When it will be the case (if it happens a day), you will have a damned good tested official tool.

So, I have added the BETA target to pkgb-update. It works, but there are no kmods repos for 15.2. Is it normal? Could be fatal in some circumstances...
 
Hi
Thank you very much—another very useful project.
I also don’t understand why a scripted tool isn’t included in the RELEASE or referential .
After all, `pkgbase` hasn’t exactly just appeared in the last few months!
Thanks Vermaden !
 
Yampress said:
pkgbase — it was supposed to be beautiful, easy, and wonderful, but it’s a disaster. I thought the goal of introducing this mechanism was to improve the update process—not just within a single release, but also for upgrades to other FreeBSD releases. How could such an option be overlooked during the tool's design phase?The old solution was the best. It worked perfectly because it *always* worked. The only drawback was updating configuration files, which could be an ordeal for beginners. I am disappointed. The direction in which the system is evolving is getting worse and worse.

vermaden, excellent work. The script should be implemented in the base system.
Click to expand...
This may be controversial to some:
  • freebsd-update has been around for a while, so it stands to reason most of it's problems have been solved already
  • pkgbase has been introduced primarily with 15, it's still on the experimental phase exactly to evolve it and to figure out the pain points and address them in time 16 gets released (December 2027), as an early adopter I know for a fact that what worked on the 15 alphas to upgrade a system no longer works the same for example
  • freebsd-update is not exactly user friendly (as this forum has ample proof) and has lots of places stuff can go wrong (as is documented on the handbook), plus upgrades take ages
  • pkgbase is not really more complicated than what freebsd-update does behind your back
  • pkgbase supports upgrades (15.1 -> 15.2, 15.1 -> 16), sidegrades (15.1 to 15-STABLE and vice-versa) and downgrades (16 -> 15) caveat emptor
  • pkgbase is the official future, but as with any open source software, if there's a will to bring back the old way and someone wants to mantain whatever infra is needed to generate the patchsets and what not, maybe it doesn't need to be "your" future (generic your)
So what we are missing are tools that do the same things that freebsd-update does now like the tool Emrion created and parts of this tool Vermaden created. If now is the time to add these tools to base? Maybe not but it's nice that they exist.
 
Yampress said:
When was `pkgbase` introduced?
Click to expand...
DerTeufel said:
IIRC in 14.x. The 15.0 installer gives a choice, but still calls it preview.
Click to expand...
It goes way back further than 14.x
When conceived it sounded killer.
Somehow in 8 years it is still beta.

Phishfry

Post in thread 'Running a ssh server running on a schedule'

What do you think about pkgbase? There are 795 packages for base. I am only using 200 lines of WITHOUT_=

Then I could distribute my updated OS image as a pkg and maybe incorporate updatep1 script to run too..
I am researching it now.

I have my disk image slices down to 97MB. They will grow back some but I hope to keep it a 120MB download.
Slimming the kernel bought me 30Megs.
 
For a start - thank You all for all welcome comments.

The same as all of You I also do not like how PKGBASE is being organized and handled.

The concept is good but the 'planning' around it? Terrible.

It was kinda HUGE shock for me that it was not though at all how to do minor upgrades ... up to that point I believed that PKGBASE concept is a well though 'thing' that just needs some 'steps' for execution and time (or money) are the only 'slowers' ... but unfortunately not. Earlier the 'minor upgrades' were not though enough ... now the automation (or tool) is in the same 'stage' ... this is not what I expected from FreeBSD UNIX system and people ... but yet ... here we are ... and this is one of the reasons why pkgbase-update(8) happened.

I really wanted that PKGBASE would have its own separate pkgbase(8) command separate from pkg(8) ... but FreeBSD project decided otherwise.

grandpa said:
Looking forward to using this in the future. Maybe add a question if user wants to sync with quarterly or latest?

/grandpa
Click to expand...
There is no 'latest' or 'quarterly' for FreeBSD Base System - the 'latest' or 'quarterly' is only for pkg(8) packages.

covacat said:
the script is kinda crude and it seems that only supports zfs and efi boot. also looks like will overwrite any efi boot manager you have
Click to expand...
I can make that 'optional' ...

I already added UFS support and BIOS (gpart bootcode ...) support.

Its like with beadm(8) that I have done in the past:
https://forums.freebsd.org/threads/howto-freebsd-zfs-madness.31662/

One 'thing' at a time.

... and even after all work (not only mine) related to beadm(8) the FreeBSD project decided they will do bectl(8) rewrite instead ... such a waste of time and money in my opinion.

Especially that even years after bectl(8) was introduced it was still buggy and sometimes beadm(8) 'activation' of ZFS BS solved bectl(8) issues ... crazy.

Regards,
vermaden
 
here is a better way to find if efi boot is used, what partition it used, and the loader path
i tested it on 14.5 14.3 15.1 both arm64 and amd64 (4 hosts)
it works on all but by no means is an extensive test
it uses efivar, kenv, geom
sh: 
#!/bin/sh

get_uuid()
{
local tmp0="$1" tmp1 tmp2
tmp1=${tmp0#*HD*,*,}
tmp2=${tmp1%%,*}
tmp2=${tmp2%)}
echo $tmp2
}

IS_EFI=$(kenv -q loader.efi)
if [ "$IS_EFI" != "1" ]; then
 echo "NO EFI"
 exit 1
fi

A=$(efivar cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderDev --binary --no-name|tr -d '\0')
LOADER_DEV=$(echo $(get_uuid $A)|tr A-F a-f)
LOADER_PATH=$(efivar cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath --binary --no-name|tr -d '\0'|tr '\\' /)
echo $LOADER_DEV $LOADER_PATH
pname=""
state=0
for z in $(geom part list -a |grep -E 'efimedia|Name');do
    case $state in
        1) pname=$z
        state=0
        continue;;
        2) puuid=$z
        puuid=$(get_uuid $puuid)
        state=0
        if [ "$LOADER_DEV" == "$puuid" ];then
            echo "$puuid => $pname"
            break;
        fi
        pname=""
        continue;;
        0)
        if [ $z = "Name:" ];then
            state=1
        elif [ $z = "efimedia:" -a "$pname" != "" ];then
            state=2
        fi
    esac
done
 
You must log in or register to reply here.
Back
Top