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 12-09-2015, 11:31 AM   #1
BAcidEvil
Member
 
Registered: Dec 2003
Distribution: Slack 14.1 3.18.1
Posts: 147

Rep: Reputation: 1
Recompile Kernel Testing


Good Morning

This may be covered in Kernel Compiling 101 but I may have missed it.

Is there a way to recompile and run a "mock" test on the Kernel before loading it into LILO and booting only to find you (I) recompiled something incorrectly?

Something to the effect of running an emulator within Slack to test it, or is this already something you can do without emulating?

It doesn't always happen but at times while I am at work I wil SHH into home and recompile because I am bored and then can't log back in for some Kernel Panic nonsense.. And I don't wanna wait 8 hours to get home to boot legit Kernel.

Thanks!
 
Old 12-09-2015, 11:39 AM   #2
Tonus
Member
 
Registered: Jan 2007
Location: Paris, France
Distribution: Slackware-current
Posts: 407
Blog Entries: 3

Rep: Reputation: 106Reputation: 106
Recompile Kernel Testing

Would first try virtual machine, no? But don't know how to be sure to emulate same hardware...
 
Old 12-09-2015, 11:51 AM   #3
BAcidEvil
Member
 
Registered: Dec 2003
Distribution: Slack 14.1 3.18.1
Posts: 147

Original Poster
Rep: Reputation: 1
Quote:
Originally Posted by Tonus View Post
Would first try virtual machine, no? But don't know how to be sure to emulate same hardware...

I came to that same conclusion but wanted to make sure.. I think you are right about the hardware support.

Ty for responding.
 
Old 12-09-2015, 11:53 AM   #4
fogpipe
Member
 
Registered: Mar 2011
Distribution: Slackware 64 -current,
Posts: 550

Rep: Reputation: 194Reputation: 194
As long as you are going to compile it you might as well install it. Just make sure that you append a unique local version name and list it by that name in lilo.conf This way you can revert to the old kernel just by choosing the appropriate lilo menu item.
Code:
# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
boot = /dev/sda
#disk=/dev/sdb
#     inaccessible
default = 4.1.13odinLPD
#compact        # faster, but won't work on all systems.
install = menu 
#bitmap = /boot/slack.bmp
#bmp-table = 60,6,1,16
#bmp-timer = 65,27,0,255
#bmp-colors=250,0,255,0,255,0
# Append any additional kernel parameters:
append=" vt.default_utf8=0 raid=noautodetect"
prompt
timeout = 50
# Normal VGA console
vga = normal
# Ask for video mode at boot (time out to normal in 30s)
#vga = ask
# VESA framebuffer console @ 1024x768x64k
# vga = 0x0360
# VESA framebuffer console @ 1024x768x32k
# vga=790
# VESA framebuffer console @ 1024x768x256
# vga=773
# VESA framebuffer console @ 800x600x64k
# vga=788
# VESA framebuffer console @ 800x600x32k
# vga=787
# VESA framebuffer console @ 800x600x256
# vga=771
# VESA framebuffer console @ 640x480x64k
# vga=785
# VESA framebuffer console @ 640x480x32k
# vga=784
# VESA framebuffer console @ 640x480x256
# vga=769
#
# ramdisk = 0     # paranoia setting
# End LILO global section
# Linux bootable partition config begins
# stock current kernel
image = /boot/vmlinuz
  root = /dev/sda5
  label = Slack
  read-only
# 4.1.6 kernel custom compiled for pentiumD
image = /boot/vmlinuz-4.1.13odinLPD
   root = /dev/sda5
   label = 4.1.13odinLPD
   read-only
   append=" vt.default_utf8=0 raid=noautodetect fb=false"
#a little leaner
image = /boot/vmlinuz-4.1.6odinLPD
   root = /dev/sda5
   label = 4.1.6-odinLPD
   read-only
   append=" vt.default_utf8=0 raid=noautodetect fb=false"
        
  # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
# Windows bootable partition config begins
other=/dev/sda1
label=windows
table=/dev/sda
# Windows bootable partitn config ends
Sorry about the cruft i edit lilo.conf often.

Also copy and name the System.map file with the appropriate version designation.
ex. System.map-4.1.13odinLPD
 
Old 12-09-2015, 12:04 PM   #5
BAcidEvil
Member
 
Registered: Dec 2003
Distribution: Slack 14.1 3.18.1
Posts: 147

Original Poster
Rep: Reputation: 1
Quote:
Originally Posted by fogpipe View Post
As long as you are going to compile it you might as well install it. Just make sure that you append a unique local version name and list it by that name in lilo.conf This way you can revert to the old kernel just by choosing the appropriate lilo menu item.
Code:
# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
boot = /dev/sda
#disk=/dev/sdb
#     inaccessible
default = 4.1.13odinLPD
#compact        # faster, but won't work on all systems.
install = menu 
#bitmap = /boot/slack.bmp
#bmp-table = 60,6,1,16
#bmp-timer = 65,27,0,255
#bmp-colors=250,0,255,0,255,0
# Append any additional kernel parameters:
append=" vt.default_utf8=0 raid=noautodetect"
prompt
timeout = 50
# Normal VGA console
vga = normal
# Ask for video mode at boot (time out to normal in 30s)
#vga = ask
# VESA framebuffer console @ 1024x768x64k
# vga = 0x0360
# VESA framebuffer console @ 1024x768x32k
# vga=790
# VESA framebuffer console @ 1024x768x256
# vga=773
# VESA framebuffer console @ 800x600x64k
# vga=788
# VESA framebuffer console @ 800x600x32k
# vga=787
# VESA framebuffer console @ 800x600x256
# vga=771
# VESA framebuffer console @ 640x480x64k
# vga=785
# VESA framebuffer console @ 640x480x32k
# vga=784
# VESA framebuffer console @ 640x480x256
# vga=769
#
# ramdisk = 0     # paranoia setting
# End LILO global section
# Linux bootable partition config begins
# stock current kernel
image = /boot/vmlinuz
  root = /dev/sda5
  label = Slack
  read-only
# 4.1.6 kernel custom compiled for pentiumD
image = /boot/vmlinuz-4.1.13odinLPD
   root = /dev/sda5
   label = 4.1.13odinLPD
   read-only
   append=" vt.default_utf8=0 raid=noautodetect fb=false"
#a little leaner
image = /boot/vmlinuz-4.1.6odinLPD
   root = /dev/sda5
   label = 4.1.6-odinLPD
   read-only
   append=" vt.default_utf8=0 raid=noautodetect fb=false"
        
  # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
# Windows bootable partition config begins
other=/dev/sda1
label=windows
table=/dev/sda
# Windows bootable partitn config ends
Sorry about the cruft i edit lilo.conf often.

Also copy and name the System.map file with the appropriate version designation.
ex. System.map-4.1.13odinLPD
I do exactly that. I always have [at least] two Kernels; Working and verified and then test Kernel... I guess my meaning was if I am at work and recompile then reboot and it auto loads the Test Kernel and it Kernel Panics, I am SOL until I get home to load the other Kernel.. By default my primary Boot is the working Kernel but in this case I'd set the Test Kernel as primary (or else no point in any of this in the first place) ...

I may be asking for the impossible but it just seems like at this point in the game there'd be a redundancy for this sort of configuration/setup if a Kernel fails and you are not home to load the verified Kernel.
 
Old 12-09-2015, 12:10 PM   #6
fogpipe
Member
 
Registered: Mar 2011
Distribution: Slackware 64 -current,
Posts: 550

Rep: Reputation: 194Reputation: 194
Sorry i missed the part where you were doing this remotely. Im an idiot.

Have you looked at ktest?
Quote:
Boot testing

If you can supply ktest.pl with a way to remotely boot the target, as well as read its console via stdio, then you can perform boot testing. This does currently require ssh (actually scp) connectivity to the target (not necessarily with the kernel that was built) to be able to copy the boot image to the kernel (if one is needed) and perhaps the modules that that kernel uses, again if one is needed.

After a successful build, ktest will copy the necessary files over to the target and reboot the target to that kernel. It will watch the console for a specified string (default "login:") that will tell ktest.pl that the boot succeeded. There's configurable timeouts that ktest.pl uses to determine if the boot locked up or not.
http://elinux.org/Ktest

Last edited by fogpipe; 12-09-2015 at 12:20 PM.
 
Old 12-09-2015, 12:21 PM   #7
Drakeo
Senior Member
 
Registered: Jan 2008
Location: Urbana IL
Distribution: Slackware, Slacko,
Posts: 3,538
Blog Entries: 3

Rep: Reputation: 442Reputation: 442Reputation: 442Reputation: 442Reputation: 442
You can do it old school or you can do it in virtual box. for the newer 4.X kernels install virtual box from the Vitualbox 5.10 installer from Oracle. because I have not seen the newer VBox in SBO yet for 14.1.
other wise . do like we been doing for years. http://docs.slackware.com/slackbook:linux_kernel and install the kernel make sure you keep the old one. build the huge-kernel for testing so you have all the drivers. when done add the new kernel to lilo and try booting it. if it fails then reboot into your other kernel.
I usually edit the kernel packager in /source/k edit it for the new kernel. remember the packager makes a link to vmlinuz-huge. so relink it back before running lilo.
always make modules_install

I never do a make install I use the packager to package the kernel from source. This allows me the ability to manage multiple kernels.
 
Old 12-09-2015, 12:24 PM   #8
Emerson
LQ Guru
 
Registered: Nov 2004
Location: Saint Amant, Acadiana
Distribution: Gentoo ~arch
Posts: 6,313

Rep: Reputation: Disabled
Lilo has fallback option.
 
Old 12-09-2015, 01:22 PM   #9
guzzi
Member
 
Registered: Jun 2004
Location: Lawrence, KS
Distribution: Slackware
Posts: 307

Rep: Reputation: 39
When going through the kernel configuration look into the Kernel Hacking section. There is an option for CONFIG_PANIC_ON_OOPS.

It's been several weeks since I did any of this, but with that set as yes your system will reboot and start whatever you have as your first option in lilo.

Just checked my notes.

CONFIG_PANIC_ON_OOPS=y
CONFIG_PANIC_ON_OOPS_VALUE=1
CONFIG_PANIC_TIMEOUT=1

First time I saw this option was in the 4.2 kernels

Last edited by guzzi; 12-09-2015 at 03:56 PM. Reason: my memory is failing
 
2 members found this post helpful.
Old 12-09-2015, 01:32 PM   #10
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 5,524

Rep: Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272
To further what Emerson wrote, doing some research shows that you can use an append line to tell the system to reboot after a kernel panic after a specific time (just like how Windows will, by default, reboot after a blue screen, but you can change that in the settings). You then have two options with setting up the system. You can either add a fallback option into lilo (see the example below), or you can add your entries normally and then just call lilo with the -R option and specify the fallback kernel (lilo -R Slack-safe) but you need to make sure you have the append = "panic=5" line to ensure the system will reboot after a panic.

Code:
image = /boot/vmlinuz-test
  root = /dev/sda2
  label = Slack-test
  read-only
  fallback = Slack-safe
  append = "panic=5"
image = /boot/vmlinuz-stock
   root = /dev/sda2
   label = Slack-safe
   read-only
(NOTE: This is only based on my admittedly rushed reading of the subject. I believe it should work, but it is still probably best to test it initially while you're in front of the computer before trying it remotely.)
 
3 members found this post helpful.
Old 12-09-2015, 04:34 PM   #11
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys for decades while testing others to keep up
Posts: 2,016

Rep: Reputation: 1911Reputation: 1911Reputation: 1911Reputation: 1911Reputation: 1911Reputation: 1911Reputation: 1911Reputation: 1911Reputation: 1911Reputation: 1911Reputation: 1911
FWIW I always and very quickly after base install, compile a custom kernel. I "hedge my bets" in a couple of ways. Firstly, since i don't encrypt the filesystem I do the work to insure that I have no need for an initrd. This just makes my system simpler with less vulnerability.

Secondly, I always keep the original "HUGE" kernel available as a fallback.

Lastly, and I really don't know why other distros don't follow this simple logic, I am a huge fan of the Slackware Install disk. That immediate option to specify kernel and root partition has saved me so many times I can't possibly count. It doesn't work on all systems but I have been quite surprised that the Slackware HUGE kernel via that brilliant little stop, so very fast after CD boot, has been able to boot so many distros at least to where I can repair them. It is just one example of how fundamentally smart Slackware is. Combine that with the value of truly vanilla and we have the most flexible, stable system available. I really don't see a need for a kernel test beyond what we have since the largest time investment has already been made in building the kernel, While we are all crestfallen when we see "Kernel Panic" I don't see any way to shorten the process beyond careful building and recovery insurance.
 
Old 12-09-2015, 06:16 PM   #12
onebuck
Moderator
 
Registered: Jan 2005
Location: Summer Midwest USA, Central Illinois, Winter Central Florida
Distribution: SlackwareŽ
Posts: 13,270
Blog Entries: 29

Rep: Reputation: 2462Reputation: 2462Reputation: 2462Reputation: 2462Reputation: 2462Reputation: 2462Reputation: 2462Reputation: 2462Reputation: 2462Reputation: 2462Reputation: 2462
Member response

Hi,
Quote:
Originally Posted by fogpipe View Post
As long as you are going to compile it you might as well install it. Just make sure that you append a unique local version name and list it by that name in lilo.conf This way you can revert to the old kernel just by choosing the appropriate lilo menu item.
Code:
# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
boot = /dev/sda
#disk=/dev/sdb
#     inaccessible
default = 4.1.13odinLPD
#compact        # faster, but won't work on all systems.
install = menu 
#bitmap = /boot/slack.bmp
#bmp-table = 60,6,1,16
#bmp-timer = 65,27,0,255
#bmp-colors=250,0,255,0,255,0
# Append any additional kernel parameters:
append=" vt.default_utf8=0 raid=noautodetect"
prompt
timeout = 50
# Normal VGA console
vga = normal
# Ask for video mode at boot (time out to normal in 30s)
#vga = ask
# VESA framebuffer console @ 1024x768x64k
# vga = 0x0360
# VESA framebuffer console @ 1024x768x32k
# vga=790
# VESA framebuffer console @ 1024x768x256
# vga=773
# VESA framebuffer console @ 800x600x64k
# vga=788
# VESA framebuffer console @ 800x600x32k
# vga=787
# VESA framebuffer console @ 800x600x256
# vga=771
# VESA framebuffer console @ 640x480x64k
# vga=785
# VESA framebuffer console @ 640x480x32k
# vga=784
# VESA framebuffer console @ 640x480x256
# vga=769
#
# ramdisk = 0     # paranoia setting
# End LILO global section
# Linux bootable partition config begins
# stock current kernel
image = /boot/vmlinuz
  root = /dev/sda5
  label = Slack
  read-only
# 4.1.6 kernel custom compiled for pentiumD
image = /boot/vmlinuz-4.1.13odinLPD
   root = /dev/sda5
   label = 4.1.13odinLPD
   read-only
   append=" vt.default_utf8=0 raid=noautodetect fb=false"
#a little leaner
image = /boot/vmlinuz-4.1.6odinLPD
   root = /dev/sda5
   label = 4.1.6-odinLPD
   read-only
   append=" vt.default_utf8=0 raid=noautodetect fb=false"
        
  # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
# Windows bootable partition config begins
other=/dev/sda1
label=windows
table=/dev/sda
# Windows bootable partitn config ends
Sorry about the cruft i edit lilo.conf often.

Also copy and name the System.map file with the appropriate version designation.
ex. System.map-4.1.13odinLPD
May I suggest that you use addappend= in your image stanza. That way your global append= will remain intact;
Quote:
From man lilo.conf;
KERNEL OPTIONS (image=)
If the booted image is a Linux kernel, then one may pass command line parameters to this kernel.

addappend=<string>
The kernel parameters of this string are concatenated to the parameter(s) from an append= option (see below). The string of addappend
must be enclosed within double quotes. Usually, the previous append= will set parameters common to all kernels by appearing in the
global section of the configuration file and addappend= will be used to add local parameter(s) to an individual image. The addappend
option may be used only once per "image=" section.

If the string is a very long line, this line can be divided in more lines using "" as last character of a line, e.g.

addappend="noapic acpi=off pci=usepirqmask \
pnpbios=off pnpacpi=off noisapnp"

append=<string>
Appends the options specified to the parameter line passed to the kernel. This is typically used to specify hardware parameters that
can't be entirely auto-detected or for which probing may be dangerous. Multiple kernel parameters are separated by a blank space, and
the string must be enclosed in double quotes. A local append= appearing withing an image= section overrides any global append= appear-
ing in the global section of the configuration file. The append option may be used only once per "image=" section. To concatenate
parameter strings, use "addappend=". Example:

append="mem=96M hd=576,64,32 console=ttyS1,9600"

If the string is a very long line, this line can be divided in more lines using "" as last character of a line. See example of addap-
pend option.
Hope this helps.
Have fun & enjoy!

Last edited by onebuck; 12-10-2015 at 12:01 PM. Reason: typo
 
Old 12-09-2015, 07:36 PM   #13
the3dfxdude
Member
 
Registered: May 2007
Posts: 563

Rep: Reputation: 240Reputation: 240Reputation: 240
Running a mock test of a linux kernel without rebooting? Using real hardware? User-mode linux:
https://en.wikipedia.org/wiki/User-mode_Linux

Kind of hard to get going since it does require a special config. I've used it before for kernel debugging.
 
1 members found this post helpful.
Old 12-09-2015, 11:32 PM   #14
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 5,524

Rep: Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272Reputation: 3272
Quote:
Originally Posted by enorbet View Post
FWIW I always and very quickly after base install, compile a custom kernel. I "hedge my bets" in a couple of ways. Firstly, since i don't encrypt the filesystem I do the work to insure that I have no need for an initrd. This just makes my system simpler with less vulnerability.

Secondly, I always keep the original "HUGE" kernel available as a fallback.

Lastly, and I really don't know why other distros don't follow this simple logic, I am a huge fan of the Slackware Install disk. That immediate option to specify kernel and root partition has saved me so many times I can't possibly count. It doesn't work on all systems but I have been quite surprised that the Slackware HUGE kernel via that brilliant little stop, so very fast after CD boot, has been able to boot so many distros at least to where I can repair them. It is just one example of how fundamentally smart Slackware is. Combine that with the value of truly vanilla and we have the most flexible, stable system available. I really don't see a need for a kernel test beyond what we have since the largest time investment has already been made in building the kernel, While we are all crestfallen when we see "Kernel Panic" I don't see any way to shorten the process beyond careful building and recovery insurance.
Only problem with this is he is looking to remotely update his kernel and wants to try to prevent it hanging on a possible kernel panic until he can get home to fix it. Most of yours requires you to be physically at the computer.

Otherwise, that's some good advice
 
  


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
Kernel Panic in 64bit Arch Linux after Kernel Recompile: 2.6.35-rc3 jackerybakery Linux - General 3 06-16-2010 11:21 AM
Kernel recompile, LILO warning and Kernel-panic Tux-Slack Slackware 26 02-26-2008 06:15 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

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

Main Menu
Advertisement
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
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration