2

I am writing a BASH script that automatically configures, builds and installs the most recent kernel image. The generated kernel should include the grsecurity patchset. It would use the previous configuration from /proc/config.gz, which I created manually when compiling the first custom kernel on the machine.

Is it safe to fully automatize the process? It would look like this:

  1. Check the most recent kernel that grsecurity is available for
  2. Download the grsecurity patchset and the matching kernel source tree
  3. Patch the kernel
  4. Copy the previous kernel configuration file into the kernel source directory
  5. Run make olddefconfig to configure the kernel based on the previous configuration
  6. Compile the kernel with fakeroot make deb-pkg
  7. Install the resulting packages and change bootloader priority
  8. Send me a mail indicating that a reboot is required

The main question: is it likely that a kernel compiled with olddefconfig will contain errors that prevent the system from booting if the previous configuration is working correctly? It is very important because it is a remote server accessed via SSH and a manual rescue would take a lot of effort.

Improve this question

1 Answer 1

Reset to default
2

If you can't afford failure, test.
Even if you can afford failure, testing is good. If at all possible, run the build in a dedicated test environment. In many cases a virtual guest makes for an adequate test system. When you cab reboot into your updated kernel and any subsequent tests complete successfully too, only then copy and deploy the new package to your remote system.

Now to your main question: will your plan and make olddefconfig contain errors that will result in a boot failure?
Only an idiot would believe any system to be completely foolproof. When you want to run the most recent kernel, as you stated, you will be bleeding edge and have all the advantages and risks associated with that. Reducing risk is selecting a long term release where a feature set is frozen, and only bug/security fixes will be introduced.

Regardless: any reboot runs a small risk of failing.

On a side note: I have spent too many hours in the past in data centers repairing issues/misconfigurations in servers that I recommend everyone to always add a suitable remote management option (e.g. HP ILO, Dell's DRAC, Oracle's ILOM etc. or a KVM over IP gateway) to your remote servers, that allows you to fix most issues the comfort of your desk.

Improve this answer
3
  • Unfortunately, I don't have a spare machine for testing. I can use my main workstation for building (amd64 machine) with cross compiling (target system is i686), but I can't run the resulting kernel. I don't have a spare i686 machine for testing. Most recent in our case means the 3.2.x LTS versions as grsecurity is only available for those versions. Commented Jun 21, 2014 at 8:11
  • 1
    You should run a virtual guest with a i686 32bit virtual CPU and corresponding OS; for example in KVM by using qemu-kvm -cpu qemu32 and other (desktop) hypervisors offer similar options. Commented Jun 21, 2014 at 8:51
  • Well, I haven't thought about this before. Great idea, I'll go for it! Commented Jun 21, 2014 at 8:55

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.