01:06 | vagrantc_ has left IRC (vagrantc_!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
01:20 | gdi2k has left IRC (gdi2k!~gdi2k@49.145.67.147, Ping timeout: 246 seconds) | |
03:27 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
03:29 | gdi2k has joined IRC (gdi2k!~gdi2k@203.177.136.19) | |
03:52 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@122.55.84.2) | |
03:56 | gdi2k has left IRC (gdi2k!~gdi2k@203.177.136.19, Ping timeout: 264 seconds) | |
04:12 | gdi2k_ has left IRC (gdi2k_!~gdi2k@122.55.84.2, Ping timeout: 264 seconds) | |
04:47 | <map7> Just testing IMAGE_TO_RAM=1 on my debian 11 + LTSP 20.1 and when I add that feature (and run ltsp initrd) I cannot login to my fat-clients
| |
04:47 | When I take the option out again, it's back to normal
| |
04:47 | my fat-clients have 8GB or RAM and my img is 2.9GB
| |
05:19 | <alkisg> map7: that option was implemented/tested by kvaps, who isn't here currently, so maybe you could ask that in the github pull request where the implemenation was
| |
05:20 | <map7> alkisg: cool, I thought I better ask here before doing that.
| |
05:21 | <alkisg> Sure, you did the correct thing, I just have many things atm and I haven't tested that at all, it's a special case... :)
| |
05:21 | !sync
| |
05:21 | <ltspbot> I do not know about 'sync', but I do know about these similar topics: 's', 'sis', 'sound', 'specs', 'sshd', 'suse'
| |
05:23 | <map7> alkisg: Is this the pull request you want me to comment on? https://github.com/ltsp/ltsp/pull/86
| |
05:24 | <alkisg> Yes, sounds fine
| |
05:24 | <map7> cool thanks
| |
05:24 | <alkisg> map7, just out of curiosity, in which case is IMAGE_TO_RAM needed, when server access is required anyway for /home?
| |
05:25 | <map7> alkisg: It's not needed, but I wanted to improve the speed on access of applications and was testing out this solution
| |
05:25 | on first load of libreoffice it's taking 15seconds
| |
05:25 | second loading takes 3seconds
| |
05:26 | <alkisg> You can dd if=image of=/dev/null at boot, and cache all of it
| |
05:26 | and have the same effect as image_to_ram, with the additional benefit that if you ever need that ram, it'll be freed
| |
05:26 | <map7> Do I put that in a POST_ option in ltsp.conf?
| |
05:27 | <alkisg> I think PRE_INITRD_BOTTOM_x would be the easiest one, although POST_INIT_x=dd & with the & to background it would be the best, but it'll be difficult to locate the device then
| |
05:31 | ogra, highvoltage, hi, I want to sync ltsp from debian to ubuntu but I forgot where I kept notes about this, could you tell me the base command to do it, so that I grep through my notes?
| |
05:32 | * alkisg checks dpkg -L ubuntu-dev-tools | |
05:32 | <alkisg> Yey, syncpackage
| |
05:34 | !learn syncpackage as to sync ltsp from unstable to the current Ubuntu development series: syncpackage -d sid ltsp
| |
05:34 | <ltspbot> The operation succeeded.
| |
06:58 | adrianor1 has joined IRC (adrianor1!~adrianorg@177.204.159.122.dynamic.adsl.gvt.net.br) | |
07:01 | adrianorg has left IRC (adrianorg!~adrianorg@187.113.249.171, Ping timeout: 240 seconds) | |
07:23 | woernie_ has joined IRC (woernie_!~werner@pD9E8BE9E.dip0.t-ipconnect.de) | |
07:31 | Klimm has left IRC (Klimm!~Georg@p548973AD.dip0.t-ipconnect.de, Quit: Leaving) | |
07:35 | gvy_ has left IRC (gvy_!~mike@83.220.44.62, Quit: Leaving) | |
07:35 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
07:37 | statler has joined IRC (statler!~Georg@p548973AD.dip0.t-ipconnect.de) | |
10:02 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
10:13 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.19) | |
10:24 | gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.19, Quit: Leaving) | |
10:24 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.19) | |
10:52 | statler_ has joined IRC (statler_!~Georg@gwrz.lohn24.de) | |
10:56 | Teridon has joined IRC (Teridon!~Teridon@dragon.teridon.com) | |
11:12 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
12:39 | gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.19, Ping timeout: 250 seconds) | |
12:43 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.18) | |
13:50 | markit has joined IRC (markit!~marco@mail.ammdomus.it) | |
13:51 | <markit> hi alkisg, I've done a simple test comparison, and now client boots + responsive GUI interface in -20 less, goood job (20.04 "old" config 1'40", now 1'20")
| |
13:52 | just wondering why server VM is able to boot + responsive GUI in 30" and if there is further space to improve. I.e. systemd-analyze blame seems to have a lot of useful info, but maybe I'm wrong (like "11.747s man-db.service")
| |
13:53 | <MWALTERS> netbooting client on a VM hosted by same physical box as the server?
| |
13:54 | <markit> also there is a lot of time with black screen that I wonder what the client is doing/waiting in the meantime
| |
13:54 | <alkisg> Back, reading...
| |
13:54 | markit: do you have access now to such a client/setup?
| |
13:54 | For vnc?
| |
13:54 | <markit> I'm very far from your timings in any case, but I've a different configuration
| |
13:54 | I'm running as "test lab" in my Proxmox VM server
| |
13:55 | <alkisg> 1.20 is a lot, mine are a lot less than 1 min
| |
13:55 | OK, can you vnc to me from there?
| |
13:55 | !vnc-edide
| |
13:55 | <ltspbot> vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
| |
13:55 | <markit> yep, but I'm lazy and I've just boot and take time "visually", if you want I have a 6MB video of the client booting
| |
13:56 | sure, let me run again the server
| |
13:56 | <alkisg> For example man-db shouldn't have run at all
| |
13:56 | It's supposed to be blacklisted in: ltsp/client/init/56-mask-services.sh:man-db.timer # Daily man-db regeneration
| |
13:57 | <markit> also I was building the image and had this message: File /tmp/tmp.2AbkoAV1mI/root/var/cache/apt/pkgcache.bin changed size while reading filesystem, attempting to re-read
| |
13:57 | brb, phone call
| |
13:58 | <alkisg> That's normal if you run apt update while running ltsp image
| |
14:07 | <markit> back
| |
14:07 | yep, but apt update is automatic and wondering why it takes /tmp in consideration
| |
14:08 | but back to our problem
| |
14:08 | cennected
| |
14:08 | <alkisg> markit: rootfs, /, is bind-mounted there in tmp for the ltsp image
| |
14:08 | <markit> let me know when you wamt me to run the client
| |
14:08 | <alkisg> bind mount means that the same path is in two places
| |
14:14 | markit: ok reboot client
| |
14:14 | <markit> ok
| |
14:14 | <alkisg> You had put my optimizations inbetween of your sddm configuration, so that destroyed ltsp.conf
| |
14:15 | <markit> I saw :(
| |
14:15 | login reached after 42"
| |
14:15 | <alkisg> OK, that sound better
| |
14:16 | <markit> I've configured for NFS home
| |
14:17 | <alkisg> You haven't configured the client part
| |
14:17 | You had only done the server part
| |
14:17 | I.e. FSTAB in ltsp.conf
| |
14:17 | <markit> my misunderstanding of the whole stuff :(
| |
14:18 | <alkisg> This one needed to be uncommented: FSTAB_HOME="server:/home /home nfs defaults,nolock 0 0"
| |
14:21 | <markit> tell me what to type
| |
14:21 | I see you can't quit that program
| |
14:23 | <alkisg> Something is wrong with epoptes there, but let's leave that for later
| |
14:25 | I tested with .iso images and not with the chrootless case
| |
14:25 | So I might have omitted some more services like nfs-kernel-server
| |
14:25 | Let's see
| |
14:28 | <markit> pws is ltsp101
| |
14:29 | <alkisg> Login needs less than 20', not bad
| |
14:29 | <markit> really :)))
| |
14:30 | user is amministratore
| |
14:33 | the 'infamous' kde icon cache... there is one in each user .cache also
| |
14:34 | <alkisg> If we include it in the image, will it get regenerated anyway?
| |
14:34 | Or it only gets regenerated one time?
| |
14:34 | <markit> I think that the problem is that in any case it search through all the icons to check if something has changed, and it's a hell of I/O
| |
14:35 | probably less I/O than if it has to recreate it, but I should test. I.e. if you look at the user *.kcache, and run a new kde program, the timestamp of .kcache change
| |
14:36 | so I think that at boot time it creates the .kcache with the icons it used to run the login and desktop, then it updates it
| |
14:37 | <alkisg> The first 100 MB is the kernel/initrd now, they grew too big because of the amdgpu and other drivers
| |
14:37 | gdi2k_ has left IRC (gdi2k_!~gdi2k@203.177.136.18, Ping timeout: 250 seconds) | |
14:37 | <markit> do you want me to login in the client?
| |
14:38 | <alkisg> Only 202 to login? Woah that's very little!
| |
14:38 | I was getting more :)
| |
14:38 | No wait there
| |
14:38 | And that includes the sddm traffic
| |
14:38 | All is fine then
| |
14:39 | It's strange that the date there isn't the current one
| |
14:40 | So it's like they're opening it without actually writing anything... meh
| |
14:40 | OK anyway it seems faster than mate now :D
| |
14:40 | <markit> icon-cache.kcache is
| |
14:40 | <alkisg> Play a bit with it and tell me timings etc
| |
14:40 | <markit> ok, thanks a lot for fixing and improving my configuration
| |
14:40 | <alkisg> 15:39:11 vs 14:26
| |
14:40 | It's not the same time
| |
14:41 | np, thank you too for sponsoring the last release markit
| |
14:41 | <markit> btw, I've seen that tplink has a "not too costly" 24 Gbit port + 4 10Gb spf+ ports...
| |
14:41 | <alkisg> For now, I'll be using 2*1 Gbps bond on the servers, and plain full gigabit switches
| |
14:41 | As the government ordered a whole lot of new servers and switches for ltsp
| |
14:42 | In the next hardware update after 10 years, we'll see :)
| |
14:42 | Now at least we got rid of all pentium 3's and some p4's
| |
14:42 | <markit> Tplink T1700G-28TQ if you are curious :) ok, time to review your changes, update my "install notes" and do some tests
| |
14:42 | (TQ is fanless)
| |
14:43 | <alkisg> Sounds good :)
| |
14:44 | <markit> btw2: when I connect with socat SYSTEM:"sleep 1 && exec screen -xRR ra",pty,stderr tcp:<ip_ass_remota>:5500 & screen -l -S ra
| |
14:45 | then the X-term in my home PC seems not to like a lot of keyboard combinations
| |
14:45 | is really hard to work with emacs / nano or whatever, and nor TAB for bash completion works... is it normal?
| |
14:47 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
14:49 | <alkisg> markit: I think kubuntu is exposing some variable like TERM that screen/socat don't like, that's why I was having the issue with keyboard there,
| |
14:49 | but we'll have to look into this another time, as I'm working on something else currently...
| |
14:50 | <markit> sure, have a nice day :)
| |
14:51 | <alkisg> You too, do ping if something goes wrong with ltsp though :)
| |
15:25 | <fiesh> oh god tplink
| |
15:25 | apart from sony the only brand I will *never ever* buy anything again
| |
15:25 | my advice: don't buy it, you'll regret it, no matter what it is
| |
15:57 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
15:57 | <markit> fiesh: why? I usually buy netgear but I think are also cheap
| |
15:59 | <MWALTERS> I've been turned off netgear after this 48port poe switch I have... web interface doesn't work in any modern browser =/
| |
16:00 | <markit> MWALTERS: I've worked for some month for a municipality that had expensive HP Procurve... with web interfaces requiring Java for some features :(
| |
16:01 | MWALTERS: so the problems is (not only) the brand, but mainly their williness to keep things updated
| |
16:02 | <MWALTERS> yeah, it's not unusual, unfortunately =/. We only have 1 of those netgears, and I just keep it around for emergencies. We mostly have a bunch of cisco SGP small business switches
| |
16:02 | <markit> tplink seems have a LOT of features. I've tested (but not for ltsp) their 24 x 1Gb port and worked fine so far
| |
16:02 | <MWALTERS> I've replaced all of our routers with ubiquiti edge routers, which have been great... probably gonna go with edgeswitches when I need to buy switches in the future
| |
16:03 | They're like... $900usd for 500w 48p poe+... the web interface works well... and the cli works great too.
| |
16:03 | shored has left IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi, Read error: Connection reset by peer) | |
16:04 | <MWALTERS> But yeah, you're right. My supermicro servers all require java for the silly remote console thing in the iLO =/
| |
16:04 | My thoughts: never let a firmware developer also develop the web admin interface ;)
| |
16:06 | shored has joined IRC (shored!~shored@87-92-92-55.bb.dnainternet.fi) | |
16:44 | <alkisg> TPLINK tl-sg1024de is one of the cheapest managed switches that I've seen, with flow control=off by default, so we've bought hundreds of them, and in 5+ years only one port of all these switches has failed
| |
16:44 | It even reports "the cable in that port has problems" and the cable length etc
| |
16:45 | vagrantc: ltsp 20.03 synced to ubuntu 20.04 and to the stable ppa, ty
| |
17:09 | <markit> alkisg: hi, I've looked at systemd-analyze blame and found 2 more services that eat time and are useless, added in MASK_SYSTEM_SERVICES, they are wpa_supplicant pppd-dns
| |
17:29 | statler_ has left IRC (statler_!~Georg@gwrz.lohn24.de, Remote host closed the connection) | |
17:33 | <fiesh> must be random variance in the quality of tplink products... the ones I had all sucked horribly
| |
18:05 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
18:30 | <markit> alkisg: I've kdeconnect (/etc/xdg/autostart/org.kde.kdeconnect.daemon.desktop) that starts in the client even if I have MASK_SESSION_SERVICES=org.kde.discover.notifier org.kde.kdeconnect.daemon
| |
18:31 | Also discover seems was running anyway, I had to purge it
| |
18:31 | am I doing something wrong? seems they are "dbus" services and not easy to disable, but I don't really know what am I talking about
| |
18:32 | <quinox> does it start before you log in?
| |
18:32 | <markit> let me try
| |
18:32 | <quinox> I would think that KDE starts all sorts of shit as soon as you login with a KDE session
| |
18:33 | <markit> quinox: sure
| |
18:33 | i can't remove it due to a tons of dependencies
| |
18:33 | <quinox> I hate Mate, I don't use it but whenever you install it it will overwrite your Firefox homepage with a Mate URL >:(
| |
18:35 | I install all the Desktops / Window managers that people want, so my image contains at least 4 different ones at all times
| |
18:35 | <MWALTERS> just make them all use i3
| |
18:35 | <markit> quinox: yep, after login
| |
18:37 | MWALTERS: have a look at supermicro latest firmware for your MB, they intruduced HTML5 console recently
| |
18:40 | <MWALTERS> oh, thanks... I'll have to actually look at that
| |
18:40 | :)
| |
19:03 | <markit> alkisg: in 56-mask-services I find this line "re rm -f "/etc/xdg/autostart/$service.desktop" \" ... what does "re" stand for? seems not to be a command
| |
19:11 | <alkisg> back, reading...
| |
19:13 | markit, previously /etc/xdg/autostart was used, now there's a trend to migrate everything to systemd user services,
| |
19:13 | and, there's also desktop-environment-specific dirs for autostart
| |
19:13 | "re" means "run and exit on error"
| |
19:13 | It's a shell function in /usr/share/ltsp/ltsp
| |
19:14 | Did you remember to run `ltsp initrd` after modifying ltsp.conf?
| |
19:15 | MASK_SESSION_SERVICES=org.kde.discover.notifier org.kde.kdeconnect.daemon => remember to use quotes
| |
19:15 | A=B C in shell means:
| |
19:15 | Set A=B, and run C with A in the environment
| |
19:15 | MASK_SESSION_SERVICES="org.kde.discover.notifier org.kde.kdeconnect.daemon"
| |
19:24 | <markit> alkisg: quotes are there, dinner time, I will take one more look later, thanks
| |
19:25 | btw, for systemservices adding "wpa_supplicant pppd-dns" worked fine, some less seconds for boot :)
| |
19:26 | <alkisg> markit: sure, but we can't disable these by default as some people might want to use wifi or ppp with ltsp clients
| |
19:27 | <markit> you remarked the line POST_INIT_SWAPPINESS="sysctl vm.swappiness=10"
| |
19:28 | is it not userful at all?
| |
19:28 | <alkisg> In general, setting swappiness usually harms rather than helps
| |
19:28 | So I wanted to test with the defaults first
| |
19:28 | If you see that it helps, np, use it
| |
20:29 | Teridon has left IRC (Teridon!~Teridon@dragon.teridon.com, Remote host closed the connection) | |
20:51 | Klimm has joined IRC (Klimm!~Georg@p54897080.dip0.t-ipconnect.de) | |
20:52 | statler has left IRC (statler!~Georg@p548973AD.dip0.t-ipconnect.de, Ping timeout: 256 seconds) | |
21:17 | woernie_ has left IRC (woernie_!~werner@pD9E8BE9E.dip0.t-ipconnect.de, Remote host closed the connection) | |
22:55 | <map7> alkisg: I did the caching the when I benchmark starting libreoffice it still takes the same amount of time.
| |
22:55 | PRE_INITRD_BOTTOM_IMAGE_TO_RAM="dd if=/root/images/x86_64.img of=/dev/null"
| |
22:56 | I upgraded to 20.3 this morning and that helped a little (15secs -> 9secs on a cold start of libreoffice)
| |
22:56 | 2secs on a warm start
| |
22:57 | <markit> map7: just curious, why dd in /dev/null?
| |
22:58 | <map7> that's what alkisg said to do if I want to cache the image to memory, but I would of thought it would just throw it away if anything goes to /dev/null
| |
22:59 | markit: I tried IMAGE_TO_RAM=1 but then my fat-client doesn't boot
| |
23:00 | <markit> map7: are you using the last version of ltsp, so only "fat, chrootless" clients are supported, right?
| |
23:01 | <map7> yes I'm using ltsp 20.3 from PPA on Debian bullseye (testing)
| |
23:02 | yesterday I was on 20.1
| |
23:02 | The IMAGE_TO_RAM wasn't booting on 20.1
| |
23:02 | I'm just testing now with 20.3 to see if that's fixed
| |
23:03 | <markit> btw, how much ram do you have on the client?
| |
23:03 | <map7> 8GB
| |
23:03 | <markit> urgh!
| |
23:03 | <map7> and my image is 2.9GB
| |
23:04 | The image seems to copy to ram, but the boot process stops at 'A start job is running for /home'
| |
23:05 | I do have this in my config: FSTAB_HOME="server:/home /home nfs defaults,nolock 0 0"
| |
23:05 | <markit> map7: what is your goal? Mine is improve boot and login performance with Kde (kubuntu 20.04), and speed in general
| |
23:05 | map7: and you have NFS enabled on the server side too? /etc/exports.d/ltsp-nfs.exports
| |
23:05 | <map7> same goal, but I'm running debian + xfce4
| |
23:06 | yes I do have NFS enabled
| |
23:06 | it all works if I don't use the image_to_ram
| |
23:06 | just slow
| |
23:06 | <markit> define slow :)
| |
23:06 | <map7> There is a blank screen before the login for about 15secs
| |
23:06 | libreoffice takes 9seconds to load on a cold boot
| |
23:07 | 2seconds on a warm start
| |
23:07 | It has to be better performance than our current LTSP5 thin client setup otherwise we won't go with fat-clients for now
| |
23:08 | We have a powerful server so our thin-clients start programs like libreoffice very fast
| |
23:08 | <markit> just tested my libreoffice cold start, 16 seconds (test environment, a VM for server, one as client)
| |
23:08 | <map7> yes that's slow
| |
23:09 | <markit> it's a matter of disk I/O I suppose
| |
23:09 | <map7> On our thin-clients (using the same server but different VM) it loads libreoffice in 1.5seconds
| |
23:09 | both VM's are on the same disk
| |
23:10 | same IO
| |
23:10 | <markit> do you have a fast connection with the switch? Have you tested with epoptes test the lan bandwidth?
| |
23:10 | <map7> same network
| |
23:10 | I have a 10Gbit switch for the server and each client (5 thin clients) have a 1Gbit connection to that server
| |
23:11 | <markit> thin clients just transfer screen, not the program and also have direct access to home, not through NFS
| |
23:12 | libreoffice warm start here 2 seconds too
| |
23:12 | <map7> Just testing the fat-client connection speed now
| |
23:13 | <markit> I've iftop to see how much traffic, but don't know how to check how much disk I/O with a sum (iotop -o is just in "real time")
| |
23:14 | map7: NFS is much worse in I/O than direct I/O, and seems that now that programmers have SSD, they care less and less about optimization of it
| |
23:14 | <map7> I'm getting 942Mbps down, 940Mbps up to that client
| |
23:15 | <markit> loading Libreoffice is about 80MB (from server to client) and 5MB in the other direction
| |
23:16 | <map7> Just timed the blank screen before login and it was 33seconds that boot
| |
23:17 | <markit> wondering if a NFS optimization could help, but I see there already "async" parameter
| |
23:17 | map7: try in the client systemd-analyze blame
| |
23:18 | you could find some service that slows thing down and are useless
| |
23:19 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@203.177.136.19) | |
23:19 | <markit> also systemctl status should have no errors
| |
23:19 | you could have some service that has problems and wastes time
| |
23:20 | dmesg also could help
| |
23:21 | <map7> systemctl status says 'State: degraded'
| |
23:22 | <markit> if is nfs, use this line in ltsp.conf: MASK_SYSTEM_SERVICES="nfs-kernel-server wpa_supplicant pppd-dns"
| |
23:23 | (well, the last 2 services are useless for me, so you can just stay with nfs-kernel-server)
| |
23:23 | to see what is the problem, systemctl failed
| |
23:23 | (just learned watching alkisg troubleshoot my server this afternoon, lol)
| |
23:24 | <map7> cool
| |
23:25 | checked 'systemctl' and found it is nfs-server failing
| |
23:26 | Also in 'dmesg' it's complaining about a missing firmware for my NIC
| |
23:27 | <markit> map7: firmware should not be a problem, maybe you can't have certain features, or is not really stable without it, but should be fine since you tested it and was almost at 1Gb/s
| |
23:29 | now I try sync; echo 3 > /proc/sys/vm/drop_caches and then warm run again of libreoffice
| |
23:30 | again 15 seconds, so is really the time it takes to fetch the image from the server :(
| |
23:30 | 80MB at 1Gb/s should be 1 second of transfer
| |
23:31 | <map7> hmmm, could be NFS speed
| |
23:32 | <markit> I've run iotop -o on the server, and there has been NO I/O during the client libreoffice load (probably server caches that too)
| |
23:32 | so seems only a matter of NFS access to the compressed image... maybe the compress algorithm is not optimal?
| |
23:33 | let's have a look at client CPU also
| |
23:33 | mmm does not seem to be saturated during LiBo loading
| |
23:34 | I think only alkisg can save us :)
| |
23:35 | <map7> after adding the firmware and disabling those three services the blank screen is still taking 30seconds
| |
23:38 | my client is running an i3-7100U @ 2.4Ghz
| |
23:38 | Intel HD graphics 620
| |
23:38 | it's pretty new
| |
23:41 | <markit> I'm googling for nfs3 optimization
| |
23:41 | netstat -s (client side) could give info about network problems
| |
23:41 | <map7> markit: I now have an error free systemctl status and no errors in my dmesg at all
| |
23:41 | same slow speed
| |
23:45 | <markit> you can see what is "wrote" during boot by the client having a look at /run/initramfs/ltsp/0/up
| |
23:45 | using du -csh you can see how many MB
| |
23:47 | <map7> 16MB
| |
23:49 | My NFS mount is;
| |
23:49 | server:/home /home nfs defaults,nolock 0 0
| |
23:52 | <markit> map7: I've instead the default one generated by ltsp command
| |
23:53 | ah, sorry, in ltsp.conf, ok
| |
23:53 | but I think loading libo is a matter of fetching it's executable from the image file
| |
23:53 | <map7> FSTAB_HOME="server:/home /home nfs defaults,nolock 0 0"
| |
23:53 | Yes I agree
| |
23:54 | I don't think it has to do with my FSTAB_HOME line
| |
23:54 | <markit> cat /etc/exports.d/ltsp-nfs.exports
| |
23:54 | <map7> It's either NFS or the image file compression as you said
| |
23:54 | <markit> that has /srv/ltsp *(ro,async,crossmnt,no_subtree_check,no_root_squash,insecure)
| |
23:55 | but don't understand how is used by the client, is not listed if I use the "mount" command in the client
| |
23:55 | (I can only see home mounted as nfs4 protocol, and rsize=262144,wsize=262144 that look strange value to me)
| |
23:57 | <map7> my rsize & wsize on home NFS4 is 1048576
| |
23:58 | <markit> nfsstat -r shows 0 retransmissions
| |
23:59 | <map7> same
| |
23:59 | <markit> I think that a) the image is compressed, so it needs time to decompress what has been transfered b) nfs is not that efficient
| |