LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 02-16-2013, 10:25 PM   #1
psionl0
Member
 
Registered: Jan 2011
Distribution: slackware_64 14.0
Posts: 506
Blog Entries: 2

Rep: Reputation: 67
Question A SlackBuild script for building a kernel?


Quote:
Originally Posted by Alien Bob View Post
Better to build that kernel from source. See http://docs.slackware.com/howtos:sla...kernelbuilding

Eric
It puzzles me that the instructions get you to build the kernel in-situ.

What's wrong with using a SlackBuild script that builds the kernel and makes a package that could be installed or uninstalled instead? Patrick includes a SlackBuild for the kernel in his sources directories although this assumes a compiled kernel. It should be easy enough to modify this script so that it also compiles the kernel as well.

I gather that "make oldconfig" and "make menuconfig" would still run interactively from within a script so you could still set your custom parameters. As long as "make modules_install" honours the DESTDIR option, you would have a build process that doesn't leave droppings all over the place should you have to remove the newly built kernel for any reason.

The script could also leave helpful messages like "Don't forget to modify lilo.conf and run lilo if you wish to use this new kernel" and other housekeeping messages as well.

Is there a difficulty I haven't thought of?

Last edited by psionl0; 02-16-2013 at 10:28 PM.
 
Old 02-16-2013, 10:42 PM   #2
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-14.1 on a Lenovo T61 6457-4XG
Posts: 3,949

Rep: Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930
What do you need besides the SlackBuilds already shipped in the /source/k/packaging-<arch> directories?
 
Old 02-16-2013, 10:47 PM   #3
psionl0
Member
 
Registered: Jan 2011
Distribution: slackware_64 14.0
Posts: 506
Blog Entries: 2

Original Poster
Rep: Reputation: 67
Quote:
Originally Posted by Didier Spaier View Post
What do you need besides the SlackBuilds already shipped in the /source/k/packaging-<arch> directories?
As I said, those SlackBuilds don't compile the kernel - only make a package out of a compiled kernel.
 
Old 02-16-2013, 11:03 PM   #4
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-14.1 on a Lenovo T61 6457-4XG
Posts: 3,949

Rep: Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930
Then IMO you do not need a SlackBuild to clean the house, a very simple shell script will do. Take as a basis the /source/k/README.TXT and just add the steps to (re)configure, make the kernel, make the modules, package & clean what needs to be. Then use or adapt the aforementioned SlackBuilds to build the packages. You can even use the rpm-pkg target if you wish, as _it's_your_machine_

Last edited by Didier Spaier; 02-16-2013 at 11:07 PM.
 
Old 02-16-2013, 11:15 PM   #5
psionl0
Member
 
Registered: Jan 2011
Distribution: slackware_64 14.0
Posts: 506
Blog Entries: 2

Original Poster
Rep: Reputation: 67
You are missing the point. From the README.TXT:
Quote:
For a 2.6.x kernel (much easier):

Untar Linus' source in /usr/src.
Make all files owned by root:root with reasonable perms.
Install a suitable .config, or use make menuconfig, etc.

An example would be to use one of the config files here:
# cat config-generic-3.7.1 > /usr/src/linux-3.7.1/.config
This is telling you to use the global directories.

I want to know if there would be any problem with using $PKG/usr/src etc instead.
 
Old 02-16-2013, 11:25 PM   #6
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-14.1 on a Lenovo T61 6457-4XG
Posts: 3,949

Rep: Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930
Quote:
Originally Posted by psionl0 View Post
I want to know if there would be any problem with using $PKG/usr/src etc instead.
No. You can put the kernel source anywhere you want. /usr/src is just the place where the kernel-source package puts it. For instance you could have PKG=$HOME/work_in_process and download the source tarball there, or if you just want to re-configure a Slackware kernel, install the source package then cp -ar /usr/src/kernel-<version> $HOME/$PKG. I personally do not see any advantage in changing the location of the kernel source, but there is no inconvenience that I can think of either. Bear in mind tough if you compile programs that stuff that need kernel sources to be compiled won't look for it there, so if you need to compile something I suggest you keep the original source in /usr/src

PS instead of cp -a you could use the -root option of 'installpkg' but I have no experience doing that.

Last edited by Didier Spaier; 02-17-2013 at 03:05 AM.
 
Old 02-17-2013, 12:09 AM   #7
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 226Reputation: 226Reputation: 226
Actually the kernel install routine does create 2 symlinks back to the source under /lib/modules/(kernelversion)/[build/source]

These symlinks exist so that automated kernel module builds from things like nvidia and virtualbox work in a simple manor.

If you put the source in an arbitrary location and built the system from there and then later moved the source to the normal location of /usr/src then those links would no longer be valid.
 
1 members found this post helpful.
Old 02-17-2013, 12:38 AM   #8
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.0
Posts: 2,239

Rep: Reputation: 602Reputation: 602Reputation: 602Reputation: 602Reputation: 602Reputation: 602
I use a few scripts to automate compiling myself. To keep things clean, run
Code:
make bzImage modules
instead of just make, and copy the bzImage to the packaging directory instead of doing a potentially messy `make install`. For installing the modules, use
Code:
INSTALL_MOD_PATH="/path/to/directory" make modules_install
Note that some (all?) kernel versions will still dump stuff in /path/to/directory/lib/firmware for no reason with `make modules_install` so you will have to remove that directory before creating a Slackware package. If you do use INSTALL_MOD_PATH it will still create bad symlinks to the kernel source as it was when building. You can just hack those into place...
Code:
cd $PKG/lib/modules/*
rm -rf source build
ln -sf /usr/src/linux-$VERSION source
ln -sf /usr/src/linux-$VERSION build
Then makepkg will remove the symlinks and add their creation to doinst.sh.

I make packaging directories for {kernel,kernel-modules,kernel-source} and package them appropriately. Hacking the symlinks in the modules package also allows me to compile as a non-root user -- I just `chown -R root:root` each packaging directory before makepkg'ing each package. (FYI I do a permissions verification step to make sure the file permissions are OK for each packaging directory before packaging them up...) Of course, I don't actually run these commands...I have a building script to run as a user, a verification script also run as a user, and a packaging script run as root.

In short, nothing is preventing you from writing a script to do all that you want. However, Pat may manually massage certain kernel builds before packaging so there isn't an official do-all SlackBuild. (Note: that is merely speculation)
 
3 members found this post helpful.
Old 02-17-2013, 02:06 AM   #9
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,746

Rep: Reputation: 458Reputation: 458Reputation: 458Reputation: 458Reputation: 458
This might be helpful:
http://distro.ibiblio.org/amigolinux...l-kiss.src2pkg
 
1 members found this post helpful.
Old 02-17-2013, 05:17 AM   #10
GazL
Senior Member
 
Registered: May 2008
Posts: 3,312

Rep: Reputation: Disabled
Quote:
Originally Posted by psionl0 View Post
]
What's wrong with using a SlackBuild script that builds the kernel and makes a package that could be installed or uninstalled instead?
You're welcome to use mine


P.S. If you do try it, don't worry about all the zero length file warnings for the header files that makepkg throws out That is normal. I've been meaning to mask them but just haven't gotten around to it.

.

Last edited by GazL; 03-04-2013 at 05:16 PM.
 
1 members found this post helpful.
Old 02-18-2013, 11:51 AM   #11
psionl0
Member
 
Registered: Jan 2011
Distribution: slackware_64 14.0
Posts: 506
Blog Entries: 2

Original Poster
Rep: Reputation: 67
Quote:
Originally Posted by T3slider View Post
I use a few scripts to automate compiling myself.
At last! Somebody who doesn't think this is a pointless idea. Obviously, I would prefer to do my first ever kernel build as somebody other than root. Eric's instructions are clear enough but you can still do a lot of harm if you are the root user - especially if you have made a mistake and have to trawl through the system directories removing the stuff you just installed.

Quote:
Originally Posted by T3slider View Post
To keep things clean, run
Code:
make bzImage modules
instead of just make, and copy the bzImage to the packaging directory instead of doing a potentially messy `make install`. For installing the modules, use
Code:
INSTALL_MOD_PATH="/path/to/directory" make modules_install
Note that some (all?) kernel versions will still dump stuff in /path/to/directory/lib/firmware for no reason with `make modules_install` so you will have to remove that directory before creating a Slackware package. If you do use INSTALL_MOD_PATH it will still create bad symlinks to the kernel source as it was when building. You can just hack those into place...
Code:
cd $PKG/lib/modules/*
rm -rf source build
ln -sf /usr/src/linux-$VERSION source
ln -sf /usr/src/linux-$VERSION build
Then makepkg will remove the symlinks and add their creation to doinst.sh.
That all seems clear. It is consistent with Eric's instructions and I actually discovered the INSTALL_MOD_PATH when examining the Makefile. I wouldn't have thought to delete the $PKG/lib/firmware as I would have assumed that was an important part of the process (Eric doesn't say to do that).

Interesting the bit about symlinks. Previously when making SlackBuilds, I have been creating my own doinst.sh to deal with symlinks. Now I know that makepkg will do that for me (you never stop learning when you are a Slacker ).

Quote:
Originally Posted by T3slider View Post
I make packaging directories for {kernel,kernel-modules,kernel-source} and package them appropriately. Hacking the symlinks in the modules package also allows me to compile as a non-root user -- I just `chown -R root:root` each packaging directory before makepkg'ing each package. (FYI I do a permissions verification step to make sure the file permissions are OK for each packaging directory before packaging them up...) Of course, I don't actually run these commands...I have a building script to run as a user, a verification script also run as a user, and a packaging script run as root.
I don't think I need 3 separate scripts. My usual strategy is, once I am satisfied that the SlackBuild works properly when I run it as a user, I then run it as root. The SlackBuild template (available from SlackBuilds.org) actually includes instructions to make sure all files are owned by root and all permissions are 755 or 644 (naturally I have to comment out the chown instructions when I am not root).

Quote:
Originally Posted by T3slider View Post
In short, nothing is preventing you from writing a script to do all that you want. However, Pat may manually massage certain kernel builds before packaging so there isn't an official do-all SlackBuild. (Note: that is merely speculation)
That's good advice. Once I have a SlackBuild script, it should work for any kernel (I can even make it work for generic and huge kernels) but after any Slackware upgrades, I should examine Patrick's kernel SlackBuilds just in case he has added some new tricks (it all looks standard for 14.0).

Quote:
Originally Posted by gnashley View Post
Quote:
Originally Posted by GazL View Post
You're welcome to use mine.
Ah! It looks like I am re-inventing the wheel. Both these scripts will be immensely helpful when I am doing my own SlackBuild. I could of course, used them as is but one of the reasons I became a Slacker is that I like tinkering.

Since a kernel.SlackBuild seems to be straight forward enough, I will mark this thread as solved.
 
Old 02-18-2013, 12:31 PM   #12
GazL
Senior Member
 
Registered: May 2008
Posts: 3,312

Rep: Reputation: Disabled
Quote:
Originally Posted by psionl0 View Post
Ah! It looks like I am re-inventing the wheel. Both these scripts will be immensely helpful when I am doing my own SlackBuild. I could of course, used them as is but one of the reasons I became a Slacker is that I like tinkering.
Yep, tinkering is what Slackware is all about. Best of luck with your script.
 
Old 02-18-2013, 01:46 PM   #13
qweasd
Member
 
Registered: May 2010
Posts: 435

Rep: Reputation: Disabled
Here's the script I use, for what it's worth.
http://melikamp.com/features/slackbu...-common.tar.gz
 
Old 02-18-2013, 02:32 PM   #14
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.0
Posts: 2,239

Rep: Reputation: 602Reputation: 602Reputation: 602Reputation: 602Reputation: 602Reputation: 602
Quote:
Originally Posted by psionl0 View Post
I wouldn't have thought to delete the $PKG/lib/firmware as I would have assumed that was an important part of the process (Eric doesn't say to do that).
In the past Slackware shipped firmware from each kernel version so throwing firmware from the new kernel in /lib/firmware was fine (though really when making Slackware packages, the modules/firmware packages should be separate anyway so it would have been better to remove the spam in $PKG/lib/firmware from the `make modules_install` command anyway and run a separate `INSTALL_MOD_PATH="$PKG-firmware" make firmware_install` to create a firmware package -- but since Eric's instructions don't make a package [AFAIK -- been a while since I read them], any spam from `make modules_install` would produce valid firmware files anyway so it wouldn't matter). However, now Slackware ships firmware from upstream (git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git) rather than the firmware included with each kernel version. So as of 14.0 there is no point in including additional firmware files, so removing spam from that `make modules_install` command is a good idea. (Note: you *can* use the firmware from each kernel version but it just means an extra package, and to keep things kosher, if you do it that way you're better off using /lib/firmware/$(uname -r) instead of just /lib/firmware so you don't overwrite anything).
Quote:
Originally Posted by psionl0 View Post
I don't think I need 3 separate scripts. My usual strategy is, once I am satisfied that the SlackBuild works properly when I run it as a user, I then run it as root. The SlackBuild template (available from SlackBuilds.org) actually includes instructions to make sure all files are owned by root and all permissions are 755 or 644 (naturally I have to comment out the chown instructions when I am not root).
The reason I use at least two scripts is so I can run the building script as a non-root user in case there is a problem in the Makefile that would otherwise spam the system (though this would be unlikely, the kernel does change a lot and mistakes can creep in). So in my case two scripts are necessary since I only want root doing known chown/packaging commands to reduce any potential problems. If you're happy with the risk of compiling kernels as root then that's your decision.
 
Old 02-18-2013, 09:10 PM   #15
psionl0
Member
 
Registered: Jan 2011
Distribution: slackware_64 14.0
Posts: 506
Blog Entries: 2

Original Poster
Rep: Reputation: 67
Quote:
Originally Posted by T3slider View Post
If you're happy with the risk of compiling kernels as root then that's your decision.
No matter which user makes a package, only root can install it. I would never su up until I was convinced that all the bugs were removed from the slackbuild.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Building linux-firmware package with Pat's slackbuild script Phorize Slackware 8 10-05-2011 05:54 AM
[SOLVED] Failure building nvidia-kernel Slackbuild from SBo sysfce2 Slackware 7 07-02-2011 01:10 AM
[SOLVED] error building glade3 slackbuild? trademark91 Slackware 5 01-21-2011 10:31 PM
building from slackbuild script konfigure Slackware 2 03-21-2009 09:59 AM
SlackBuild.org nvidia kernel build script bug Woodsman Slackware 3 04-06-2008 07:48 PM


All times are GMT -5. The time now is 12:29 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration