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
[email protected]
785-532-7790
_______________________________________________
x2go-user mailing list
[email protected]
https://lists.x2go.org/listinfo/x2go-user
