Free boot barn software for linux

Bootchart is a software for performance analysis and visualization of the GNU/Linux boot process. Resource utilization and process information are collected during the boot process and can later be displayed in a PNG, SVG or EPS-encoded chart.

The boot process is modified to start the boot logger (/sbin/bootchartd) instead of /sbin/init. The boot logger will run in background and collect information from the proc file system (/proc/[PID]/stat, /proc/stat and /proc/diskstats).

The statistics are logged to a virtual memory file system (tmpfs). Once the boot process completes (denoted by the existence of specific processes), the log files are packaged to /var/log/bootchart.tgz.

The log package can later be processed using a Java application which builds the process tree and renders a performance chart. The chart may then be analyzed to examine process dependency and overall resource utilization. A renderer web form is also available on the project web site.

The chart can then be analyzed to examine process dependency and overall resource utilization.

Runing:

1. Install bootchartd and the bootchart renderer. See INSTALL for details.

2. Modify your boot loader (GRUB/LILO) if necessary. Alternatively, change the kernel command line interactively upon reboot.
Reboot.

3. Verify that /var/log/bootchart.tgz was created and contains the log files.

4. Render the chart by running:

$ java -jar bootchart.jar

Alternatively (if no Java Development Kit is installed to build the JAR package), the web renderer may be used.

To use the web renderer from a script, run:
curl --form format=svg --form log=@/var/log/bootchart.tgz
http://bootchart.klika.si:8080/bootchart/render > bootchart.svgz

(optionally replacing the svg/bootchart.svgz pair with png/bootchart.png or eps/bootchart.eps.gz)

5. View the generated image and analyze the chart.
SVG images may be viewed using any of the following programs:
- rsvg-view (librsvg; GNOME)
- svgdisplay (ksvg; KDE)
- Gimp (using the gimp-svg plugin)
- Inkscape
- Squiggle (Batik; http://xml.apache.org/batik/)

To get help for additional options, run:

$ java -jar bootchart -h

How it works:

Logger Startup

The boot logger (/sbin/bootchartd) is run by the kernel instead of /sbin/init. This can be achieved by modifying the GRUB or LILO kernel command line, e.g.:

/boot/grub/menu.lst
[...]
title Fedora Core (2.6.10) - bootchart
root (hd0,1)
kernel /vmlinuz-2.6.10 ro root=/dev/hda1 init=/sbin/bootchartd
initrd /initrd-2.6.10.img

The installation script and RPM package will try to add the boot loader entry automatically.

The boot logger will start itself in the background and immediately run the default init process, /sbin/init. The boot process will then continue as usual.

Data Collection

Since the root partition is mounted read-only during boot, the logger needs to store data in memory, using a virtual memory file system (tmpfs).

As soon as the /proc file system is mounted — usually early in the sysinit script — the logger will start collecting output from various files:
/proc/stat system-wide CPU statistics: user, system, IO and idle times
/proc/diskstats system-wide disk statistics: disk utilization and throughput
(only available in 2.6 kernels)
/proc/[PID]/stat information about the running processes: start time, parent PID, process state, CPU usage, etc.

The contents of these files are periodically appended to corresponding log files, every 0.2 seconds by default.

The logger will try to detect the end of the boot process by looking for specific processes. For example, when in runlevel 5 (multi-user graphical mode), it will look for gdmgreeter, kdm_greet, etc. As soon as one of these processes is found running, the logger will stop collecting data, package the log files and store them to /var/log/bootchart.tgz.

Optional Process Accounting

In most cases, the output from /proc/[PID]/stat files suffices to recreate the process tree. It is possible however, that a short-lived process will not get picked up by the logger. If that process also forks new processes, the logger will lack dependency information for these "orphaned" processes — meaning that they might get incorrectly grouped by the chart renderer.

When truly accurate dependency information is required, process accounting may be utilized. If configured, the kernel will keep a log file with detailed information about processes. BSD process accounting v3 includes information about the process PID and parent PID (PPID) — effectively enabling an accurate reconstruction of the process tree.

To enable process accounting, the kernel needs to be configured to include CONFIG_BSD_PROCESS_ACCT_V3, under:

[ ] General setup
[ ] BSD Process Accounting
[ ] BSD Process Accounting version 3 file format

The GNU accounting utilities (package psacct or acct) also need to be installed. The boot logger will use the accton command to enable process accounting; it will include the accounting log in the tarball.

Visualization

The log tarball is later passed to the Java application for parsing and rendering the data. The CPU and disk statistics are used to render stacked area and line charts. The process information is used to create a Gantt chart showing process dependency, states and CPU usage.

A typical boot sequence consists of several hundred processes. Since it is difficult to visualize such amount of data in a comprehensible way, tree pruning is utilized. Idle background processes and short-lived processes are removed. Similar processes running in parallel are also merged together.

Finally, the performance and dependency charts are renderer as a single image in either PNG, SVG or EPS format.

TCCBOOT project is a boot loader able to compile and boot a Linux kernel directly from its source code.

TCCBOOT is only 138 KB big (uncompressed code) and it can compile and run a typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4.

TCCBOOT is based on the TinyCC compiler, assembler and linker. TinyCC is an experiment to produce a very small and simple C compiler compatible with the GNU C compiler and binary utilities.

TCCBOOT boots the same way as a Linux kernel, so any boot loader which can run a bzImage Linux kernel image can run TCCBOOT. I only tested it with ISOLINUX, but LILO or GRUB should work too.

TCCBOOT reads C or assembly sources from a gzipped ROMFS filesystem stored in an Initial Ram Disk (initrd). It first reads the file boot/tccargs which contains the TinyCC command line (same syntax as the tcc executable). The TinyCC invocation should output one binary image kernel. This image is loaded at address 0x00100000. TCCBOOT then does a jump to the address 0x00100000 in 32 bit flat mode. This is compatible with the ABI of the vmlinux kernel image.

Compilation:

TCCBOOT was only tested with Linux 2.4.26. In order to build TCCBOOT, you must first compile a 2.4.26 kernel because for simplicity TCCBOOT uses some binary files and headers from the Linux kernel. TCCBOOT also needs the source code of TinyCC (tested with TinyCC version 0.9.21). You can modify the Makefile to give the needed paths.

Example:

An "Hello World" ROMFS partition is included (initrd.img). You can rebuild it from the example/ directory. You can test it with the QEMU PC emulator with the qemu-tccboot script.

Kernel compilation:

For your information, the patch linux-2.4.26-tcc.patch gives the necessary modifications to build a Linux kernel with TCCBOOT (NOTE: it is not suffisant to build the kernel with its own Makefiles - I never tried). The corresponding kernel configuration is in file linux-2.4.26-config. Patches are necessary for the following reasons:

- unsupported assembly directives: .rept, .endr, .subsection
- #define __ASSEMBLY__ needed in assembly sources
- static variables cannot be seen from the inline assembly code
- typing/lvalue problems with ? :
- no long long bit fields
- aligned attribute not supported for whole structs, only for fields
- obscur preprocessor bug

Some of these problems could easily be fixed, but I am too lazy now. It is sure that there are still many bugs in the kernel generated by TinyCC/TCCBOOT, but at least it can boot and launch a shell.

BootRoot creates a boot disk with lilo, a kernel and an initrd image. The initrd script mounts another root disk with a compressed (gzip or bzip2) filesystem.

The root filesystem isnt made by this program, but there lots of compressed filesytems out there to use.

You can use a bzip2 compressed filesystem, this program is easy to use, and it provides a framework showing a simple initrd method which you can freely modify.

The four steps to making a Boot Root set.

1). Grab the Perl Script right here .. boot_root give it a name .. umm .. boot_root.

