Just attempted to upgrade a working aarch64 Tumbleweed 20221123 (VM running VMware Fusion 13 on Apple mini M1) (2020) to 20221219.
After the upgrade, I find that trying to type more than 2 characters in the KDE desktop’s search bar will crash the desktop, and YaST will not execute many of its modules, even when presented with admin credentials.
Rolling back to 2022I123 gave me back a working VM.
The one strange thing that I noticed that during the upgrade, multiple instances of segmentation faults of /usr/bin/chkstat occurred. Notable faults occurred when installing unix_chkpwd, unix2_chkpwd, chfmn, chsh, expiry, passed, newgrp, passed, newgidmap, newuidmap, and cron.
/usr/sbin/unis2_chkpwd. I’ve upgraded this installation many times over the last 6 months and have never seen this behavior - I suspect that this snapshot is borked for aarch64.
1 Like
I wonder why you use a more than 10 day old snapshot to upgrade? Zypper is an outstandingly excellent package manager that will upgrade you with much less downloading involved than using a downloaded snapshot, and get you totally current in the process.
Using TW20221231 on x86_64 on hardware, I can’t reproduce your problem with typing in the search bar.
If zypper is so good, then the date differential between snapshots shouldn’t matter. But this isn’t a zypper issue, IMO. It’s an issue with the packages in the snapshot.
The particular VM where this occurs has been upgrading itself via zypper for months now. This particular snapshot update is the first I’ve had where it’s broken sone pretty basic functionality in the VM.
This could be an aarch64 issue. I’ll see if a newer snapshot fixes the issues.
I’m finding that there hasn’t been a newer snapshot available on aarch64 platforms for over 2 weeks. I know aarch64 sometimes lags x86_64, but 2 weeks is an awfully long time without any update. Perhaps they know of an issue…
1 Like
this… or there are holidays out there? 
In the days I was playing around with arm/raspi and TW I came to the conclusion it’s better not to update, as it will highly likely break something. There are other OSs for arm…
Agreed that the holidays may have something to do with it. But there are updated x86_64 snapshots, so I don’t buy that’s entirely the story. Downloading from openSUSE still gives me the 20221219 snapshot ISO installer, even though x86_64 has newer snapshots. The 20221219 aarch64 snapshot installer ISO is also seriously broken - it throws errors that prevent the installer from starting for both netboot and DVD ISOs.
I’m aware that there are other arm64 distros out there. I regularly test out various aarch64/arm64 operating systems on VMware Fusion running on a Mac mini (2020) M1. In addition to Tumbleweed, I’ve got RHEL, CentOS, Fedora, Ubuntu, Rocky Linux, Oracle Linux, openSUSE Leap, Gentoo, Kali. Windows 11 ARM, FreeBSD VMs working fine even with there with latest updates, plus I’ve done a few others in the past that I’ve forgotten. I’ve been doing this since VMware first distributed its Apple Silicon Tech Preview in Fall 2021. Tumbleweed has been one of the most stable aarch64 distros out there for me and the one that has given me the fewest problems. This is the first time that something got broken for me by a Tumbleweed snapshot update on aarch64.
1 Like
Debian, maybe? But maybe 32bit…
Agree with PERockwell. I’m having the same issues. A new snapshot for aarch64 needs to be made. The 20221219 one does not work.
To jklepach: Ran a test and found the same problems happen when running under UTM (which front-ends QEMU on Macs). Definitely leaning more toward problems with the snapshot rather than the virtualization platform.
I forgot to mention. My test was under Parallels Desktop 18 (most current version), running on M1 Apple Mac.
It looks like someone reported this to Bugzilla: Bug 1206684 – Segmentation fault with zypper-1.14.58-1.2.aarch64
According to the bug report, this is bug in libgcc_s1-13.0.0+git197351-4.1.aarch64. The issue has been reported to the upstream maintainers. There is a workaround for the ISO installer: add arm64.nopauth to the kernel arguments, and the installer will work and persist this setting into the installed system.
This also seems to be a workaround for existing installations who want to upgrade to 20221219. I added this into the kernel arguments of my existing installation, then upgraded to snapshot 20221219. I no longer have segfaults during package installations and the resulting system has YaST working properly as well.
As long as this works, I’ll keep the workaround in place until I can verify hat that underlying bug has been fixed.
1 Like
The workaround is still needed (and still works) for the 20230101 arm64 snapshot.
I’ve installed the upgrade to arm64 snapshot 20230119 on a working VM, and removed the workaround. All is working as expected (YaST works fine, for example).
A boot from the arm64 20230119 ISO also does not exhibit the errors that prevented the installer from running.
I think we can safely consider this issue as fixed in the latest snapshots.