WARNING: Leap 16.0 users' CPUs must meet baselevel-x86_64-v2

English Open Chat
,
1

implement better protection from effect of failure to meet baselevel-x86_64-v2 is the title of a Bugzilla report I filed on 24 Jan. that has been locked inaccessible to openSUSE users. What I write here belongs in the news and announcements forum, but I am not allowed to create posts there. It was announced there Sept. 2022 as applicable to ALP, but I found out the hard way with a 4-core 4-thread AMD Phenom II X4 965 it applies to Leap 16.0, and duly reported so on the Factory mailing list, whereupon LuboĹĄ Kocman asked that I file a Bugzilla report.

What this means is that current Leap users should not bother to try an online upgrade from 15.6 to 16.0, or installing 16.0 pre-alpha or later afresh, on an unsupported (too old) CPU. These CPUs and the PCs and laptops containing them have been, unlike Tumbleweed, which uses hwcaps to keep older CPUs viable, ecologically un-greenly determined to be more landfill fodder for those wishing to continue using the stable version of openSUSE to which they have been accustomed.

The upgrade and installation processes are supposed to inhibit or outright prevent installation or upgrade on unqualified hardware, but this is apparently broken at least for now. Any simple go/nogo method for Leap users to determine in advance whether their CPU meets baselevel-x86_64-v2 qualification I have not yet located, but the tail of the following command will list subdirectories of glibc-hwcaps as a fair indicator:

/lib64/ld-linux-x86-64.so.2 --help
3 Likes
2

Version 2 chips have been around for about 18 years. How long after then did version 1 chips continue to be produced?

3

Among other x86_64s with 15.6 running on them, I have:

  1. 6 2009 CPUs, of which only 1 is v2
  2. 5 2008 CPUs, none v2
  3. 3 2007 CPUs, none v2
  4. 8 2006 CPUs, none v2

Years listed are manufacturer release dates. All except two have 2 cores with 2 total threads. My newest of the whole bunch is 4 core v1 from AMD. 2nd newest is 2 core 4 thread Intel. After the 09s I didn’t acquire for 3 years, in part due to the absence of OEM PS/2 ports.

4

Are there any criteria about what bug reports are publicly viewable and what are not?

5

Great, I’m sure Luca and the rest of the Leap team will be excited to see your contributions to keep support for x86_64-v1 in Leap 16, Felix, since it seems to be so important to you.

3 Likes
6

I don’t know the background for this, but hardware deprecation used to be an MS-method for keeping hardware sales high. Moreover it was one of the reasons to switch to linux/opensuse in the past.

Very sad to here this “industry standard” has reached linx/opensuse. Is Debian an alternative?

1 Like
7

@suse_rasputin but it’s the cpu feature set, flags, vulnerabilities etc that can’t be supported by software as well… As Spock said “The needs of the many, out way the needs of a few”

8

It is unrealistic and nonsensical to stop developement and progress, only to keep compatibility with over 17 (in words: seventeen) years old hardware.

To stay up to date, keep maintenance efforts at a reasonable level, keep the code base somewhat “clean”, to save the rare time of devs and to be able to support a software product for the next 10 years you have to drop the support for some antigue hardware at one point.

And to be honest, support for over 17 years for cheap consumer hardware is more than one could ever expect. Honestly you can’t even use such antigue hardware for more than editing a text.

And as already pointed out by others: the ppl which still use such antique hardware and would be able to support the devs with testing in most cases don’t step up. This was the same with the split from 32-bit openSUSE derivates. The devs asked for support as they don’t had the hardware to test. The outcry of the last few users of the antigue hardware was loud, but the will to support the devs is zero. So the 32-bit derivates are more or less dead…

9

64bit - 64-bit Linux and x86_64-v1 micro-architecture - Unix & Linux Stack Exchange

10

@malcolm: Spock was psychodivers (at best), in our world other words for his mindset come to mind :smiley:

