Archive for September, 2010

NBD is a software which enables one computer to provide another computer a direct low-level access to a block device. In other terms it helps share a block device over network.

Advantages
In some environment the performance of sharing over network is better than NFS.( Sometimes even 10x it is claimed). This is commonly seen in thinclient.
It can export any type of filesystem
Best used as swap over network

Installation
NBD has two components. nbd-server and nbd-client.

On debian/ubuntu installation is like this

apt-get install nbd-server
apt-get install nbd-client

nbd-server is required on the server sytem.
nbd-client is required on the client system

Usage
On debian/ubuntu you can start relevant services like this

—————————————————-
# /etc/init.d/nbd-server start

** (process:4393): WARNING **: Could not parse config file: Could not open config file.
** Message: Nothing to do! Bye!
nbd-server.
—————————————————-
Do not bother about the Warning. This will be issued if no configuration file present. You can give all required paramaters in command line.
Start the client
————————————–
#/etc/init.d/nbd-client start
Starting NBD client process: Connecting…Activating…
nbd-client.

127.0.0.1 denotes server’s IP address
5000 denotes server port number
/dev/nbd0 is the device on the client.
Once the above command is executed, nbd-client will talk to server
and negotiate appropriate communication mechanism. This we can see
as the output above

Here I want to export an iso image to client as an ISO file sytem.
I have debian dump in /home/lenny_stable/

The sequence of commands are
Start the server
————————————–
# nbd-server 8000 /home/lenny_stable/debian-500-i386-DVD-1.iso
** (process:4456): WARNING **: Could not parse config file: Could not open config file.
————————————–

Re-building and re-booting a distro kernel is conceptually, and in practice, a fairly easy thing to do. But it is also very easy to mess up your system with a single simple typo, with the practical consequences that you may need to reinstall your system. Being unable to re-boot a shared system where someone else has data that wasn’t backed up is a “most unpleasant” feeling. Be Wary

First. We strongly urge you to practice these steps on a victim system, where you have no problems what-so-ever of completely reinstalling the system. A “victim system” means there is nothing of importance on the system. No important data. No critical users or applications. No key work-in-progress.

Second. These steps are provided simply as a step-by-step guide of how several of us re-built the kernel in the labs on freshly installed victim systems. We most-certainly are not the official source for the right steps, nor do we claim this will work for everyone, and you should not expect any level of support from us on this.

Third. This should be intuitive, but amazingly-enough often isn’t clearly understood. So we’ll say it here explicitly. If you re-build your own kernel and you use that kernel, you have invalidated any hope for “official support” from your service provider while using that kernel.

SLES 11. Find the kernel-source “src.rpm”

On SLES 11, there are two DVD iso images.
SLES-11-DVD-ppc64-GM-DVD1.iso
SLES-11-DVD-ppc64-GM-DVD2.iso

This rpm cleverly doesn’t show up as installed if you do a rpm -qa | grep kernel-source. To tell whether you have installed the package, look under /usr/src/packages/SPECS. If there’s nothing there, then you have not installed the correct rpm.

Install the kernel-source “src.rpm”

You want the “src.rpm”, not just the “.rpm” file.
cd /dvd/suse/src
rpm -i kernel-source-2.6.27.19-5.1.src.rpm

Copy the “spec” file from SOURCES over to the SPECS sub-directory.
cd /usr/src/packages/SOURCES
cp kernel-ppc64.spec ../SPECS

If the kernel-ppc64.spec file does not exist, you will first have to build the platform specific spec files…
# cd /usr/src/packages/SOURCES
# ls
kernel-binary.spec.in kernel-module-subpackage kernel-source.rpmlintrc kernel-spec-macros
kernel-docs.spec.in kernel-source.changes kernel-source.spec.in kernel-syms.spec.in
# ./mkspec

and then copy the kernel-ppc64.spec file to ../SPECS as previously stated.

Note the current kernel level which will be used to compare the version after the rebuild/successful boot.
# uname -r
2.6.27-19-5-ppc64

rpmbuild -ba kernel-ppc64.spec

rpmbuild is the clever step that packages all of the patches that constitute the “whole” of the kernel.
# rpmbuild -ba kernel-ppc64.spec
error: Failed build dependencies:
sparse is needed by kernel-ppc64-2.6.27.19-5.001.ppc64
fdupes is needed by kernel-ppc64-2.6.27.19-5.001.ppc64
kernel-dummy is needed by kernel-ppc64-2.6.27.19-5.001.ppc64

Try again (noticing that there is no such thing as a kernel-dummy rpm file).
# rpmbuild -ba kernel-ppc64.spec
error: Failed build dependencies:
kernel-dummy is needed by kernel-ppc64-2.6.27.19-5.001.ppc64

Eh?

From the README.SUSE file in /usr/src/packages/SOURCES
* kernel-dummy

This package is relevant inside the SUSE build system only. We use
it to synchronize release numbers among the kernel packages. When
building packages locally, the kernel-dummy package can safely be
ignored.

We’re ready to go. But before we start, we want to modify the “spec” file to compile in parallel.

vi kernel-ppc64.spec
After the “build_flavor” line, add a line to define “jobs” to be the number of available CPUs.
%define build_flavor “ppc64”
%define jobs %(cat /proc/cpuinfo | grep processor | wc -l)

So then we can install the new kernel rpm.
# cd /usr/src/packages/RPMS/ppc64
# rpm -i kernel-ppc64-2.6.27.19-5.001.ppc64.rpm
Setting up /lib/modules/2.6.27.19-5.001-ppc64

We recommend that you reboot to this kernel and confirm that it boots correctly.

We recommend that you do NOT change the default boot kernel, leaving the test kernel as an alternative choice.

Adding patches into the kernel build process.

There are several steps required to add a patch set into the build process.

Prepare the patch set.

The patch set it prepared by creating a patch directory and adding the patches to the directory. Once the patches are added to the directory, create a tar/bzip file of the patches.
tar -cjf patches.osjitter.tar.bz2 patches.osjitter

Add (copy) the patch set to the /usr/src/packages/SOURCES directory.
cp -p patches.osjitter.tar.bz2 /usr/src/packages/SOURCES/

Edit the kernel-ppc64.spec file and specify the patch set in 2 places.

1) Insert the patch set name after the last patch in the kernel-ppc64.spec file. Note to increment the Source number (Source121 is used for this case).
Source113: patches.kabi.tar.bz2
Source120: kabi.tar.bz2
Source121: patches.osjitter.tar.bz2 <— add the patch set
BuildRoot: %{_tmppath}/%{name}-%{version}-build
ExclusiveArch: ppc ppc64

For completeness, here’s the quick steps for building a mainline kernel.

Go to kernel.org, download a stable or recent kernel. For example, at the time this is being updated, the current stable kernel we recommend is 2.6.32.12. We would suggest keeping within 2.6.32 stable kernels.

In this example, we download the 2.6.32.12 mainline kernel
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.32.12.tar.bz2

If you wish, you can confirm the new settings in the .config file:
…
CONFIG_PPC_HAS_HASH_64K=y
# CONFIG_PPC_4K_PAGES is not set
# CONFIG_PPC_16K_PAGES is not set
CONFIG_PPC_64K_PAGES=y
# CONFIG_PPC_256K_PAGES is not set
CONFIG_FORCE_MAX_ZONEORDER=9
# CONFIG_PPC_SUBPAGE_PROT is not set
…
CONFIG_NR_CPUS=256
…
#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_EVENT_PROFILE=y
# CONFIG_PERF_COUNTERS is not set
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set