2). Make sure the bang line points to the right place:

$ which perl
/usr/bin/perl
$ grep "perl -w" boot_root
#!/usr/bin/perl -w

3). Make it executable:

$ chmod 755 boot_root

4). Put it in one of your LIB PATHS:

$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:.:
$ mv boot_root /usr/bin

5). Run it, and have lots of fun! More directions can be found at the beginning of the script.

Bioknoppix is a customized distribution of Knoppix Linux Live CD. With this distrubution you just boot from the CD and you have a fully functional Linux OS distribution with open source applications targeted for the molecular biologist. Beside using some RAM, Bioknoppix doesnt touch the host computer, being ideal for demonstrations, molecular biology students, workshops, etc.

SLAX Boot CD is used to boot SLAX from USB devices on computers which cant boot from USB directly. SLAX Boot CD can be also used to boot SLAX from ISO file on disk.
Enhancements:
- added KDE 3.5.4 with Slackware 11 fixes for media:/ URL in konqueror
- probeusb parameter now sleeps delay_use+1 seconds to wait for USB devices
- (this usually defaults to 6 seconds)
- fixed fuse libraries, which were missing in rc1 version
- added newest NTFS-3g beta version, NTFS writing now works, I hope

Ubuntu Bootloader Manager is a graphical user interface (GUI) for configuring GRUBs menu.lst.

This app is still very alpha, use at your own risk and make sure to make a backup of our grub config file (/boot/grub/menu.lst).

Loki Render software is a queue manager. It serves Blender render jobs or your own scripts to a pool of clients.

This is commonly called "distributed network rendering" or a "render farm". Loki can also boot clients via PXE, making for a quick and scalable pool.