@arvid: I read the link, is TW supporting v1 or not? The link says no, in the the OP I read it as yes…

11

What’s actually important to me is retarding pollution however I can, which includes activities tending to keep useful equipment out of landfills, and retarding consumption of natural resources - green stuff - like any good Geeko.

I’m not a developer or programmer or maintainer, but I do like contributing in the fashion that I already am, much of which shows up in the 393 bugs reported to date over the past 19 years on bugzilla.novell.com, bugzilla.opensuse.org, and often in turn to upstream bug trackers, so I won’t be reallocating to something entirely out of my realm.

Depends on the meaning of “progress”. 17 years ago, 32bits was still adequate to task. The progress I see the most of is bloat. 17 years ago, openSUSE 11.0 shipped a 64bit kernel 2.6.22 in a single 20M rpm. The current kernel in 16.0 is shipped as 3 packages, 114M + 29M + 31M, 174M in total, or 8.7X larger than 11.0’s. The so-called development and progress comes with tremendous can-do (but so what, better to track users and feed video ads?), and opportunity for CVEs and other bugs, baggage.

Just as junk accumulates according to the amount of space available for it to fill, so does software grow according to the capability of the hardware. The final upstream Linux incarnation of Firefox 2.0 as 2.0.0.20 released in December 2008 was 9.3M, only in 32bit. For 3.x in March 2012 as firefox-3.6.28.tar.bz2 it was still 32bit and up to 11M. openSUSE 11.3 in November 2011 provided 3.6.24 in an 861K 64bit rpm. Upstream’s firefox-128.6.0esr.tar.bz2 is 83M, while MozillaFirefox-128.6 in Leap 16.0 is 70.4M.

I haven’t seen any indication of v1 being dropped in Trixie (testing for Debian 13 release expected this summer). Of it I have around 13-14 installations on x86_64 v1 PCs (called amd64 on Debian).

I have around 30 TW installations on x86_64-v1 PCs.

12

Felix, You’ve been around the project long enough to know how this works.

And I’m tired of you throwing fits, impugning other’s work, and generally being negative.

For those of you that don’t know, or those of you that haven’t looked into it, this is how things work:

Primary development happens in Factory, which becomes the Distribution we release, called “Tumbleweed”. SUSE takes periodic snapshots of Tumbleweed, and develops their SUSE Linux Enterprise product from that.

Leap is then developed from the SLE sources at a slight delay from SLE Releases. i.e. SLE 16 releases, and shortly after, you’re going to see a Leap 16. SLE 16 SP1 would become Leap 16.1

SUSE is a business, and their customers have either told SUSE that they don’t care about x86_64-v1 support, or SUSE has determined, through whatever method, that they don’t have any customers still using x86_64-v1 machines.

Therefore, SUSE isn’t going to allocate resources to continue supporting -v1 in SLE 16.

Why does this matter to openSUSE Leap?

Because Leap is built from SLE sources. If SLE 16 doesn’t support it, Leap 16 won’t support it. UNLESS somebody/somebodies from the community step up, to maintain it in Leap. SUSE has no reason to be doing it.

The argument about tumbleweed using hwcaps is a red herring. Leap could be made to do it, but again, it would be up to community developers to make it work in Leap, if that’s something the community wants.

Again, if SLE doesn’t do a thing, neither will Leap, without community members stepping up to make it happen.

Or, you know, you can sit around, and accuse volunteers of not putting in the work to make the distribution you want.

I for one, am not going to sit here on the sidelines, and watch you insult other people anymore Felix.

4 Likes
13

No, it is not. It directly uses SLE binary packages, nothing gets rebuilt. There are very few packages built for Leap (release package first and foremost) and those packages are not built from SLE sources.

And that does hurt community involvement. For a start, we are not even entitled to see build logs for these packages unless we are also SUSE employees with access to the internal OBS instance. Or sudden changes in packages by SUSE employees due to bug reports that we are not even allowed to see. Etc.

For all practical purposes, Leap as it is now is not a community product, but SUSE product.

14

SLED free edition?

Leap 16.0 will rebuild packages, because of conversion from x86-64-v3 to v2.

15

I’m moving this discussion to Open Chat. It is NOT a request for help.

2 Likes
16

100% agreed here, @sfalken .

17

Given that it’s an important thing to you, Felix, it seems to me that rather than coming to the forums or the MLs to complain about it, you might step up in some way (as sfalken suggested) and find out how you can help.

Yes, you’ve said you’re not a developer - and I saw that. So ask the maintainers how, as a non-developer, you can help. Maybe you can help by finding other users who have similar ancient hardware, and maybe some of those people do have development skills.

Coordination is an important contribution.

Yelling from the rooftops isn’t. (In my opinion - and it seems I’m not alone in that opinion)

Otherwise, it seems to me your options are:

  1. Find another distro that supports your old hardware
  2. Accept that you will just need to run something other than the latest version of Leap
  3. Find a way to make a contribution that doesn’t read to the people who do the work as “yet another complaint to ignore”.

The problem of hardware becoming obsolete isn’t new. I have two older systems (not quite as old as the ones you’re using) sitting in a closet.

But I’m also not going back to using a Commodore 64, and doing machine language programming on an SDK-86.

But as hardware improves and gets faster, it’s only logical that software is going to be developed that takes advantage of the new functionality - and as more people use newer hardware, those who have older hardware are going to get left behind, as there are fewer and fewer people to maintain it. We went through this exact same cycle of complaints when 32-bit went away. When i386 went away.

And someday, it’ll be when x86_64 goes away because at some point, nobody will have the knowledge or desire to maintain those ‘ancient’ early 21st century systems.

If you want the older systems to continue to be usable, you’ve gotta do the work. The “work” isn’t just development work.

Shouting from the rooftops isn’t the “work”. “Raising awareness” isn’t the “work”.

4 Likes
18

I found this: GitHub - HenrikBengtsson/x86-64-level: x86-64-level - Get the x86-64 Microarchitecture Level on the Current Machine.

19

Your beloved inxi shows this information. And you are perfectly aware about it, because the very same discussion about the default baseline already took place a couple of years ago with your participation.

1 Like
20

Intel® Core™ i7-4790K Processor launched in Q2/2014

> inxi -C -a
CPU:
  Info: model: Intel Core i7-4790K bits: 64 type: MT MCP arch: Haswell
    gen: core 4 level: v3 note: check built: 2013-15 process: Intel 22nm
    family: 6 model-id: 0x3C (60) stepping: 3 microcode: 0x28
  Topology: cpus: 1x dies: 1 clusters: 4 cores: 4 threads: 8 tpc: 2
    smt: enabled cache: L1: 256 KiB desc: d-4x32 KiB; i-4x32 KiB L2: 1024 KiB
    desc: 4x256 KiB L3: 8 MiB desc: 1x8 MiB
  Speed (MHz): avg: 800 min/max: 800/4400 scaling: driver: intel_cpufreq
    governor: schedutil cores: 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800
    8: 800 bogomips: 64000
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: KVM: Split huge pages
  Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT
    vulnerable
  Type: mds mitigation: Clear CPU buffers; SMT vulnerable
  Type: meltdown mitigation: PTI
  Type: mmio_stale_data status: Unknown: No mitigations
  Type: reg_file_data_sampling status: Not affected
  Type: retbleed status: Not affected
  Type: spec_rstack_overflow status: Not affected
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
    prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
    sanitization
  Type: spectre_v2 mitigation: Retpolines; IBPB: conditional; IBRS_FW;
    STIBP: conditional; RSB filling; PBRSB-eIBRS: Not affected; BHI: Not
    affected
  Type: srbds mitigation: Microcode
  Type: tsx_async_abort status: Not affected
>

inxi reports level: v3