Re: MythTV frustration.

Dylan Griffiths wrote:

> flags I remember being required from last time. That cuts the stack from:
> to:
> * DNS (or hosts file correctly setup)
> * NFS Server (I use the kernel server, not user-space.)

Yes. That would probably be the easiest in a home network. Test with
floppy before you flash the NIC's ROM or burn to CD. I've found that it
takes _a lot_ of trial and error to find the correct ROM for any
particular NIC. When you are testing, don't assume your custom configs
are broken, assume the ROM incorrect for your NIC.

> the remote X stuff before, but it's not needed in this case. It should
> be relatively simple to get the remote kernel image over, and then pass
> it a ROOT= that is NFS (assuming Linux supports this) which is just a
> dump of the current drive inside the machine. It's on 100Mbps, so the
> speed will be roughly equivalent given that the old PATA drive inside
> can't push 100Mbps ;)

Even 10BaseT is sufficient to push the kernel over, I'm not sure how you
are going to pivot root though, I didn't see any options for that in the
custom Etherboot options. Nor do I think you can compile in a root path
to the kernel. That's one of the reasons I use DHCP for this; option
root-path "192.168.56.1:/opt/ltsp/i386"; makes life easy.

> I'm also assuming Linux supports swap space via NFS (like good ol'
> SunOS). Anyone with experience here?

I don't do this manually, and instead rely on LTSP to set it up. I would
imagine though that you need to create a swap, and then set it up via
nfs in your thins /etc/fstab and in the boot scripts. LTSP uses a
network block device and a daemon on the server to offer swap though, so
there may be monsters. I can send you the init script from the clients
if you want. They may be helpful. HOW-TO's on creating custom rescue
discs might help here too.

http://www.linux.com/howtos/Network-boot-HOWTO/x542.shtml offers good
info on both swap over nfs and swap over nbd. It also explains why LTSP
uses a daemon on the server.

> Now I need to know how to setup my NFS server to feed the kernel to the
> system, and I need to dump the drive off onto the server such that it's
> shared out. I'm thinking of making a nice, large LVM slice in XFS and
> putting all the data onto it. Has anyone combined XFS with NFS before?
> I've heard of issues with NFS and less-mainstream filesystems.

I'm guessing that when you enable NFS in the Etherboot ROM, and
customize the static options, the STATIC_BOOTFILE is probably the kernel
image.

No problem w/ NFS and XFS. Most of our NFS mounts are XFS. You won't
have an issue. We use it because XFS is better for large amounts of
smaller files compared to ext3 and the Posix ACL's are fully compatible
with samba. The latter won't matter to you though.

> Also, how do I know if I'm using kernel or userland NFS servers? I have
> the NFS v2/3 servers turned on in my kernel config, but I still see nfsd
> processes in the process table. I've tried turning up the # of these to
> help offset the performance loss on gigabit I get by using small (1500)
> packets. That'll learn me for buying a switch that doesn't support
> jumbo frames :(

from the Debian package on nfs-kernel-server:

Use this package if you want to use the kernel-mode NFS server. The
user-mode NFS server in the "nfs-user-server" package is slower and less
featureful but easier to debug than the kernel-mode server.

Debian package on nfs-user-server:
This package contains all necessary programs to make your Linux machine
act as an NFS server, being an NFS daemon (rpc.nfsd), a mount daemon
(rpc.mountd). Unlike other NFS daemons, this NFS server runs entirely in
user space. This makes it a tad slower than other NFS implementations,
and also introduces some awkwardnesses in the semantics (for instance,
moving a file to a different directory will render its file handle
invalid). There is currently no support for file locking.

The last one is a must have in my implementation, and the speed factor
is important too, but I haven't tested to see what the difference is.

Heh, got burned on the large packets with a 3Com4200 switch. Took me a
while to figure out that the Quality of Service default configurations
were fragmenting the NFS packets on the GBit ports. Very annoying,
100BaseT worked fine, just not the Gigs until we turned off QOS. Then
everything screamed. That affected AFP too. I think it's dumb for 3Com
to default their switches to standard TCP packet size.

> If nothing else, I could put the important and relatively unchanging
> things on one of those 15$ 512mb USB keys and get the machine to boot
> off of that, and then NFS the rest.

This maybe your easiest option. I've never made a bootable USB as none
of our machines are new enough to have that as a boot option in their
ROM. That might be fun too. :)

Cheers,
lance

-- 
Lance Levsen,
Catprint Computing
Tel:  (306) 493-2249
Cell: (306) 230-8783
Blog: http://www.catprint.ca/blog/
SaskBlogs: http://saskblogs.catprint.ca/