Le boot sous Linux, ça peut rester obscur surtout pour les débutant ! Mais vous voulez quand même savoir ce que fait votre système lorsqu’il démarre ?

Utilisez alors bootchart qui va à partir de la séquence de boot, générer un graphique PNG pour rendre tout cela plus compréhensif.

Pour installer bootchart, un petit

et le tour est joué.
Vous devez ensuite rebooter le PC et lorsque vous êtes loggé, allez dans le dossier /var/log/bootchart et vous y trouverez le graphique.

Kudzu

Kudzu is the Red Hat Linux hardware probing library, and the associated configuration program. The probing library is used by various system utilities, such as anaconda, Xconfigurator, and hwbrowser. The tool runs at system boot time to determine what hardware has been added or removed from the system.

How to get it

You can get the kudzu source code in a variety of ways.

• The most recently built version is normally available on rawhide.

• Via anonymous CVS.
  

       export CVSROOT=:pserver:anonymous@rhlinux.redhat.com:/usr/local/CVS
       cvs -z3 login
       (hit enter)
       cvs -z3 co kudzu
       

• The source is also browseable via cvsweb.

How to report bugs, or send patches

Mailing lists specifically for kudzu

Documentation

• README
• A description of the /etc/sysconfig/hwconf file used by kudzu

You can configure your personal build of ROCK and easily build your own distribution. It is software for managing operating environments. In a way it is a software development toolkit for building OS solutions.

The available config options include, but are not limited to:

Package Selection

You can select the packages you want to have in your distribution. So packages you don't want or need are not built at all. A list of available packages can be found here.

Compiler and Optimization

You can select a compiler and optimization options for building your distribution. That enables you to highly optimize for your hardware. You can also build your entire distribution with the GCC Stack-Smashing Protector enabled for enhanced security.

Dietlibc and uClibc

You can use dietlibc or uClibc instead of the GNU LibC as your C library. That can be very useful e.g. for embedded systems.

And much more ...

Other options are: selection of an init-style and package manager, custom GNU configure options, cross-building, and much more. A major focus in the ROCK development always has been to make adding new features and config options as easy as possible. [...]

Supported Architectures

Most of the ROCK Linux development is done on x86 hardware. But ROCK Linux also supports the Alpha AXP, ARM, HPPA/HPPA64, ia64, MIPS, PowerPC, Sparc32/Sparc64 and x86-64 architectures. Others will follow and are easy to add.

The ROCK Linux Core has been ported to the PowerPC. This was done live, on stage at the Chaos Communication Congress 1999 in only 3 congress days . That was a very impressive demonstration of the high portability of ROCK Linux.

http://www.rocklinux.org/
http://www.rocklinux.org/wiki/About

http://www.linux4all.de/livecd/livecdanaconda/index.htm

http://www.gentoo.org/proj/en/releng/gcloop/index.xml

http://www.gentoo.org/proj/en/releng/catalyst/

dfsbuild works by obtaining packages from your nearest Debian mirror. It will generate an ISO image that contains a bootable Debian system generated by installing those packages. Also, it can place all the .debs and files needed by cdebootstrap in the image. Thus, the generated image can be used to install the base Debian system on a PC as well.

http://darcs.complete.org/dfsbuild/
dfsbuild Debian Packages

A GNAP is a LiveCD, much like Knoppix, geared toward routing services like firewalling, traffic profiling, VPN and network monitoring. Specific configuration files are burnt onto the LiveCD to customize its behaviour, making it easy to restart, and impossible to permanently compromise.

It is also possible to install GNAP on a hard disk, DiskOnModule or CF card for embedded configurations."

http://www.gentoo.org/proj/en/base/embedded/gnap.xml

http://umigumi.org/

This document proposes the design of a CDD Toolkit that tries to standardize the way developers define their CDD and provides tools to distribute, install, update and manage the customized system.

This toolkit is being developed on the current CDD Project on alioth and discussed on the debian-custom [...] mailing list.

http://people.debian.org/~sto/cddtk/cddtool.html
http://alioth.debian.org/projects/cdd/

An rxmaster is a machine used to configure and build iso cdrom images for rxnodes. The rxmaster holds the configurations for all rxnodes. Each rxnodes can be managed, configured and updated from the rxmaster. The rxmaster also served as software distributor for the rxnodes. An rxmaster is a simple web server running the rxmaster cgi."

http://on-x.ca/html/rxlinux.html
http://www.fusionw3.com:8031/on-x/html/downloads.html

http://wiki2.archlinux.org/index.php/ArchLiveTx

http://www.informatik.uni-koeln.de/fai/fai-cd

http://packages.gentoo.org/ebuilds/?livecd-tools-1.0.24

Thanks to this generator, it's now possible to build a bootable image of the GeeXboX from the binaries. This lets you build the GeeXboX after slight changes in the configuration files, for example, with no need to build the full sources. [...] Just execute the ./generator.sh (under Linux) script [...] and watch the magic ;-)

http://www.geexbox.org/en/downloads.html
http://www.geexbox.org/en/doc.html

http://user-contributions.org/projects/archie/source/
http://user-contributions.org/projects/archie/
http://user-contributions.org/wikis/userwiki/index.php/Mkliveiso

This is version 0.20 and it has been tested by creating a Personal Workstation for Fedora Core 3 in one partition and then made a CD image for the Personal Workstation. Also created a Personal Workstation for Fedora Core 4 in another partition and made live boot CD image."

http://dc.qut.edu.au/yetaa/

Kadischi is heavily based on readonly-root package from Stateless-linux project. Many design decisions are collective work of people from fedora-livecd list. There are also some ideas taken from linux4all project.

