Mageia forum

to check to see if Mageia 7 will run on your older unit, open a terminal and

Code: Select all

lscpu

for me, trimmed output thus:

Code: Select all

$ lscpu
Architecture:          i686
CPU op-mode(s):        32-bit

AMD Athlon(tm) XP 2400+

Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
                       mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext
                       3dnow cpuid 3dnowprefetch vmmcall

if sse, and not also sse2, returns in the flags, you, like me will have a decision to make, as Mageia7 code does not appear to be able to installed on this hardware due to this.

I would normally open a bug for this type of issue, but due to the age of the unit, (17 years) I thought it best to gauge how many systems are likely to be affected before continuing.

benmc wrote:as Mageia7 code does not appear to be able to installed on this hardware due to this.

What's the actual issue, does the installer not run, does it crash, does it not boot at all, or ... ?

doktor5000 wrote:the installer not run

The Live installer fails just after starting the install wizard, clicking next produces a window which says "please wait...", then the installer exits after a few minutes.

extract from journal :

Code: Select all

Apr 10 16:38:59 localhost kernel: traps: finish-install[2411] trap invalid
opcode ip:b1a08df8 sp:bffc7170 error:0 in librsvg-2.so.2.46.0[b19f9000+4cc000]
Apr 10 16:38:59 localhost drakx-installer-xsetup[2025]:/etc/X11/xsetup.d/40finish-install.xsetup: line 38: 2411 Illegal
instruction (core dumped) /usr/sbin/finish-install

The Classic (and net) install) exit immediately before presentation of language selection screen.

It has been my observation that, regardless of intent, support for 32 bit is decaying away.

As much as anything, this seems to be happening because the developers have a dearth of working hardware on which to test, and the toolsets continue to evolve...with the old 32 bit code not being adequately tested as this evolution occurs. When an update to, say, gcc occurs and it breaks 32 bit support, no one notices until way, way downstream. Then, fixing that problem becomes a low priority upstream.

For myself, I am working on a major update to the firmware in the system our company sells, and this involves a migration from FreeBSD 8.4 to FreeBSD 12. Our package has been 32 bit, and I tried to migrate to FreeBSD 12 32 bit in order to support backward compatibility with some of our oldest devices (which are 32 bit) but I found a key feature of FreeBSD 12 to be broken in the 32 bit version. After debating the merits of fixing it (I could, though it is deep in the kernel) vs making the technically right decision of moving to 64 bit, I decided to move to 64 bit, and we will block these very old boxes from trying to update (there's only a few hundred of them out there).

So, I think this problem is beginning to be widespread and it will continue to spread. Rather than a date certain after which there will be no 32 bit support, many projects will just see that support decay away.