Page: Previous  1, 2

techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4076
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
this should now be fixed, it required adding more testing logic to handle debian dropping support for 686 non pae kernels. Why they did that I cannot understand given their near obsessive desire to support the most arcane platforms.

The tests are more granular now, and include error messages when no non pae kernel is detected for a system that doesn't support pae, ie, pentium M laptops mainly.

I believe it should work now, we'll see.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4076
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
Update, for standard debian kernels, I modified the 686 detection to use the following:

if a non pae kernel is available and if the system has less than 3 gB ram, use 686 standard.

else if a pae kernel is available and if the system supports pae, use the pae

else if bigmem (previous name for pae) is available and system supports bigmem, use the bigmem

else if no non pae 686 kernel is available and the system does not support pae, then use the 486 kernel.

Siduction has both 686 and 686-pae for the time being, so smxi will pick the right one for your system.

liquorix as of 3.7 offers only pae, so if the user system doesn't support pae, they will see an error message and get no kernel offered.

I think that about covers it.
Back to top
ckosloff
Status: Contributor
Joined: 21 Dec 2011
Posts: 292
Location: South Florida
Reply Quote
Thanks for update and all the clarifications you posted.
I just ran update/dist-upgrade via smxi on same dinosaur machine and kernel detection went through without a glitch.
So that should be fixed by now, will test later on the other 32-bit computers, if something goes wrong will report here.

What I have seen recently is that when doing update smxi will fail with error 100. However, upon selecting option 2 (update), it does work. Don't know if this is related to smxi or the damn US mirror.
Depending on your answer I will start new thread for further testing.

Regarding your criticism of Debian's overreach, this has been addressed to the project several times and I fully agree.
The project should be more focused, and stop supporting things that never worked like the HURD.
It would issue timely releases if it would just focus more, wheezy is delayed.
Like KDE for Windows, never seen even one fkuing user.
Cheers.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4076
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
error 100 simply means there was an error of some type in the update, usually the output that scrolls by shows it.

It's easier to see this when you use smxi in x, with: smxi -G

then you can scroll back and find the error.

Errors can be time outs, failures to download update files, failure to have proper keyrings installed for repo, and failure of repo itself.

If running update again fixes it, it's probably slow/bad repos, I can certainly state I never use ftp.us.debian.org repos, those are horribly slow and unreliable, though over time they apparently improved, only to start failing again recently. I use better repos that are more consistently reliable.

Hopefully they will put up mirrors.kernel.org but that was taken down after kernel.org was hacked and severely compromised, don't know when that will go back online, if it does, that's consistently the fastest.

But mirror.peer1.net is quite fast in my part of the country, sometimes it's geographical, so you want to find the mirror close to you that's consistently fast. None of the debian mirrors, like ftp.xx.debian.org are reliable in my experience.
Back to top
ckosloff
Status: Contributor
Joined: 21 Dec 2011
Posts: 292
Location: South Florida
Reply Quote
Hi techadmin,

Thanks for generous explan on mirrors.
This time the d-u worked fine on this really old computer too, kernel detected OK.
It dates back to the era when the IBM computer department still existed, before Lenovo purchased it.
Also, no error 100, seems everything is working.

:: Code ::
root@Netvistamami:/home/netvistamami# inxi -bxx
System:    Host: Netvistamami Kernel: 3.2.0-4-686-pae i686 (32 bit, gcc: 4.6.3)
           Desktop: KDE 4.8.4 (Qt 4.8.2) dm: kdm Distro: Debian GNU/Linux 7.0
Machine:   System: IBM product: 679021U serial: KA6G670  Chassis: type: 3
           Mobo: IBM model: IBM Bios: IBM version: 20KT46AUS date: 06/04/2004
CPU:       Single core Intel Pentium 4 CPU (-UP-) clocked at 1793.834 MHz
Graphics:  Card: NVIDIA NV6 [Vanta/Vanta LT] bus-ID: 01:00.0 chip-ID: 10de:002c
           X.org: 1.12.4 drivers: nouveau (unloaded: fbdev,vesa) tty size: 80x37 Advanced Data: N/A for root
Network:   Card: Intel 82801BA/BAM/CA/CAM Ethernet Controller
           driver: e100 ver: 3.5.24-k2-NAPI port: 2000 bus-ID: 02:08.0 chip-ID: 8086:2449
Drives:    HDD Total Size: 82.0GB (-)
Info:      Processes: 174 Uptime: 10 min Memory: 484.1/755.2MB Runlevel: 5 Gcc sys: N/A
           Client: Shell (bash 4.2.37) inxi: 1.8.27
root@Netvistamami:/home/netvistamami# inxi -f
CPU:       Single core Intel Pentium 4 CPU (-UP-) cache: 256 KB clocked at 1793.834 MHz
           CPU Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts
           acpi mmx fxsr sse sse2 ss ht tm up pebs bts
root@Netvistamami:/home/netvistamami#

Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4076
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
that reminds me, I have to make the inxi flags sort for cpu.

You might also try liquorix, on that old system you might find it a touch snappier than default debian.

easy to add in smxi, just select add liquorix sources, set system to use liquorix by default, then install latest liquorix.

Or not, if you like the more stable debian style.
Back to top
Display posts from previous:   
Page: Previous  1, 2
All times are GMT - 8 Hours