Upgrade to the 2.6-kernel (ppc only)

From NAS-Central Buffalo - The Linkstation Wiki
Revision as of 19:22, 16 June 2006 by Bauldrick (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

How to upgrade to a 2.6 kernel

from the 2.4 currently included in the Debian (FreeLink) release, on LS1, HG, KuroBox, and KuroHG. There's a package with additional files for users on Openlink, Sylver, or Stock Firmware.


WARNING: use "v30" or later!|USE AT YOUR OWN RISK IN ANY RESPECT. If unsure, just leave everything as it is. Detailled information on the boot process is available on this page.


Overview

Our 2.6* kernels address virtually all shortcomings of the LS stock kernels: Very good USB support, NFS, routing, quotas, lots more.

The 400+ modules are optional -- you could delete them, as the "LS core functions", support for mass storage devices and printing, have been compiled into the kernel.

Please read the WARNING note for the bad news.


Installation (automatic)

  • A webinstaller is provided; it can do everything for you. The webinstaller is the recommended installation method for all users. Learn about it and where to download it from:

http://hvkls.dyndns.org/downloads/documentation/README-webinstaller.html

  • Provided you've installed the kernel, check what version you're running after a reboot:
uname -a
Linux linkstation 2.6.16.19-kurobox #5 Wed May 31 10:27:16 CEST 2006 ppc GNU/Linux


    • If you see a 2.6.x kernel, it worked.
    • If you see a 2.4.x kernel, it didn't work. Gather information, and get help. While booted into the stock kernel, check the output of
cat /boot*/boot.log
dmesg | head
lspci
uname -a


Maintenance


  • If you keep up with development, remove the obsoleted old modules from time to time. Old modules consume a lot of space.

Always keep the 2.4* modules and the 2.6.* modules with the highest version number, and you're on the safe side.

rm -r /lib/modules/2.6.old.versions-only


  • Kernel modules can be loaded using
modprobe modulename

without the .ko extension, e.g.,

modprobe fuse


  • If you don't need any functionality beyond what you could achieve using the 'original' web interface and want to conserve disk space, you can delete the modules using
rm -r /lib/modules/2.6*


The boot process and how to control it

Overview

All Linkstations, Kuro Boxes, and Kuro HGs are supported by the bootloader, if running a Buffalo (Stock Firmware, OpenLink, Sylver) or Debian (FreeLink) style init system. Gentoo's BSD style is not supported by the bootloader out-of-the-box, although the bootloader comes with everything else you need to boot a custom 2.6 kernel.

The system boots into the Buffalo kernel in the Flash ROM, then checks your LS flavor and loads the special kernel module /boot*/loader*.o, which in turn boots the new kernel /boot*/vmlinux*.bin. The bootloader is fail-safe to our best knowledge: If booting the new kernel fails, the old one simply continues booting; or your next boot will take you back to the old kernel. Errors are logged.

The bootloader itself is controlled in two phases, the first shall be used by the system only, the second by the user.

System control phase

On startup, the bootloader checks for the presence of the file /boot*/try_new_kernel. The file is initially created for you in /boot on the LS1, /bootHG on the HG, /bootKB/try_new_kernel on the Kuro Box, and /bootKG/try_new_kernel on the Kuro HG. It must contain echo -n "vmlinux.bin" > /boot/try_new_kernel on the LS1, echo -n "vmlinuxHG.bin" > /bootHG/try_new_kernel on the HG, echo -n "vmlinuxKB.bin" > /bootKB/try_new_kernel on the Kuro Box, and echo -n "vmlinuxKG.bin" > /bootKG/try_new_kernel on the Kuro HG.

If this file doesn't exist, or contains unexpected content, the old kernel continues booting. If it does, the root filesystem is remounted read-write, the control file is moved to /boot*/try_new_kernel.running, and the root filesystem is remounted read-only. Thereafter, an attempt to load the new kernel is made. If this attempt is successful, /boot*/try_new_kernel is restored on shutdown and reboot. This mechanism has been reported to work for both LS1 and HG. Do not interfere unless you have to, which is the case only when your first boot into the new kernel fails.

User control phase

In a second step, the bootloader reads /etc/default/boot_new.sh. You can configure the NO_START variable here but should not have to touch the others.

If you change NO_START="0" to NO_START="1", the LS will boot into kernel 2.4.* the next time. You can switch between the two settings whenever you want.

Logging

Errors will be written to /boot*/boot.log