|00:13||ben_roose has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|01:10||gehidore is now known as man|
|01:10||man is now known as gehidore|
|02:26||lee_ has joined IRC (lee_!43f63279@gateway/web/freenode/ip.22.214.171.124)|
|02:27||lee_ is now known as Guest78403|
guys i am looking for a little help with the ltsp-localapps process
when i type the command in i get command not found
i dont know if it matters but i am on the raspberry pi2 client. It works as expected except for the local apps
|02:34||Guest78403 has left IRC (Guest78403!43f63279@gateway/web/freenode/ip.126.96.36.199, Quit: Page closed)|
|02:38||Lee_ has joined IRC (Lee_!43f63279@gateway/web/freenode/ip.188.8.131.52)|
|02:39||Lee_ is now known as Guest77238|
looking for help with ltsp-localapps
i have installed ltsp server and i can boot a client to the lubuntu desktop. i have been in the chroot and also install the lubuntu desktop in there
my goal is to get a hand full of apps to run directly from the pie...no apps would be run at the same time...with the main app being kodi
in the terminal when i type ltsp-localapps i get command not found from the client side...i can type this in one the server and it looks like it does nothing
local apps is set in the lts.conf
|05:18||Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 255 seconds)|
|05:23||Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)|
|06:08||Statler has joined IRC (Statler!~Georg@p4FC87FA9.dip0.t-ipconnect.de)|
Guest77238: do you have epoptes installed?
epoptes: Epoptes is a computer lab administration and monitoring tool. It works on Ubuntu and Debian based labs with LTSP or non-LTSP servers, thin and fat clients, standalone workstations, NX clients etc. More info: http://www.epoptes.org
|06:46||gdi2k has joined IRC (email@example.com)|
|07:24||ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)|
client-list: to get a list of all nbd-clients (which sometimes is the same as ltsp clients), run: netstat -tn | sed -n 's/.*:10809 *\([0-9.]*\):.*/\1/p' | sort -Vu
nbd-client: To try mounting the NBD image from the client initramfs: nbd-client 192.168.67.1 -N /opt/ltsp/i386 /dev/nbd0
|08:06||mikkel has joined IRC (firstname.lastname@example.org)|
|08:35||Statler has left IRC (Statler!~Georg@p4FC87FA9.dip0.t-ipconnect.de, Remote host closed the connection)|
|09:33||Statler has joined IRC (Statler!~Georg@mail.lohn24.de)|
|09:40||gvy has joined IRC (gvy!~mike@altlinux/developer/mike)|
|09:58||markus_e92 has left IRC (email@example.com, Ping timeout: 255 seconds)|
|10:00||markus_e92 has joined IRC (firstname.lastname@example.org)|
systemd-udevd[xxx]: Process 'ltspfs_entry add nbd5' failed with exit code 1
has someone seen this
|11:55||markus_e92 has left IRC (email@example.com, Ping timeout: 258 seconds)|
got this for all nbds excluding nbd9
|11:57||markus_e92 has joined IRC (firstname.lastname@example.org)|
Statler: I don't think ltsp uses nbd5
Anything customized there?
I got this fpr nbd2 to nbd13
excepting nbd 9
[ 13.864409] block nbd9: NBD_DISCONNECT
[ 13.864492] block nbd9: shutting down socket
[ 13.864652] block nbd9: Receive control failed (result -32)
[ 44.047869] block nbd9: Connection timed out, shutting down connection
[ 44.047881] blk_update_request: I/O error, dev nbd9, sector 3956416
[ 44.048058] block nbd9: Attempted send on closed socket
devices/virtual/block/nbd9' is taking a long time
and when I ask via "fdisk -l" nothing is connected to nbd9
|12:17||lucascastro has left IRC (email@example.com, Remote host closed the connection)|
|12:33||lucascastro has joined IRC (firstname.lastname@example.org)|
|13:29||lucascastro has left IRC (email@example.com, Remote host closed the connection)|
|13:32||ogra_ has left IRC (firstname.lastname@example.org, Ping timeout: 240 seconds)|
|13:33||ogra_ has joined IRC (email@example.com)|
|13:39||mikkel has left IRC (firstname.lastname@example.org, Quit: Leaving)|
<alkisg> no i do not hae epoptes installed
|14:01||vsuojanen has joined IRC (email@example.com)|
Statler: nbd0 is root (/), nbd1 is swap, and nbd9 is a test for updated root
The rest are unused, so maybe udev calls ltspfs_entry and nothing happens
Guest77238: eh, it will be hard to help if you answer once every 8 hours :D
alkisg, "nbd9 is a test for updated root" and was accessed after disconnecting it?
what is the sense of it?
Statler: I haven't checked that part of the code recently, but it's just a check of "if a newer image is available, and we're at ldm, reboot"
It may have issues, sure, and also nbd-client is kinda buggy...
im looking for the reason why kworker and nbd-client hang
At which point does nbd-client hang?
'/devices/virtual/block/nbd9' is taking a long time
I don't get the actual issue
nbd-client hangs while accessing nbd9?
So if you actually remove that part of the code, everything works fine?
Or do you think it's a problem with nbd-client/server in your distro/version, unrelated to ltsp?
i paste you a part of the syslog
<alkisg> sorry have to get ready for work
but i do have a fe minutes
Guest77238: no problem, come back some other day...
when you'll be more available
<alkisg> have you seen that error before?
Guest77238: only if packages are missing
Statler: that message usually happens when the connection is lost
Statler: like, actual networking issues, cables, switch, that kind of stuff
or, nbd-server restarted server-side etc etc
<alkisg> that is a posibility as i have never done this before...idea on what package i might search for?
Guest77238: the package that provides ltsp-localapps is ltsp-client-core
<alkisg> i know that package is installed
# dpkg -S /usr/bin/ltsp-localapps
Sorry, ltsp-server provides ltsp-localapps
While ltsp-client-core provides ltsp-localappsd
alkisg, I01-nbd-checkupdate do this. I have found it :)
If you installed a desktop in the chroot, it's a fat client now
So it doesn't have ltsp-localapps because it's not running on the server anymore
It's already running as "localapps"
<alkisg> yes it a fat client
Statler: yes, that is what tests nbd9, but it's surely not what's causing the kernel panic
Guest77238: I think you don't realize what a fat clients is
A fat client runs everything as "localapps"
So ltsp-localapps wouldn't do anything in this case
If you set LTSP_FATCLIENT=False in lts.conf, then it will be thin again
So then you can enable "some localapps"
Now you have "everything is a localapp"
this test only takes effect after a user logs out from the X. Than they normal shut down the client. Makes not really sense for me to reboot the client when the user wants to go home ;)
<alkisg> that was my goal i just dont think it is happening...if i open firefox it opens it through the server
Guest77238: if you open a terminal and run `hostname`, do you see ltsp123 or server there?
This will tell you if things run locally or on the server
So, what do you see? ltsp123?
Now run `firefox` in that terminal
It will run locally
Why do you think it runs from the server?
ok? why is there so much lag?
Because pis are really really lame computers that should never be used as desktop pcs
Take something like that ^ instead, less money, and runs 10 times faster than rpi3
ok thanks. will i have better luck with thin client?
rpi as thin client?
ya instead of using it as a fet
It depends on how many clients, what server, network speed etc
In general, we don't recommend thin clients anymore
Especially for tasks like web browsing etc
4 clients hooked up a a 48 port switch
Server cpu and ram?
server is amd 6 core 16 gigs of ram
It should work a bit better then, yes, except for videos
flash: Yes, flash sucks. An HD full screen 30 fps video needs 2.5 Gbps bandwidth (1920×1080×4×30)! Make sure you have LDM_DIRECTX=True in your lts.conf file, or if it's just youtube you're after, try some flash replacing plugin like http://linterna-magica.nongnu.org
2.5 gbps bandwidth per client is surely unfeasible
ok thanks again will be back
Please throw away the rpis :D
Then, be back :D
isn't youtube mostly dumping flash? I guess that still doesn't really change the bandwidth requirement too much
|14:53||ben_roose has joined IRC (firstname.lastname@example.org)|
rlyshw: it's not a problem with flash, all screen updates have that issue, even if it's just simple window scrolling
That's why ltsp 6 will switch to fat clients by default
Fat clients transfer disk data from the network, which is a whole less than monitor data
|15:05||Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 240 seconds)|
Yeah, makes sense
btw, I'm getting an error with ltsp-build-client...
"The following packages have unmet dependencies:"
then it lists things, "dh-python : Depends: python3:any (>=3.#.#)"
|15:10||Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)|
I'm trying to install a xenial chroot
Also says things like Depends: dbus but it is not going to be installed
It seems like output from apt-get but I don't recognize it not auto-resolving deps. Is there some module I can change in the Ubuntu plugins to fix it?
Otherwise I just ltsp-chroot in and do it manually, but then I'm not sure how to generate the initramfs.. The /boot/ dir in the chroot remains empty
|15:23||Grembler has joined IRC (Grembler!~Ben@cpc87179-aztw31-2-0-cust6.18-1.cable.virginm.net)|
ltsp-build-client is getting removed in ltsp6 too :D
rlyshw: pastebin the chroot /etc/apt/sources.list...
|15:41||lucascastro has joined IRC (email@example.com)|
|16:13||forum has joined IRC (forum!~Icedove@194-118-247-7.hdsl.highway.telekom.at)|
|16:16||Grembler has left IRC (Grembler!~Ben@cpc87179-aztw31-2-0-cust6.18-1.cable.virginm.net, Quit: I Leave)|
|16:30||Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 255 seconds)|
alkisg: removing ltsp-build-client? Are there docs on ltsp6 somewhere?
|16:59||gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving)|
|17:04||Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)|
|17:26||forum1 has joined IRC (forum1!~Icedove@194-118-247-7.hdsl.highway.telekom.at)|
|17:26||forum has left IRC (forum!~Icedove@194-118-247-7.hdsl.highway.telekom.at, Remote host closed the connection)|
|17:26||forum1 is now known as forum|
looks like this is most likely an issue in the debootstrap thing again... ugh
|17:59||forum has left IRC (forum!~Icedove@194-118-247-7.hdsl.highway.telekom.at, Ping timeout: 240 seconds)|
|17:59||forum has joined IRC (forum!~Icedove@194-118-247-7.hdsl.highway.telekom.at)|
|18:02||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
|18:05||forum has left IRC (forum!~Icedove@194-118-247-7.hdsl.highway.telekom.at, Remote host closed the connection)|
|18:06||forum1 has joined IRC (forum1!~Icedove@194-118-247-7.hdsl.highway.telekom.at)|
|18:10||forum1 has left IRC (forum1!~Icedove@194-118-247-7.hdsl.highway.telekom.at, Ping timeout: 252 seconds)|
|18:13||forum has joined IRC (forum!~Icedove@194-118-247-7.hdsl.highway.telekom.at)|
|18:21||Statler has left IRC (Statler!~Georg@mail.lohn24.de, Remote host closed the connection)|
rlyshw: only some draft plans for ltsp6, it's not developed yet
rlyshw: ports.ubuntu.com? is that armhf?
If you're trying to build cross-distro, you'll need some weird syntax...
If it's just cross-arch, it's easier
About the /boot dir being empty, that would mean ltsp-build-client didn't finish and no kernel was installed
I don't think you should work upon that chroot; better re-create it
yeah, running builds trying to figure out what's going wrong
|19:23||sasho_ has joined IRC (sasho_!5549aa13@gateway/web/freenode/ip.184.108.40.206)|
rlyshw: ok if you need help give more info
It looks like the version of lsb-base in the trusty repos 4.1+Debian11ubuntu6 is too old. ltsp-client-core requires (>=)4.1+Debian11ubuntu6
so now instead of trying cross-dist stuff I'm just going to upgrade the dist on the server
|19:41||sasho_ has left IRC (sasho_!5549aa13@gateway/web/freenode/ip.220.127.116.11, )|
rlyshw: building xenial from trusty should be easy, it's not really cross distro like e.g. building ubuntu from debian
The dependencies of packages shouldn't be broken when on the same distro (chroot), so I can't believe that ltsp-client-core depends on a newer lsb-base than what's offered by the distro
But if you're using "ports.ubuntu.com", that's something broken in your setup
(unless you use armhf and didn't say so yet)
ltsp-client-core in trusty depends on lsb-base without version number, see http://packages.ubuntu.com/trusty/ltsp-client-core
|20:13||forum has left IRC (forum!~Icedove@194-118-247-7.hdsl.highway.telekom.at, Quit: forum)|
|21:07||eddytv has joined IRC (firstname.lastname@example.org)|
Is there a way to rename NICs on LTSP clients? The normal /etc/udev/rules.d/10-network.rules approach doesn't seem applicable.
|21:47||eddytv has left IRC (email@example.com, Quit: My MacBook has gone to sleep. ZZZzzz…)|
|21:48||eddytv has joined IRC (firstname.lastname@example.org)|
|22:25||ben_roose has left IRC (email@example.com, Remote host closed the connection)|
|22:48||eddytv has left IRC (firstname.lastname@example.org, Quit: My MacBook has gone to sleep. ZZZzzz…)|
|22:50||eddytv has joined IRC (email@example.com)|
eddytv: why do you want to or need to do that?
I am trying to use LTSP on systems that have multiple NICs, and I want to control the naming of the interfaces
|23:03||ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)|
why do you want or need to control the naming of the interfaces?
|23:04||markit has joined IRC (firstname.lastname@example.org)|
Trying to match the configuration of existing systems that have existing udev rules that rename the interfaces for consistency and to avoid "re-training"
i just don't understand why the interface name would matter in an LTSP setup
what needs to be retrained?
if i understand what problem you're actually trying to solve, it'll be easier to resolve the issue
because renaming interfaces on your rootfs is likely to be problematic, and probably not the best way forward...
The users of the existing non-LTSP systems. I'm trying to setup LTSP as a proof-of-concept for these systems, but unless the interface names can match the "traditional boot from disk" systems, it will probably be a no-go.
what sort of things are they doing that require knowing the name of the interface?
Network training. Setting up virtual interfaces, routes, iptables, etc.
basically, this is a shoot yourself in the foot situation you're asking for, so really need to know why you need it to be the way you're asking
managing network interfaces on devices used for your rootfs is a *bad* idea.
The existing training materials already reference the NICs using names that are set via udev.d rules. The systems currently use "traditional" disk-based installs. I'm trying to see if it is possible to have them boot from an LTSP server and end up in the same state, so the benefit is that when they are rebooted, they come up in a "known good" state.
you might try one of the LTSP on disk approaches
but that would involve installing to all the machines
but you could reset to a known state with it
That's what I'm trying to avoid; it would be a benefit to be able to remove the storage devices from the machines.
another approach would be to load the rootfs into ram, then you wouldn't rely on having the boot interface once it's booted
you'd still have to figure out how to rename the interfaces
but you don't want to rename the interface that the rootfs is running off of in a typical LTSP environment
it's essentially like unplugging the disk while the OS is running...
I've been futzing around and it seems that if I put the udev rules in /opt/ltsp/amd64/etc/udev/rules.d and rebuild the initrd with ltsp-chroot update-initramfs -c and update the image, it works!
if the initramfs renames the interface early enough in the process, i guess it might work
good luck, in any case
if your install works out for you, consider adding it:
!worldmap | echo eddytv
eddytv worldmap: If you're using LTSP, please let the world know and share your story at http://www.ltsp.org/stories/ Your can add a nice pin to our world map at your location, plus your setup will count towards the global LTSP usage statistics.
it would be a novel use of LTSP
Sure thing. I'll continue to do some testing and if the proof-of-concept works out, will definitely add it. Thanks!
|23:24||eddytv has left IRC (email@example.com, Quit: Textual IRC Client: www.textualapp.com)|
|23:30||markit has left IRC (firstname.lastname@example.org, )|