Raskas’ blog

Everybody knows and uses output redirection to get the output of a command to a file.

With > you redirect STDOUT, with 2> you redirect STDERR and with &> you redirect both at the same time.

ls > output.txt
ls 2> error.txt
ls &> output_and_error.txt


But how do you get the output written to the screen AND to a file?

“tee” answers this question. This little program will accept text from STDIN and put in on STDOUT and write it to a file.
This is how you use it:

ls | tee output.txt


Kris explained in a previous blog post how you can create multiple bridges.

While testing the multiple bridges in a situation where every bridge is connected to a physical interface and that every virtual interface must be connected to the correct bridge (peth0->xenbr0->vifX.0; peth1->xenbr1->vifX.1; …) I noticed something strange.

The vif interface was not always connected to the correct bridge. When the bridgename is provided in the configuration file (with or without the mac address) the first entry is not always mapped to vifX.0.

A wrapper script brought again a solution. The vif-wrapper-bridge script will chech the name of the vif interface and use the last number (interface number) to define the bridge. That bridgename is stored in the xenstore and used by the vif-bridge script.


[root@GW-Y ~]$ grep wrapper xend-config.sxp
(network-script network-wrapper-bridge)
(vif-script vif-wrapper-bridge)


vif-wrapper-bridge
#!/bin/sh
 
if [ $1 = "online" ]
then
  # load some general functions
  dir=$(dirname "$0")
  . "$dir/vif-common.sh"
  # find the bridge number out of the vif interface name
  brnum=$(echo $vif | sed 's/vif.*\.//')
  bridge=xenbr$brnum
  # store the bridgename in xenstore
  bridge=$(xenstore_write "$XENBUS_PATH/bridge" "$bridge")
fi
 
# load the real vif-bridge script
/etc/xen/scripts/vif-bridge $1


During testing of heartbeat 1 on a xen dom0, some strange errors appeared. One of the error messages was:
ERROR: No local heartbeat. Forcing shutdown

This error message was explained in the heartbeat FAQ but the explained causes didn’t make any sense.
An update from Xen 3 to Xen 3.0.4 didn’t solve the problem.
Updating heartbeat from v1 to v2 made the error disappear and heartbeat was now working without any problems.
Heartbeat v2 has a complete new config file. The main config file (ha.cf) is now an xml file. But don’t worry, if you don’t want to upgrade the config file, you can keep working with a v1 config file. You can’t take advantage of the new features of heartbeat v2 but at least you’re taking advantage of the bugfixes

I repeadetly tried to install xen. The installation of the rpms, downloaded from the xen site, succeeded but when I rebooted into the xen kernel a kernel panic occured.
A message like no version for “struct_module” found: kernel tainted scrolled over the screen during the loading of the modules. A deeper look into that message showed me that it was not fatal and the kernel panic was caused by something else.

A lot of kernel panics are caused because they can’t find the harddisk. This happens because the correct module isn’t build into the kernel or available in the initrd. The same problem occured here. The xen kernel has not as many build in modules as a normal centos kernel and the needed modules aren’t automatically added in the initrd.

The solution is easy: include the needed modules in the initrd.
But which module is the correct one? That depends on the hardware in your system. You can start finding the correct modules by reading the dmesg when you boot that system with a working kernel.

Following command worked on my home machine:

[root@xen ~]# mkinitrd -v -f --with=ide-generic /boot/initrd-2.6.16.33-xen_3.0.4.1.img 2.6.16.33-xen_3.0.4.1


By default xen will bind it’s console on ttyS0 and following message is visible in /var/log/message
kernel: Xen virtual console successfully installed as ttyS0

At this moment you can’t send messages over a serial cable connected to your system because the device is already in use by xen.

Adding following parameter in the grub config file, the default ttyS0 will be changed to whatever you provide or removed if you enter xencons=off.
module /boot/vmlinuz-2.6-xen ro root=/dev/sda1 xencons=ttyS9

ttyS0 will be unused after a reboot and the module providing the serial devices can be loaded, the module is called 8250.
Normally the serial modules are compiled in the kernel and nothing is implemented to load them during boot. But we want to load when the system is booted. Therefore I added that module in /etc/modprobe.conf:
# loading the module for serial devices. We want this at boot time therefore it is aliased to snd-card.
alias snd-card-0 8250
alias snd-card-0 8250_pci
alias snd-card-0 8250_pnp


This is how you can test the serial connection between 2 machine:
* On machine 1 open the serial device: cat /dev/ttyS0
* On machine 2 send a message over the link: echo “Hello World” > /dev/ttyS0
The message should appear on machine 1.

When you initiate a kickstart installation from a bootcd you have to enter something like: linux ks=hd:sda1:/ks.cfg.
This and whatever you enter on the same line can be accessed during the installation. This line is stored in /proc/cmdline.
It is not specific to a kickstart installation, but on every linux system you can find the information entered at the boot prompt in /proc/cmdline.

In a previous post I mentioned how you can mount your usb-drive. As you can see sda1 is hard-coded which isn’t very flexible. This can be done on a different way:

%pre
if grep -iqE "ks=hd:[a-z]{2,3}[0-9]:" /proc/cmdline
then
  DISK=`cat /proc/cmdline | sed 's/.*ks=hd:\(.*\):.*/\1/'`
fi
mkdir -p /tmp/usb-disk-mount/
mount /dev/$DISK /tmp/usb-disk-mount/


There are many things you can do with the line stored in /proc/cmdline.
You can enter a keyword, and with that keyword you can select which files are needed for the installation.
That keyword can also be used to specify a specific option.

The bad thing is that the %pre section is executed in a seperate run. If you set some variables during the %pre section (like $DISK in the above example) they won’t be available for the rest of the script.
The include path of the file must be hard-coded but you can change existing content or generate the complete file during the %pre section.