Brain Goo

By default, when zypper upgrades your kernel, it treats the package like any other package. The old kernel is removed and the new kernel is installed. There are three ways to get your old kernel back (or keep it).

1. You can re-install it with RPMS. This is involves manually updating your /boot/grub/menu.lst files when you are done.
   In order to boot on your previous kernel
2. After the upgrade, you can use zypper to install the kernel packages that it removed by throwing various flags on there to force it to ignore conflicts. You still have to go mess with /boot/grub/menu.lst because your old kernel will now be the new default
3. The best way: Tell zypper to leave your old kernel alone, but install the new kernel as the new default.

Number three is easily done by adding two lines to the /etc/zypp/zypp.conf file before upgrading your kernel.

Add or update these lines in the [main] section of /etc/zypp/zypp.conf

multiversion = provides:multiversion(kernel)
multiversion.kernels = latest,latest-1,running

multiversion defines which packages are allowed to exist with multiple versions of the same package name. Just specifying kernel will allow you to retain all of the available kernel packages. You can restrict which packages by being more specific. For instance: multiversion = kernel-default,kernel-default-base,kernel-source

multiversion.kernels defines package specific retention rules. In this case we defined three to retain:

1. latest The kernel with the highest version number.
2. latest-1 The kernel with the next highest version number. This is defined as latest-N where N is the Nth highest version number
3. running The running kernel version.

If we have three kernels, I would expect to see three after the next update with the oldest of the three falling off the list. If we have two kernels installed, I would expect to see three after the update. If we have one, I would expect two.

The extra, double-cool thing is that the old kernel retain their kdump configurations so you can crash-dump any installed kernel.

You can re-apply your /etc/inittab file in real-time without rebooting your machine. This allows you to do a lot of neat things, such as redirect your system console to the serial port without a reboot.

1. Edit your /etc/inittab file and add this line:
   • S0:12345:respawn:/sbin/agetty -L 9600 ttyS0 vt102
2. Execute the following command:
   • telinit q && telinit u
3. Your primary console (ttyS0) should magically appear on the serial console!

So what just happened? The /etc/inittab file is read by the init system at boot. If you added the line from step 1 and simply rebooted, you would have your console show up on the serial port right away. We told init to re-read the /etc/inittab file (telinit q) and then to re-execute itself (telinit u) while preserving the init state. Since the only change was the location of ttyS0, the console was redirected, but the system continued to run as though nothing else changed.

The reason we used the && method was because we may loose our console before we get a chance to execute telinit u. This way both commands are run and init is always executed after re-reading its config.

Did you find this post useful or have questions or comments? Please let me know!

In Python, as with most languages, STDIN is treated like a file. You can read from it any time, but knowing what kind of file it is lets us know if someone passed us something via STDIN or if we are going to prompt them for it.

import os, sys

if os.isatty(file.fileno(sys.stdin)):
    print "Reading list from STDIN."
    print "Enter your list. Press ^D to continue, ^C to quit."
    my_list = sys.stdin.readlines()
else:
    print "Thank you for passing me a list through a pipe."
    my_list = sys.stdin.readlines()

Now lets try it two ways:

First, pass it some stuff:
echo mother sister father brother | ./myapp.py

Then try it plain:
./myapp.py

Did you find this post useful or have questions or comments? Please let me know!