Basically, Kadischi uses anaconda to install the system in a temporary directory (specified in the configuration file) on user`s hard drive. It then executes the collection of scripts (stored in /usr/share/kadischi/post_install_scripts) in order to modify the system to run successfully in read-only environment (CD). After all modifications are done, Kadischi creates an initrd image, then compresses the system tree (actually, it creates a compressed copy, and then removes the original one), and finally creates iso image of the system."

http://fedoraproject.org/wiki/Kadischi
http://fedoraproject.org/wiki/KadischiDoc

http://syslinux.zytor.com/iso.php

BBLCD is a toolkit for building your own bootable Linux CD from your favorite (and possibly customized) distribution. It is more or less an intelligent cp -a / /dev/cdrom (with Linux, it's not that simple, but with Windows, it's impossible). I have created this toolkit because these single-floppy Linux systems have three major drawbacks: floppies are slow, errorprone and always too small.

http://bblcd.berlios.de/
http://developer.berlios.de/project/showfiles.php?group_id=695
http://bblcd.berlios.de/doc/index.html

http://www.linuxlots.com/~fawcett/yard/

http://lists.debian.org/debian-hurd/2001/10/msg00136.html

So you've compiled everything and have a bunch of rpms. Now what do you do with them? You could make a Live CD with them. Here's how:

http://www.web-insights.net/rookery/index.html

Esta es una guía sencilla de cómo hacerse una distribución basada en el sistema Metadistros. No se va a profundizar en cómo funciona o el el sistema mismo, sino en la manera actual más sencilla de hacerlo. Dado que el proyecto no está acabado y anda en plena evolución, lo que aquí se diga es más que probable que cambie en unas semanas. Así que éste documento seguirá esa evolución. Es por ello que le recomiendo que busque la versión más actual del mismo.

https://software-libre.org/cgi-bin/moin.cgi/Meta/en/HowTo
https://software-libre.org/cgi-bin/moin.cgi/Metadistros

http://web.isteve.bofh.cz/deadcd/deadmini/documentation.htm#build

The goal of the catalyst project is to provide a single multi-faceted tool that can reliably build all aspects of a Gentoo Linux release: stage tarballs, GRP package sets, and install CDs.

Our specific development goals for catalyst include the following: ensuring it provides high-quality builds of Gentoo Linux, and for the tool to be easy to use, customize, extend and maintain. The catalyst tool is intended to be used by those who wish to create their own customized versions of Gentoo Linux, or their own customized LiveCDs. Our goal is to make catalyst a powerful tool that's a pleasure to use, and to ensure that the code we write is maintainable and of high-quality. [...]

This document is intended to be a complete reference for all Catalyst targets, spec file options, and all other aspects of Catalyst."

http://www.gentoo.org/proj/en/releng/catalyst/
http://www.gentoo.org/proj/en/releng/catalyst/2.x/reference.xml

http://www.lnx-bbc.org/faq-GAR.html
http://www.lnx-bbc.org/README.html

http://www.t2-project.org/
http://article.gmane.org/gmane.comp.t2.devel/1515
http://www.t2-project.org/about.html
http://www.t2-project.org/packages/

http://packages.debian.org/stable/admin/aboot-cross
http://packages.qa.debian.org/a/aboot.html

mkrboot can also use loadlin to make a floppyless installation possible.

Boot methods supported:

- Loadlin from running DOS/Windows without a floppy
- Loadlin from a FreeDOS bootup disk
- Lilo from one floppy
- Kernel Boot loader from one floppy
- Syslinux from one floppy

http://packages.debian.org/stable/admin/mkrboot
http://packages.qa.debian.org/m/mkrboot.html

LifeBoat has no security. It can be used to repair a broken or forgotten root password. LifeBoat builds a rescue CD by copying some your Linux system components to a CD and making the CD bootable. [...]

LifeBoat can be configured to your needs by adding utilities you need for your system. LifeBoat has an Addons function which you can use to add utilities which inspect and repair components specific to your system, such as RAID or a journaling file system.

LifeBoat will create either a CD-R or a CD-RW at whatever speed you choose.

Once you get LifeBoat configured to your system you can easily burn a new LifeBoat rescue CD. Whenever you make major changes to your Linux system you can quickly burn a new LifeBoat CD to match your latest system.

http://users.rcn.com/srstites/LifeBoat/LifeBoat.home.page.html
http://users.rcn.com/srstites/LifeBoat/downloads/

The scripts were tested using a fully up to date Ubuntu 5.10 install on an AMD 1.9GHZ, with a little over a gig of swap, lots of free space, and 512MB of RAM."

http://stuporglue.com/content/view/29/35/
http://stuporglue.com/downloads/mybuntu.tbz

The plugscript configuration system includes a modular interface, many modules for various tasks, 'mmkcdrom' - an easy tool for recording KNOPPIX CD-ROMs, and something more.

http://rcswww.urz.tu-dresden.de/~holzhey/plugscript/
http://rcswww.urz.tu-dresden.de/~holzhey/plugscript/doc/why_plugscript.html
http://rcswww.urz.tu-dresden.de/~holzhey/plugscript/download

http://alextreme.org/morphix/knoppixhacks/autobuildingmorphix.html
http://www.alextreme.org/phpwiki/index.php/ModuleMaker

Normally you're stuck with the type and amount of applications the creator decided to include, now you can customize the system to fit your needs, by generating on-the-fly compressed modules (layers) including additional software .

The idea is to don't "debase" the Default Debian System, for this pourpose has been designed the USS (The Upstream Salmon Struct).

In this way you'll have a knoppix like HW autodetection and autoconfiguration flavor without affecting the standard system.

DSS can be used to:

* create your own live distribution
* put together a demo disk to show off the power of our favourite OS
* build a portable system to install on external USB/FIREWIRE HD and boot it up.
* backup you system and run it from a CD/DVD
* build a morphix base module

http://www.dsslive.org/mediawiki/index.php/Home
http://www.dsslive.org/mediawiki/index.php/Downloads

http://www.artemio.net/projects/linuxdoc/squashfs/SquashFS-HOWTO.html#mksqoverview

* LiveCD_Druid has a pleasant looking GUI.
* LiveCD_Druid has simple and advanced options.
* LiveCD_Druid feature graphical progress indication.
* LiveCD_Druid has an ever present Default button to revert back.
* LiveCD_Druid includes complete documentation.

The LiveCD's that you create may include:

* Customizable splash screens on the live CD.
* Additional mount points on the live CD to enable hybrid setups.
* Customizable ISO files and sizes.
* Selectivity in the data you wish include or exclude on the live CD.
* Personalization of the user environment on the live CD. [...]

The LiveCD_Druid is quite flexible, this is only recommendations.

* A running Mandriva 2006 system with X.
* Two partitions, one root directory of 5GB or more, a swap partition of 2GB or more.
* Installing the rpm's in the download section. [..]

The LiveCD_Druid is written in Perl, using the Gtk2-Perl and Gnome2-Perl bindings."

http://forgeftp.novell.com//livecd-druid/homepage/index.html

http://trinityhome.org/trk/development.php
http://www.hyguard.com/trk/trkdev-2006-01-03.tgz

Maybe you create your own mini iso with mrxcdram

* ./ramdisk.sh # generate the /boot/ramdisk.gz, with all command defined in ramdisk.db
* ./snapshot.sh # snapshot your current linux system without personal information directories
* ./geniso.sh # create bootable iso using the /boot/ramdisk.gz and current /vmlinuz kernel"

http://murix.sourceforge.net/modulo-mrxcdram.php
http://sourceforge.net/project/showfiles.php?group_id=35615&package_id=91455

It can be used at for easy creation of (non-exhaustive): advanced Live-rescue, live-desktop, autoconfiguring DHCP client and LAN, gateways, NAT-box, Distribution specific install-CD (binaries and or sources based), cluster nodes, media-box etc..."

http://norean.freecontrib.org/norean/#Nbed
http://norean.freecontrib.org/norean/SVN/snapshot/norean/current/nbed/

Garfio es un sistema e infraestructura, que te permite crear una livecd instalable de tu distribución preferida, en cuestión de minutos."

http://www.garfio.org.ar/

MKDanix - Build your own live CD today!
Document Actions

* Send this page to somebody
* Print this page

Having your own custom live CD rocks!
Have you ever dreamed to have your own custom live CD?

Imagine you can :

* build the cd noninteractively (even newbies can do it),
* use latest debian archives from stable or unstable debian suite,
* add custom set of packages,
* add custom texts and images,
* add custom configuration scriptlets."

http://www.danix.org/Documentation/mkdanix/
http://unix.freshmeat.net/projects/mkdanix/

Currently 4 types of images are supported:

* Floppy images (1.2M, 1.44M or 2.88M)
* Knoppix-like image (one per CD)
* Kernel-binary images (e.g. memtest86)
* Windows XP Recovery Console

Note that using more than one Knoppix image is currently not possible, but may be in a future version. And of course you can't use the original 700MB Knoppix version (unless you use 800MB CDR blanks). See below for some smaller alternatives.

MBCD is licensed under the GNU GPL
(http://www.gnu.org/copyleft/gpl.html)

http://stephan.walter.name/MBCD
http://stephan.walter.name/wiki/images/3/32/Mbcd-README

http://www.ibiblio.org/pub/Linux/system/recovery/!INDEX.html
http://www.ibiblio.org/pub/Linux/system/recovery/

The goal of the Grand Unified Installer project, is to create one CD, which can help install Linux/Windows on a single hard disk, and also function as a rescue disk for these operating systems. In addition, this CD can also be used to backup the harddisk to tape, and restore the hard disk from the tape. The starting point is a very useful utility called ISOLINUX, which functions as a boot loader for CD based Operating Systems."

http://people.cs.uchicago.edu/~gmurali/gui/

Non-root users construct, develop, test and run all types of distributions with Root Methods (Yard, etc.) and user-mode-linux, then finish with a Boot Method (2-disk compression, etc). Make_debian yard template creator provided for Debian users."

http://freesoftwarepc.com/projects/gbootroot/
http://sourceforge.net/projects/gbootroot

The root filesystem isn't made by this program, but there lots of compressed filesytems out there to use (see rest of FAQ). This program is patterned after mkrboot, but unlike mkrboot it creates an unique bootdisk and a separate root disk."

http://freesoftwarepc.com/projects/bootroot/

The [...] 6 big groups of stages: 1) Install base system: the 'base' stages build a basic system on a directory, downloading and installing some packages (base_*) 2) Install live CD-related software: the 'knoppix' stages install some packages and add support for auto configuration and booting (they're called knx_* because they're a group of Knoppix packages) 3) Install final contents: the 'einam' stages add the real usefull contents to the directory, so here's the big list of package contents (the stages are named einam_* because 'dscdbuilder' was first written for use on the build of Einam CDs) 4) Miscelaneous operations: here come some extra 'knoppix' stages that need to be run after any package installation 5) Build initrd image: the 'miniroot' stages are used to build the initial root filesystem to mount and boot the CD as a live CD (minirt_*) 6) Create an ISO"

http://lists.debian.org/debian-knoppix/2005/01/msg00010.html
http://lafarga.upc.edu/scm/cvsweb.php/dscdbuilder/?cvsroot=gnupcix
http://lafarga.upc.edu/scm/cvsweb.php/dscdbuilder/README?cvsroot=gnupcix

Essentially we do a cdebootstrap, install all the packages we need, create a squashfs, setup syslinux and make an ISO."

http://www.gnewsense.org/Builder/Builder
http://www.gnewsense.org/LiveCD/LiveCD

You have exactly the same tools that developers use. Hope this may help you customize and make your own live CD quickly and easily."

http://pud-linux.sourceforge.net/en/bfs.htm
http://download.penkia.org/build-livecd-current.tar.gz

https://www.redhat.com/archives/fedora-livecd-list/2006-September/msg00079.html
Pilgrim Build System README

The Source-Kit consists of injectors project files and gives you the opportunity to modify and tamper the filesystem as you like.

Get Injector Linux Source-Kit (5MB)

http://injector.sourceforge.net/
http://downloads.sourceforge.net/injector/injector_sourcekit-1_4.tar.gz

eMoviX, MoviX and MoviX² are tiny GNU/Linux distributions dedicated to multimedia playback (e.g. movies, music and slideshows).*

MoviXMaker-2 includes disk image customization possibilities such as :
- Choosing your boot help language, subtitle fontset and boot label.
- Including additionnal files in the disk image.
- Specifying values for some MoviX parameters¹.

¹ Here are the currently (version 0.8.2) supported MoviX parameters:
- movix/mplayer menu language (language),
- keyboard layout (kb),
- tv region (region),
- remote control (remote),
- loop,
- random,
- shutdown (shut),
- reboot,
- eject,
- dma,
- extra_mplayer_options,
- unwanted_mplayer_options.

MoviXMaker-2 is available on Debian GNU/Linux official mirrors."

http://savannah.nongnu.org/projects/movixmaker/
http://packages.debian.org/stable/utils/movixmaker-2

Once you have successfully performed make devel you can then start removing RPMS and adding your preferred packages, assuming you have the RedHat Fedora Core distribution CDs."

http://os.cqu.edu.au/adios/adk.html

http://www.gpstudio.com/stux/remastering.html#liso

http://kiwi.berlios.de/
http://en.opensuse.org/KIWI
http://developer.berlios.de/projects/kiwi/

Live-helper is extremely flexible, allowing interested parties to create their own system completely specific to their needs, including support for custom package lists, kernel parameters, encryption, additional commands to configure the live system etc."

http://wiki.debian.org/Live-helper
http://lists.alioth.debian.org/pipermail/debian-live-devel/2007-March/000998.html

https://sourceforge.net/projects/kickstart-tools/

Our scope includes all manner of LiveCD creation. LiveCD tools should provide a robust enough environment for the Ubuntu developers to generate the official CDs from them. Required functionality includes:

* Creating LiveCDs based on templates, such as bare minimum installing ubuntu-minimal
o Selects repositories
o Selects default packages

* Adjusting the packages on the LiveCD by adding or removing through a Synaptic-like interface

* Adding files directly to the LiveCD just before finalizing

* Modifying the default X11 environment
o Execute a GNOME, KDE, or XFCE log-in in Xnest
o Save the home directory as the /etc/skel

* Saving and updating LiveCD templates
o Save the package list, /etc/skel, and additional files
o Update by adjusting repositories and performing upgrades or dist-upgrades

* Adding the Ubiquity installer"

https://wiki.ubuntu.com/LiveCDCreator
https://blueprints.launchpad.net/ubuntu/+spec/livecd-creator

Default X configuration includes the Xvnc server, allowing remote control of the target system. Using Xvnc eliminates the necessity of a graphics card in the target system, at the cost of requiring a network interface. Options are also provided for conventional X servers.

You can build a minimal floppy disk size compressed image of 1.22Mb and/or an X capable compressed image of 3.7Mb (these are functional sizes, not minimums. Depending on your linux and selected applications, the size can vary wildly). This does not include a bootable kernel which you will have to provide.

Be forewarned, this is NOT a distribution. This is a framework for creating your own distribution."

http://modest-proposals.com/Hacklin.htm
http://modest-proposals.com/README.txt

Installation media would be the media you use when you install a machine to run Fedora (the CDs and DVDs the Fedora Project releases every 6 months). You cannot do anything with installation media other then install a system to run Fedora.

Live media on the other hand allow you to run Fedora, without the need to install it on your system first. Actually, the operating system is installed on a CD, DVD or USB Thumbdrive, and you let your computer boot that operating system."

http://revisor.fedoraunity.org/

https://hosted.fedoraproject.org/projects/pungi

mkimage is your friend for image creation. This script creates a
archive of your current system.

The output file is an imagefile that can be used to replace the plain "stock" ariane image. If you are sure that your system boots, put it on the CD as linux.tgz in the /bootcode directory and boot from the CD (see ArianeDiskCreation).

mkimage excludes certain parts of the running system you don't want to have in the image. Hardcoded exclusion are /proc/*, /tmp/* and /var/tmp/* since the contents of these directories simply interferes with the idea of a fresh installed system. More exclusions can be configured in the file /sbin/ariane.d/etc/image.exclude. This file contains filenames (with or without shell wildcards) that should be excluded from the image, one per line. There are already some exclusion defined because there is more to drop for a clean image than just the directories above."

http://quietsche-entchen.de/cgi-bin/wiki.cgi/-ariane,/ArianeImageCreation#M1

live-initramfs is a hook for the initramfs-tools, used to generate a initramfs capable to boot live systems, such as those created by live-helper(7). This includes the Debian Live isos, netboot tarballs, and usb stick images.

At boot time it will look for a (read-only) media containing a "/live" directory where a root filesystems (often a compressed filesystem image like squashfs) is stored. If found, it will create a writable environ‐ ment, using unionfs, for Debian like systems to boot from."

http://wiki.debian.org/DebianLive/live-initramfs
http://wiki.debian.org/DebianLive/live-initramfs-manpage

http://www.threatmind.net/secwiki/UbuntuTrinux
http://code.google.com/p/ubuntutrinux/

After having gone through the LFS and BLFS books more than 2 or 3 times, you will quickly appreciate the ability to automate the task of compiling the software you want for your systems.

The goal of ALFS is to automate the process of creating an LFS system. It seeks to make the process of building LFS easier and more efficient while still providing flexibility by granting the user total control and insight into the compilation and management of his LFS build."

http://www.linuxfromscratch.org/alfs/

Live-helper is a collection of programs that can be used to build Debian Live system images. The philosophy behind live-helper is to provide a collection of small, simple, and easily understood tools that can be used in your own program to automate building of a Live system.

A typical program that uses live-helper will call several live-helper commands in sequence. Live-helper commands are all named with a "lh_" prefix.

Homepage:

This package contains the gui frontend.

Tags: Implemented in: Python"

http://packages.debian.net/source/sid/live-magic
http://packages.debian.net/unstable/live-magic

1. "Try before you burn" You can download extensions and try them out before you commit to making an iso and burning.

2. "Construction Set" by downloading in parts, you truly have a construction set method. This makes it easier for a slow modem users to be able to take advantage by not having to download a large single mydsl.iso

3. "Privacy" By makeing the iso locally, you are not "sending" private information to a website only to have to download the results back. This is where the myconf.tar.gz comes into play. This is your "personal" and "private" configuration including passwords, etc.

4. "No double down" You already have the base iso and have proved that it works on your system, so you don't have to download it again only this time MUCH bigger. Also, you already have your local "proven" collection of extensions

5. "The Sky 's the Limit" I know of one user, Ke4nt, who uses the mkmydsl script to make DVD sized mydsl.iso. Imagine having to download DVD sized images."

http://damnsmalllinux.org/wiki/index.php/Mkmydsl

This is the package used by the Gibraltar project to create the initrd images used for booting from CD-ROM or USB sticks. The bootable CD-ROMs or USB mass storage devices are actual live CD-ROMs respective live filesystems. That is, the root file system is the CD-ROM or an image on the USB device, ramdisks are the only things needed for operation without a hard disk. Although a harddisk can be used for e.g. storing log files permanently or when the machine acts as a proxy server.

Given a kernel image and the corresponding modules, it creates a complete boot image that can be written to floppy or be used as El Torito image for a bootable CD-ROM. Additionally, it is possible to create an initrd image to be used on a USB stick (e.g. with syslinux). Upon bootup, the initrd image will try to locate an ATAPI CD-ROM drive or a USB mass storage device. When this does not succeed, it auto-probes for SCSI adapters and tries to locate SCSI drives. It also works when multiple CD-ROM drives are installed in the system by checking if the inserted CD is the correct one for booting.

The package can be of use to developers and packagers who want to create their own bootable, live Debian CD-ROM or bootable, live Debian USB stick. It will probably not be of any use to others."

http://packages.debian.org/mkinitrd-cd
http://packages.debian.org/sid/mkinitrd-cd
http://www.mayrhofer.eu.org/mkinitrd-cd

The Makefile ought to contain everything you need to build the bootimage. For hacking, an optional script "please" helps you do things with the kernel tree. [...]

The toolchain is based on uClibc - http://www.uclibc.org/ [...]

RAMDISKIMAGE USAGE

The ramdisk that is built by this Makefile has the following usage:
* lots of functions are defined in /etc/functions -- see by yourself
* you may add your own additional functions in /etc/functions.local
* Use "standalone" to configure linux for standalone usage with the ramdisk.
* Use "rootfs" to chain-boot into your first Linux partition on CF.
* The ramdisk will automatically attempt to "rootfs" at startup, unless you
create a file or directory named "noautomount" in your WinCE partition.
* We have mkfs.minix and fsck.minix in busybox. No ext2 support, sorry.
To build an ext2 filesystem, you'll have to use a CF reader on your PC,
or to NFS mount a filesystem with your ext2 utilities.
* Busybox is packed up with lots of functionality. Check it out!
* To free the memory occupied by the ramdisk, your rootfs will need to run
the program blockdev, which is part of the util-linux debian package.

* With kernel 2.6, you must use cat /proc/modules instead of lsmod"

http://cvs.sf.net/viewcvs.py/jornada820/bootimage
http://cvs.sf.net/viewcvs.py/jornada820/bootimage/README

The guide allows easy publishing and including of new a boot file, background, startup index.html, and desktop on your custom DVD. [...]

Boot from a KNOPPIX KANOTIX CD, get grow-knoppix, save to /home/knoppix. right click --> Properties --> Permissions --> put X in Exec boxes, click to run"

http://grow-knoppix.berlios.de/
ftp://ftp.berlios.de/pub/grow-knoppix/ (download)
http://wiki.kanotix.net/CoMa.php?CoMa=Grow_Knoppix

draklive's philosophy is to keep the live distribution as close as possible to a normal Mandriva Linux distribution. All specific live tweaks are done in a very tiny initrd script. Since this one is generated on the fly, it's very small, and gets quite easy to debug.

The list of drivers included in the initrd is adjusted during the live distribution creation, according to the medium type. draklive uses the DrakX libraries to have an up-to-date drivers list. [...]

Once the initrd script is done booting, the root device will be used transparently by the distribution, without any additional tricks.

Hardware detection is done with harddrake, providing a reliable integration.

Features

* live CD
* live distribution on USB key
* easy to test over NFS
* uses the Mandriva installer to create the live system
* fully read-write live system (using unionfs)
* automatic hardware configuration (using harddrake)
* generic code structure to make new technical choices usable quickly"

http://qa.mandriva.com/twiki/bin/view/Main/DrakLive
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/gi/tools/draklive

If you have installed the Udpcast image generator RPM, the boot image generator is located in /usr/lib/udpcast/makeImage, and needs the following additional packages to be installed:

* mknbi (only needed for generating etherboot images), can be downloaded from Etherboot's site
* syslinux (for PXE, and CD-Rom. For floppy, the relevant files are already included with the image generator itself)

These additional packages are already supplied with most major distributions (SuSE, Redhat, Mandrake, Debian, ...)"

http://www.udpcast.linux.lu/mkimagedoc.html

But since every testing project is unique, we strive to structure Crucible as a set of distinct tools that can be used independently or in other frameworks. Thus, if you're working on your own test harness, we hope you can cherry pick something of use to you from Crucible. :-)

Crucible has been used for doing automated testing of:

* NFSv4 kernel code - client / server multi-machine testing
* Inkscape - build, make check
* Cairo - build, make check
* Crucible - of course [...]

It was created because while there are a lot of automated test harness out there, none were found that could both do kernel booting and allow for orchestrating testing across multiple machines. The Samba build farm was selected as a starting point because the code was simple and relatively clear.

A key design goal of Crucible is to keep its focus as *limited* as possible. "Do one thing, and do it well." Many test harnesses try to do _too_ much, and in the process become too cumbersome and unweildy to be of real use for doing real world testing. I need the ability to easily break things apart and run things in isolation, so I can dig my hands in and get a good grasp on the bug. Also, every test project is unique, so by keeping Crucible's scope limited, it makes it easier to reuse for a wide variety of test harness needs.

Crucible is implemented mainly in Bash. This was done not because I love bash (I actually much prefer Perl), but because bash is reasonably easy to debug, it's widely known, and fairly easily learned. Much of what Crucible does is just file and process manipulation, and bash is pretty good at that. For more complex tasks, or for functionality that bash isn't that good at, I code a tool in a better language and exec that."

http://crucible.sourceforge.net/

Currently it allows you to:

* Create bootable LiveCD with predefined languages based on original Ubuntu/Kubuntu live CD using wizard with GUI.

* Build live CD with special features using scripts. It is possible to customize root filesystem (for example install/remove packages), ISO contents (add/remove docs, change names) and initrd (add modules to boot, change boot sequence)."

http://uck.sourceforge.net/
http://sourceforge.net/projects/uck/
http://lichota.net/~krzysiek/projects/ubuntu-livecd-customization/

http://www.dreamlinux.com.br/english/saiba-tutor.html

Building the new system in short:

* user is selecting programs from web site which will be added to his system
* next he downloads specially prepared pack of scripts and runs it. Scripts will prepare iso image which user can burn on CD/DVD
* user burns an iso image and booting the new system from CD/DVD [...]

Project status

Currently project is at testing stage. The quickly test the latest working version of scripts by generating live from WWW (see links below). You can browse the latest source code with Your WWW browser from adress:

http://svn.aurox.org/cgi-bin/viewcvs.cgi/scripts/livecd/

or download the latest SVN version by typing:

svn co http://svn.aurox.org/svn/aurox/scripts/livecd/branches/kwojnowski/

You can also browse automaic home generation scripts written by Dariusz Gut from Aurox Core Team by typing:

svn co http://svn.aurox.org/svn/aurox/scripts/generate-live-custom-home/
http://www.aurox.org/en/

In the section 1 explained like one is installed a Debian basic system by Qemu and entpakt with lomount. I have myself consciously approximately debootstrap decided because I the opinion am which one the expiration with Qemu better understand. In addition the Qemu is simpler variant to handle. They can download the result of section 1 in form of a tar.bz2 Archives (121 MT).

In the section 2 we come then on the point. We provide step by step own live CD. The finished live CD can download you here (227,9 MT).

In the section 3 I explain as simply and fast one MINIMIX rem asters and to install can.

This HOWTO is constantly updated and improved, if someone has an idea like one it make better could please answer-gives.

http://www.minimix.ch/debian-live/ (Allemand)
http://www.minimix.ch/debian-live/files/minimix-core.tar.bz2
http://translate.google.com/translate?hl=en&sl=de&u=http://www.minimix.ch/debian-live/

http://soleup.eup.uva.es/mediawiki/index.php/TCOS/en
http://soleup.eup.uva.es/tcos/
http://soleup.eup.uva.es/tcos/screenshots/

* cdebootstrap a debian standard system in a subdirectory.
* apt-get install the linux kernel image together with squashfs, unionfs modules and the casper initramfs image generator.
* Install the proper flavour packages with right preseeded questions.
* Clean things up
* Compress this rootfs as a squashfs image.
* Copy out the kernel and initramfs image.
* Assemble the iso, hd or netboot final image."

http://live.debian.net/wiki/live-package

LinuxCOE is licensed under the GNU General Public License.

LinuxCOE System Designer is a CGI-based web application that allows a user to create localized network boot images. To get started, download System Designer and follow the documented installation and configuration procedure.

Features :

* A CGI-based network install image generator
* A profile manager to store custom install images
* A retrofit process to configure machines to use LinuxCOE processes for patch and package management

http://linuxcoe.sourceforge.net/
http://linuxcoe.sourceforge.net/snapshot/
https://sourceforge.net/project/showfiles.php?group_id=144250

Install any Windows, Linux, BSD or Solaris, and test live-CDs in a safe environment.

Filling in only four configuration fields will create a downloadable virtual machine. [...]

You can install the following operating systems in VMware Player:

* Any of your favourite Linux distributions, be it Slackware, TurboLinux, Mandrake, Linspire, Ubuntu, Debian, Gentoo, SUSE/Novell or Redhat.
* Any version of Novell Netware.
* Any version of FreeBSD.
* Any version of Sun Solaris for x86.
* You can even install Darwin!
* Most other operating systems for the x86 platform will also run in VMware Player.

Il existe 3 différentes versions, chacune tenant sur une disquette 1722 Ko. Elles permettent respectivement de créer un serveur Samba, FTP ou NFS. La version NASLite+ permet d'établir ces trois serveurs, mais est commerciale.

Liens externes 

• (en) Site officiel
• (en) Projet sur Freshmeat

• libncurses5-dev
• libreadline4-dev

tar xvzf pam_usb-0.3.2.tar.gz
./configure
make
make install

usbadm keygen [/path/to/mounted/usbmemorystick] [username] [bits]

more .auth/[username].[hostname]

auth       required   pam_usb.so fs=vfat check_device=-1 check_if_mounted=-1 force_device=/dev/sda log_file=/var/log/pam_usb.log

vi /var/log/pam_usb.log

#
# The PAM configuration file for the Shadow `login' service
#
# NOTE: If you use a session module (such as kerberos or NIS+)
# that retains persistent credentials (like key caches, etc), you
# need to enable the `CLOSE_SESSIONS' option in /etc/login.defs
# in order for login to stay around until after logout to call
# pam_close_session() and cleanup.
#

