OpenBSD 7.3 hangs during upgrade

[TCH]

I have an OpenBSD 7.2 VM in VirtualBox 7, which i would like to upgrade. I use

sysupgrade

which gets the sets, reboots the machine, installs the sets, then prints

Making all device nodes... done.

and then hangs forever.

I tried to switch to another virtual console with Ctrl+Alt+Fx, but it did not work. Ctrl+C worked, i got a prompt, but barely could do anything, almost everything gave back "not found". (If it ran from a ramdisk, then it is not surprising.) If i told

reboot

to it, then it hanged again and not even Ctrl+C could bring it back.

After a physical reset of the VM, the system booted up and based on

uname -a

it is upgraded.

sysmerge
pkg_add -Uu

ran without problems.

I could install ports 7.3 too.

However, after the upgrade, Lazarus and all programs it compiled die. (Error messages in the linked topic.) I tried to rebuild Lazarus from the ports, but it failed because the lack of the library atk-1.x.

I already tried to do this several time and with one exception - when it froze right after downloading the sets and rebooting - the results was always the same.

I've reported the problem to ibara and he thinks my system is not upgraded properly. Considering it hanged each time during the upgrade, it is not a thought without merit...

Any ideas why does it hangs after making those device nodes and what else it should still do after it?

[jggimi]

The missing library is part of Gnome -- specifically, the package at-spi2-core. It could be that using -U with pkg_add could have missed the package update, or, that it is not actually installed. You can update it manually (if it's installed), with # pkg_add -u at-spi2-core.


The hanging you experienced was with the RAMDISK kernel, used for initial install, upgrade, and sometimes rescue.

[TCH]

I tried to do pkg_add -u too, but there was no difference. Now, still in the unupgraded 7.2 i did pkg_add at-spi2-core and it installed it. It seems, that this package was not installed at all. (I don't understand how did Lazarus built before then...) Then i upgraded my system (the upgrade hanged again after the device node part), then did sysmerge and pkg_add -u. It upgraded at-spi2-core too. Then i tried to install Lazarus. It failed again, because the lack of atk-1.x.

I've double-checked: at-spi2-core is now installed and upgraded. Still, building Lazarus fails.

Also, why does the upgrade hangs after making those device nodes? Any ide on that?

[jggimi]

Looking again in more detail, the issue you reported to ibara was:

===>  Installing lazarus-2.2.0_0 from /usr/ports/packages/amd64/all/
Can't install lazarus-2.2.0_0 because of libraries
|library atk-1.0.21809.4 not found
| /usr/local/lib/libatk-1.0.so.21810.0 (at-spi2-core-2.46.0p2): bad major

At 7.3-release, the package is at-spi2-core-2.46.0p2 and the library installed with that package is libatk-1.0.so.21810.0. Your port build is looking for an earlier version. Looking at ibara's devel/lazarus/Makefile, I see a WANTLIB for atk-1.0, without any detailed specificity, so I suspect you have a ports tree inconsistency, a mismatch between your tree's version and your OS version. Did you update your ports tree to 7.3?


I cannot tell you why your RAMDISK kernel was hanging, but I don't believe that issue is related to your build problem.

[TCH]

Originally Posted by jggimi

Did you update your ports tree to 7.3?

I did. It was in the opening post:

Originally Posted by TCH

I could install ports 7.3 too.

Although, i could've done it wrong. This is how i installed the new ports:

cd /tmp
ftp https://cdn.openbsd.org/pub/OpenBSD/$(uname -r)/{ports.tar.gz,SHA256.sig}
signify -Cp /etc/signify/openbsd-$(uname -r | cut -c 1,3)-base.pub -x SHA256.sig ports.tar.gz
cd /usr
tar xvzf /tmp/ports.tar.gz
rm /tmp/ports.tar.gz

And this is how i tried to install Lazarus from ibara's ports:

pkg_add fpc gmake libiconv gtk+2 at-spi2-core
pkg_delete lazarus
rm -rf /usr/ports/devel/lazarus
git clone --depth 1 https://github.com/ibara/openbsd-ports-wip /tmp/obsd-wip
cp -r /tmp/obsd-wip/devel/lazarus /usr/ports/devel
rm -r /tmp/obsd-wip
cd /usr/ports/devel/lazarus
make install

Originally Posted by jggimi

I cannot tell you why your RAMDISK kernel was hanging, but I don't believe that issue is related to your build problem.

So, you say, if it's done with installing the sets, then it's okay, even if it hangs after it?

[jggimi]

I don't think the two issues are related, because the RAMDISK kernel's upgrade script does not touch the contents of /usr/local/, nor does it touch your package database in /var/db/pkg/.

If you are concerned you may have inconsistencies in your installed packages and package database, run pkg_check(8) to correct them:

1. Back up your system.
2. Run pkg_check(8)

As for your ports tree: inspect the contents of /usr/ports/x11/gnome/at-spi2-core/distinfo and see if you're at release 2.46.0, which aligns with 7.3, or 2.44.1, which aligns with 7.2. If you're at 7.2, you've got the wrong tree, and if you're at 7.3, you've got some cleanup to do based on package builds while at the earlier release. That cleanup, if needed, would be something like $ make clean='all depends'. The clean=all target cleans out everything: old builds, bulk build cookies, packing lists, ... basically anything other than distfiles, while the clean=depends target applies the cleaning to the port and to all underlying dependencies in the build chain.

[TCH]

Okay, i'll do that, but i need to ask something first.
If i do make clean='all depends' and then rm /usr/ports before upgrading the system and install 7.3 ports after the system upgrade, will it yield the same result? Or i need to do make clean='all depends' explicitly after upgrading the system to 7.3?

[jggimi]

The clean targets will remove files from within the ports tree that may have been created during prior builds, such as files in /usr/ports/{bulk,plist,packages,pobj}/. If you delete your entire ports tree, that will eliminate the need to clean it.

For more information on `make clean` and its options, see the bsd.port.mk(5) man page.

[TCH]

Originally Posted by jggimi

If you delete your entire ports tree, that will eliminate the need to clean it.

Doesn't ports install files unto locations elsewhere in the FS? Or yes it does, but cleaning will not remove them either, so it does not matter?

In that case, i'd rather remove the entire ports tree and install the new one. Sicher ist sicher.

[jggimi]

The ports tree is used to build packages from source. That's its sole purpose. All package building and package creation occurs within the tree. The extraction and building from source code takes place in /usr/ports/pobj. Built packages are stored in /usr/ports/packages/. If you "make install" a port, many steps are taken before the `install` target calls pkg_add(1) to install the package that was just built.

Generally, packages are installed and managed with the pkg_* utilities. And usually when installed, programs and supporting executable files are stored in /usr/local, configuration and provisioning files are stored in /etc, and data structures, if any, are stored in /var.

If you're going to use the ports tree, I recommend you spend some quality time with the section of the FAQ called the Porter's Handbook, the ports(7) man page, and the bsd.port.mk(5) man page.

[TCH]

All right, with your guidance, i managed to upgrade the system and rebuild Lazarus in the new environment. (The key was to do the make clean='all depends' inside /usr/ports/devel/lazarus, after the upgrade, but before the rebuild.) Thank you very much.

Still, i do not understand, why did the already compiled Lazarus and all the programs compiled by Lazarus die with a bunch of errors after the system upgrade... Was there an ABI breakage between OpenBSD 7.2 and 7.3?

[jggimi]

Originally Posted by TCH

All right, with your guidance, i managed to upgrade the system and rebuild Lazarus in the new environment.

Congratulations! Glad you got things working again.

Was there an ABI breakage between OpenBSD 7.2 and 7.3?

I don't have enough information to be able to provide a specific answer. I can see that Lazarus has 34 run dependencies, and you would have to review each individually to see what has changed between releases, should you be deeply interested in the nitty gritty details.

[TronDD]

Originally Posted by TCH

Was there an ABI breakage between OpenBSD 7.2 and 7.3?

Yes. Immutable stack, changes to syscalls. Maybe other things.

[TCH]

Originally Posted by jggimi

I don't have enough information to be able to provide a specific answer. I can see that Lazarus has 34 run dependencies, and you would have to review each individually to see what has changed between releases, should you be deeply interested in the nitty gritty details.

Based on what TronDD said, it's not the dependencies, but the system itself...

Originally Posted by TronDD

Yes. Immutable stack, changes to syscalls. Maybe other things.

Oh, dear... It seems, that i need to provide two OpenBSD binaries of my program; one for 7.2 and below and other for 7.3 and above. Great...

Thanks for enlightening me.

[jggimi]

OpenBSD's binaries -- whether included in the base OS, or a third party application packaged for execution -- are intended to match the system they are built with. Every component the program depends upon has interfaces which may alter between releases. In this particular instance, your application depends on 34 separate dependent third party packages to execute properly, and requires 14 callable libraries -- both third party and base -- for direct functionality.

It is possible -- but not guaranteed -- to upgrade an existing OS to the next release and have some previously installed third party packages continue to run, because an upgrade does not delete old libraries.

[jggimi]

It may help to review the section on shared library major.minor numbering in the Porter's Handbook.

http://www.openbsd.org/faq/ports/spe...tml#SharedLibs

The tl;dr is 1) a minor number bump is used whenever only new functionality is added and programs built against a prior revision will still continue to work, and 2) a major bump is used whenever there are changes to the interface and applications require rebuilds to function.

[TCH]

The program died with an access violation, what does not seem an API mismatch to me; the changed syscall scheme - ABI change - seems to be the culprit...but i might got the wrong impression. However, until this point since i started to support OpenBSD, i've never encountered such a result, that a Lazarus built binary failed to run after a system upgrade, because the only external dependencies my programs have are GTK2 components which are no longer under development.

[TronDD]

As jggimi was describing, OpenBSD does not guarantee ABI compatability between releases choosing instead to allow themselves the freedom to advance technology, improve security, and shed legacy baggage. That trade-off bit other people this release as well with applications in other languages.

I don't know who you're providing binaries to or what your support plans are but if you follow OpenBSD's support structure, you would support the current release and the previous. So in cases where there is a breaking change, you would provide 2 releases for a year at which time it would be expected that they upgrade the OS.

[TCH]

Originally Posted by TronDD

As jggimi was describing, OpenBSD does not guarantee ABI compatability between releases choosing instead to allow themselves the freedom to advance technology, improve security, and shed legacy baggage. That trade-off bit other people this release as well with applications in other languages.

I understood that, i think you guys misunderstood me.

Originally Posted by TronDD

I don't know who you're providing binaries to or what your support plans are but if you follow OpenBSD's support structure, you would support the current release and the previous. So in cases where there is a breaking change, you would provide 2 releases for a year at which time it would be expected that they upgrade the OS.

I understood that too, i already got it done: http://oscomp.hu/?lang/en*games/s/YTFE
The old OpenBSD binary was working since OpenBSD 6.8 or 6.7; i do not remember which i used in November 2020, when i started to support OpenBSD: http://oscomp.hu/?lang/en*news/min/549

[TronDD]

Ah, great. I was just making it clear in case it wasn't and to say that you weren't the only one caught off guard with this release.

Glad you're sorted out.