Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
wiki:user:less1 [2009/05/23 07:17] less1 |
wiki:user:less1 [2009/06/14 16:41] (current) mdc |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== Hello World ===== | ===== Hello World ===== | ||
| - | I will start with exploring following pages\\ | + | For information about me and my [[:soc:2009:start|Google Summer of Code 2009]] project please visit my GSoC [[:soc:2009:pravin:notes:start|notes pages]] and [[:soc:2009:pravin:journal:start|journal 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. | + | |
