Upgrading the Linux Kernel
With the release of Linux 1.2.x, there have been a lot of questions on the newsgroups asking what needs to be done to upgrade a stable 1.0.x system to a stable 1.2.x system. Fortunately, this is relatively easy and painless.
One thing you should note is that you should upgrade to the 1.2.1 kernel, especially if you are using firewall software. Version 1.2.0 was somewhat broken in this respect.
The first thing you should realize is that a new program, bdflush, is required by the 1.2.x kernel. The program arrived early in the 1.1.x series and replaces update, implementing a style of disk caching that is a bit more efficient than the older style. Without this program, your disk caching will not work as well, and you will be warned: “Warning - bdflush not running”.
The networking tools should also be upgraded. The new versions have been upgraded to support improvements in the kernel networking code. Do note that normal networking programs do not need to be upgraded; only a few special programs, included in a single kit, are affected by the changes.
I have built a package that includes all of these programs. It's called “The Linux Upgrade 1.2”, in a file called linuxupgr-1.2.tar.gz. It is available at sunsite.unc.edu and its mirrors in /pub/Linux/system/, and at tsx-11.mit.edu and its mirrors in /pub/linux/binaries/sbin/. Download this package along with the version 1.2.1 kernel, which should be available nearby in the file linux-1.2.1.tar.gz. Sunsite and its mirrors have the kernel in /pub/Linux/kernel/v1.2/, and tsx-11 and its mirrors have the kernel in /pub/linux/sources/system/v1.2/.
Back everything up! Back up your system just in case of any problems along the way. In case anything goes wrong, you can always go back to a stable system. At least back up your data files.
Make notes about your system. The kind of filesystems you have, extra cards, sound card information, and so on.
From this point on, you should be the root user with few users logged on.
Move the linux kernel tar file to the /usr/src directory. mv linux-1.2.1.tar.gz /usr/src
Back up the old kernel by moving its directory tree to a directory with another name. For example, if the old kernel is a 1.0.9 kernel, you can (in the /usr/src directory) mv linux linux-1.0.9. This way, you still have the source to the old 1.0.9 kernel available.
Uncompress and untar the kernel file by running tar xzvf linux-1.2.1.tar.gz You should see a list of files being sent to the screen. They should all begin with “linux/”.
Change to the linux directory and run make config. You will be offered options, for which you will need the information you collected from step 2. In many cases, you can take the defaults, unless you have a specialized system. Issue 7 of Linux Journal had an article, “Linux Performance Tuning for the Faint of Heart”, which specifically covers how to compile new kernels.
One specific item that is not covered in that article is the new IDE driver in Linux 1.2. In the Linux kernel source, there is a file drivers/block/README.ide that you should read if you have a large IDE drive, multiple IDE controllers, or ATAPI IDE CD-ROM drives. Nearly everyone will want to answer “Use new IDE driver for primary/secondary [interface]” with yes. The only reason not to is if you use MFM or RLL drives, since the new IDE driver supports only IDE drives.
Once the configuration is ready, make the dependencies needed by gcc to build the kernel correctly. Run make dep.
At this point, if you're using lilo, you can run make zlilo and the makefile will automatically begin building the kernel and installing the new kernel in LILO. If you boot off a floppy drive, you can just run make zdisk, and put a blank formatted 1.4 (or 1.2) MB disk in the drive and makefile will build the kernel and install it on your floppy.
NOTE: My preference is to install first to a diskette, and boot from that. If there are no problems, then I go back and run make zlilo. Another option is copying the current Linux kernel to another filename (such as vmlinuz1.0.9) and making a new LILO entry for that file. If you reboot with the first kernel and have problems, you can reboot again, get into LILO, and boot the older kernel. If you feel comfortable using LILO, this may be easier for you.
You will also need to tell the kernel file to mount the root device read-only so that it can run fsck if necessary. If you're using a floppy, run rdev -R /dev/fd0 1. If you're using LILO, run rdev -R /vmlinuz 1. Using the capital R here is important. If you are using LILO, another option is to use the read-only option for the boot image. This is covered in the excellent LILO documentation.
Once the kernel is built, install the Linux Upgrade Package. From /usr/src, run tar xzvf linuxupgr-1.2.tar.gz. This will create a directory called upgrade which has the bdflush and other assorted files in it. Read the README file for instructions on installing the upgrade files.
Reboot the machine. If you did everything correctly, you should have a successfully running 1.2.1 kernel. If you do run into problems and you are using a floppy disk, you can pop the floppy out of the drive and reboot with the old kernel.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- Interview with Patrick Volkerding
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide