S.A.K.C. - SUSE Automated Kernel Compiler - Version 2.81

English Open Chat
#1

Introducing S.A.K.C. - SUSE Automated Kernel Compiler version 2.81 now with TURBO MODE COMPILE! With Turbo Compile Mode, you only compile the modules actually in use by your Kernel at the time of the compile. Typical compiler times will be reduced to 25% of normal. If you have never used sakc or ever compiled your own kernel before I would most likely skip the Turbo Mode until you understand more about just what this added feature is doing. S.A.K.C. works great with openSUSE 12.2, 12.3 and 13,1! S.A.K.C. now works with the newly selected kernel default (by kernel.org) of tar.xz files as well as still supporting tar.bz2 files.

S.A.K.C. uses the following kernel configuration creator to achieve this new speed.

chmod +x ./scripts/kconfig/streamline_config.pl ; ./scripts/kconfig/streamline_config.pl > ./config_strip ; mv ./config_strip ./.config

So, if this method is so fast, why not use it all of the time? Well, like most really good things, there is a downside. And that downside is any hardware you have not connected, turned on or otherwise have the kernel module loaded for it, will not work after a Turbo Compile. Of course, if this happens, use a regular compile, get ALL your devices working, and try Turbo Again. Here is one of the new screens you get that requests if you want to use Turbo Mode or switch to the kernel configuration menu:

http://paste.opensuse.org/view/download/5537621

In addition, the kernel selection menu has been enhanced using color and you can now remove older kernel source files if you wish. If the bash script file S.A.K.R. is found, an option to run it will be presented, allowing you to remove kernel files already compiled with S.A.K.C. S.A.K.C. can now create KDE icon files on your desktop and in the Applications menu if allowed to. New settings for for icon file creation have been added.

I have added a simplified option selection menu to be sure of your options and who should select them:

http://paste.opensuse.org/view/download/92374973

And there is a new kernel configuration selection menu as well. Kernel config files contain info on how each kernel module will or will not be loaded or available to be loaded. Using Turbo Mode creates a smaller kernel config file. A new kernel .config edit and .config save option has also been added in version 2.80 for you to select.

http://paste.opensuse.org/view/download/72162555

So, how does S.A.K.C. 2.81 deal with the kernel config issues?

  1. It creates a new Configs save folder ~/Kernel/Configs
  2. It archives for future use your default /boot config file as config.sav
  3. It saves each active kernel configuration in to ~/Kernel/Configs folder as config.sav.date.time
  4. It creates a turbomode text file to note a Turbo Mode Compile was used last.
  5. If you switch from Turbo Mode, back to standard the next, the archive config.sav file is used and the turbomode text file is removed.
  6. After a Turbo Compile, reusing the existing Active config (which was the old normal) just keeps the turbo mode going
  7. And finally, you may elect to use any previous saved kernel config. If it was from a Turbo Compile, your compile will also be as fast.

In order to start using the new kernel compile just Copy and Paste the text of this script into a text editor and save it as the file sakc in your home area bin folder (~/bin/sakc). The script is too large to be posted in a message here and is included in SUSE Paste.

S.A.K.C. - SUSE Automated Kernel Compiler - Version 2.81

Open the above Link in a new Tab. Select the Download option in the top right and then select Open With Kwrite or other text editor and then save the bash script text file as ~/bin/sakc. It is possible to directly download sakc using the following terminal command (You must delete or remove the old version first):

rm ~/bin/sakc

wget -nc http://paste.opensuse.org/view/download/55036844 -O ~/bin/sakc

This script must be marked executable to be used. Please run the following Terminal command:

chmod +x ~/bin/sakc

It is even possible to string all three of these commands together as one. Copy the following command, open up a terminal session, paste it in and press enter:

rm ~/bin/sakc ; wget -nc http://paste.opensuse.org/view/download/55036844 -O ~/bin/sakc ; chmod +x ~/bin/sakc

To use sakc, download the latest kernel source files from …

The Linux Kernel Archives

Into your downloads folder. Open up a terminal session, change to your downloads folder and run the command:

sakc kernel_file_name.tar.bz2

OR

sakc kernel_file_name.tar.xz

OR — Open up a terminal session, Start sakc from anywhere and have it display a list of source files to select from to compile (Prefered Method):

sakc

To make sure you can compile a kernel, I suggest you do the following (Shown using KDE instructions):

Open YaST / Software / Software Management - Select the View Button on the top left and pick Patterns. Now, you will see several Patterns listed and you want to select:

   Development 

[X] Base Development
[X] Linux Kernel Development
[X] C/C++ Development

Then Press the Accept button on the bottom right and allow these applications to install.

If you would like the ability to create a kernel tarball (which sakc can use) for any released version of the Linux kernel back to 2.6.11 (2005) you can use my bash script called SuSE Git Tar Ball (S.G.T.B.) which you can find in this blog.

