Slackware 13.0 with KDE 3.5.10?
Tuxedo
I recently installed Slackware 13.0 on a notebook and everything
worked more or less as expected, except for direct graphic rendering
with my integrated Intel card. This has been the case for most major
up-to-date distros I tested on the somewhat old notebook, namely a
Samsung Q25. That said, a Knoppix CD with its superior HW-detection
came to rescue: I simply copied the entire xorg.conf file from within
a live Knoppix session over the version Slackware had generated and
all graphics thereafter worked brilliantly!
After testing Slackware 13.0 with KDE 4.2.4 for a while I found I
missed KDE 3.5. I personally think the old GUI is more user-friendly.
As such, I uninstalled Slackware 13.0 and reinstalled the earlier
Slackware 12.2, which of course comes with KDE 3.5.10. However, I
guess the better solution would be to install the latest Slackware
13.0 initially without KDE and thereafter manually install KDE 3.5.10.
I understand there are no binary packages for Slackware (http://
kde.org/info/3.5.10.php). Not having manually installed a windows
manager ever before, I have a subjective question: Is it a complicated
affair to install KDE 3.5.10 on Slackware? Will it even work on
Slackware 13.0? Or would I be better off to stick with Slackware 12.2?
If so, what important features would I be missing? Eg. the 'speaking'
kernel sounds like a potentially useful feature which I believe isn't
an available out-of-the-box option in 12.2.
Many thanks for any tips!
Tuxedo
Tuxedo
> If so, what important features would I be missing? Eg. the 'speaking'
> kernel sounds like a potentially useful feature which I believe isn't
> an available out-of-the-box option in 12.2.
In fact my current 12.2 Slackware installation appears to have 'Speak
Text' built into Konqueror. Only KTTS has not been configured. But for
some reason adding a voice does not seem to work. Must I install the
'festival' back-end first? I can't find this in KPackage. However,
kdeaccessibility-3.5.10-i48 exists on the system.
Henrik Carlqvist
> I missed KDE 3.5. I personally think the old GUI is more user-friendly.
> As such, I uninstalled Slackware 13.0 and reinstalled the earlier
> Slackware 12.2, which of course comes with KDE 3.5.10. However, I guess
> the better solution would be to install the latest Slackware 13.0
> initially without KDE and thereafter manually install KDE 3.5.10.
First question: Why would you prefer Slackware 13.0 instead of Slackware
12.2? If you don't know the answer and already know an answer to why you
would prefer Slackware 12.2 the easiest path is probably to stick with
Slackware 12.2 and keep your Slackware 12.2 up to date with patch
packages.
If Slackware 13.0 has some more package that you really like it is
probably a lot easier to compile that package for Slackware 12.2 than to
compile KDE 3 for Slackware 13.
So my advice for you right now is to stick with Slackware 12.2. One day
KDE 4 will have improved so much that it will have some features that you
really envy. That day you will be willing to learn the new look and feel
of the GUI to gain access to those new features and once you have learned
how to use the new version you will probably find even more new features
that you will like but also miss some old lost features. That day might be
when Slackware 13.1 is released or it might be when Slackware 17.3 is
released. You choose when to upgrade, if you don't think you have a good
reason to upgrade you shouldn't upgrade.
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
Eric Hameleers
> After testing Slackware 13.0 with KDE 4.2.4 for a while I found I
> missed KDE 3.5. I personally think the old GUI is more user-friendly.
> As such, I uninstalled Slackware 13.0 and reinstalled the earlier
> Slackware 12.2, which of course comes with KDE 3.5.10. However, I
> guess the better solution would be to install the latest Slackware
> 13.0 initially without KDE and thereafter manually install KDE 3.5.10.
>
> I understand there are no binary packages for Slackware (http://
> kde.org/info/3.5.10.php). Not having manually installed a windows
> manager ever before, I have a subjective question: Is it a complicated
> affair to install KDE 3.5.10 on Slackware? Will it even work on
> Slackware 13.0? Or would I be better off to stick with Slackware 12.2?
> If so, what important features would I be missing? Eg. the 'speaking'
> kernel sounds like a potentially useful feature which I believe isn't
> an available out-of-the-box option in 12.2.
Easy... download and install these packages which Pat made for people
like you who are not ready for KDE4:
http://slackware.osuosl.org/unsupported/kde-3.5.10-for-slack13.0/
They are compiled on Slackware 13.0. Their status is "unsupported",
meaning there is no guarantee they will work on slackware-current or
any future stable release.
Eric
Henrik Carlqvist
> Their status is "unsupported", meaning there is no guarantee they will
> work on slackware-current or any future stable release.
What about security patches? I suppose that unsupported packages will not
get any security patches? On the other hand as there is no longer any
upstream support for kde 3 there will probably not be much patches for the
official kde 3 packates in earlier versions of Slackware either.
Tuxedo
[...]
> Easy... download and install these packages which Pat made for people
> like you who are not ready for KDE4:http://slackware.osuosl.org/unsupported/kde-3.5.10-for-slack13.0/
>
> They are compiled on Slackware 13.0. Their status is "unsupported",
> meaning there is no guarantee they will work on slackware-current or
> any future stable release.
>
> Eric
Thanks for the tip - I will give this a try on a 13.0 installation!
Tuxedo
wrote:
> Eric Hameleers <er...@sox.homeip.net> wrote:
[...]
> What about security patches? I suppose that unsupported packages will not
> get any security patches? On the other hand as there is no longer any
> upstream support for kde 3 there will probably not be much patches for the
> official kde 3 packates in earlier versions of Slackware either.
Thanks for the above note as well as your previous comments on whether
to upgrade or not to upgrade. The answer to your question as to why I
prefer 13.0 over 12.2 is indeed what you suggested: I do not know.
Not having used either or having read or compared the release notes in
detail, except for the window manager version difference, I guess my
preference for a 13.0 version would be based on a notion that newer is
better, or more specifically in software, the assumption that some
things may last a bit longer in terms of compatibility with future
applications. Otherwise, kde-3.5.10 sounds like the perfect window
manager, no more updates, no more bugs, nothing new to learn. Finally
I can get some real work done!
Eef Hartman
> Eric Hameleers <er...@sox.homeip.net> wrote:
>> Their status is "unsupported", meaning there is no guarantee they will
>> work on slackware-current or any future stable release.
>
> What about security patches? I suppose that unsupported packages will not
> get any security patches?
No, they don't. It is an "as is" (then) compilation for 13.0 (both versions).
> upstream support for kde 3 there will probably not be much patches for the
> official kde 3 packates in earlier versions of Slackware either.
There never were any for 12.2 either, even when 3.5.10 was still supported.
The last KDE patch Pat supplied was for 12.1 (and KDE 3.5.9), in 2008:
kdenetwork-3.5.9-i486-3_slack12.1.tgz
And there were 3 updates for KDE 3.5.7 in Slackware 12.0
--
*******************************************************************
** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
** e-mail: E.J.M....@tudelft.nl - phone: +31-15-278 82525 **
*******************************************************************
jo...@wexfordpress.com
> Henrik Carlqvist <Henrik.Carlqv...@deadspam.com> wrote:
> > Eric Hameleers <er...@sox.homeip.net> wrote:
> >> Their status is "unsupported", meaning there is no guarantee they will
> >> work on slackware-current or any future stable release.
>
> > What about security patches? I suppose that unsupported packages will not
> > get any security patches?
>
> No, they don't. It is an "as is" (then) compilation for 13.0 (both versions).
>
> > upstream support for kde 3 there will probably not be much patches for the
> > official kde 3 packates in earlier versions of Slackware either.
>
> There never were any for 12.2 either, even when 3.5.10 was still supported.
> The last KDE patch Pat supplied was for 12.1 (and KDE 3.5.9), in 2008:
> kdenetwork-3.5.9-i486-3_slack12.1.tgz
> And there were 3 updates for KDE 3.5.7 in Slackware 12.0
> --
> *******************************************************************
> ** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
> *******************************************************************
The only reason I have for using 13 instead of 12.2 is Qt4, which is
required by the latest versions of some applications
such as Scribus.
Just FYI I doubt if I will be ever ready for KDE 4. It is about as
clunky as can be. Bad initial design can't be patched. I have gone
over to XFCE and will stay with that GUI for as long as it is
available. Someday someone or several someones will get the message
and put KDE 4 in the bit bucket along with Vista and the other failed
projects.
John Culleton
Slack since 1996 or thereabouts.
Tuxedo
[...]
> The only reason I have for using 13 instead of 12.2 is Qt4, which is
> required by the latest versions of some applications
> such as Scribus.
>
> Just FYI I doubt if I will be ever ready for KDE 4. It is about as
> clunky as can be. Bad initial design can't be patched. I have gone
> over to XFCE and will stay with that GUI for as long as it is
> available. Someday someone or several someones will get the message
> and put KDE 4 in the bit bucket along with Vista and the other failed
> projects.
Same here. I doubt I will ever switch to KDE 4! There's a KDE 3 for
Slackware 13 linked above in the thread. I just installed Slackware 13 but
couldn't make X windows run with DRI as I don't master the fine art of xorg
configuration, so I didn't get a chance to test this bundle. Instead, I
will bluntly revert to Slackware 12.2 in order to run X windows in DRI mode.
I believe my system has a fairly standard Intel on-board 82852/8255 GM
Graphics Controller, but none of the auto-config tools, such as "X
-configure" or "xorgsetup" generated an X windows config file with the
result of direct graphic rendering working on the system.
Does anyone here happen to have the same type of hardware and an xorg.conf
file with DRI configured and working?
My screen is 1024x768 True Color (60 Hz) although I'm not sure what
vertical and horizontal refresh rates and other necessary values may be. In
fact, I haven't found much documentation in relation to the graphics
hardware and screen configuration for any Linux system.
Alternatively, does anyone know of a procedure to run a Windows based
driver in Slackware using some kind of third-party program wrapper
application? I think the main file for the graphics driver in Windows XP is
located in c:\windows\system32\drivers\ialmnt5.sys. This is in an ntfs
partition on the same disk as my Slackware, mounted somewhere in
/media/hda4/WINDOWS/.... As far as I understand, it is an "Intel Extreme
Graphics 2" driver, which doesn't come with Windows itself but is supplied
by Intel or whoever sells the hardware and then installed separately, also
to speed up direct graphic rendering in Windows (without XP works sluggish).
So far only the vesa powered X windows works for me in most Linux's for
the hardware, which is a Samsung Q25 notebook. In fact, I found that the
graphics of many distros are either broken while attempting to run DRI on
this hardware. The effect is a kind of erratic screen flickering and other
graphical display errors that seems to kick more or less in depending on
what or how many applications are running at the same time. If left
unattended, sooner or later the hardware would probably get damaged.
An example of where graphics work including DRI is Knoppix 5. Knoppix uses
an auto-generated xorg.conf for the i810 driver. Also, the exact same
Knoppix generated xorg.conf file runs fine with DRI in Slackware 12.2, but
not in Slackware 13 for some reason. I understand some X things has changed
between the two versions.
The graphics will work Ok with any window manager which doesn't require
DRI, but of course, that doesn't include KDE, nor does it include running
programs within any window manager that happens to require 3D effects.
If anyone here has the same of type hardware using Slackware or another
distro with hardware acceleration working, it would be much appreciated if
you can kindly post a copy of your /etc/X11/xorg.conf in this thread.
Many thanks,
Tuxedo
Henrik Carlqvist
> I believe my system has a fairly standard Intel on-board 82852/8255 GM
> Does anyone here happen to have the same type of hardware and an
> xorg.conf file with DRI configured and working?
Sorry, I don't have that hardware and haven't much experience from
Slackware 13. However, in CHANGES_AND_HINTS.TXT I notice the following
rows:
extra/xf86-video-intel-alternate/xf86-video-intel-* (several alternate
versions of the Xorg intel driver just in case the default doesn't work
properly for you)
Dir you try any alternate drivers for your intel graphics chipset?
Tuxedo
> Tuxedo <tux...@mailinator.com> wrote:
> > I believe my system has a fairly standard Intel on-board 82852/8255 GM
>
> > Does anyone here happen to have the same type of hardware and an
> > xorg.conf file with DRI configured and working?
>
> Sorry, I don't have that hardware and haven't much experience from
> Slackware 13. However, in CHANGES_AND_HINTS.TXT I notice the following
> rows:
>
> extra/xf86-video-intel-alternate/xf86-video-intel-* (several alternate
> versions of the Xorg intel driver just in case the default doesn't work
> properly for you)
>
> Dir you try any alternate drivers for your intel graphics chipset?
Yes I also read that initially but couldn't find the packages in the 13.0
installation file system. So I had a closer look and now found the various
files within the extra directory on the bootable USB I had created:
xf86-video-intel-2.5.1-i486-1.txt <- text file (contaning no useful details)
xf86-video-intel-2.5.1-i486-1.txz <- package with driver
xf86-video-intel-2.5.1-i486-1.asc <- PGP signature
Additionally, there are txt/txz/asc files for driver versions 2.6.3 and
2.7.1 and 2.8.1, so in all there appears to be four additional Intel
drivers to the one that came with the Slackware installation.
Doing tar 'xf xf86-video-intel-2.5.1-i486-1.txz' on the first bundle I
found it contains the following files:
install/doinst.sh
install/slack.desc
usr/lib/libI810XvMC.la
usr/lin/libI810XvMC.so.1.0.0
usr/lib/libIntelXvMC.la
usr/lib/libIntelXvMC.so.1.0.0
usr/lib/xorg/modules/drivers/ch7017.la
usr/lib/xorg/modules/drivers/ (about 10 more driver files..).
usr/man/man4/i810.4.gz
usr/man/man4/intel.4.gz
Is there a package manager procedure to install these type of bundles in
Slackware automatically or should I just run the doinst.sh script?
After installation, xorg.conf will surely need to be configured for the
specific hardware/screen combination etc., but maybe 'xorgconfig', 'X
-configure' or 'xorgsetup' with one of the above drivers will then work.
To run a particular Slackware version or even Linux distro depending on
whether a fairly standard graphics chip works with xorg or not is far from
an ideal world....
Many thanks for any tips or pointers on how to do these rather complex
installations procedures.
Tuxedo
Henrik Carlqvist
> Doing tar 'xf xf86-video-intel-2.5.1-i486-1.txz' on the first bundle I
> found
> Is there a package manager procedure to install these type of bundles in
> Slackware automatically or should I just run the doinst.sh script?
The way to install a package is:
installpkg app-version-arch-build.txz
However as you are now upgrading or at least replacing a currently
installed package you should instead:
upgradepkg --install-new app-version-arch-build.txz
With the switch --install-new upgradepkg works for installing new packages
as well as replacing already installed packages.
> To run a particular Slackware version or even Linux distro depending on
> whether a fairly standard graphics chip works with xorg or not is far from
> an ideal world....
The problem in this case comes from the lack of standard when it comes to
graphics chips. During the time intel has made different changes and
improvements to their chipsets. These changes have also required changes
in the drivers, older drivers does not work with newer chipsets.
Unfortunately newer drivers also does not work with older chipsets. Even
more unfortunate, the driver still keeps the same old name "intel". As
things now are it would be better with different drivers for different
intel chipsets where the drivers with different names all could be
installed at the same time and correctly selected by matchin the name with
the PCI ID.
However, I don't want to complain about intel, at least this is a company
which realizes the advantage of releasing the source for their drivers.
Tuxedo
As mentioned, DRI works on 12.2 with an old Knoppix xorg.conf file.
However, sometimes, but only rarely, after logging out of a graphical
interface the text on the screen flickers as if the card had to work double
shifts. Perhaps the i810 driver in Slackware 12.2 isn't working entirely as
it should in combination with the xorg.conf options created for the
different Knoppix system and for use with possibly a different version i810
driver or the 12.2 built-in driver isn't the right one for the particular
hardware I have, who knows? Yet, the desktop is very speedy. All KDE 3D
screensavers etc. work perfectly! The 13.0 still hasn't been fixed and I
will try different drivers from the 13.0 'extra' repositary with
--install-new upgradepkg procedure and thereafter experiment with the
xorg.conf for each one on both systems, as I now have Slackware 12.2 as
well as Slackware 13.0 running on different partitions of the same drive.
Again, anyone who happens to have a functional xorg example or just the
relevants parts that define DRI and who can post them here would be most
helpful. The type of hardware used is an Intel on-board 82852/8255 GM
Graphics Controller and screen 1024x768 True Color (60 Hz). Although in the
display preferences in KDE as well as XFCE can be toggled up to 85 Hz and
of course various values below.
Tuxedo
Murat D. Kadirov
> Again, anyone who happens to have a functional xorg example or just the
> relevants parts that define DRI and who can post them here would be most
> helpful. The type of hardware used is an Intel on-board 82852/8255 GM
> Graphics Controller and screen 1024x768 True Color (60 Hz). Although in the
> display preferences in KDE as well as XFCE can be toggled up to 85 Hz and
> of course various values below.
I suggest upgrade your kernel to 2.6.31/32. AFAIK, 2.6.29 kernel has many
problems with Intel drivers in Linux. Upgrading to the 2.6.31 has helped
me with frequent Xorg' crashes after resume from suspend-to-ram. I have:
root@apollo:/home/murat# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME
Express Integrated Graphics Controller (rev 03)
But anyway, I think upgrading will help you. 2.6.29 kernel was bad
kernel in many way and it does not supported anymore.
--
Murat D. Kadirov
PGP fingerprint: 3081 EBFA 5CB9 BD24 4DB6 76EE 1B97 0A0E CEC0 6AA0
Tuxedo
Thanks for the tip, upgrading to kernel 2.6.31/32 sound worth a try! As a
user, I've never had a need to change a kernel before, so however simple it
may sound to some people on this group, I would have no idea how!
What is the best or easiest procedure to install and test an alternate
kernel? For starters, where can I find the actual kernel?
The way I installed the current system was by creating a bootable USB media
using UNetbootin (http://unetbootin.sourceforge.net). An excellent tool
btw. It includes the option of defining a path to a custom kernel.
My newly installed Slackware 12.2, which works extremely well in comparison
to any other distro I've tested, now has kernel 2.6.27.7:
bash-3.1# uname -a
Linux q25 2.6.27.7 #1 Mon Dec 8 15:21:42 CST 2008 i686 Intel(R) Pentium(R) M
processor 1.60GHz GenuineIntel GNU/Linux
Tuxedo
Henrik Carlqvist
> Murat D. Kadirov wrote:
>> I suggest upgrade your kernel to 2.6.31/32.
> I've never had a need to change a kernel before, so however simple it
> may sound to some people on this group, I would have no idea how!
Downloading a kernel from kernel.org and compiling it with reused settings
from /boot/config to .config might not be so hard. Also installing all the
modules included with the kernel is easy.
However, after this is done some problems may remain. Maybe some kernel
modules are missing because they were not part of the kernel package but
instead came from other packages like X, alsa or some kind of binary
drivers. Also those modules will have to be tracked down and recompiled. I
don't know how many such modulers there is in Slackware 13, but I know
there have been such modules in earlier versions of Slackare.
Then with a new kernel you will have a glibc which doesn't match your
current kernel. In most cases this is not a problem, but at least in teory
it could lead to problems.
So instead of upgrading the kernel I would suggest to upgrade or downgrade
the entire distribution to a version that works fine.
Tuxedo
[...]
>
> So instead of upgrading the kernel I would suggest to upgrade or downgrade
> the entire distribution to a version that works fine.
Yes, sticking with a kernel that comes with an installed Slackware version
and then somehow making the Intel graphics work with DRI sounds like the
potentially "easier" option for me compered with updating the kernel.
Tuxedo
Grant
>Tuxedo <tux...@mailinator.com> wrote:
>> Murat D. Kadirov wrote:
>>> I suggest upgrade your kernel to 2.6.31/32.
>
>> I've never had a need to change a kernel before, so however simple it
>> may sound to some people on this group, I would have no idea how!
>
>Downloading a kernel from kernel.org and compiling it with reused settings
>from /boot/config to .config might not be so hard. Also installing all the
>modules included with the kernel is easy.
>
>However, after this is done some problems may remain. Maybe some kernel
>modules are missing because they were not part of the kernel package but
>instead came from other packages like X, alsa or some kind of binary
>drivers. Also those modules will have to be tracked down and recompiled. I
>don't know how many such modulers there is in Slackware 13, but I know
>there have been such modules in earlier versions of Slackare.
Huh? Maybe back in the pre 2.4 series days?
>
>Then with a new kernel you will have a glibc which doesn't match your
>current kernel. In most cases this is not a problem, but at least in teory
>it could lead to problems.
No, upgrading the kernel doesn't change glibc at all.
>
>So instead of upgrading the kernel I would suggest to upgrade or downgrade
>the entire distribution to a version that works fine.
Er, no.
Running the latest kernel is easy, I've been doing it for many years.
First thing I do after a new slack install is upgrade to latest kernel.
Only exception to running latest is on slack-11 box where I'm running
2.6.27.42 (2.6.27 is extended maintenance release kernel) to avoid
updgrading iptables user-space.
Usually only the latest and latest-1 kernel releases are maintained,
this means you may have security or other issues with older kernels.
Grant.
--
http://bugs.id.au
Grant
You're being wimpish about upgrading kernel ;)
Kernel Intel driver fixed in later kernel. So wait for slack-13.1?
Grant.
--
http://bugs.id.au
Tuxedo
[...]
> You're being wimpish about upgrading kernel ;)
Yes, wimpishness, as well not having a clue how to upgrade a kernel :-(
Currently I have a newly installed Slackware with kernel 2.6.27.7.
The installation was done with a full DVD version of Slackware 12.2, while
specifying the 'speakup.s' option, hoping my laptop will speak to me one
day. The installation was done on a reiserfs partition with no prior
Slackware system or library leftover files etc., and more or less according
to all default settings, with the exception of adding all available
languages in KDE and excluding some unwanted window managers.
One thing I haven't quite figured yet is why to create an initial RAM disk
image (initrd) and then adding parameters in LILO. It appears important but
I'm still not sure what the actual purpose is? In HINTS_AND_CHANGES it is
suggested to use a provided generic kernel for daily use and something
about stock generic kernels and that the huge kernels are primarily for
installation and emergency, as well as more about whether to use a SMP or
non-SMP kernel.?.. This particular section of HINTS_AND_CHANGES assumes a
great deal of knowledge on the topic of kernel configuration, which is
beyond my understanding. It is certainly nothing I've had to deal with when
installing other ready-to-run distros. As far as I can see, the installed
Slackware already runs fine without these post-installation preparations.
Anyway, I understand the latest stable kernel is 2.6.32.2:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.2.tar.bz2
Is the Intel i810 driver working better in this version?
Are there any standard Slackware specific tools or procedures that can be
used to upgrade the kernel? Can anyone kindly give me any pointers on how
to perform the upgrade, ideally including actual commands?
I found a "LILO Boot Manager" section in KDEs Control Centre and that in
the "Operating Systems" tab there's an "Add Kernel" button. Is this a tool
used in the process of updating the kernel? I doubt it is as easy as
pressing a button, although that would be a dandy feature :-)
> Kernel Intel driver fixed in later kernel. So wait for slack-13.1?
Ideally not!
Tuxedo
Henrik Carlqvist
> On Fri, 01 Jan 2010 12:52:12 +0100, Henrik Carlqvist wrote:
>> Maybe some kernel modules are missing because they were not part of the
>> kernel package but instead came from other packages like X, alsa or
>> some kind of binary drivers.
> Huh? Maybe back in the pre 2.4 series days?
Yes, it was probably in the 2.4 or maybe even in the late 2.2 series that
I got scared of compiling upgraded kernels for production installations.
With some version of Slackware kernel modules was included with the X
packages but the source for X was not included. Maybe this was with
Slackware 8. Instead I got a habit of patching the current kernel to keep
the old version but still get the few new features or security patches
that I needed.
However, I did a quick check on a Slackware 12.0 system with
kernel 2.6.21.5 and it had kernel modules installed from the following
packages:
/var/log/packages/kernel-modules-2.6.21.5-i486-2
/var/log/packages/kernel-modules-smp-2.6.21.5_smp-i686-2
/var/log/packages/kqemu-1.3.0pre11-i486-mp
/var/log/packages/svgalib_helper-1.9.25_2.6.21.5-i486-1
The kqemu package was compiled by me, but svgalib_helper is a standard
Slackware package which contains extra kernel modules.
>>Then with a new kernel you will have a glibc which doesn't match your
>>current kernel. In most cases this is not a problem, but at least in
>>teory it could lead to problems.
>
> No, upgrading the kernel doesn't change glibc at all.
Yes, thats right, you still have the old glibc and most likely the old
glibc will also work fine with your new kernel. But glibc does make calls
to the kernel API and sometimes in rare circumstances the kernel API might
change in a way which isn't backwards compatible. Once there also used to
be a problem of how to select installed kernel headers with a kernel that
didn't match glibc, however I think that problem is solved now.
>>So instead of upgrading the kernel I would suggest to upgrade or
>>downgrade the entire distribution to a version that works fine.
>
> Er, no.
>
> Running the latest kernel is easy, I've been doing it for many years.
I used to do so with kernel 1.x and 2.0, maybe also 2.2. But then at some
time I got burned and instead started to patch the standard Slackware
kernel.
> Usually only the latest and latest-1 kernel releases are maintained,
> this means you may have security or other issues with older kernels.
For that reason I have backported security patches for my installed
kernels the last years. I have a Makefile which applies a number of
patches to the kernel sources, builds a number of kernels with different
configurations and then creates a slackware package which upgrades to the
kernel with the same configuration as the current kernel.
Grant
>Grant <g_r_a...@bugsplatter.id.au> wrote:
>
>> On Fri, 01 Jan 2010 12:52:12 +0100, Henrik Carlqvist wrote:
>>> Maybe some kernel modules are missing because they were not part of the
>>> kernel package but instead came from other packages like X, alsa or
>>> some kind of binary drivers.
>
>> Huh? Maybe back in the pre 2.4 series days?
>
>Yes, it was probably in the 2.4 or maybe even in the late 2.2 series that
>I got scared of compiling upgraded kernels for production installations.
>With some version of Slackware kernel modules was included with the X
>packages but the source for X was not included. Maybe this was with
>Slackware 8. Instead I got a habit of patching the current kernel to keep
>the old version but still get the few new features or security patches
>that I needed.
>
>However, I did a quick check on a Slackware 12.0 system with
>kernel 2.6.21.5 and it had kernel modules installed from the following
>packages:
>
>/var/log/packages/kernel-modules-2.6.21.5-i486-2
>/var/log/packages/kernel-modules-smp-2.6.21.5_smp-i686-2
Well those two are near the same
>/var/log/packages/kqemu-1.3.0pre11-i486-mp
>/var/log/packages/svgalib_helper-1.9.25_2.6.21.5-i486-1
And these two want closer hardware access, I guess.
>
>The kqemu package was compiled by me, but svgalib_helper is a standard
>Slackware package which contains extra kernel modules.
>
>>>Then with a new kernel you will have a glibc which doesn't match your
>>>current kernel. In most cases this is not a problem, but at least in
>>>teory it could lead to problems.
>>
>> No, upgrading the kernel doesn't change glibc at all.
>
>Yes, thats right, you still have the old glibc and most likely the old
>glibc will also work fine with your new kernel. But glibc does make calls
>to the kernel API and sometimes in rare circumstances the kernel API might
>change in a way which isn't backwards compatible. Once there also used to
>be a problem of how to select installed kernel headers with a kernel that
>didn't match glibc, however I think that problem is solved now.
Yeah, been solved for a long time providing people use the 'sanitised'
headers:
headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH
-- 'linux: make help'
>
>>>So instead of upgrading the kernel I would suggest to upgrade or
>>>downgrade the entire distribution to a version that works fine.
>>
>> Er, no.
>>
>> Running the latest kernel is easy, I've been doing it for many years.
>
>I used to do so with kernel 1.x and 2.0, maybe also 2.2. But then at some
>time I got burned and instead started to patch the standard Slackware
>kernel.
Possibly around the late 2.2 era when it was a tossup whether mainline
or -ac kernel version ran on one's hardware? Following the latest
kernel was more of an adventure then. :-)
>
>> Usually only the latest and latest-1 kernel releases are maintained,
>> this means you may have security or other issues with older kernels.
>
>For that reason I have backported security patches for my installed
>kernels the last years. I have a Makefile which applies a number of
>patches to the kernel sources, builds a number of kernels with different
>configurations and then creates a slackware package which upgrades to the
>kernel with the same configuration as the current kernel.
Well, with a script or Makefile doing the donkey work, sounds good.
Grant.
--
http://bugs.id.au
Glyn Millington
> Grant wrote:
>
> [...]
>
>> You're being wimpish about upgrading kernel ;)
>
> Yes, wimpishness, as well not having a clue how to upgrade a kernel :-(
>
You should find a clue here
http://www.slackbasics.org/html-singlepage/slackware-basics.html#kernel
This outlines the basic process pretty well.
atb
Glyn
--
RTFM http://www.tldp.org/index.html
GAFC http://slackbook.org/ The Official Source :-)
STFW http://groups.google.com/groups?hl=en&group=alt.os.linux.slackware
JFGI http://jfgi.us/
Tuxedo
> Tuxedo <tux...@mailinator.com> writes:
>
> > Grant wrote:
> >
> > [...]
> >
> >> You're being wimpish about upgrading kernel ;)
> >
> > Yes, wimpishness, as well not having a clue how to upgrade a kernel :-(
> >
>
> You should find a clue here
>
>
>
> http://www.slackbasics.org/html-singlepage/slackware-basics.html#kernel
>
> This outlines the basic process pretty well.
>
> atb
>
> Glyn
Perfect! That looks like the right kind of study material for me :-)
Thanks,
Tuxedo
barnabyh
> Grant wrote:
>
> [...]
>
> Currently I have a newly installed Slackware with kernel 2.6.27.7.
>
> The installation was done with a full DVD version of Slackware 12.2
There is an official patch to kernel 2.6.27.31 for Slack 12.2.
Barnabyh
--
The general public is a bunch of morons who destroy the fun and life in
everything it collectively touches. Disney is what the public wants.
NASCAR is what the public wants. Windows is what the public wants.
(Comment on Slashdot, Monday March 28 2005, @11:02AM, Gnome
Removed From Slackware.)
Tuxedo
> Tuxedo <tux...@mailinator.com> writes:
>
> > Grant wrote:
> >
> > [...]
> >
> >> You're being wimpish about upgrading kernel ;)
> >
> > Yes, wimpishness, as well not having a clue how to upgrade a kernel :-(
> >
>
> You should find a clue here
>
>
>
> http://www.slackbasics.org/html-singlepage/slackware-basics.html#kernel
>
> This outlines the basic process pretty well.
>
> atb
>
> Glyn
Proceding with various recommended post-install configurations in order to
set up a 'daily use' system I wonder if the following is about right
procedures?
... after a standard 12.2 DVD installation:
I inserted the DVD that was used for the installation and mounted it as
follows (although I guess there's a more 'normal' way):
mount /dev/cdrom0 /tmp/DVD
cp /tmp/DVD/kernels/speakup.s/config /usr/src/linux/.config
I did the initial installation with the speakup.s kernel so I also used
this one when compiling the kernel from the DVD. These were my next steps:
cd /usr/src/linux
make menuconfig
Press Exit.
Do you wish to save your new kernel configuration <Yes>
The configuration was written to .config
make
.... about an hour later:
Note: According to
http://www.slackbasics.org/html-singlepage/slackware-basics.html#chap-kernel-compile
"a compressed kernel image 'bzImage' exists in
/usr/src/linux/arch/i386/boot".
This however is a symlink to /usr/src/linux/arch/x86/boot/bzImage
Install kernel modules:
Note: According to slackbasics.org it is a good idea to remove old modules
as in 'rm -rf /lib/modules/2.6.27.7'
However, I did mv /lib/modules/2.6.27.7 /lib/modules/2.6.27.7_old
I then did:
make modules_install
A new /lib/modules/2.6.27.7 directory was created.
I thereafter copied the generated bzImage into the boot directory. I
noticed there is a boot image there already named:
/boot/vmlinuz-speakup.s-2.6.27.7 which is 4570992 (about 4.5MB)
I named the new image /boot/vmlinuz-speakup.s-2.6.27.7-new:
cp -i /usr/src/linux/arch/x86/boot/bzImage
/boot/vmlinuz-speakup.s-2.6.27.7-new
The new image is 4540208, so only a bit smaller than the speakup kernel
that already exist in the boot directory.
I thereafter added the 'Image = /boot/vmlinuz-speakup.s-2.6.27.7-new' line
to /etc/lilo.conf and ran lilo (which made an old floppy diskette for now).
There were some warnings, but probably nothing important. This was the
complete output of running 'lilo':
* LBA32 addressing assumed
* boot recod relocation boyond BPB is necessary: /dev/fd0
* The boot sector and map file are on different disks
Added Slack-12.2-new *
Added Slack-12.2
Added XP
------------------------
Slackware now boots fine from either Slack-12.2-new or Slack-12-2. Start up
time counting from the LILO menu until the log-in prompt takes about 50
seconds for either LILO options.
This may be an obvious question but with the exception of the kernel image
filesize being a slightly different what is the actual difference in
running the system with either kernel booting options at this stage, if any?
Anyhow, I guess I should do an the initial RAM disk creation. I continued
as follows:
mkinitrd -c -k 2.6.27.7 -m reiserfs
Output was:
2982 blocks
An initrd-tree directory and initrd.gz file now exists.
I added the /boot/initrd.gz bit to the relevant section of /etc/lilo.conf
and ran 'lilo' again.
I then rebooted and Slackware start-up appears to run fine, until it gets
stuck on some critical errors:
initrd.gz: Loading kernel modules from initrd image:
scsi2 : SBP-2 IEEE-1395
mount: mounting /dev/root on /mnt failed: No such file or directory
ERROR: No /sbin/init found in rootdev (or not mounted). Trouble ahead.
You can try and fix it. Type 'exit' when things are done.
/bin/sh: can't access tty; job control turned off
/ $ ieee1394: sbp2: Logged into SBP-2 device
ieee1394: sbp2: Node 0-00:1023: Max speed [S400] - May payload [2048]
scsi 2:0:0:0: CD-ROM TSSTcorp CD/DVDW TS-L632B TM32 PQ: 0 ANSI: 0
sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
---
I press 'exit' and the following errors occur:
/ $ edit
initrd.gz: exiting
switch_root: bad newroot /mnt
Kernel panic - not syncing: Attempting to kill init!
... Thats where all stops, even the screen gets frozen, no further keyboard
input is possible, only switching off the power button.
Slackware still boots up and runs fine from the old LILO option that does
not load the recompiled kernel and initrd.gz.
Does anyone have any idea what part(s) of the set-up I did wrong?
Thanks,
Tuxedo
Tuxedo
> * Tuxedo <tux...@mailinator.com> wrote:
> > Grant wrote:
> >
> > [...]
> >
> > Currently I have a newly installed Slackware with kernel 2.6.27.7.
> >
> > The installation was done with a full DVD version of Slackware 12.2
>
> There is an official patch to kernel 2.6.27.31 for Slack 12.2.
>
> Barnabyh
Do you know where to find more information about this and if the patch may
address the Intel graphic xorg driver problems?
Thanks,
Tuxedo
barnabyh
Hi Tuxedo, have a look at the security advisories for 2009 on
slackware.com, 18th Aug 2009, kernel (SSA 2009-230-01). I don't think it
addresses your specific problem but addresses a rather important security issue (kernel
bug).
(null)
*** Not only can you get the latest kernel, but you can also menuconfig it
to take out all the hardware that you don't have. So you wind up with a smaller
and faster kernel. There's an awful lot of hardware in a full-boat kernel.
Admittedly, mostly in modules.
- Jerry Kaidor
Peter Chant
Unloaded modultes won't slow it. Apart from time to load the kernel does
other unused stuff have any effect?
barnabyh
Probably overrated on modern hardware. On a dual-core I can't notice any
difference between the fully loaded huge-smp and the modular one when
booting.
Same goes for an old single-processor AMD Duron actually. I'm not sure
that recompiling is worth it if the only objective is speed increase
either. How much is a split second worth to you?
Aaron W. Hsu
> I'm not sure
> that recompiling is worth it if the only objective is speed increase
> either. How much is a split second worth to you?
I can definitely vouch for this. Compiling your kernel for speed or
optimization generally causes more trouble than it is worth. On the other
hand, if there is a module that is not compiled and you need it, you can
usually selectively compile only that module and integrate it in with an
existing generic kernel. If you want to do something else, more
specialized, then the usual mantra is, "If you need it, you won't be
asking about it."
Aaron W. Hsu
--
A professor is one who talks in someone else's sleep.