Slackware 13.0 with KDE 3.5.10?
in [Slackware]
|
Prev: useradd, upgrading Feunster
Next: Qemu help
From: Tuxedo on 1 Jan 2010 18:43 Grant wrote: [...] > 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
From: Henrik Carlqvist on 1 Jan 2010 20:08 Grant <g_r_a_n_t_(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 /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. 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(a)localhost postmaster(a)localhost
From: Grant on 1 Jan 2010 23:25 On Sat, 02 Jan 2010 02:08:34 +0100, Henrik Carlqvist <Henrik.Carlqvist(a)deadspam.com> wrote: >Grant <g_r_a_n_t_(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
From: Glyn Millington on 2 Jan 2010 03:57 Tuxedo <tuxedo(a)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 -- 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/
From: Tuxedo on 2 Jan 2010 08:13
Glyn Millington wrote: > Tuxedo <tuxedo(a)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 |