# Outputs an issue file prior to each login prompt (Replaces the
# ISSUE_FILE option from login.defs). Uncomment for use
# auth       required   pam_issue.so issue=/etc/issue

# Disallows root logins except on tty's listed in /etc/securetty
# (Replaces the `CONSOLE' setting from login.defs)
#auth       requisite  pam_securetty.so

# Disallows other than root logins when /etc/nologin exists
# (Replaces the `NOLOGINS_FILE' option from login.defs)
#auth       requisite  pam_nologin.so

# This module parses /etc/environment (the standard for setting
# environ vars) and also allows you to use an extended config
# file /etc/security/pam_env.conf.
# (Replaces the `ENVIRON_FILE' setting from login.defs)
auth       required   pam_env.so

auth       required   pam_usb.so fs=vfat check_device=-1 check_if_mounted=-1 force_device=/dev/sda log_file=/var/log/pam_usb.log

# Standard Un*x authentication. The "nullok" line allows passwordless
# accounts.
@include common-auth

# This allows certain extra groups to be granted to a user
# based on things like time of day, tty, service, and user.
# Please uncomment and edit /etc/security/group.conf if you
# wish to use this.
# (Replaces the `CONSOLE_GROUPS' option in login.defs)
# auth       optional   pam_group.so

# Uncomment and edit /etc/security/time.conf if you need to set
# time restrainst on logins.
# (Replaces the `PORTTIME_CHECKS_ENAB' option from login.defs
# as well as /etc/porttime)
account    requisite  pam_time.so

