00:08 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Remote host closed the connection) | |
00:30 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
01:10 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
01:43 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 268 seconds) | |
02:09 | GodFather has left IRC (GodFather!~rcc@47.33.250.142, Ping timeout: 260 seconds) | |
02:41 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
03:15 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 268 seconds) | |
03:58 | lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18) | |
04:12 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
04:36 | johnsmith has joined IRC (johnsmith!~Adium@106.219.154.25) | |
04:36 | johnsmith has left IRC (johnsmith!~Adium@106.219.154.25) | |
04:44 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 246 seconds) | |
05:03 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 240 seconds) | |
05:08 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
05:08 | Statler has joined IRC (Statler!~Georg@p579FEEBB.dip0.t-ipconnect.de) | |
05:42 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
06:14 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 255 seconds) | |
06:17 | Eric2 has joined IRC (Eric2!~eric@sdi.iut-valence.fr) | |
06:21 | forum has joined IRC (forum!~Thunderbi@93-82-104-159.adsl.highway.telekom.at) | |
06:29 | forum has left IRC (forum!~Thunderbi@93-82-104-159.adsl.highway.telekom.at, Quit: forum) | |
06:32 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
06:42 | ZAJDAN has left IRC (ZAJDAN!4d30954b@gateway/web/freenode/ip.77.48.149.75, Quit: Page closed) | |
06:57 | v4169sgr has joined IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa) | |
06:58 | <v4169sgr> Hello! Has anyone ever heard of Evolution (the mail client) segfaulting in thin clients, but running fine on the server?
| |
06:58 | Alternatively, is it possible to configure evolution to run fat while everything else runs thin ?
| |
07:02 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
07:04 | <alkisg> v4169sgr: you're using ubuntu-mate with evolution instead of thunderbird? how so?
| |
07:04 | You can run some applications in "fat mode" with ltsp "remote apps", see the lts.conf man page
| |
07:04 | !lts.conf
| |
07:04 | <ltsp> lts.conf: (#1) http://manpages.ubuntu.com/lts.conf, or (#2) lts.conf manpage is available in the ltsp-docs package
| |
07:05 | <v4169sgr> Thank you! I'll check that out right away! :)
| |
07:05 | Yes, our users run Evolution by preference for migration reasons (look and feel)
| |
07:06 | The install is vanilla 16.04 with ubuntu-mate-desktop installed over the top and used as an option
| |
07:06 | <alkisg> You already have a messy setup :D
| |
07:07 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
07:07 | <alkisg> The 'vanilla' ubuntu is using unity, which is not developed anymore, so it's not a good option
| |
07:08 | <v4169sgr> We prefer unity when we can run it. Mate is good for the thin clients.
| |
07:09 | I am personally agnostic, but I am going with user adoption (and hard work already invested! :)) here
| |
07:10 | <alkisg> As a sysadmin, I always notify my users when they use something that is not developed anymore
| |
07:10 | <v4169sgr> good policy :)
| |
07:10 | <alkisg> They don't know that it's no longer maintained. I do. So I tell them to avoid it. :)
| |
07:10 | <v4169sgr> think of it as a 'soft migration' :P
| |
07:10 | <alkisg> np
| |
07:11 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 255 seconds) | |
07:12 | <alkisg> Btw, your clients have 1 GB RAM, so they should probably be used as fat clients and not as thin clients
| |
07:12 | <v4169sgr> yes, true, and I've tested fat vs thin, but found thin to be much more responsive, so will stick with thin
| |
07:12 | 1 GB really isn't enough even for mate
| |
07:12 | <alkisg> Even if they only have N270 CPU, with... 270 passmark (wow, what a coincidence...)
| |
07:13 | It depends on your network and server too. If your server has more than 1 GB *per client*, then OK
| |
07:13 | E.g. for 20 clients => 20 GB RAM on the server...
| |
07:13 | <v4169sgr> pardon my ignorance but isn't lts.conf REMOTE_APPS intended for fat client set ups wanting to run an app on the server?
| |
07:13 | I have the opposite case: I run thin but want to try runnjing evolution locally
| |
07:13 | <alkisg> Ah sorry you are right,
| |
07:14 | you're looking for LTSP_LOCALAPPS instead
| |
07:14 | <v4169sgr> thanks, will search instead for that
| |
07:14 | and yes my server is more than adequately provisioned (16 GB, 3 clients)
| |
07:14 | <alkisg> LOCAL APPLICATIONS LOCAL_APPS boolean, default True
| |
07:15 | LOCAL_APPS=True in lts.conf, and also the menu items there
| |
07:15 | <v4169sgr> and I am sitting on a 1 gbps LAN :)
| |
07:15 | <alkisg> It should be OK then, except for full screen videos etc
| |
07:15 | <v4169sgr> full screen videos run ok too
| |
07:15 | very acceptable
| |
07:15 | <alkisg> A full screen video needs 2.5 gbps per client
| |
07:15 | <v4169sgr> yes thats ok too
| |
07:16 | <alkisg> So for 3 clients you'd need 7.5 gbps, and you only have 1 gbps :)
| |
07:16 | So you have some dropped frames, but it should be fine
| |
07:16 | <v4169sgr> from experience 1 gbps can carry the load
| |
07:16 | without dropped frames
| |
07:16 | <alkisg> Nah
| |
07:16 | Math beats experience any time
| |
07:17 | !thin-client-bandwidth
| |
07:17 | <ltsp> I do not know about 'thin-client-bandwidth', but I do know about these similar topics: 'thin-clients-bandwidth'
| |
07:17 | <v4169sgr> LOL :P
| |
07:17 | <alkisg> !thin-clients-bandwidth
| |
07:17 | <ltsp> thin-clients-bandwidth: A small explanation why thin clients can't perform well with video, lots of screen updates etc: https://sourceforge.net/p/ltsp/mailman/message/35694699/
| |
07:17 | <v4169sgr> understood, and this is something large scale installations need to watch for
| |
07:17 | but my installation is very small
| |
07:18 | <alkisg> As I said, you have dropped frames. If it's ok with you, it's ok. But I can't accept that you don't have dropped frames :)
| |
07:18 | Math says otherwise
| |
07:20 | <v4169sgr> Would I use "LOCAL_APPS_WHITELIST = evolution" to specify only evolution to run locally?
| |
07:21 | <alkisg> You only need LOCAL_APPS, LOCAL_APPS_MENU, and LOCAL_APPS_MENU_ITEMS
| |
07:21 | You don't need the whitelist
| |
07:22 | <v4169sgr> Thanks. Do you have an example of usage? I only want to run evolution locally, nothing else
| |
07:23 | <alkisg> LOCAL_APPS=True, LOCAL_APPS_MENU=True, LOCAL_APPS_MENU_ITEMS=evolution
| |
07:23 | <v4169sgr> Thank you, will edit and test
| |
07:24 | and thanks for your instant and knowledgeable help !!! :)
| |
07:24 | <alkisg> np
| |
07:33 | ZAJDAN has joined IRC (ZAJDAN!4d30954b@gateway/web/freenode/ip.77.48.149.75) | |
07:34 | <ZAJDAN> LTSP pnp for Debian9 ..exist any howto?
| |
07:42 | <v4169sgr> ZAJDAN: I found this very useful
| |
07:43 | https://wiki.debian.org/LTSP/Howto
| |
07:43 | The PNP section is the second part of the page
| |
07:43 | @alkisg: setting evolution as a local app did not work: it still segfaults
| |
07:44 | <alkisg> v4169sgr: rarely, applications have issues with sshfs
| |
07:44 | Evolution might be one such application; although I assume someone would have mentioned it...
| |
07:44 | Try on the server, to mount sshfs home and launch evolution there
| |
07:45 | So that ltsp isn't involved at all
| |
07:45 | If evolution fails on sshfs, then there are ways around the issue
| |
07:45 | <v4169sgr> ok, dumb question time, what is sshfs and where can I find it?
| |
07:46 | <alkisg> sshfs is the remote file system that ltsp uses by default
| |
07:47 | You can see its man page here: manpages.ubuntu.com/sshfs
| |
07:47 | Eh, wait, you also said evolution breaks on thin clients too
| |
07:47 | Sorry I'm not very focused today
| |
07:47 | Thin client session runs on the server
| |
07:47 | So there's no sshfs there
| |
07:47 | Scratch that idea out
| |
07:47 | <ZAJDAN> v4169sgr: yes, but from there is not clear what packages I should install....the section 'Installing LTSP using the LTSP-PNP method' speaks about setting not installation
| |
07:48 | <alkisg> v4169sgr: try putting this line in lts.conf: X_SMART_COLOR_DEPTH=False. Then reboot the thin clients, to see if it has an issue with the color depth.
| |
07:48 | <v4169sgr> @ZANJAN: Install ltsp-server-standalone, ltsp-client (since there is to be no separate chroot) dnsmasq (an easy to configure tool) other desired software and the desktop environment of your choice.
| |
07:48 | from the page
| |
07:49 | item #2, second list
| |
07:49 | Thanks alkisg :) Will try ...
| |
07:49 | forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at) | |
07:51 | Statler has left IRC (Statler!~Georg@p579FEEBB.dip0.t-ipconnect.de, Remote host closed the connection) | |
07:51 | <ZAJDAN> v4169sgr: ok..I will try to record all steps to create some simple manual
| |
07:51 | johnsmith_ has joined IRC (johnsmith_!6adb0364@gateway/web/freenode/ip.106.219.3.100) | |
07:56 | <v4169sgr> By the way I am finding that sometimes after reboots the dnsmasq service needs to be restarted, else the client fails to find the TFTP service
| |
07:56 | I've added "sudo service dnsmasq restart" to rc.local but that doesn't seem to be helping
| |
07:56 | I still need to manually restart
| |
07:57 | so wonder if I can run this line after some small delay
| |
07:57 | <alkisg> v4169sgr: what's the output of this? egrep -rv '^$|^#' /etc/dnsmasq.* | nc termbin.com 9999
| |
07:57 | <v4169sgr> http://termbin.com/byzq
| |
07:58 | no idea what that means :)
| |
07:58 | <alkisg> The problem is "bind-interfaces", you didn't remove it
| |
07:58 | !ltsp-pnp
| |
07:58 | <ltsp> ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
| |
07:58 | <alkisg> Hrm, I need to document that bug in network-manager too
| |
07:59 | <v4169sgr> thanks, so what do I need to do?
| |
07:59 | <alkisg> Remove the line "bind-interfaces" from the file "/etc/dnsmasq.d/network-manager"
| |
08:01 | <v4169sgr> # WARNING: changes to this file will get lost if network-manager is removed.
| |
08:01 | Does this mean changes are not persistent over time ?
| |
08:02 | <alkisg> No
| |
08:02 | They're persistent
| |
08:02 | <v4169sgr> ok, backed up original and changed, will reboot and try
| |
08:02 | and try the other lts.conf change too :)
| |
08:02 | <alkisg> I hope you didn't back it up in the same dir
| |
08:02 | Because then it would still cause issues :)
| |
08:03 | <v4169sgr> So a filename of "network-manager.07Jun2017" isn't safe?
| |
08:03 | if so that would be a first for me
| |
08:04 | <alkisg> Yes, it's not safe
| |
08:04 | Because dnsmasq still reads that file
| |
08:04 | So the bad option still applies
| |
08:04 | <v4169sgr> can I create a "backups" directory immediately underneath?
| |
08:04 | <alkisg> This is an issue with all config.d dirs
| |
08:04 | <v4169sgr> I need to safeguard the original
| |
08:04 | <alkisg> Create a backup somewhere else, e.g. in /home/user/mybackups
| |
08:06 | <v4169sgr> saved here
| |
08:06 | ~/systembackups/etc/dnsmasq.d/network-manager.07Jun2017
| |
08:06 | being me I've gone totally over the top LOL
| |
08:08 | v4169sgr has left IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa) | |
08:10 | v4169sgr has joined IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa) | |
08:16 | <v4169sgr> @alkisg: ok, removing the bind-interfaces directive seems to have worked
| |
08:16 | <alkisg> Yes I reported that bug ages ago but some Ubuntu maintainers just won't listen :/
| |
08:17 | Fortunately they'll stop abusing dnsmasq in 17.10
| |
08:17 | <v4169sgr> Setting X_SMART_COLOR_DEPTH=False unfortunately did not prevent evolution segfaulting
| |
08:17 | Thanks and well done for persisting with it :)
| |
08:18 | <alkisg> So, you're saying that evolution works for userA on the server, but not for the same userA on a thin client?
| |
08:19 | <v4169sgr> correct
| |
08:19 | and that is also independent of using mate or unity as a dE
| |
08:20 | so LTSP seems to be the common factor
| |
08:21 | Statler has joined IRC (Statler!~Georg@mail.lohn24.de) | |
08:21 | <v4169sgr> unfortunately there just doesn't seem to be a lot on this out there
| |
08:25 | How about setting SSH_FOLLOW_SYMLINKS to True ?
| |
08:25 | <alkisg> Before using LOCAL_APPS=True, you were running evolution on the server (via the thin client session)
| |
08:26 | <v4169sgr> presume that's only for local apps
| |
08:26 | <alkisg> So sshfs was not involved at all there
| |
08:26 | <v4169sgr> ye4s
| |
08:26 | yes
| |
08:26 | correct
| |
08:26 | <alkisg> So if it's not sshfs and it's not the color depth... I'm not sure why it would be ltsp-related
| |
08:26 | <v4169sgr> ok, so nothing obvious to me in the lts conf man page then
| |
08:27 | <alkisg> And if it doesn't even run locally (localapps) then it's not related to "remote xorg" either
| |
08:27 | <v4169sgr> I could try "gdb evolution" on the client and see if I can get any more information that way
| |
08:28 | <alkisg> So, the problem doesn't really sound like it's related to ltsp... so I'm not fond of spending too much time with it ;)
| |
08:28 | ZAJDAN has left IRC (ZAJDAN!4d30954b@gateway/web/freenode/ip.77.48.149.75, Ping timeout: 260 seconds) | |
08:29 | <v4169sgr> well it's only a pb on the client, so not sure what else it could be :)
| |
08:29 | agreed it is hard to diagnose tho
| |
08:30 | <alkisg> Ah, another thing that might be related, is the login manager, ldm, along with the accountsservice
| |
08:30 | Eric2 has left IRC (Eric2!~eric@sdi.iut-valence.fr, Ping timeout: 246 seconds) | |
08:30 | <alkisg> E.g. evolution might be querying them about the logged in users etc
| |
08:30 | Anyways... yeah sounds tricky to diagnose
| |
08:34 | <v4169sgr> This is the result
| |
08:34 | Thread 1 "evolution" received signal SIGSEGV, Segmentation fault.
| |
08:34 | 0xb7fe3d9b in check_match (undef_name=undef_name@entry=0xb3308ad1 "mincore",
| |
08:34 | ref=ref@entry=0x0, version=version@entry=0x0, flags=7, type_class=0,
| |
08:34 | sym=0xb32f91cc, symidx=163, strtab=0xb32f96cc "", map=0xb330a000,
| |
08:34 | versioned_sym=0xbf8000ac, num_versions=0xbf8000a8) at dl-lookup.c:110
| |
08:34 | 110 dl-lookup.c: No such file or directory.
| |
08:34 | At first sight I'd say that's internal to the app, but not sure
| |
08:36 | running the same command on the server does not produce anything like this: just normal running
| |
08:42 | https://ubuntuforums.org/showthread.php?t=2363142
| |
08:43 | <alkisg> I don't think any ltsp developer is participating in ubuntuforums...
| |
08:43 | We're mostly using IRC, or the mailing lists
| |
08:44 | You could ask in the mailing lists if anyone else has that issue, or if it just affects you
| |
08:46 | <v4169sgr> yes indeed, digging deeper seems that something similar was reported in the past few months on a centos install
| |
08:46 | but no action taken
| |
08:47 | seems possibly connected with stack management or memory allocation
| |
08:48 | Eric2 has joined IRC (Eric2!~eric@sdi.iut-valence.fr) | |
08:50 | <bcg_> probably not related, but we just noticed random segfaults on localapps firefox if running in 32bit kernel/chroot. quick fix was to recreate chroot as 64bit.
| |
08:53 | johnsmith_ has left IRC (johnsmith_!6adb0364@gateway/web/freenode/ip.106.219.3.100, Ping timeout: 260 seconds) | |
09:22 | <v4169sgr> Thanks bcg_ :) Not an option for me I am afraid as the clients must run 32 bit. H/W is DELL FX 170
| |
09:22 | <alkisg> The server is 32 bit and runs evolution, so that shouldn't be related in this case
| |
09:23 | <v4169sgr> agreed
| |
09:42 | bcg_ is now known as bcg | |
09:46 | <v4169sgr> Seriously considering migrating from evolution to thunderbird
| |
09:46 | ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Quit: Coyote finally caught me) | |
09:47 | <v4169sgr> I already use thunderbird for another mail account, so migration would not be so straightforward for me, but would be simpler for other users
| |
09:47 | apart from the 10+ years of emails to save in mboxes LOL
| |
09:47 | <alkisg> Thunderbird supports multiple accounts
| |
09:48 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
09:50 | <v4169sgr> considering merits of a hard cut over and not migrate the mboxes, but leave them as archive reference, and simply set up the accounts on thunderbird
| |
10:12 | markus_e92 has left IRC (markus_e92!~markus_e9@80-121-121-35.adsl.highway.telekom.at, Ping timeout: 255 seconds) | |
10:14 | markus_e92 has joined IRC (markus_e92!~markus_e9@62-46-102-74.adsl.highway.telekom.at) | |
10:19 | ogra_ is now known as ogra | |
10:20 | ogra has joined IRC (ogra!~ogra_@ubuntu/member/ogra) | |
10:24 | zerkalo has joined IRC (zerkalo!myricae@ny1.hashbang.sh) | |
10:25 | <v4169sgr> incidentally, does anyone know what this means:
| |
10:25 | cat /sys/block/sda/queue/scheduler
| |
10:25 | noop [deadline] cfq
| |
10:26 | Does this mean I am using the deadline scheduler?
| |
10:26 | important for me as my server runs with an SSD on /dev/sda
| |
10:37 | forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Ping timeout: 240 seconds) | |
10:39 | forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at) | |
10:58 | v4169sgr has left IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa, Ping timeout: 240 seconds) | |
10:59 | v4169sgr has joined IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa) | |
11:00 | <alkisg> How is the cpu scheduler related to the disk?!
| |
11:00 | Whooops sorry, misread
| |
11:04 | TatankaT has joined IRC (TatankaT!~tim@193.190.253.114) | |
11:06 | <bcg> v4169sgr: that means you're using deadline.
| |
11:07 | deadline is fine for ssd too.
| |
11:07 | so is cfq.
| |
11:08 | see: https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.9-IO-Scheduler-SSD
| |
11:09 | alkisg: I just found a bug in ltsp-update-kernels. on rhel it might select older kernel because of sort. for example:
| |
11:09 | -rwxr-xr-x. 1 root root 4137728 May 30 19:45 vmlinuz-2.6.32-696.3.1.el6.i686
| |
11:09 | -rwxr-xr-x. 1 root root 4137504 Mar 22 00:34 vmlinuz-2.6.32-696.el6.i686
| |
11:10 | .3.1.el6 is newer but .el6 sorts as last.
| |
11:10 | I'll have to replace "find | sort" with "ls --sort=time" to fix this.
| |
11:11 | forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Read error: Connection reset by peer) | |
11:13 | forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at) | |
11:14 | <v4169sgr> Thanks bcg :)
| |
11:14 | ZAJDAN has joined IRC (ZAJDAN!4d30954b@gateway/web/freenode/ip.77.48.149.75) | |
11:16 | <ZAJDAN> I started to prepare LTSP on pure fresh installation of Debian 9, but first problem which appears during installation dnsmasq: Failed to start dnsmasq -A lighwei...
| |
11:21 | do anybody has experience?
| |
11:22 | Eric2 has left IRC (Eric2!~eric@sdi.iut-valence.fr, Ping timeout: 245 seconds) | |
11:23 | <alkisg> bcg: sort=time doesn't sound good, e.g. if I touch a kernel it'll be newer?
| |
11:24 | <bcg> any better idea?
| |
11:24 | <alkisg> You can define a custom sort function, but depending on file date doesn't sound good
| |
11:24 | ZAJDAN has left IRC (ZAJDAN!4d30954b@gateway/web/freenode/ip.77.48.149.75, Quit: Page closed) | |
11:24 | <bcg> is there "version number" sort? I remember seeing one, somewhere.
| |
11:24 | <alkisg> sort -g
| |
11:25 | sort -v something
| |
11:25 | We already use that, afaik
| |
11:25 | ZAJDAN has joined IRC (ZAJDAN!4d30954b@gateway/web/freenode/ip.77.48.149.75) | |
11:25 | <bcg> ah.yes.
| |
11:25 | find "$tftpname" -mindepth 1 -maxdepth 1 -type f -printf "%f\n" \
| |
11:25 | | sed -n "$KERNEL_NAMES" | sort -k 4,4V -k 3,3rV \
| |
11:25 | nope.
| |
11:26 | i'll fix that in my ltsp-rhel
| |
11:27 | hmm... or is it that V after 4... Anyway, I end up with wrong kernel. I'll debug.
| |
12:02 | problem seems to be in server/ltsp-build-client file, detect_latest_kernel() function. it has:
| |
12:02 | kernelversion="`ls -d $ROOT/lib/modules/2* | sort -nr | head -n1 | xargs basename`"
| |
12:04 | <alkisg> If there's old rhel-specific code around, try to check the generic or the debian/ubuntu code for it instead
| |
12:04 | Faith has joined IRC (Faith!~paty_@unaffiliated/faith) | |
12:04 | <bcg> apparently.
| |
12:04 | <alkisg> We fixed many things when there was no rhel maintainer around...
| |
12:04 | <bcg> generic code seems better.
| |
12:04 | <alkisg> E.g. I don't think we check for 2* anywhere, to detect the kernel version
| |
12:05 | <bcg> I'll just have to fix KERNEL_NAMES define for rhel.
| |
12:06 | rhel-code creates vmlinuz.ltsp and initrd.ltsp symlinks. does generic code create vmlinuz.x86_64?
| |
12:08 | <alkisg> Ideally we want "vmlinuz" and "initrd" symlinks for all distros
| |
12:08 | Then we can have a generic pxelinux.cfg/default for all of them
| |
12:10 | <bcg> is it named just "vmlinuz", no dot-something?
| |
12:10 | I don't have any reference ubuntu-ltsp around...
| |
12:28 | <alkisg> We generate vmlinuz and initrd.img with no dots
| |
12:29 | And we also generate vmlinuz-generic or vmlinuz-generic-pae etc, for different kernel flavors (not versions but flavors), but those don't matter much
| |
13:19 | v4169sgr has left IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa) | |
13:21 | v4169sgr has joined IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa) | |
13:32 | <ZAJDAN> on Debian 9 is ltsp.conf on another place as is usual?
| |
13:33 | because in /var/lib/tftpboot/ltsp/i386/ ...is not
| |
13:36 | forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Ping timeout: 246 seconds) | |
13:38 | forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at) | |
13:38 | ben_nabiy has joined IRC (ben_nabiy!~bennabiy@unaffiliated/bennabiy) | |
13:44 | <ZAJDAN> ahhhh..I forgot, that I have to create the config
| |
13:45 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 255 seconds) | |
13:47 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
13:49 | <v4169sgr> @ZANJAN, one would need to use "ltsp-config lts.conf"
| |
13:55 | <ZAJDAN> v4169sgr.....thnx yes..already created
| |
14:00 | Debian 9 - Epoptes -> thinClient reboot doesnt works (frozen with SQUASHFS error: Unable to read page)
| |
14:11 | erka
| |
14:18 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
14:22 | professor^profes has joined IRC (professor^profes!b104a921@gateway/web/freenode/ip.177.4.169.33) | |
14:22 | <professor^profes> Bom dia
| |
14:26 | <v4169sgr> trying to clean my system:
| |
14:26 | Jun 7 15:24:43 aammscott com.canonical.Unity.Scope.Applications[4006]: (unity-scope-loader:5824): unity-applications-daemon-WARNING **: daemon.vala:1111: Error performing search '': Timeout was reached
| |
14:26 | would suggest disabling global file indexing should be up there in top 10 things to do in fresh installs of 16.04
| |
14:27 | iowait still 25%
| |
14:52 | sutula has left IRC (sutula!~sutula@207-118-157-250.dyn.centurytel.net, Ping timeout: 255 seconds) | |
14:58 | sutula has joined IRC (sutula!~sutula@207-118-149-86.dyn.centurytel.net) | |
15:03 | professor^profes has left IRC (professor^profes!b104a921@gateway/web/freenode/ip.177.4.169.33, Quit: Page closed) | |
15:40 | Statler has left IRC (Statler!~Georg@mail.lohn24.de, Remote host closed the connection) | |
15:40 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
15:46 | lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Remote host closed the connection) | |
15:46 | lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18) | |
15:52 | forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Ping timeout: 240 seconds) | |
15:58 | forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at) | |
16:30 | Eric2 has joined IRC (Eric2!~eric@sdi.iut-valence.fr) | |
17:03 | forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Remote host closed the connection) | |
17:08 | forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at) | |
17:13 | forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Remote host closed the connection) | |
17:16 | forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at) | |
17:26 | forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Remote host closed the connection) | |
17:28 | forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at) | |
17:57 | forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Remote host closed the connection) | |
17:57 | forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at) | |
18:11 | Eric2 has left IRC (Eric2!~eric@sdi.iut-valence.fr, Ping timeout: 246 seconds) | |
18:34 | ben_nabiy has left IRC (ben_nabiy!~bennabiy@unaffiliated/bennabiy, Remote host closed the connection) | |
18:34 | bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Remote host closed the connection) | |
18:35 | bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy) | |
18:45 | <quinox> that file indexer of KDE is annoying -_-
| |
18:45 | I had some serious problems getting it to stop spawning
| |
18:49 | <v4169sgr> you mean beagle? yes the ditro maintainers seem to like that kind of thing. the one behind the dash indexing seems dreadful. luckily it can be turned off in system settings
| |
18:51 | <quinox> mm I think I had trouble with Baloo
| |
18:52 | it seems Beagle was their old indexer
| |
18:52 | it was probably in their list of requirements they had to implement for the new one:
| |
18:53 | "Baloo must suck at least as bad as Beagle at thrashing your harddrive"
| |
18:57 | I use Awesome myself
| |
18:57 | it starts up in like 0.3 seconds
| |
18:58 | those other users that use KDE have to actually wait for their desktop to load
| |
18:58 | they even have to be amused with an animated loader to make it bearable
| |
18:59 | <v4169sgr> imagine what that would do to an ssd ... :P
| |
19:20 | forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Quit: forum) | |
19:23 | <alkisg> Maybe they should have named it Mowgli, he was definately lighter than baloo
| |
19:41 | <||cw> indexing is mostly read right? an ssd would make quick work of it
| |
20:48 | Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving) | |
20:55 | lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Remote host closed the connection) | |
20:56 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
20:59 | v4169sgr has left IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa) | |
21:26 | tek__ has joined IRC (tek__!tek@kapsi.fi) | |
21:26 | sebd_ has joined IRC (sebd_!~seb@aditu.ldd.fr) | |
21:29 | tek_ has left IRC (tek_!tek@kapsi.fi, Ping timeout: 240 seconds) | |
21:29 | sebd has left IRC (sebd!~seb@aditu.ldd.fr, Ping timeout: 240 seconds) | |
21:29 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 240 seconds) | |
21:32 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
21:33 | markus_e92 has left IRC (markus_e92!~markus_e9@62-46-102-74.adsl.highway.telekom.at, Ping timeout: 240 seconds) | |
21:34 | markus_e92 has joined IRC (markus_e92!~markus_e9@62-46-102-74.adsl.highway.telekom.at) | |
21:41 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
21:45 | gehidore has left IRC (gehidore!~username@unaffiliated/man, Ping timeout: 268 seconds) | |
21:48 | gehidore has joined IRC (gehidore!~username@unaffiliated/man) | |
22:46 | GodFather has joined IRC (GodFather!~rcc@2600:1007:b009:c40f:a536:ff49:82f0:9f21) | |
23:43 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Remote host closed the connection) | |
23:43 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
23:48 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 240 seconds) | |
23:54 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |