Differences between revisions 6 and 7
Revision 6 as of 2009-09-26 09:36:49
Size: 7560
Comment: describing extlinux - yet unconfirmed if this is indeed working
Revision 7 as of 2009-09-26 10:14:43
Size: 7577
Comment: addition
Deletions are marked like this. Additions are marked like this.
Line 130: Line 130:
   umount /proc

This writeup is still experimental, it may nonetheless be useful for some.

Well, the term "LiveCD" is somewhat historic. But we all know that we basically mean a

Preinstalled portable Debian Med software stack

The motivation for this effort is to bring the packages offered in Debian even more closely towards a direct usability. This may be via your USB stick, a local/remote virtual image or just a better collaboration via a completely homogeneous infrastructure.

This page was put up to discuss pros and cons for various ways to prepare such a LiveCD. Points for discussion are

  • selection of packages
    • the adaptation of those selection for the various media
    • the influence that this selection may have on the description of tasks in Debian Med
  • extra efforts that may be beyond main Debian
    • integration of public data
    • integration of educational material
  • most suitable tool to prepare the LiveCD
  • who does what, what folks external to the core of Debian can we get involved

Selections for Scenarios

All selections shall be additive.

Scenario

Selection

Comment

development happens on machine

build-essential|med-bio-dev

machine is worked with locally

med-bio

features many programs with GUI

machine is for computations only

'app list'

GUI-free sub-task is being discussed for Debian Med

executed on cloud

euca2ools

a major motivation behind this effort

integration of data

getData

the integration work will look very differently for cloud and non-cloud installs, getData is still in development and yet not prepared at all for the demands of the cloud

strong interest in special packages

install those packages

and consider mailing the list about it

netboot

does not need Live CD (ref?)

some advanced packackages of general interest

debfoster, deborphan

a ready live CD does not profit from these, but its production does.

Preparation

There shall be two tools proposed

  • live-helper
  • plain chroot plus boot loader
  • vmbuilder

Protocol for Live Helper

Live Helper, see DebianLive for details, was prepared for preparing the LiveCD in a multi-stage manner. One does a configuration first, a script 'lh_config' prepares a good (and for us now until we want images and other bits added at various places sufficient) template for that. A second step will involve the actual compilation of the thus specified infrastructure.

The following sniplet will build an image to dd to the USB stick. Please follow the instructions on ?DebianLive/Howto/USB for further insights.

sudo apt-get install live-helper
lh_config -b usb-hdd \
  --distribution squeeze --categories "main contrib non-free" \
  -p standard --packages '^(libcv-dev|autodock|gromacs|ballview|autodocktools|dropbear|boinc-client|r-cran-qtl|r-recommended)$' \
  -m http://ftp2.de.debian.org/debian/
sudo lh_build

The complete build time - over DSL and with a now elderly laptop is about 45 minutes. The resulting hard drive image can then be dumped to the USB stick's device (not its partition). With a disk partitioning tool the remainder of the stick may be rendered usable again - the DD also writes the partition table and this needs to be adapted for.

dd if=binary.img of=/dev/sdb
fdisk /dev/sdb 
...

As a hard disk image, the live CD can also be run in a variety of virtual setups. The expert tool for such though is "vmbuilder", described below.

When preparing this live medium, one should be aware that the device is not directly mountable, but that on the FAT or FAT32 filesystem a very large file is created, which represents the real image. I have failed to make changes to the local setup, e.g. /etc/hosts changed or so, persistent. This is certainly possible, somehow, but this overview would need a good soul to describe how. I want the medium to be the only medium that the machine sees, e.g. to boot from otherwise diskless clients. If someone would know how for instance to create a second partition on the USB stick (ok, I have done that) and use that together with the aufs/squashfs to achieve persistency within the USB stick, not with the (non-existent) hard disk.

One persistency is achievable, and the image possibly compressed, this setup would seem ideal for many causes.

Protocol for plain chroot plus boot loader

The motivation behind this effort is to have the USB stick function like a regular hard drive and provide the basic functionality for some virtual or real machine to do exactly what it is supposed to do (and nothing much else). Again, a compressed file system would be lovely, but plain journaled ext2 seems to allow a good start.

The installation is performed via deboostrap. Then to be added is a bootloader. I tried with grub2, but it reads from hd0 instead of hd1 when tested on a Windows machine, and I failed to change that. If hd0 is correct for a diskless client I cannot tell. The next attempt will be with extlinux, a ext2-compatible syslinux. The following describes my current state of my attempts:

   sudo fdisk /dev/sdb1 # create a partition
   mke2fs -j /dev/sdb1 # journaled ext2 file system
   tunefs -c 0 /dev/sdb1 # don't check
   sudo mkdir /mnt/stick # prepare mount point
   mount -t ext2 /dev/sdb1 /mnt/stick

   debootstrap squeeze /mnt/stick http://ftp.de.debian.org/debian #  please adjust to your mirror

A disadvantage of this setup is the self-biting installation, which does not care about removing packages from /var/cache/apt to free disk space during installation. After the debootstrap, one should hence loop over $packages to install, like

   chroot /mnt/stick
   packages="boinc-client autodock autogrid autodocktools gromacs"
   for p in $packages; do echo "Installing $p"; apt-get install $p && apt-get clean; done

For getting the beast to boot, I attempted the following. The kernel should be installed, first, and the installation inspects the /proc directory, so this is prepared for it, too.

   sudo chroot /mnt/stick # entering the chroot just created

   cat /etc/fstab # make sure you really want to overwrite this with
   echo "Will be overwritten in ten seconds if you don't CTRL-C"
   sleep 10 # you shall not copy and paste blindly
   cat > /etc/fstab << EOFSTAB
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/sdb1       /               ext3    defaults,errors=remount-ro 0       1
EOFSTAB
   mount /proc
   apt-get install linux-image
   # answering 'Y' to the questions asked, except the initrd is fine - press "don't cancel"

Now the system should be installed. It was not clear from the documentation about how the configuration file should be named - so some good soul please improve the description given here.

   mkdir /boot/extlinux # needed?
   mkdir /boot/syslinux # or this one?
   cat > /boot/syslinux/syslinux.cfg <<EOCFG
DEFAULT linux
LABEL linux
SAY Now booting the kernel from EXTLINUX sdb1
KERNEL vmlinuz
APPEND ro root=/dev/sdb1 initrd=initrd.img
EOCFG
   ln /boot/syslinux/syslinux.cfg /boot/extlinux/extlinux.cfg
   exit  # now back from the chroot

   sudo apt-get install syslinux
   extlinux -i /mnt/stick

   sync # does not help too much with journaled file systems, though
   umount /proc
   umount /mnt/stick

Protocol for vmbuilder

To be written - David?