# Uncomment and edit /etc/security/access.conf if you need to
# set access limits.
# (Replaces /etc/login.access file)
account  required       pam_access.so

# Standard Un*x account and session
#@include common-account
@include common-session

# Sets up user limits, please uncomment and read /etc/security/limits.conf
# to enable this functionality.
# (Replaces the use of /etc/limits in old login)
# session    required   pam_limits.so

# Prints the last login info upon succesful login
# (Replaces the `LASTLOG_ENAB' option from login.defs)
#session    optional   pam_lastlog.so

# Prints the motd upon succesful login
# (Replaces the `MOTD_FILE' option in login.defs)
#session    optional   pam_motd.so

# Prints the status of the user's mailbox upon succesful login
# (Replaces the `MAIL_CHECK_ENAB' option from login.defs). You
# can also enable a MAIL environment variable from here, but it
# is better handled by /etc/login.defs, since userdel also uses
# it to make sure that removing a user, also removes their mail
# spool file.
#session    optional   pam_mail.so standard noenv
@include common-password

Authentication token is no longer valid; new one required.

1. blame someone else
2. reboot into single user mode.I have GRUB installed as bootmanager so in the GRUB menu upon boot I edited the line starting the kernel and added the word "single" to it. Now your system will boot in single-user mode and you can login and repair the damage.

GRUB supports the no emulation mode in the El Torito specification(5). This means that you can use the whole CD-ROM from GRUB and you don't have to make a floppy or hard disk image file, which can cause compatibility problems.

For booting from a CD-ROM, GRUB uses a special Stage 2 called `stage2_eltorito'. The only GRUB files you need to have in your bootable CD-ROM are this `stage2_eltorito' and optionally a config file `menu.lst'. You don't need to use `stage1' or `stage2', because El Torito is quite different from the standard boot process.

Here is an example of procedures to make a bootable CD-ROM image. First, make a top directory for the bootable image, say, `iso':

$ mkdir iso

Make a directory for GRUB:

$ mkdir -p iso/boot/grub

Copy the file `stage2_eltorito':

$ cp /usr/share/grub/i386-pc/stage2_eltorito iso/boot/grub

If desired, make the config file `menu.lst' under `iso/boot/grub' (see section 5. Configuration), and copy any files and directories for the disc to the directory `iso/'.

Finally, make a ISO9660 image file like this:

$ mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot \
    -boot-load-size 4 -boot-info-table -o grub.iso iso

This produces a file named `grub.iso', which then can be burned into a CD (or a DVD). mkisofs has already set up the disc to boot from the boot/grub/stage2_eltorito file, so there is no need to setup GRUB on the disc. (Note that the -boot-load-size 4 bit is required for compatibility with the BIOS on many older machines.)

