openSUSE-13.2 install successful on old 32-bit PC that has no SSE2 support

I successfully installed openSUSE-13.2 on an old PC whose CPU (32-bit athlon-1150) has no SSE2 support. The openSUSE-13.2 Beta-1 install had failed previous (as noted here in this thread and here in this bug report that 32-bit installations fail with YaST error. That bug report was closed in lieu of another (bug 872908)](http://bugzilla.opensuse.org/show_bug.cgi?id=872908) to track the problem. There was also a very active thread on the mailing list debating whether such old hardware as this should continue have to support. In the end it was agreed to support such old hardware for openSUSE-13.2 version, and a fix was applied.

The fix was successful in that my install eventually was successful.

I did have a failure during install, with what appeared to be a kernel error. I obtained this error shortly after the install config MMI/GUI settings were set and when the applications were installing:

http://thumbnails110.imagebam.com/36320/5e4c47363192338.jpg](http://www.imagebam.com/image/5e4c47363192338)

where this was on the top of the same page (illustrating kernel version ) …

http://thumbnails112.imagebam.com/36320/9c9be5363192342.jpg](http://www.imagebam.com/image/9c9be5363192342)

I took a look at one of the install terminals but saw nothing that indicated a failure to me…

http://thumbnails112.imagebam.com/36320/478cfa363192343.jpg](http://www.imagebam.com/image/478cfa363192343)

This is OLD hardware, I thought it might be a DVD read error (as the DVD reader is old) or someother problem associated with PC age, so I decided not to waste time, but rather I immediately rebooted and tried a Fail Safe install. That appeared to work, although in the very first reboot at the end of the install I obtained this totally unreadable display (and the PC simply hung during boot) :

http://thumbnails111.imagebam.com/36320/498a4a363192344.jpg](http://www.imagebam.com/image/498a4a363192344)

I obtained that screen when booting nominally and also when booting with SAFE Settings. So I then embarked on an effort to try and see if there was a boot code that I could modify to get the PC to boot. In the end, I used SAFE SETTINGs but removed the ‘x11failsafe’ and instead applied 'brokenmodules=nouveau" and the PC booted to the LXDE desktop. I am not convinced the “brokenmodules=nouveau” was the fix to get this first boot to work. Once it was booted I noted that the TEXT setting applied for the screen display when booting is obsolete. I went into the GRUB2 menu, and removed the various kernel code that the SAFE install had applied, and in doing so the Boot manager also applied the setting “vga=normal” and I believe it is that kernel boot code that allows the boot to continue nominally. The ‘TEXT’ setting is apparently depreciated.

The PC now runs great with this 13.2 and compared to the older 12.3 I also have on this PC the 13.2 appears to boot quicker and also execute quicker (mostly). I note YaST runs slower, but that may be because I changed the LXDE YaST to use QT instead of GTK.

The above was on a Test partition on this old PC, and I plan next to install the 13.2 on this same PC, replacing its main functional partition (which has 12.3 on it). I suspect then if I obtain the same kernel installation error, I will know if the problem is repeateable (and not just a failed DVD read problem with the old DVD drive on this PC).

inxi -F output detailing the very old hardware that is running :


oldcpu@linux-spsv:~> inxi -F
System:    Host: linux-spsv Kernel: 3.16.6-2-default i686 (32 bit) Desktop: LXDE (Openbox 3.5.2) 
           Distro: openSUSE 13.2 (Harlequin) 
Machine:   Mobo: MSI model: MS-6380E v: 1.0 Bios: American Megatrends v: 07.00T date: 04/02/01
CPU:       Single core AMD Athlon (-UP-) cache: 256 KB clocked at 1150 MHz
Graphics:  Card: NVIDIA NV34 [GeForce FX 5200]
           Display Server: X.Org 1.16.1 drivers: nouveau (unloaded: fbdev,nv,vesa) Resolution: 1680x1050@59.88hz
           GLX Renderer: Gallium 0.4 on NV34 GLX Version: 1.5 Mesa 10.3.0
Audio:     Card-1 Ensoniq 5880B [AudioPCI] driver: snd_ens1371 Sound: ALSA v: k3.16.6-2-default
           Card-2 VIA VT8233/A/8235/8237 AC97 Audio Controller driver: snd_via82xx 
Network:   Card-1: Realtek RTL-8100/8101L/8139 PCI Fast Ethernet Adapter driver: 8139too
           IF: enp0s8 state: unknown speed: 100 Mbps duplex: full mac: 00:50:fc:5f:ba:6d
           Card-2: Qualcomm Atheros AR5212/AR5213 Wireless Network Adapter driver: ath5k
           IF: wlp0s10 state: down mac: 00:11:95:91:76:f5
Drives:    HDD Total Size: 484.0GB (1.6% used) ID-1: /dev/sda model: ST3320620A size: 320.1GB
           ID-2: /dev/sdb model: Maxtor_6Y160P0 size: 163.9GB
Partition: ID-1: / size: 25G used: 3.7G (16%) fs: ext4 dev: /dev/sdb1 
           ID-2: /home size: 50G used: 145M (1%) fs: ext4 dev: /dev/sdb5 
           ID-3: swap-1 size: 1.04GB used: 0.00GB (0%) fs: swap dev: /dev/sda3 
           ID-4: swap-2 size: 2.85GB used: 0.00GB (0%) fs: swap dev: /dev/sdb3 
Sensors:   System Temperatures: cpu: 46.5C mobo: 41.0C 
           Fan Speeds (in rpm): cpu: 4192 fan-2: 0 
Info:      Processes: 117 Uptime: 0:35 Memory: 343.7/2016.4MB Client: Shell (bash) inxi: 2.1.95-4 

I next installed the 32-bit openSUSE-13.2 (from the installation DVD) with LXDE desktop on to same old PC, this time on the main partition replacing openSUSE-12.3.

I did a normal install (ie NOT with SAFE settings) with one exception … in the installation DVD initial boot menu, I added the boot code “vga=normal”. I don’t know if that made a difference, but this time the install was smooth. No kernel errors. Nominal / regular graphics upon the 1st reboot. The installation was much slower this time, but I believe is because (1) install was going on to a slower hard drive on this old PC, and (2) I was using the normal install, and not a ‘safe’ install.

Thus far, the install has been a SUCCESS ! :slight_smile:

I plan to setup printer , scanner, test sound, etc … next.

I setup the network printing and scanning (to my HP All-In-One Premium C309a Printer) on this old PC. The printing install was easy, BUT it did NOT go perfectly smooth. On the first attempt, right at the end of configuring the printer, from HPLIP application wizard I obtained a warning that the printer install application could not find the .ppd file for my printer. That made no sense to me as HPLIP was installed as was the necessary libraries and I was highly confident the printer .ppd file was there. So rather than waste time investigation, I went to YaST and forced a re-install of HPLIP and its libraries. I then tried again to install the printer driver (using the EXACT same method as before) and it worked fine this time. …

… I can’t explain the first failed attempt, other than to note this is an old PC. The network scanning function was also easily setup.

I downloaded the 32-bit Google Chrome browser and installed it, but it turns out old hardware such as is on this PC is not supported by Google Chrome. I obtained this warning …
http://thumbnails111.imagebam.com/36328/210223363272406.jpg](http://www.imagebam.com/image/210223363272406)

advising me Google Chrome is NOT supported by this old hardware.

So not all is golden in the old PC world.

But it IS good to see openSUSE-13.2 supporting this hardware, and I do intend to get more use out of this old PC, even if the lights in our city dim at night (due to the inefficient power draw of this old PC) everytime I boot up the PC. :stuck_out_tongue:

Hi, I’m also upgrading to 13.2 on an old PC and I have the same graphics card (GeForce FX 5200). I also got the illegible blocks after booting and your “vga=normal” setting cured that for me too. I got this problem when installing 12.2 2 years ago and the setting “nopat” cured it then (not this time). On 12.2 I then installed the nvidia driver “X11-video-nvidiaG01” and after that I could remove the boot settings and the graphics was good. I find now that nvidiaG01 is not available for 13.2 (here) and I’m wondering will it be provided later or are we now canned? Does anybody know?
Mike

You may have to dig but my understanding is that NVIDIA is droping support for the older cards. ie GO1 drivers. Maybe time for a new card :slight_smile: Or make do with the OS driver

NVidia dropped support for the G01 driver quite some time ago already, I’m afraid.

So there definitely won’t be any effort to make it work with newer kernels and Xorg versions.
See here: Support timeframes for Unix legacy GPU releases | NVIDIA

Support for X.Org xserver version 1.15 was added to the 173.14.* legacy driver series with version 173.14.39. No further releases from the 173.14.* series are planned.

Heck, even the G03 driver is already labelled as “Legacy driver”…

On 2014-11-10 23:26, wolfi323 wrote:

> Heck, even the G03 driver is already labelled as “Legacy driver”…

Heck, that’s what I have on my main computer!

It is an “GeForce 9500 GT” card (“nVidia G96 [GeForce 9500 GT]”, says
hwinfo), using x11-video-nvidiaG03-331. It is not that old! Less than 8
years, surely.

http://en.wikipedia.org/wiki/GeForce_9_series#GeForce_9500_Series

Launched 29th July 2008. Six years ago.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Well, they won’t stop support (“for new Linux kernels and X servers, as well as fixes for critical bugs”) for G03 until the end of 2019 though.
Even G02 will still be supported until 2017…

Who knows, till then nouveau maybe really is a viable alternative for those cards? :wink:

On 2014-11-11 01:26, wolfi323 wrote:
>
> robin_listas;2675051 Wrote:
>> On 2014-11-10 23:26, wolfi323 wrote:
>>
>>> Heck, even the G03 driver is already labelled as “Legacy driver”…
>>
>> Heck, that’s what I have on my main computer!
>
> Well, they won’t stop support (“for new Linux kernels and X servers, as
> well as fixes for critical bugs”) for G03 until the end of 2019 though.
> Even G02 will still be supported until 2017…
>
> Who knows, till then nouveau maybe really is a viable alternative for
> those cards? :wink:

It is already an alternative, but not for things such as a flight
simulator game. Not for anything that needs speed. Till not long ago,
even gnome 3 complained. And the nouveau devs surely concentrate on new
hardware, same as the nvidia devs do, meaning they will never catch up.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Did you test a Firefox install?

So far, all seems good and encouraging in your report, thanks for sharing.:slight_smile:

The Firewall was active by default.

I did enable the ssh daemon and open the SSH port (in the Firewall) and was successfully able to sftp into this old PC. So I think that suggests in that aspect the firewall works.

On 2014-11-11 07:36, oldcpu wrote:
>
> Fraser_Bell;2675064 Wrote:
>>
>> Did you test a Firefox install?
>>
>
> The Firewall was active by default.

Er… FireFox, not FireWall :wink:

However, I intend to keep using 13.1 (Evergreen when it comes) on my 32
bit machine(s). If possible, I will upgrade that to whatever becomes the
following LTS to 13.1. I use it as home server, after all, not as
primary work machine. In that task it doesn’t matter slow desktop response.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

I upgraded my 32-bit box. That went smoothly. It is running quieter than it was with 13.1, which I think has to do with the radeon driver and graphics card power use.

Congratulations Oldcpu for keeping an old box alive, and thankyou for sharing.
You may choose to trim the default behaviour of systemd-journald if /var/log is on the “slower drive”, or install rsyslog.
The default would easily clog slower disks (e.g. SATA-I) within a few weeks of normal use with logs exceeding 30-80 MB per day.

Beware, installing “rsyslog” will not disable the on-disk journal!
You can have both without problems, as I do.
You have to remove the directory /var/log/journal/ to disable it.

The default would easily clog slower disks (e.g. SATA-I) within a few weeks of normal use with logs exceeding 30-80 MB per day.

I doubt that. At least not on a normally running system and KDE (AIUI, GNOME’s gdm would redirect all aplication output to the journal instead of ~/.xsession-errors-:X).

See here, from my system:

wolfi@amiga:~> du -h /var/log/journal/
63M     /var/log/journal/70b4618d99f9a3c39bfc0300471913e3
63M     /var/log/journal/

And the journal is enabled since at least January 2013:

wolfi@amiga:~> ls -ld /var/log/journal/
drwxr-sr-x 3 root systemd-journal 96  4. Jän 2013  /var/log/journal/

and I haven’t changed the defaults.

Oh and btw, I do not even have a SATA-1 drive here. It’s an 11 years old EIDE (parallel ATA) drive, with “only” 5400 RPM, and never noticed any problems caused by the journal.
I first used that drive/system on an Athlon XP (no SSE2 support) btw, now it’s an Athlon64, but only upgraded since then, no fresh installation… :wink: (I did switch to 64bit in the meantime though)

You got me… GNOME here!

total 143360
-rwxr-xr-x  1 root systemd-journal  8388608 nov  9 20:21 system@00050771f2a0f6ed-3237ab02a890fe00.journal~
-rwxr-xr-x  1 root systemd-journal 16777216 nov  9 21:46 system@0005077324140c97-e3e7e3b5ba445087.journal~
-rwxr-xr-x  1 root systemd-journal  8388608 nov  9 21:47 system@0005077328d77e74-d230c994cb2de36f.journal~
-rwxr-xr-x  1 root systemd-journal 16777216 nov 10 15:23 system@00050781e6d40251-aa4d93da926f3aeb.journal~
-rwxr-xr-x  1 root systemd-journal 20971520 nov 10 09:20 system@62146367ff4f4eaab3007a3a6c561314-0000000000000001-0005077327e1c5fa.journal
-rwxr-xr-x  1 root systemd-journal 20971520 nov 10 14:43 system@62146367ff4f4eaab3007a3a6c561314-0000000000006f11-0005077cd5ae64a9.journal
-rwxr-xr-x  1 root systemd-journal 20971520 nov 10 16:14 system@c57bba647a0f4184bf0c3ae3b5af3d17-0000000000000001-00050781e59fefff.journal
-rw-r-----  1 root systemd-journal 16777216 nov 11 19:11 system.journal
-rwxr-xr-x+ 1 root systemd-journal 16777216 nov  9 18:33 user-1000.journal


and this is just THREE days…
and nothing abnormal, maybe a few reboots more than usual just to play with some settings.

And IIRC you had (or still have?) a problem with some GNOME apps spitting out errors all the time, right?

My ~/.xsession-errors also doesn’t grow at that speed:

wolfi@amiga:~> ls -lh .xsession-errors-\:0 
-rw------- 1 wolfi users 1,3M 11. Nov 19:16 .xsession-errors-:0

That’s me being logged in for 8 hours:

wolfi@amiga:~> who
wolfi :0 2014-11-11 11:21 (console)
wolfi pts/2 2014-11-11 11:22 (:0)
wolfi pts/1 2014-11-11 11:22 (:0)

So this would be about ~12 MB in 3 days, and the journal does get compressed so even less.

Hey, it would be nice to discover that it’s just me, but this is not the case apparently!
I had gnome apps flushing the journal in 13.2RC1, but now with 13.2 “official” everything seems ordinary.
You are correct, with GNOME almost everything goes to the journal, from kernel (dmesg) to Xorg, to systemd.services proper or demons, to apps (NetworkManager, file manager, Firefox and all).
This adds up to (roughly) 600kB per boot + 400kB per hour of “normal” operation when extracted to a text file.
Plus, the original binary file for journal is all but compressed: to me it seems rather a “sparse” file.
So I collected some 21MB of binary journal for today’s activity (well, yesterday’s at the time of writing).

No other GNOME user noticed that to date? Are we so few out here?:cry:

On 2014-11-12 00:56, OrsoBruno wrote:

> So I collected some 21MB of binary journal for today’s activity (well,
> yesterday’s at the time of writing).
>
> No other GNOME user noticed that to date? Are we so few out here?:’(

There is a bug on 13.1 that some unknown gtk library or tool has been
recompiled, since an update, with debug logging on. I have tried to rise
attention to it, uselessly.

I had to create filters on rsyslog to dump those entries out of the
normal log:


> <1.4> 2014-11-11 15:18:36 Telcontar org.freedesktop.Tracker1.Extract 4456 - -  Tracker-Message: Importing config file to GSettings
> <1.6> 2014-11-11 15:18:36 Telcontar org.gtk.Private.UDisks2VolumeMonitor 4456 - -  ### debug: in handle_supported
> <1.6> 2014-11-11 15:18:36 Telcontar org.gtk.Private.UDisks2VolumeMonitor 4456 - -  ### debug: in handle_list
> <1.6> 2014-11-11 15:18:36 Telcontar org.gtk.Private.MTPVolumeMonitor 4456 - -  ### debug: in handle_supported
> <1.6> 2014-11-11 15:18:36 Telcontar org.gtk.Private.MTPVolumeMonitor 4456 - -  ### debug: in handle_list
> <1.6> 2014-11-11 15:18:36 Telcontar org.gtk.Private.GoaVolumeMonitor 4456 - -  ### debug: in handle_supported
> <1.6> 2014-11-11 15:18:36 Telcontar org.gtk.Private.GoaVolumeMonitor 4456 - -  ### debug: in handle_list
> <1.6> 2014-11-11 15:18:36 Telcontar org.gtk.Private.GPhoto2VolumeMonitor 4456 - -  ### debug: in handle_supported
> <1.6> 2014-11-11 15:18:36 Telcontar org.gtk.Private.GPhoto2VolumeMonitor 4456 - -  ### debug: in handle_list
> <1.6> 2014-11-11 15:18:36 Telcontar org.gtk.Private.AfcVolumeMonitor 4456 - -  ### debug: in handle_supported
> <1.6> 2014-11-11 15:18:36 Telcontar org.gtk.Private.AfcVolumeMonitor 4456 - -  ### debug: in handle_list
> <1.6> 2014-11-11 15:19:06 Telcontar org.gtk.Private.AfcVolumeMonitor 4456 - -  ### debug: Name owner ':1.163' vanished
> <1.6> 2014-11-11 15:19:06 Telcontar org.gtk.Private.GoaVolumeMonitor 4456 - -  ### debug: Name owner ':1.163' vanished
> <1.6> 2014-11-11 15:19:06 Telcontar org.gtk.Private.MTPVolumeMonitor 4456 - -  ### debug: Name owner ':1.163' vanished
> <1.6> 2014-11-11 15:19:06 Telcontar org.gtk.Private.UDisks2VolumeMonitor 4456 - -  ### debug: Name owner ':1.163' vanished
> <1.6> 2014-11-11 15:19:06 Telcontar org.gtk.Private.GPhoto2VolumeMonitor 4456 - -  ### debug: Name owner ':1.163' vanished

But it is just 5 MB in over a month. With certain type of activity, it
would grow more.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

lol !

Yes - Firefox runs fine. Its a bit slow to startup, but that was also the same in openSUSE-12.3.

As noted, I run LXDE on this old PC, and I am pretty happy with its performance. Frankly, I’m amazed it runs so well after all these years, and amazed I can have the latest OS with the latest applications. That is a testament to the GNU/Linux community and to the packagers and testers and users (who contribute) of openSUSE at SuSE-GmbH and the openSUSE community.