[X2Go-User] USB forwarding documentation

[Seth Galitzer]

On 11/20/2017 07:09 PM, Stefan Baur wrote:
> Am 20.11.2017 um 23:42 schrieb Seth Galitzer:
>> I've been trying for a couple of weeks now to build a TCE image that
>> this actually works on. I applied your new script to my latest attempt
>> today and finally discovered that the libfreerdp-plugins-standard
>> package is not actually getting installed in the chroot image. As a
>> result, while the USB flash drive is getting correctly mounted in the
>> expected location, when I run my RDP connection, I do not see the share
>> presented by the tsclient host.
> 
> Ah-ha!
> 
> 
> [libfreerdp-plugins-standard package missing]
> 
>> If I try "dpkg -l|grep freerdp-plugins" on the booted client, I don't
>> get any results. Not even a package in "rc" state". If I grep for
>> freerdp, I get the rest of the packages requested in the overlay list.
>>
>> I should note that I'm using a very lightly-patched x2goclient v4.1.1.1
>> in this build and a slightly modified version of
>> 2900-x2go-thinclientconfig from the chroot overlay, but I don't think
>> these are related to this build issue. I will double-check the latter to
>> make sure.
>>
>> Any thoughts as to what might be causing this or possible work-arounds
>> this?
> 
> Are you using the timestamp feature I added? If so, I would first
> compare timestamps of your running system and of the image you built.
> cat x2go-tce-timestamp in the builddir vs. the build number you see at
> the local or ssh login prompt (cat /etc/issue, bottom line), or, lacking
> the timestamping code in your build, comparing the output of
> 
> # in the builddir
> TIMESTAMP=$(stat -c %Y ./config/includes.chroot/lib)
> HUMANTIMESTAMP=$(date --date="$TIMESTAMP")
> echo "Build Version: $TIMESTAMP ($HUMANTIMESTAMP)"
> 
> # in the booted TCE
> for TIMESTAMPFILE in /lib/live/mount/rootfs/*/lib; do
>   TIMESTAMP=$(stat -c %Y $TIMESTAMPFILE)
>   HUMANTIMESTAMP=$(date --date="@$TIMESTAMP")
> done
> echo "Build Version: $TIMESTAMP ($HUMANTIMESTAMP)"
> 
> Because to me, it sounds like you're not booting the image you're
> expecting to boot. Maybe you're storing it to the wrong directory, maybe
> the client you're testing with has a custom PXE boot entry that causes
> it to boot the image from a different location, maybe your USB media is
> actually a bootable X2GoThinClient because you were experimenting with
> that, and you're booting off of USB rather than PXE, ...
> 

OK, this is the exact problem. I've been forgetting that I actually have 
a separate PXE boot server for my thin client lab and was uploading my 
images to my "general purpose" PXE server for the rest of my public 
machines. Now that I'm properly remembering, I'll do more testing and 
see what I can find.

> 
> Did you try using the entire build script from the wiki page, or only
> patch the automount script?
> What happens when you try to build a stock image using our scripts, our
> git repo, and no custom changes?

I went back through the wiki page and updated my build scripts to match 
the new info, and got the newer version of the x2gousbmount script. I 
can try a vanilla build and see what happens.

> 
> I just checked it myself on a stretch amd64 build, a stretch i386
> (686-pae), and a jessie i386 (686-pae), the package is always there,
> just like it should be.
> 
> Of course, if all else fails, you could run unsquashfs, chroot into the
> resulting directory, install the package manually, then run mksquashfs
> again. I would suggest adding options
> -comp xz -Xbcj x86 -b 1024K -Xdict-size 1024K
> to mksquashfs (based on a suggestion by intrigeri from the TAILS team),
> and reading the man page for mksquashfs first.

I was wondering how I might accomplish this, thanks for the tips.

> 
> Kind Regards,
> Stefan Baur
> 

Chalk this one up to my own error. :) Thanks for the help.

Seth

-- 
Seth Galitzer
Systems Coordinator
Computer Science Department
Kansas State University
http://www.cs.ksu.edu/~sgsax
sgsax at ksu.edu
785-532-7790