You can use the device `(cd)' to access a CD-ROM in your config file. This is not required; GRUB automatically sets the root device to `(cd)' when booted from a CD-ROM. It is only necessary to refer to `(cd)' if you want to access other drives as well.

It's often useful to make an image of either an entire hard disk or an entire partition. One reason is to duplicate an installed system onto another PC (probably over a network connection); another is to make a backup of your complete hard disk including every aspect of the installed operating systems, which you can restore if you have to replace your hard disk or if you screw things up. Typically it's useful to be able to transfer these images over the network to another machine, although you may want to save images onto a different partition or hard disk.

Commercial tools to do this job include Norton Ghost, Acronis TrueImage (which now seems to have overtaken Ghost in usefulness), and DriveImage (which I believe can't save over the network). Nowadays these tools are quite sophisticated and can even work from within Windows on mounted filesystems and do incremental block-level backups. There is a open source Linux program called partimage which is similar to Ghost, but I prefer to make backups using basic tools which I know will always be to hand, and in a pure format which I understand.

My preferred solution in some situations is to use raw linux commands. The backup technique uses linux, but you don't have to have linux installed on your computer to do this, and you can use this technique to backup partitions containing any filesystem.

IMPORTANT NOTE: I can offer no guarantees whatsoever that the methods detailed on this page are correct or reliable. I've used them on a few occasions without problems, but I have not exhaustively tested this method, and it could be that in some situations it does not perform as expected. Also, these instructions are designed to give pointers and suggestions. They do not comprise step-by-step instructions which you can blindly follow without understanding them. Many of the commands described here are very likely to trash the contents of your hard disk if you don't understand them properly. Use at your own risk!

Copying partitions under linux

When making an image of a disk/partition, you don't want the drive contents changing under you, so the partition(s) must be either unmounted or mounted read-only. The latter possibility means that you can probably drop down to single-user mode and remount essential partitions read-only in order to backup a linux system. If you do this, make sure you have a way of restoring the backup which doesn't depend on already having the OS installed!

A more general method is to boot from CDROM into linux without using the hard disk at all, for example using Knoppix. It's brilliant at autodetecting hardware.

Once you have a linux running, the basic technique is to use the dd command to read the hard disk device (or one of its partitions). The output of dd can be written to a file (perhaps to an external hard disk you have mounted) or piped over the network to another instance of dd on a remote machine. Note that there is a neater way of backing up NTFS partitions: see below.

Example:

dd if=/dev/hda1 bs=1k conv=sync,noerror | gzip -c | ssh -c blowfish user@hostname "dd of=filename.gz bs=1k"

This instructs dd to read the contents of /dev/hda1 (the first partition). conv=sync,noerror tells dd that if it can't read a block due to a read error, then it should at least write something to its output of the correct length. Even if your hard disk exhibits no errors, remember that dd will read every single block, including any blocks which the OS avoids using because it has marked them as bad. So don't be too surprised if dd seems to struggle to read some blocks. (But see the next section for a better way of handling this situation).

bs=1k sets the block size to be 1k. I'm not quite sure what the optimal value is, but it needs to be no larger the the block size for the disk, otherwise a bad block may mask the contents of a good one. 1k is a safe bet.

In the above example the output of dd is piped through gzip to compress it. We then pipe the compressed data stream over an ssh connection to another linux machine (which may also be running Knoppix - see Knoppix notes below). If you wanted to write straight to a local file, you could either just add of=filename to the first dd command (to write an uncompressed image), or if you want to compress it, just redirect the output of the gzip to a filename.

Continuing with our explanation, the -c blowfish option to ssh selects blowfish encryption which is much faster (useful since we're sending tons of data) than the default. Finally another dd command is invoked on the remote machine to read the data stream and write it to a file there. Alternatively you could pipe it through gunzip -c and write it straight to a partition on the remote machine instead of to a file.

Note that, as long as its not compressed, you should be able to mount a file containing a single partition's image using a loopback device in linux. (With a little more jiggery-pokery to find the correct offset, you can also mount partitions within a whole-disk image; see here).

What to do if the disk is damaged and dd takes forever?

Tobias Wolf pointed out "dd_rescue, which deals a lot better with bad blocks than plain dd. A useful helper script to dd_rescue is dd_rhelp, which postpones re-reading bad blocks to the very end because it can be a struggle to retreive something from them".

Steve Holmes reports that dd with conv=sync,noerror doesn't correctly image disks with LVM2 Logical Volumes. I haven't investigated this. He also points out GNU ddrescue ( not the same as dd_rescue mentioned above) which looks useful. According to Steve, ddrescue works finewith LVM2, and some people seem to suggest it's generally superior to dd_rescue.

Restoring partitions

The restore procedure is fairly similar. For example, on the machine with the image on it, you might do something like:

dd if=filename.gz | ssh -c blowfish root@deadhost "gunzip -c | dd of=/dev/hda1 bs=1k". This assumes you have linux (e.g. Knoppix) running on the target machine with an ssh server running. See 'Knoppix tips', below. Note that you should not include conv=sync,noerror in the restore dd - doing so can, in certain situations, corrupt the data being written, since it instructs dd not to wait for more data to arrive from the network or filesystem if a whole block isn't available.

The partition needs to already exist before you do this, and needs to be large enough to take all the data. If it's too big, that doesn't matter, you'll just be wasting space at the end. You should then be able to grow the filesystem to fill that extra space. For ext2 filesystems, try using the ext2resize tool. You may also be able to persuade the partition editing tool parted to do this, since it can handle resizing most filesystems.

Copying an entire hard disk

You can simply use "/dev/hda" as the source (target) to backup (restore) an entire hard disk image, including partition table, MBR and all partitions. This will certainly work if the hard disk being written to is identical to the one the image was made from. I think it will generally also work in other situations as long as the destination disk is larger than the source. I'm not 100% sure that this is always true - partition table entries do contain information in C/H/S (i.e. disk geometry dependent) units, which may be used by the boot loader even if the OS uses LBA. (Links to some gory details about partition table formats are at the end of this page).

If you do make an image of a whole disk, I strongly recommend that you also store extra information about the drive geometry which is necessary in order to interpret the partition table stored within the image, should you need to do that. The most important thing is the cylinder size. Best thing is just to grab a copy of the information fdisk can tell us: fdisk -l /dev/hda > hda_fdisk_information. Keep that file with the image. For good measure, why not get the same information as sfdisk displays it: sfdisk -d /dev/hda > hda_sfdisk_information

Knoppix tips

To become root in knoppix, just use sudo su -

If you are using Knoppix as a destination machine in one of these examples, you'll need to start up its ssh server. A command to do so is on the KDE menus; otherwise /etc/init.d/sshd start (as root) should do the trick. You'll then need to set a password for root so you can login remotely (sudo passwd root).

Knoppix tries to acquire an IP address by DHCP, so if you have a DHCP server on your network you can just find out the IP addresses of the machines (e.g. with ifconfig) and use those in place of hostnames in the ssh commands. If you don't have a DHCP server running on your network (or you're connected two machines directly together by crossover cable), you should be able to manually assign IP addresses using something like ifconfig eth0 192.168.x.y.

Reducing the storage space required

One of the disadvantages of the dd method over software specifically designed for the job such as Ghost or partimage is that dd will store the entire partition, including blocks not currently used to store files, whereas the likes of Ghost understand the filesystem and don't store these unallocated blocks. The overhead isn't too bad as long as you compress the image and the unallocated blocks have low entropy. In general this will not be the case because the emtpy blocks will containing random junk from bygone files. To rectify this, it's best to blank all unused blocks before making the image. After doing that, the unallocated blocks will contain mostly zeros and will therefore compress down to almost nothing.

A slightly clunky way to do this is to mount the partition, then create a file of zeros which fills the entire disk, then delete it again. e.g:

dd if=/dev/zero of=delme bs=8M; rm delme

It's worth doing this regardless of the type of filesystem in use. But don't do it if you suspect the filesystem may be corrupt, as you'll lose the ability to 'recover' lost files.

At the time of writing there is no reliable write support in the Linux NTFS drivers, so you won't be able to use this zeroing technique on an NTFS partition. However, ther are other ways (see below) of efficiently backing up NTFS partitions.

Backing up the MBR (Master Boot Record)

If you save copies of some or all of your partitions individually, and want to be able to use them to restore a working system, you'll also need to backup and restore the MBR and partition table. (The same caveats apply as discussed above about whether partition tables can be restored onto a disk of a different size).

Backing up the MBR:

dd if=/dev/hda of=backup-of-hda-mbr count=1 bs=512

This stores the first 512 bytes of the disk (contianing the MBR and the primary partition info - i.e. the first four primary entries) into the file "bcakup-of-hda-mbr" which you can then copy to somewhere safe.

To restore (be careful - this could destroy your existing partition table and with it access to all data on the disk):

dd if=backup-of-hda-mbr of=/dev/hda

If you only want to restore the actual MBR code and not the primary partition table entires, just restore the first 446 bytes: dd of=/dev/hda if=backup-of-hda-mbr bs=446 count=1. (Those first 512 bytes are 446 bytes of MBR, then 64 bytes of primary partition table).

Backing up the extended partition table

sfdisk -d /dev/hda > backup-hda.sfdisk

(sfdisk is in the util-linux package. I think it's in Knoppix.)

Restore (ditto the above warning):

sfdisk /dev/hda < backup-hda.sfdisk

(then reboot)

I also recommend making a record of the partition table details as displayed in whatever disk partitioning program you like to use, and also as displayed by fdisk -l. Could be handy if you find yourself needing to repartition the disk by hand in preparation for restoring some images of individual partitions.

Linux swap partitions

Somebody asked me how a linux system knows which partitions to use as swap partitions - this is of course an issue if you're restoring a linux partition to a new disk and need to re-create the swap partition for it. The answer is that the swap partition should be listed in /etc/fstab, e.g.:

# <file system> <mount point>   <type>  <options>   <dump>  <pass>          
/dev/hda6       none            swap    sw          0       0

During bootup, one of the init scripts runs swapon -a which activates all swap partitions listed in /etc/fstab.

I imagine that if a swap partition listed in /etc/fstab isn't actually found to be of the correct partition type (or isn't initialised), then the system will ignore it. So it should be safe to boot the restored system even if the swap partition information in /etc/fstab is incorrect, and then amend it to point to a swap partition you've created and run swapon -a.

Backing up and restoring NTFS partitions

Alternative to ssh

File-level backup techniques

Backing up entire partitions or disks is most useful when replacating systems across hard disks or when backing up partitions containing operating systems which are otherwise hard to fully backup. For more every-day backups of your data, a file-level method is more appropriate. Here are some handy tools for doing backups over a network to a remote machine in various clever ways:

• rsync
• unison
• rdiff-backup
• duplicity

Random technical details

Anders Lennartsson sent me this information, which doesn't directly affect any of the above notes, but could be useful to know if trying to reconstruct partition tables by hand or whatnot:

Sectors on harddrives normally have 512 bytes each. To find out how many sectors there are in one partition one can use for instance cfdisk. After changing the units by typing a "u" cfdisk reports the number of such sectors. However, for obscure historic reasons, the partition data doesn't start until sector 64. Thus the numbers of sectors obtained by dd when specifying for instance if=/dev/hda1 is the number of sectors seen in cfdisk for this partition, minus 63. I don't remember exactly how (linux) fdisk does report the numbers.

Page about recovering disks containing ext2 filesystems when you don't know the partition table.

Details on how partition tables are stored: here and here.

Program which tries to find partitions even if partition table is damaged: TestDisk