====== place to log useful random commands ======

Useful to find the dependency of given executable on other shared libraries.
<code>
ldd
</code>

===== Useful information =====
AndyTim: By the way, if you ever get the ^M problem again.
 Try following it by a ^J


===== Links to watch-out =====
  - [[http://unit.aist.go.jp/itri/knoppix/http-fuse/index-en.html|HTTP-FUSE-KNOPPIX]] someone has done if before also.
  - [[http://paste.etherboot.org/?page=view&id=1239849078]] script to create automatic gpxe bootable USB

===== For Shell script =====
If you want to terminate execution of a shell script on encounter any error then
<code>
#!/bin/bash
set -e
</code>

===== Useful git commands =====
To create 
<code>
git clone --bare git://git.kernel.org/pub/scm/boot/syslinux/syslinux.git syslinux.git
</code>
The "--bare" means you don't need a working tree, only the internal .git/ files.  Since you'll never been working directly in this directoy on rom, it makes sense not to have a working tree.

==== creating blank repository on remote server ====
<code>
git init --bare
</code>

Adding remote head to cloned repository
<code>
git remote add master git+ssh://pravin@git.etherboot.org//pub/scm/people/pravin/BKO.git
</code>

For pushing the local master repository from local to remote server repository, it can be done with
<code>
git push master master
</code>

Where you are pushing local branch called "master" onto remote branch called "master"

===== git submoduling =====

to register the git submodules
<code>
git submodule init
git submodule update
</code>

==== git bisect ====
This command is quite useful for finding broken commit.
Here is the [[http://jbowes.wordpress.com/2007/02/18/git-bisect-a-practical-example-with-yum/|blog]] which mentions how to use it.

===== useful commands for qemu =====
One can use qemu monitor for debugging.\\
Here is the [[http://en.wikibooks.org/wiki/QEMU/Monitor|wikibook]] for using monitor with qemu.

===== Notes =====

I will start with exploring following pages\\
 * http://www.babytux.org/articles/howto/how2netknoppix.php \\
 * http://openlab.jp/oscircular/inetboot/ \\
 * http://www.kegel.com/linux/pxe.html \\
 * http://unit.aist.go.jp/itri/knoppix/http-fuse/index-en.html \\
 * com32/lib/syslinux/initramfs*.c \\
 * Linux Terminal server project.. LTSP \\
 * http://www.mjmwired.net/kernel/Documentation/early-userspace/buffer-format.txt \\
 * http://www.mjmwired.net/kernel/Documentation/filesystems/ramfs-rootfs-initramfs.txt \\
 * http://en.gentoo-wiki.com/wiki/Initramfs \\
 * com32/modules/linux.c \\
 * http://git.kernel.org/?p=boot/syslinux/syslinux.git;a=blob;hb=HEAD;f=com32/modules/linux.c \\


=== My ToDo list ===
  - Get QEMU + PXE working. -- Done [[wiki:QemuPxe]].
  - Get QEMU + PXE + HTTP working -- Done .
  - Get QEMU + PXEKnife working. [[wiki:QemuPxeKnife]] -- Done
  - Get QEMU + PXEKnife + HTTP working. [[wiki:QemuPxeKnifeHTTP]] -- Stuck :-(
  - Explore the ability of PXE and SYSLinux to dynamically create INITRAMFS.
  - Get PXE-Knife working over HTTP.
  - Check how can I use com32 module from inside syslinux to modify inintramfs files.


=== Questions that I need to find answers ===
  * In case of linux distribution, Will entire distriibution run from RAM as initRAMfs or it will use root filesystem from NFS of server?
    * **warthog9:** a normal distribution will very unlikely run out of ram, in particular when you consider a "normal" distribution is going to need a couple of gig's of data to be complete.  That said there are smaller distributions (like Damn Small Linux) which are only in the 50M range of size.  It might be more possible to run these straight out of ram.  I have not tested DSL specifically for this but it was the thing that seemed the most likely as a 'live' distribution for BKO for the time being.  The possibility of running a 'live' distribution out of NFSv4 has also been discussed as a not horrible option, but may have adverse consequences for the server.
  * Can we exploit the PXE/SYSLinux ability to dynamically create INITRAMFS? this way, server will send the part of initramfs whenever user makes any selection and SYSLinux will merge newly downloaded part on initramfs with orinial one. This may reduce the workload on server.
    * **warthog9:** This should be doable, just stacking the initrd's together would make things a lot simpler, particularly for Linux based utilities.  Treat each piece as an individual package (like an rpm of sorts), keep a dependency tree of what each package needs and we should be able to completely build a minimal set of files needed to run a specific component dynamically (or pre-generated if the selection would be static anyway, but the pre-generation would just be the list of things to include)
  * In case, we need to use NFS root filesystem, what about scalability? many users may not have outgoing NFS port access. Can NFS service provided on HTTP?
  * **warthog9:** NFSv3 from a public internet perspective is off the table for a whole host of reasons the least of which is individual ports, security, etc.  NFSv4 would be a consideration, but the scalability might be a bigger issue here.  Investigation into the access patterns, load, etc would need to be done.  For now a Proof-of-concept for nfsv4 could be done, but actual full implementation should be looked after basic framework is up and running.
  * Whats the difference between initrd and initramfs ?