S.G.T.B. - SuSE Git Kernel Tarball Creator - Version 1.80 - Blogs - openSUSE Forums

When you compile a new kernel with SAKC, your new files will exist in four places and a new menu entry. I have not created an automatic way of getting rid of the old kernels yet. I first make sure to know and to not remove the active kernel version and I do not remove any kernels install by YaST.

Location: Size

  1. Delete the ~/Downloads/linux-version.tar.bz2 Compressed kernel file: 75 MB
  2. Delete the ~/Kernel/linux-version folder and all of the kernel source files: 7 GB
  3. Delete the /lib/module/version-desktop folder and the kernel modules: 1.7 GB (Must be root to remove)
  4. Delete three files in the /boot folder: 21 MB, called initrd-version, System.map-version & vmlunuz-version (Must Be root to remove)
  5. Delete your entry(s) in the /boot/grub/menu.lst file for kernel **version **(Must be root to edit file)

To completely remove an unused kernel version compiled with SAKC, you must manually remove these files as listed above. All will include the exact kernel version number you no longer are using. Anyone using an SSD may find that you need to remove these files on a regular basis if you compile lots of kernel files.

This whole process has been automated so have a look here: S.A.K.R. - SUSE Automated Kernel Remover - Version 1.0.1

If you have any comments, problems or requests, please let me know.

Thank You,

Blogs: asroot : C.F.U. : FastBoot : fewrup : F.S.M. : H.I. : LNVHW : MMCHECK : N.S.F. : S.W.A.T. : S.A.S.I. : S.C.L.U. : S.K.I.M. : S.L.A.V.E. : S.L.R.C. : S.T.A.R.T. : SYSEdit : systemd

#2

Thank you. Very useful for me who I want to develop with C/C++

#3

I am trying to upgrade my openSuse 11.4 system (Linux 2.6.37 kernel), so I downloaded and installed SAKC, checking that I had followed the instructions regarding the existence of the files and folders. I then downloaded the kernel file linux-2.6.39.4.tar.bz2 int the Download folder. Running SAKC as instructed produced the following:

Running sakc linux-2.6.39.4.tar.bz2 did not work unless I put in the full path; sakc ~/Download/linux-2.6.39.4.tar.bz2. However, Simply running sakc and entering the file number did pick up the kernel file. So far so good.

Although decompression ran, it eventually failed with exit code 2. Thinking that the file may have been corrupted in the course of download, I picked up the tar line at 521 in the sakc script and ran tar -vxjf linux-2.6.39.4.tar.bz2. This worked fine and all the files appeared in ~/Download/linux-2.6.39.4. Running tar -vxjf linux-2.6.39.4.tar.bz2 > /dev/null 2>&1 (ie the full sakc line 521 with linux-2.6.39.4.tar.bz2 substituted for $FILE) also seemed to work (echo $? produced the result 0). All the output went (presumably) to /dev/null, but I don’t know where the decompressed file went. It certainly did not go to ~/Kernel.

It looks as though I have missed something in the instructions for configuring the sakc file. That and my limited Linux knowledge have probably conspired against me. Can you please help?

#4

Well you say you downloaded the file to:

~/Download/linux-2.6.39.4

But sakc is using this folder name:

kernel_folder=~/Downloads

The ending “s” is missing from Download. Was this a typo or does your Download folder not end with an “s”? forsate you must modify the folder name for where the kernel source file is downloaded before you run the script.

Thank You,

#5

My download folder is indeed written as ‘Download’, omitting the ‘s’ as you point out. Rather than change the name of the folder and screw up links to it, I simply changed what seemed to me to be the appropriate lines in sakc. That may not have been a clever thing to do, especially at my level of knowledge of shell scripting. What I’ll try is to restore your original script in place of the one I have tinkered with and create a folder ‘Downloads’. I’ll run sakc again and see what happens. I’ll let you know the result.

#6

So somewhere down the road, the default download folder in openSUSE got a s on the end, becoming Downloads, but it was not always that way. In any event, the intent of the value kernel_folder= was to permit you to use a kernel_folder=~/Download or kernel_folder=~/Downloads as actually existed in your computer. You only need to change this value in the script and not create a different folder name on your computer to make sakc happy. Since, newer versions of openSUSE do call this folder Downloads, its also OK to switch to using that name as you desire. The ~/ is expanded to become /home/username when the script is run.

Thank You,

#7

Very nice! Thanks for sharing!

-James :wink:

#8

You are so welcome jtrageser and thanks for the kind words.

Thank You,

#9

Thank you James, this is a great script, just used it to install the latest kernel.

#10

Happy to hear you had success using S.A.K.C and don’t forget we always accept any suggestions.

Thank You,

#11

Hello James,

Thank you for the script. I have a couple of questions for you:

(1) I add a suffix to the kernel name that specifies the machine’s name and the compilation date (e.g., -T10022330-08Jan12). In the /boot/grub/menu.lst file, the title for the generated kernel begins with suffix date (i.e., 08Jan12). How do I prevent the data after the second hyphen from being prefixed to the menu.lst kernel title’s name?

(2) In my menu.lst, I identify the root partition using the command “root=/dev/disk/by-id/scsi-…-part2”. However, SAKC identifies the root partition using the “root=/dev/disk/by-uuid/”. I like the by-id because I can recognize the drive. How do I change the script so that it uses by-id?

Thanks

#12

[QUOTE=jamescleaver;bt346]Hello James,

Thank you for the script. I have a couple of questions for you:

(1) I add a suffix to the kernel name that specifies the machine’s name and the compilation date (e.g., -T10022330-08Jan12). In the /boot/grub/menu.lst file, the title for the generated kernel begins with suffix date (i.e., 08Jan12). How do I prevent the data after the second hyphen from being prefixed to the menu.lst kernel title’s name?

(2) In my menu.lst, I identify the root partition using the command “root=/dev/disk/by-id/scsi-…-part2”. However, SAKC identifies the root partition using the “root=/dev/disk/by-uuid/”. I like the by-id because I can recognize the drive. How do I change the script so that it uses by-id?

Thanks[/QUOTE]

I just realized that point (2) is taken from my mount instruction in /etc/fstab. Please disregard this point :X

#13

[QUOTE=jamescleaver;bt346]Hello James,

Thank you for the script. I have a couple of questions for you:

(1) I add a suffix to the kernel name that specifies the machine’s name and the compilation date (e.g., -T10022330-08Jan12). In the /boot/grub/menu.lst file, the title for the generated kernel begins with suffix date (i.e., 08Jan12). How do I prevent the data after the second hyphen from being prefixed to the menu.lst kernel title’s name?

(2) In my menu.lst, I identify the root partition using the command “root=/dev/disk/by-id/scsi-…-part2”. However, SAKC identifies the root partition using the “root=/dev/disk/by-uuid/”. I like the by-id because I can recognize the drive. How do I change the script so that it uses by-id?

Thanks[/QUOTE]

So I don’t actually know the answer to your question #1, but I shall find out. I must say that I am not excited about making the actual kernel version name even longer, but perhaps it could be an option. I will check into it and let you know what I find out.

Thank You,

#14

If you use S.A.K.C. then you will want to download the latest version, now with Turbo Compile. Please check it out!

Thank You,

#15

Thanks a lot. This is very useful. :slight_smile:

#16

You are welcome lak611.

Thank You,

#17

SAKC has been updated to version 2.71 now with the ability to directly edit a kernel .config file and save a .config file and a simplified startup menu selection to inform you as to whom should use what menu options in SAKC. Other fixes have also been made.

Thank You,

#18

I decided to try this over the repository method. Two quick questions.

I have an i3 and was wondering if the standard compile should take over an hour for kernel 3.4?

I noticed while compiling that I needed 7GB for the kernel so I made room during the compiling stage on my home partition. Is there a chance of a screw up from doing data transfers?

#19

[QUOTE=Static2k;bt474]I decided to try this over the repository method. Two quick questions.

I have an i3 and was wondering if the standard compile should take over an hour for kernel 3.4?

Compile time is almost totally CPU speed dependent. My Desktop, an i7 2600K, can do a standard compile in 8 minutes while my i5 Laptop takes 44 minutes. And, one of the moderators ran this on a Pentium II and said it took over seven hours. Using an SSD can improve the time by 10%, which is good, but an expensive speed up. So, taking an hour is not that uncommon.

I noticed while compiling that I needed 7GB for the kernel so I made room during the compiling stage on my home partition. Is there a chance of a screw up from doing data transfers?

So, when SAKC runs, it is very CPU intensive, but not so much disk intensive. However, if your computer has any hardware issues, its possible the extreme load put on it by SAKC could cause a problem, but you already have a problem in the making anyway. So, if you have had other issues, perhaps don’t use SAKC, but in general, no one has come and said SAKC has done anything bad to their system. Look at SAKC as being able to extensively test your computer operation. If you start the System Monitor, then look at the System Load tab, you will see all CPU cores go to 100% when the actual compile stage begins. Don’t expect to be surfing the Web while doing a compile and making SAKC the foreground task will improve its speed to completion. I looked at my kernel 3.4 compile and it took 7.3 GB in disk space in my /home area.

[/QUOTE]

I love to get questions and comments.

Thank You,

#20

S.A.K.C. has been updated to version 2.73 in this maintenance release. Minor changes included are:

  1. Kernel .config file is now saved after ALL changes have been made and is the final one used in the compile.
  2. The make Jobs calculation based on the cpu core count has been updated.
  3. If the compile Kernel or Downloads folders do not exist, you will be asked if you wish to create them.
  4. Other minor wording and text shifts are included.

As always, please let me know if you have any problems or suggestions with SAKC.

Thank You,