ltspfs/ltspfsd broken on hardy amd64 thin client

[blueness]

Binary package hint: ltspfsd

The hardy amd64 thin client server builds an amd64.img by default during installation (in /opt/ltsp/images). 64-bit thin clients boot fine and even appear to properly mount removeable media such as usb drives or CD-ROMs via the ltspfs-ltspfsd system, but there is a clear problem: The user can navigate the filesystem either via the shell or nautilus in gnome, can see all his/her files, gets all the correct filesystem data such as permissions, ownership, file size, creation date, etc, BUT cannot open the files to read their contents, cannot delete the files, cannot create new files (eg. cannot do cat existing_file.txt, touch my.txt, or echo "hi" > my.txt, etc.) The reported error is "can't allocate memory". Looks like the filesystem metadata is there, but the file contents are not.

However, when a 32-bit thin client image is built on a 64-bit server (/opt/ltsp/images/i386.img), or a 32-bit image on a 32-bit server, all is good. This seems to be a bug specific to 64-bit ltspfsd.

This was tested in the wild (an IT lab) as well as a fresh "out of the box" install in vmware. Same behavior in all cases.

Possibly a bug report should go upstream to the ltspfs maintainers?

Package version:
ltspfs 0.5.0~bzr20080109-3ubuntu2 -> on the server
ltspfsd 0.5.0~bzr20080109-3ubuntu2 -> in the chrooted environment of /opt/ltsp/amd64

[Andreas Schreiner (andreas-schreiner)]

This bug is still not fixed in Karmic.
This bug is apparently a duplicate of bug #415952