NFS based minimyth

[Eduardo]

This has spawned from a previous thread about DVD support. A couple of people have been playing with NFS as the boot medium versus CRAMFS.

I have decided to see if I could boot off NFS, for my own self serving purposes (aka MythDVD and other myth modules) and the higher purpose of giving something back to Larry and the others who have created minimyth.

On the technical side, I have minimyth booting over NFS.

The system uses DHCP to get the PXE info The entry is still pretty much the same as the standard cramfs version

Code: Select all

        host myth1 {
             hardware ethernet 00:40:63:c5:ea:eb;
             fixed-address 192.168.1.120;       # frontend IP
             next-server 192.168.1.119;          # Backend/TFTP/DHCP/NFS IP
             filename "PXEClient/pxelinux.0";
             option routers 192.168.1.1;          # Gateway IP
             option root-path "192.168.1.119:/nfsroot/myth1/,rw,v3,rsize=8192,wsize=8192";     #NFS Server, and ROOTFS Share
        }

I don't know if the two option lines are required or not. But they don't affect a rollback to the standard cramfs boot.

The PXE settings have changed, I added an new entry to PXEClient/pxelinux.cfg. I finally realized that the filenames are Hex versions of the IP and not ethernet address so in my case the file is called C0A80178.

Code: Select all

LABEL myth1
        KERNEL myth1.bzImage
        APPEND ip=dhcp nfsroot=192.168.1.119:/nfsroot/myth1 root=/dev/nfs init=/sbin/init

DEFAULT myth1

The bzImage is just the kernel, and so far this is the same bzImage that the cramfs version uses.

The third thing to provide is the NFS share that is the root FS. The root FS, is the image that Larry created within the cramfs, it is conveniently in a tar.bz2 format for download on the site. I expanded the tar to be /nfstroot/myth1 on my NFS server. and added the following line to my /etc/exports to support it:

Code: Select all

#New NFS boot
/nfsroot/myth1 myth1(rw,no_root_squash,no_all_squash,sync)

The no_root_squash and no_all_squash are supposedly to allow root and specific users to be able to use their matching id's on the filesystem and not have permissions of "nfsnobody". This piece does not seem to be working properly.

Note: You could make any rootfs, and debian has a tool to create one for you (I don't use debian so never bothered). Larry has made an very small image and has all the binaries etc, configured and compiled for the EPIA platform. If you want to do this you can, and make your own fully featured install and ignore the rest of this.

Now the troubleshooting starts, first off the paradigm has shifted, so lots of the boot process becomes unneccessary. You definately have to comment out the DHCP part, if you run it you kill your network connection and thus lose your filesystem (error 101 repeating forever on the screen).

I manually walked through the boot process performing the actions that would now only need to be performed once, and the NFSroot would "save" the changes. Some of these could still be passed as "boot parameters" and the files left intact for quick changes, especially if you have multiple forntends, or only want to have one rootfs for all frontends.

dchp.script - justs creates /etc/resolv.conf and a stores the tftp server address. So I manually created my resolv.conf, which is the same as my backend server, and ignored the tftp piece as obsolete.
getremotefiles.script - I copied the files that I used (localtime and fstab) into the rootfs, and now it is no longer required.
lirc.script - I removed the choices and just kept the command to enable my homebrew on com2 section.
mysql.script - I modified the mysql.txt file in the rootfs and now this file was obsolete.
network.script - I have eliminated this entirely, but the loopback interface initialization may be required.
servers.script - I embedded my time server into the file, and left the rest as is.
translucency.script - is obsolete if you have modied the files manually, and would also be obsolete if my rootfs wasn't loading as read-only.
preaap.script - I manually made the lirc.conf, lircrc, fstab and other changes manually to the rootfs and it became obsolete.

The other pieces are in /etc/rc that I commented out:

Code: Select all

#/etc/scripts/translucency.script
#/etc/scripts/network.script
#/etc/scripts/getremotefiles.script

#[ -e /tmp/preapp.script ] && /bin/sh /tmp/preapp.script

I have left

Code: Select all

/bin/mount -t tmpfs -o size=512K tmpfs /var
/bin/mount -t tmpfs -o size=512K tmpfs /tmp
/bin/mount -t tmpfs -o size=512K tmpfs /mnt

for now as they are my work around for the read-only problem.

The system that I have boots, however it is slower than the cramfs version. The loadmods.script and loadalsamods.script run, and they seem very slow. (maybe a read-only issue as well) I'm not sure if they run in the cramfs version, they don't show up in the frontend.log.

I haven't had anytime to put the frontend through it's paces, so I don't know if the apps have busted. It's also why I don't know if the loadmods are neccessary.

Feel free to join in the fun. This is just a first pass butcher job to get it running, a nicer version of what to change or a new rootfs will hopefully come from these trials.

Eduardo

PS: If your wife wants to watch TV, quickly change your PXE file and the system boots normal.

[Nem]

Hi Eduardo,

Did you check out my howto here.

I have been away from the project for the last couple of releases doing my own thing with gentoo, but I will be back experimenting again quite soon. Let me know if you have any specific issues that you can't get to the bottom of.

Regards,

Darren