Suse does something different - again

I wanted to report something that I wasn’t able to find any reports, yet, still - for an issue that exists since 16.0 hit the floor - or at least it’s not documented well enough for me able to find it myself …

… anyway: the issue is about how to bootstrap a new system via pxe
in the past I used the ability of iPXE to be able to download kernel and initrd from teh internetz and boot it without me having to provid any physical or local media
that’s it: a simple three-liner: download kernel from download.opensuse.org - download matching initrd - boot it with a few flags to start the installer

with 16.0, however, this no longer works - at least not as convenient as I’m used to
I still can download the kernel and the initrd - and even the LiveOS/squashfs.img from the repo - but at switch root all I get is this:

[  OK  ] Finished Plymouth switch root service.
         Starting Switch Root...
[   24.313788][    T1] systemd[1]: Failed to execute /bin/sh, giving up: Exec format error
[  !!  [   24.313820][    T1] systemd[1]: Freezing execution.
] Failed to execute /sbin/init
[!!!!!!] Failed to execute fallback shell.

this is still true with the most recent 16.1 as well
however, when I download the netinstall iso, i have
agama-installer-Leap.x86_64-Leap.iso
agama-installer.x86_64-Leap_16.0.iso
agama-installer.x86_64-Leap_16.0_PXE.iso
only the 555mb one from agama-installer.x86_64-Leap_16.0.iso works - which requires me to host it somewhere to bootstrap via pxe

well, within my lan that wasn’t an issue - for my VMs - but when I wanted to finally upgrade my server from 15.3 to 16.0 I again had the problem: as it was the very machine providing all the pxe stuff i had to put the new stuff on the esp and boot from there (i stopped trying an in-place dist-up long ago - last time I tried was 10.2 or so - as for some reason suse just doesn’t like it - so I switch to just clean install since)
well - ok, for my homelab that’s a possible option - or maybe host at my main system for the mean time - but how about my root at OVH?
it’s still on 15.6 as I still struggle to get simple stuff like apache2 user_dir working thanks to that annoying SELinux - it costs me more than it helps

so - TL;DR: why you provide a faulty image at repo/oss/LiveOS - and why noone has reported that, yet? or am I doing something wrong? likely - but, if so, because it’s nowhere properly explained
even figuring out how to properly pxe boot took quite some effort by digging through quite thin agama documentation

overall this release gets an D at best - the only thing keeping me from getting it an outright F is: at least it somehow works when you put quite a lot of work into it

why is, that suse always seem to do something somewhat slightly different that things working on other baselines break for unknown reasons? I had years of issues with MariaDB because the repo-build was somewhat different to what they provide themself - so whenever I installed my James database it failed when I used the repo provided version - using the version from MDB themself - no issue - never figured out why … but at least that seems to got fixed, finally
now we have a broken installer - btw, if you rely on cockpit, you should make it default - first try 16.0 - not selected cockpit - uhm, yea, let’s just say: trying to get yast working was quite an adventure - and, of course, failed in the end
cockpit has its own issues: for some reason I’m unable to use its packagekit to update but have to rely on zypper - which can break due to auto-logout from the active terminal → better use ssh instead

honestly - I grew quite annoyed over the years - using arch since 2022 on my main system - never had any issues of such kind - I should really reconsider keep using suse on my servers

OpenSUSE Leap 16.0:

bash-5.2# ls -alh /bin/sh
lrwxrwxrwx 1 root root 4 Mar 10  2025 /bin/sh -> bash
bash-5.2# ls -alh /bin/bash
-rwxr-xr-x 1 root root 1015K Mar 10  2025 /bin/bash

SUSE Linux Enterprise Desktop 15 SP7:

ls -alh /bin/sh
lrwxrwxrwx 1 root root 11 13. Okt 2025  /bin/sh -> /usr/bin/sh
foo@mymachine:~> ls -alh /usr/bin/sh
lrwxrwxrwx 1 root root 4 13. Okt 2025  /usr/bin/sh -> bash
foo@mymachine:~> ls -alh /usr/bin/bash
-rwxr-xr-x 1 root root 989K 13. Okt 2025  /usr/bin/bash

The squashfs.img in the LiveOS directory of the Leap 16.0 distribution has S/390 binaries in it. That’s why you’re getting the exec format error. S/390 binaries don’t work very well on x86_64 hardware ;). I ran into the same problem and it took me a while to figure out what was going on. OpenSUSE should distribute squashfs.img images for all the supported architectures in LiveOS.