IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 2 November 2015 (all times are UTC)
| 00:17 | Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas) | |
| 00:17 | fede2 has joined IRC (fede2!~alvaro@186.176.20.162) | |
| 00:22 | FrozenZia has left IRC (FrozenZia!pbrown@evo.paivola.fi, Ping timeout: 260 seconds) | |
| 00:23 | FrozenZia has joined IRC (FrozenZia!pbrown@evo.paivola.fi) | |
| 00:24 | fede2 has left IRC (fede2!~alvaro@186.176.20.162, Ping timeout: 256 seconds) | |
| 02:18 | work_alkisg is now known as alkisg | |
| 02:19 | <alkisg> vagrantc: I don't get it. set_lts_var was invented in order to save a variable, and that's why I updated the code to use it, instead of >>ltsp_config
| |
| 02:20 | Why do you think that reimplementing set_lts_var is better in this case?
| |
| 02:24 | ltsp_config.d scripts calculate and store variables to be used later on in various boot/login phases of ltsp clients. init-ltsp.d is one of the phases. init-ltsp.d scripts don't store variables, they use them to do a one-time initialization.
| |
| 02:25 | So, storing the value of LTSP_CLIENT_MAC belongs in ltsp_config.d, not in init-ltsp.d. Right?
| |
| 02:27 | Sure, the distinction there is a bit fuzzy, and it would be better if the scripts for all phases were allowed to calculate and store configuration values (i.e. if we completely merged ltsp_config.d into init-ltsp.d), but that's not how it is now, there's no "set_lts_var" in init-ltsp.d scripts at all...
| |
| 02:28 | <vagrantc> it seems like a static, non-changeable thing, like the root server ... so it doesn't seem like configuration in the same way that lts.conf is...
| |
| 02:29 | ltsp_config.d is basically an extension of lts.conf
| |
| 02:30 | when ltsp5 happened, mdz basically implemented "eval $(getltscfg -a)" and poof, all the variables are now always exported ...
| |
| 02:30 | in ltsp4, VAR1=$(getltscfg VAR1) was used more ...
| |
| 02:31 | alkisg: set_lts_var seemed needlessly complex ...
| |
| 02:31 | <alkisg> $ grep set_lts_var 45nc-q-compat
| |
| 02:31 | set_lts_var nc_q_param "$nc_q_param"
| |
| 02:31 | <vagrantc> alkisg: so i guess i've never been convinced of it's need
| |
| 02:31 | <alkisg> How is the mac address different than e.g. nc_q_param?
| |
| 02:31 | They're both "static"...
| |
| 02:32 | I'm all in for removing ltsp_config.d. But that's what we have now, there's no point in re-implementing set_lts_var in all scripts where we want to save state...
| |
| 02:34 | In the future, I'd like it if the server was sending code to the clients instead of .ini-style configuration values (even if the code was just VAR=value)
| |
| 02:34 | Our "run-parts" function at various boot phases would have one step for loading state, and one in the end for saving it
| |
| 02:34 | And the "set_lts_var" function would store the state in a variable, until it's saved in a file at the end of the phase
| |
| 02:35 | i.e. it would be more efficient, and allowed in any of the boot/login phases
| |
| 02:35 | But I see no point in the code doing >>file to save the state instead of using a function
| |
| 02:36 | <vagrantc> i suppose the function could then change the backend more easily
| |
| 02:36 | so sure.
| |
| 02:37 | but it was really a one-line diff to get it working where it was
| |
| 02:41 | <alkisg> But I was wrong to put it in init-ltsp.d when I implemented it, and I fixed my mistake...
| |
| 02:41 | Having a small line diff is not better than improving the code
| |
| 02:43 | At the time, I hadn't realized what set_lts_var was designed for, that's why I wrongly re-implemented it and put it in init-ltsp.d
| |
| 02:50 | * alkisg thinks that in this case vagrantc is thinking more like a debian maintainer, minimizing the diff in patches, rather than as an upstream programmer, maintaining/increasing the code quality... :) | |
| 02:52 | * vagrantc doesn't see a move from init-ltsp.d as improving code quality | |
| 02:52 | <vagrantc> seems like a regression to a deprecated mechanism
| |
| 02:53 | <alkisg> So, if I did the opposite, i.e. took all the code from ltsp_config.d that uses set_lts_var and put it to init-ltsp.d and made it use >>ltsp_config, it would improve quality?! :)
| |
| 02:53 | <vagrantc> the code used to just set and export the variables... then someone wanted to make it complicated and cache the variables for a virtually unmeasurable performance increase
| |
| 02:55 | and then someone wanted to change the variables at every run ...
| |
| 02:55 | <alkisg> When we have 10 places that uses function_x and 1 place that reimplements function_x, merging those improves the code.
| |
| 02:55 | If function_x is badly designed, that a different issue that needs to be addressed in all 11 places at once, or maybe at 1 point in a library
| |
| 02:55 | <vagrantc> so it needed a way to ignore the cache...
| |
| 02:56 | <alkisg> So my commit is not about endorsing set_lts_var, it's about consistency. If we don't want set_lts_var we can remove it in a separate commit for wherever it's used.
| |
| 02:56 | But I think set_lts_var is nice, it's the ltsp_config.d that shouldn't exist
| |
| 02:56 | (dir)
| |
| 02:58 | I don't think set_lts_var is deprecated, I think ltsp_config.d/ should become deprecated when ltspd is implemented.
| |
| 02:58 | <vagrantc> ltsp_config.d should have become deprecated when we implemented init-ltsp.d ...
| |
| 02:59 | but that's when we lost steam and development slowed...
| |
| 02:59 | <alkisg> Gadi implemented set_lts_var exactly at that time though
| |
| 02:59 | * vagrantc shrugs | |
| 02:59 | <alkisg> When I proposed init-ltsp.d, that's exactly when Gadi implemented set_lts_var
| |
| 02:59 | But it's not a bad thing, we don't have to change it
| |
| 03:00 | When we standarize the ltsp phases, we'll see that we have e.g. 10 places where ltsp code runs
| |
| 03:01 | In the initramfs, in init-ltsp.d, when services start, when xorg starts, before login, etc etc
| |
| 03:01 | All those dirs will be similar to init-ltsp.d, and will be ran by something like run-parts
| |
| 03:01 | <vagrantc> after working with it for years, and having to figure out what does what every time i look at that part of the code, i can't really agree that it doesn't need a complete rethinking
| |
| 03:02 | <alkisg> So, that run-parts function will automatically load/save the state we want
| |
| 03:02 | <vagrantc> alkisg: that sounds good, though, yes.
| |
| 03:02 | <alkisg> No ltsp-config.d necessary. I think that's where we have the problem, in the fact that ltsp_config.d exists.
| |
| 03:02 | <vagrantc> you should have seen it before ltsp_config.d existed
| |
| 03:03 | one big file with all those hacks
| |
| 03:03 | <alkisg> set_lts_var will still be there, we won't change the calls. We'll only change the implementation a bit for efficiency, to temporarily use RAM instead of files, and let the run-parts function then use files.
| |
| 03:03 | <vagrantc> figuring out what the difference between cache/ltsp_config and cache/ltsp_config_env are has always baffled me
| |
| 03:03 | didn't have that confusion prior to set_lts_var
| |
| 03:04 | <alkisg> So what I'm saying is that I don't think using set_lts_var/ltsp_config.d now is a bad thing or a regression. ltsp_config.d should be removed in the future, yes, but that's a completely different step.
| |
| 03:04 | Using set_lts_var now makes it easier to remove ltsp_config.d in the future.
| |
| 03:05 | The ltsp_config file should probably be removed, the initramfs can use ltsp_config_env instead
| |
| 03:11 | Eh. We removed its use from the initramfs. We can just remove the 3 files that still use it and replace it with set_lts_var.
| |
| 03:13 | So we just need 3 more commits like the one I did yesterday :D
| |
| 03:16 | I think that initially, cache/ltsp_config was designed to pass values from the initramfs to ltsp_config.d and init-ltsp.d
| |
| 03:16 | Because it was possible that ltsp_config_env would be there since ltsp-build-client/ltsp-chroot, and it might contain invalid values
| |
| 03:17 | Then cache/ltsp_config was misunderstood/remembered wrongly by a few developers (myself included) and misused to store stuff from init-ltsp.d/ltsp_config.d
| |
| 03:17 | Those commits should be fixed. The mac thing was one of them.
| |
| 03:18 | Then, to go back a step and solve the initramfs issue, we should completely stop using /var/cache and switch to /run
| |
| 03:18 | We don't want that state remembered across reboots, /var/cache is the wrong place to put it
| |
| 03:19 | That also means that we don't need 01-clean-cache, /run is always cleared, only the initramfs can store things there
| |
| 03:23 | this helps to visualize the issues I'm talking about: ltsp-trunk$ grep -r /var/cache/ltsp/ltsp_config .
| |
| 03:25 | Better yet, $ grep -r /var/cache/ltsp .
| |
| 03:25 | /client/Debian/share/initramfs-tools/scripts/init-bottom/ltsp:mkdir -p "$rootmnt/var/cache/ltsp/"
| |
| 03:25 | ./client/Debian/share/initramfs-tools/scripts/init-bottom/ltsp: cp "$netconf" "$rootmnt/var/cache/ltsp/"
| |
| 03:26 | See, these lines only exist because we're using the wrong dir, cache instead of run, where netconf is already there and automatically moved
| |
| 03:26 | all the bind-mount things also are not needed if we switch to /run
| |
| 03:27 | And all the init-ltsp.d that use cache, should be changed to use set_lts_var
| |
| 03:27 | *scripts
| |
| 03:32 | vagrantc: if you agree, I'll file a bug report about switching /var/cache/ltsp to /run/ltsp and another one about dropping /var/cache/ltsp/ltsp_config, and we can implement them when we have time.
| |
| 03:35 | * alkisg waves for now, later... :) | |
| 03:35 | alkisg is now known as work_alkisg | |
| 03:44 | <vagrantc> work_alkisg: sounds fine
| |
| 03:44 | it's historical ... /var/cache/ltsp predates the existance of /run
| |
| 03:45 | arguably, /var/run might have been a better place for that stuff ... which would mean we'd still be in a better position
| |
| 03:45 | since in think /var/run is just a symlink to /run
| |
| 04:46 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 05:36 | work_alkisg is now known as alkisg | |
| 06:08 | ricotz has joined IRC (ricotz!~ricotz@p5B2A89EE.dip0.t-ipconnect.de) | |
| 06:08 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 07:04 | <alkisg> !raspberrypi
| |
| 07:04 | <ltsp`> raspberrypi: (#1) LTSP with raspberry pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#2) To use a similar environment to LTSP on the raspberry pi http://berryterminal.com/, or (#3) https://github.com/gbaman/RaspberryPi-LTSP, or (#4) https://pi-ltsp.net
| |
| 07:04 | <alkisg> !forget raspberrypi 2
| |
| 07:04 | <ltsp`> The operation succeeded.
| |
| 07:07 | <alkisg> !raspberry pi
| |
| 07:07 | <ltsp`> I do not know about 'raspberry pi', but I do know about these similar topics: 'raspberrypi'
| |
| 07:07 | <alkisg> !raspberrypi
| |
| 07:07 | <ltsp`> raspberrypi: (#1) Ubuntu/LTSP on Pi 2: https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi, or (#2) Debian/LTSP (with raspbian chroot) on Pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#3) unofficial Ubuntu/LTSP (with raspbian chroot) on Pi: http://pinet.org.uk/
| |
| 07:49 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
| 08:13 | yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be) | |
| 08:17 | adrianorg has left IRC (adrianorg!~adrianorg@179.187.28.197.dynamic.adsl.gvt.net.br, Ping timeout: 244 seconds) | |
| 08:18 | adrianorg has joined IRC (adrianorg!~adrianorg@187.113.244.122) | |
| 08:30 | sutula has left IRC (sutula!~sutula@207-118-152-139.dyn.centurytel.net, Ping timeout: 240 seconds) | |
| 08:35 | sutula has joined IRC (sutula!~sutula@207-118-162-188.dyn.centurytel.net) | |
| 08:42 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 250 seconds) | |
| 08:44 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 08:55 | gdi2k has left IRC (gdi2k!~gdi2k@180.191.106.186, Quit: Ex-Chat) | |
| 09:02 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 256 seconds) | |
| 09:09 | yanu has left IRC (yanu!~yanu@178-116-58-90.access.telenet.be, Quit: Lost terminal) | |
| 09:17 | eemeli has joined IRC (eemeli!3e94cd0c@gateway/web/freenode/ip.62.148.205.12) | |
| 09:17 | eemeli has left IRC (eemeli!3e94cd0c@gateway/web/freenode/ip.62.148.205.12, Client Quit) | |
| 09:19 | yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be) | |
| 09:24 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 09:49 | schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de) | |
| 10:00 | schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, Read error: Connection reset by peer) | |
| 10:00 | schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de) | |
| 10:01 | schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, Read error: Connection reset by peer) | |
| 10:02 | schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de) | |
| 10:07 | schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, Remote host closed the connection) | |
| 10:29 | schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de) | |
| 10:34 | schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, Ping timeout: 244 seconds) | |
| 10:36 | nataraj has joined IRC (nataraj!7aa6e4aa@gateway/web/freenode/ip.122.166.228.170) | |
| 10:37 | <nataraj> Hi
| |
| 10:37 | where do I put ltsp-x86_64.ks, in rhel7?
| |
| 10:38 | <alkisg> Unfortunately not many people are using rhel with ltsp these days... mostly .deb-based distros
| |
| 10:39 | <nataraj> well, what about this kickstart thing? will it install the server and client?
| |
| 10:39 | <alkisg> No idea, but I haven't heard of anyone succeeding with installing ltsp on rhel here for the few past years
| |
| 10:40 | .deb-based distros don't have kickstart files so personally I don't even know what that is...
| |
| 10:40 | I do know that we didn't have any upstream commits for fedora/rhel in years... so it should be very broken now
| |
| 10:43 | <nataraj> itc, where do i start for building the server ? ltsp-5.4.5.tar.xz
| |
| 10:44 | <alkisg> You won't be able to, unless you plan to be an ltsp developer + maintainer for rhel
| |
| 10:44 | You'll need to change your distribution to use ltsp
| |
| 10:45 | <nataraj> well, wont it work on any kinda linux?
| |
| 10:45 | <alkisg> No
| |
| 10:45 | <nataraj> need to get source and compile. Right?
| |
| 10:45 | <alkisg> No
| |
| 10:45 | It has much distro-specific code
| |
| 10:45 | It's not an application. It's a glue to make the distro netboot
| |
| 10:46 | So distributions that want to support ltsp, have "ltsp maintainers"
| |
| 10:46 | <nataraj> what about the fedora stuff?
| |
| 10:46 | <alkisg> The last rhel ltsp maintainer left years ago
| |
| 10:46 | Only .deb-based distros are supported currently. And opensuse has something similar, kiwi-ltsp.
| |
| 10:46 | <nataraj> ok, you already told
| |
| 10:46 | <alkisg> No fedora, no rhel support.
| |
| 10:46 | (I already told that as well :))
| |
| 10:47 | <nataraj> what about archlinux?
| |
| 10:47 | <alkisg> Does it use .deb?
| |
| 10:47 | Nope
| |
| 10:47 | So no, not supported.
| |
| 10:47 | Debian, Ubuntu, LinuxMint, that stuff.
| |
| 10:47 | <nataraj> what if i have a vm that runs debian? will ltsp do pxe from the vm debian?
| |
| 10:48 | <alkisg> Yes
| |
| 10:48 | <nataraj> any particular debian?
| |
| 10:49 | <alkisg> Nope, debian stable or ubuntu 14.04 are fine
| |
| 10:49 | !ltsp-pnp
| |
| 10:49 | <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
| |
| 10:49 | <alkisg> That one is quite easy to follow.
| |
| 10:51 | brb
| |
| 10:51 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 10:51 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 10:54 | <nataraj> alkisg, you suggest the ubuntu install over debian?
| |
| 10:54 | <alkisg> nataraj: I maintain the greek schools ppa (mentioned in that page), so I'm certain that it works and I can support users more easily there
| |
| 10:55 | Debian is fine as well, but yes, I suggest Ubuntu first
| |
| 10:55 | <nataraj> ok
| |
| 10:55 | is there a kinda minimal install for ubuntu?
| |
| 10:56 | <alkisg> I'm not sure that you'll want that, better start with telling us about your use case
| |
| 10:56 | <nataraj> i used to work on debian till 2010. Switched to archlinux since
| |
| 10:56 | <alkisg> How many clients, what's their cpu/ram?
| |
| 10:56 | <nataraj> well, presently its for a testing purpose of just 10 clients
| |
| 10:57 | <alkisg> CPU/RAM of the clients?
| |
| 10:57 | <nataraj> cpu/ram are decent
| |
| 10:57 | <alkisg> Then my suggestion is this:
| |
| 10:57 | create a vm in archlinux in bridged mode,
| |
| 10:57 | and follow the ltsp-pnp page exactly
| |
| 10:58 | You'll get a full ubuntu environment, both in the vm and on the clients, with minimal downloading + size
| |
| 10:58 | <nataraj> i3/4G
| |
| 10:58 | <alkisg> They'll work as "ltsp fat clients", meaning that they'll load the OS from the VM server, but they'll run it locally, with only /home persistent on the server
| |
| 10:59 | This is the best mode for decent clients. You can fall back to thins by specifying a directive in a configuration file, LTSP_FATCLIENT=False in lts.conf.
| |
| 10:59 | <nataraj> that seems good enough
| |
| 11:02 | go for Ubuntu 12.10?
| |
| 11:03 | <alkisg> No, use only LTS releases
| |
| 11:03 | And 12.10 is very old
| |
| 11:03 | Use 14.04
| |
| 11:04 | LTS releases are: 12.04 (older), 14.04 (current), 16.04 (not ready yet)
| |
| 11:04 | <nataraj> may i have a link, if you dont mind :)
| |
| 11:04 | <alkisg> Is there a chance that you'll want to netboot an i386 client? Not amd64 capable?
| |
| 11:05 | http://www.ubuntu.com/download/desktop
| |
| 11:05 | <nataraj> yeah, i might need
| |
| 11:05 | <alkisg> Ubuntu 14.04.3 LTS => i386 => download
| |
| 11:07 | http://releases.ubuntu.com/14.04.3/ubuntu-14.04.3-desktop-i386.iso
| |
| 11:09 | <nataraj> yum, gone for it. In about one hour
| |
| 11:09 | typo, yup not yum
| |
| 11:10 | old habits dont die soon ;)
| |
| 11:10 | <alkisg> apt-get install haha! :)
| |
| 11:15 | <nataraj> :D
| |
| 11:18 | schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de) | |
| 11:34 | schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, Read error: Connection reset by peer) | |
| 11:34 | schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de) | |
| 11:40 | schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, Read error: Connection reset by peer) | |
| 11:41 | alkisg is now known as work_alkisg | |
| 11:42 | schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de) | |
| 12:02 | administrator has joined IRC (administrator!5e478477@gateway/web/freenode/ip.94.71.132.119) | |
| 12:02 | administrator is now known as Guest34559 | |
| 12:17 | danau11 has joined IRC (danau11!~durban@66.251.57.114) | |
| 12:19 | danau11 has left IRC (danau11!~durban@66.251.57.114) | |
| 13:07 | andygraybeal has joined IRC (andygraybeal!~andy@h52.205.189.173.dynamic.ip.windstream.net) | |
| 13:14 | <larryni> Hi guys
| |
| 13:21 | Trying to get the display of our HP t5570 thin clients. They should support 1366x768, but insist on starting in 1024x768. The only way I can get a login screen is with XSERVER=vesa. I've tried adding the full res with XRANDR_COMMAND_x, but no success.
| |
| 13:22 | glxinfo gives me the client glx vendor string "Mesa Project and SGI"
| |
| 13:22 | I've tried so many different combinations now...
| |
| 13:25 | nataraj has left IRC (nataraj!7aa6e4aa@gateway/web/freenode/ip.122.166.228.170, Ping timeout: 246 seconds) | |
| 13:47 | <muppis> Have anyone tried to use Odroid C1 as client?
| |
| 13:51 | <ogra_> is there a usable graphics driver for it ?
| |
| 13:52 | (beyond fbdev)
| |
| 13:55 | <muppis> More than OpenGL ES 2.0 required?
| |
| 14:06 | <ogra_> i doubt desktop make much use of it
| |
| 14:07 | *desktops
| |
| 14:07 | or flash ...
| |
| 14:07 | or whatever you want to display
| |
| 14:07 | you need 2D accel more than 3D accel there ... and for that you need a proper xserver
| |
| 14:12 | <muppis> Seems like there is X11 driver for Mali GPU.
| |
| 14:24 | FrankBlues has joined IRC (FrankBlues!~alex@c-67-171-127-41.hsd1.ut.comcast.net) | |
| 14:38 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
| 14:50 | work_alkisg is now known as alkisg | |
| 14:50 | <alkisg> larryni: what's the output of `xrandr`?
| |
| 14:50 | Can you set 1366x768 with xrandr commands?
| |
| 14:56 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 14:57 | <larryni> alkisg: here's the output http://paste.debian.net/319271 - I managed to add the resolution with --newmode and --addmode lines using XRANDR_COMMAND_n lines in lts.conf. I've also got a line with "--output default", but get an error message that the screen cannot be configured as soon as I log on. The login screen is shown in 1024x768 as well.
| |
| 14:58 | When I try to set manually with xrandr I get the same error.
| |
| 14:58 | <alkisg> larryni: is that a crt or a tft monitor?
| |
| 14:58 | And, are you using a kvm switch?
| |
| 14:58 | <larryni> tft
| |
| 14:58 | <alkisg> or a splitter?
| |
| 14:59 | <larryni> no kvm or splitter
| |
| 14:59 | <alkisg> which graphics driver? lspci -nn -k | grep -A2 VGA on the client, not on a user session
| |
| 14:59 | <larryni> The machine has a DVI to VGA adapter though
| |
| 14:59 | <alkisg> !localxterm
| |
| 14:59 | <ltsp`> localxterm: Any applications that you launch on a thin client actually runs on the server, not on the client itself. If you want to open a program on the client locally, you can type 'ltsp-localapps <program>' in a run dialog or in a terminal. For example, 'ltsp-localapps xterm' to open a terminal running on the client.
| |
| 15:00 | <alkisg> Do you have a way to connect it directly, e.g. vga to vga or dvi to dvi?
| |
| 15:01 | The problem seems to be that it's not reading the edid information, it should say so in your xorg.conf
| |
| 15:01 | And you can use a premade edid or a custom X_HORIZSYNC/X_VERTREFRESH
| |
| 15:02 | <larryni> The clients have a VGA port, but male instead of female - I guess that's why my predecessor used the adapters in the first place.
| |
| 15:02 | * alkisg assumes that's a serial port... | |
| 15:02 | <alkisg> rs232, not vga
| |
| 15:02 | 2 lines of pins, not 3
| |
| 15:04 | <ogra_> well, if you squeeze hard enough ...
| |
| 15:05 | <alkisg> :)
| |
| 15:05 | <ogra_> (you might only get a serial console on screen if you actually manage to plug it in though :P ... )
| |
| 15:06 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 15:07 | <larryni> Here's the output of lspci http://i.imgur.com/F5ILW3w.png
| |
| 15:08 | <alkisg> Ah, via, lovely
| |
| 15:08 | <larryni> Is that a good or bad lovely? ;o)
| |
| 15:08 | <alkisg> Which ubuntu version is that?
| |
| 15:08 | very bad lovely :)
| |
| 15:08 | <larryni> 14.04
| |
| 15:08 | dang
| |
| 15:09 | <alkisg> You're very lucky you get a display, some months ago it was just segfaulting
| |
| 15:09 | <larryni> The screens worked on our previous ltsp which ran on 10.04
| |
| 15:09 | <alkisg> OK then if you got the xrandr commands working, just put those in lts.conf
| |
| 15:09 | Yes, xaa was removed in 10.10
| |
| 15:09 | and sis has broken exa implementation
| |
| 15:10 | https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-sis/+bug/1066464
| |
| 15:12 | So, use XRANDR_COMMAND_01, 02, 03 to define the newmode, add it etc
| |
| 15:12 | <larryni> This is what I have in my lts.conf for the HP thin clients http://paste.debian.net/319274
| |
| 15:12 | <alkisg> You can include the initial xrandr there in the command
| |
| 15:12 | If you run those inside a user session, do you get 1366x768?
| |
| 15:13 | Aren't you missing a --mode in the last command?
| |
| 15:16 | <larryni> No, it adds the option to my resolutions list, but then errors when I try to apply it.
| |
| 15:16 | Tried with and without --mode in the last line - same results
| |
| 15:20 | I've also tried XSERVER=via instead of vesa - but then I just get a black screen instead of a login screen
| |
| 15:26 | schlady_ has joined IRC (schlady_!~schlady@141-53-32-98.ip.uni-greifswald.de) | |
| 15:30 | Hyperbyt1 has joined IRC (Hyperbyt1!jan@middelkoop.cc) | |
| 15:34 | fiesh_ has joined IRC (fiesh_!~fiesh@hq.wsoptics.de) | |
| 15:34 | schlady_ has left IRC (schlady_!~schlady@141-53-32-98.ip.uni-greifswald.de, Remote host closed the connection) | |
| 15:35 | schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, *.net *.split) | |
| 15:35 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, *.net *.split) | |
| 15:35 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, *.net *.split) | |
| 15:35 | fiesh has left IRC (fiesh!~fiesh@hq.wsoptics.de, *.net *.split) | |
| 15:35 | PeperPots___ has left IRC (PeperPots___!sid1218@gateway/web/irccloud.com/x-bxscbxjpbujssqeg, *.net *.split) | |
| 15:35 | Hyperbyte has left IRC (Hyperbyte!jan@5.9.150.98, *.net *.split) | |
| 15:39 | <larryni> Another problem I have is with our Acer Veritrons. They insist on activating the built-in LVDS1 and VGA1. Even though my lts.conf says "xrandr --display LVDS1 --off --output VGA1 --mode 1366x768" it only seems to apply to the login screen. Once the desktop loads I have an extended desktop again.
| |
| 15:40 | When I enter xrandr --display LVDS1 --off in a terminal it switches to single desktop with the right res.
| |
| 15:42 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 15:42 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 15:46 | <alkisg> larryni: gnome saves desktop settings in ~/.config/monitors.xml, delete those to have the login screen resolution stick inside the user session
| |
| 15:46 | Also, I got disconnected and this didn't reach the channel:
| |
| 15:46 | (05:31:35 μμ) alkisg: larryni: didn't you say that you managed to get the correct resolution via the command line?
| |
| 15:46 | PeperPots___ has joined IRC (PeperPots___!sid1218@gateway/web/irccloud.com/x-arxxlwfsixnswrup) | |
| 15:46 | <larryni> alkisg: I prese
| |
| 15:47 | oops
| |
| 15:47 | <alkisg> You can also disable outputs via the kernel command line
| |
| 15:47 | <larryni> I presume the last one you posted was in relation to the HP clients?
| |
| 15:47 | <alkisg> Something like video:lvds-1:disabled, I think we even have a !factoid here for it...
| |
| 15:47 | Yes
| |
| 15:48 | video=LVDS-1:d
| |
| 15:48 | !video
| |
| 15:48 | <ltsp`> I do not know about 'video', but I do know about these similar topics: 'video-without-flash', 'video-test'
| |
| 15:48 | <alkisg> !lvds
| |
| 15:48 | <ltsp`> I do not know about 'lvds', but I do know about these similar topics: 'ldm', 'logs'
| |
| 15:48 | <alkisg> !i915
| |
| 15:48 | <ltsp`> I do not know about 'i915', but I do know about these similar topics: 'ipxe'
| |
| 15:48 | <larryni> No, no luck with the HP ones whatsoever - only 1024x768
| |
| 15:48 | <alkisg> Then try with X_HORIZSYNC and X_VERTREFRESH, you should have an example lts.conf with those
| |
| 15:49 | Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas) | |
| 16:00 | alkisg is now known as work_alkisg | |
| 16:16 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 16:46 | work_alkisg is now known as alkisg | |
| 16:49 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 240 seconds) | |
| 16:52 | <alkisg> !raspberrypi
| |
| 16:52 | <ltsp`> raspberrypi: (#1) Ubuntu/LTSP on Pi 2: https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi, or (#2) Debian/LTSP (with raspbian chroot) on Pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#3) unofficial Ubuntu/LTSP (with raspbian chroot) on Pi: http://pinet.org.uk/
| |
| 16:52 | <alkisg> vagrantc: ^ :)
| |
| 17:00 | Parker955_Away has left IRC (Parker955_Away!~parker@2607:5300:60:8425::2d62:a8e6, Ping timeout: 246 seconds) | |
| 17:00 | Tyrantelf has left IRC (Tyrantelf!~tyrantelf@2607:5300:60:48bd::1, Ping timeout: 246 seconds) | |
| 17:08 | Parker955_Away has joined IRC (Parker955_Away!~parker@167.114.7.167) | |
| 17:17 | <vagrantc> alkisg: nice
| |
| 17:19 | alkisg: ubuntu ships a raspi2 kernel?
| |
| 17:19 | <alkisg> Yes, from 15.10 onwards, and I copied it to the greek schools ppa for 14.04
| |
| 17:24 | <ogra_> vagrantc, yep ... mainline with Pi patches on top
| |
| 17:27 | <vagrantc> hrm. packages.ubuntu.com doesn't include armhf ...
| |
| 17:30 | <alkisg> https://launchpad.net/ubuntu/+source/linux-raspi2
| |
| 17:30 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 17:31 | stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Ping timeout: 250 seconds) | |
| 17:32 | stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org) | |
| 17:32 | <vagrantc> oddly enough, it does include armel ...
| |
| 17:32 | * vagrantc wonders how hard it would be to add the same patchset to unofficial Debian kernels | |
| 17:33 | <ogra_> packages.u.c is maintained by debian :P
| |
| 17:33 | <vagrantc> ogra_: do you have any links documenting using u-boot on raspberry pi?
| |
| 17:33 | <ogra_> vagrantc, should be fine for unofficial kernels
| |
| 17:33 | no, not yet, i still have a task to document oour uboot setup in snappy
| |
| 17:34 | <vagrantc> ogra_: you had said something about the .dtb needing to come from some strange location
| |
| 17:34 | <ogra_> it needs to sit next to the blob bootloader
| |
| 17:34 | <vagrantc> ogra_: ok, i'd love to read over that documentation once it exists, or a draft, etc.
| |
| 17:35 | <ogra_> yeah, only in my head currently :)
| |
| 17:35 | snappy keeps me busy
| |
| 17:35 | <vagrantc> ah, so i just have to snap my fingers? :)
| |
| 17:36 | schlady has joined IRC (schlady!~schlady@ip1f111023.dynamic.kabel-deutschland.de) | |
| 17:36 | <alkisg> vagrantc: we managed to boot with u-boot at #raspberrypi
| |
| 17:36 | Using the dtb and all
| |
| 17:36 | (to netboot)
| |
| 17:36 | <vagrantc> alkisg: oh!
| |
| 17:37 | <alkisg> u-boot supports an fdt directive in its pxelinux emulation
| |
| 17:37 | <vagrantc> right
| |
| 17:37 | fdt_dir as well
| |
| 17:37 | <alkisg> In my tests, the kernel was hanging because I didn't provide the blob
| |
| 17:37 | <vagrantc> i've managed to boot it... but video resolution was awful ... and maybe some devices were unreliable ... but it's been a while
| |
| 17:38 | also with the 3.18 kernel from raspbian
| |
| 17:38 | so maybe the 4.2 kernel works more sanely
| |
| 17:38 | <ogra_> you need the blob to chainload uboot
| |
| 17:38 | the blob reads the dtb and loads it to 0x100 in ram
| |
| 17:38 | <vagrantc> yeah ... and you need the right blob
| |
| 17:38 | <alkisg> Local firmware loads u-boot, which then loads the device tree from tftp
| |
| 17:38 | <ogra_> uboot needs to load it from there with the fdt command
| |
| 17:39 | else your kernel wont boot
| |
| 17:39 | it only works properly if the blob can load the dtb loacally from its dir
| |
| 17:39 | <vagrantc> alkisg: that sounds more like what i'm looking for
| |
| 17:39 | <ogra_> uboot cant override the dtb
| |
| 17:39 | <alkisg> vagrantc: we booted with that this morning
| |
| 17:39 | local firmware, kernel and initrd and device tree from tftp
| |
| 17:39 | stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 250 seconds) | |
| 17:40 | <ogra_> the kernel will automatically switch back to ATAGs if you try loading the dtb via usboot
| |
| 17:40 | <alkisg> I'll test more tomorrow and update the wiki page to use that
| |
| 17:40 | <ogra_> which means only basic HW works
| |
| 17:41 | s/usboot/uboot/
| |
| 17:48 | stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org) | |
| 17:49 | <alkisg> ogra_: could you explain to me in a few words what the device tree is about? From what I've heard so far, the GPU gets started first, then I assume it executes the code from some ROM that can initialize the SD card and read the fat partition and load the firmware from there,
| |
| 17:49 | then the firmware loads e.g. config.txt, cmdline.txt and loads e.g. u-boot or the kernel
| |
| 17:49 | schlady has left IRC (schlady!~schlady@ip1f111023.dynamic.kabel-deutschland.de, Remote host closed the connection) | |
| 17:49 | <alkisg> Where is the device tree needed? Why isn't the firmware enough?
| |
| 17:50 | <ogra_> when it loads config.txt it also loads the devicetree and all the overlays you define in there
| |
| 17:50 | <alkisg> What are the overlays? Code? Or just description of the hardware?
| |
| 17:51 | I'm missing the essential information, what's their purpose...
| |
| 17:51 | <vagrantc> .dtb/device-tree describes hardware configuration that isn't probeable
| |
| 17:51 | <alkisg> So they don't contain code, right?
| |
| 17:52 | * vagrantc doesn't understand the distinction | |
| 17:52 | <alkisg> Isn't it possible to manually load them at run time, assuming you know what your hardware is?
| |
| 17:52 | like, force_load_module my-hardware...
| |
| 17:53 | stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 268 seconds) | |
| 17:53 | <alkisg> Are they passed to the kernel like the initramfs?
| |
| 17:53 | stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org) | |
| 17:53 | <alkisg> Or are they system functions like the pc interrupt/bios services?
| |
| 17:54 | <ogra_> overlays are to enable additional HW
| |
| 17:55 | like PWM or I2C ... if you have a sound cape/hat attached you need the drivers ... so you load the matching overlay for the sound hat and it will give you sound
| |
| 17:55 | <alkisg> Why can't the kernel load them after it starts?
| |
| 17:56 | <ogra_> the beaglebone can do such stuff ... but via a kernel hack called capemgr ... the rpi kernel sadly cant
| |
| 17:56 | (dynamic loading i mean)
| |
| 17:56 | <alkisg> OK, so they exist because of bad firmware design... :)
| |
| 17:57 | <ogra_> there is no firmware design :P
| |
| 17:57 | <alkisg> Hehe
| |
| 17:57 | <ogra_> its only a first stage bootloader
| |
| 17:57 | dtb's are a kernel thing ... to prevent devs from having to re-build their kernels and get more standardization into arm
| |
| 17:57 | <vagrantc> they exist because of hardare decisions to reduce price
| |
| 17:57 | <ogra_> right
| |
| 17:57 | <alkisg> How hard would it be for the firmware to provide a hook to "load overlay"
| |
| 17:58 | <ogra_> and in the past pepole just built one kernel per board
| |
| 17:58 | <alkisg> That the kernel could call at runtime...
| |
| 17:58 | <ogra_> with dtbs it is possible to se the same kernel for multiple boards
| |
| 17:58 | with different dtbs
| |
| 17:58 | <vagrantc> the kernel needs to know how to configure the memory and cpu
| |
| 17:58 | for example
| |
| 17:58 | <ogra_> right
| |
| 17:58 | it needs to do that on startup
| |
| 17:58 | <vagrantc> you don't want to run with those settings wrong
| |
| 17:59 | <ogra_> same goes for initializing the peripherial HW
| |
| 17:59 | <vagrantc> so in the time it takes to load those settings you might fry your ram or cpu
| |
| 17:59 | and device-tree is the way to build a single kernel that supports multiple disparate boards...
| |
| 17:59 | <alkisg> It's the same with pcs, and it's been solved well enough years ago
| |
| 18:00 | <ogra_> http://paste.ubuntu.com/13084133/ ...
| |
| 18:00 | alkisg, no, it had never to be solved by PCs because there the BIOS does all this
| |
| 18:00 | <alkisg> E.g. nvidia starts with low frequency, and it supports uploading a firmware dynamically, that gives you the option to run it at higher rates
| |
| 18:00 | <vagrantc> alkisg: it was solved by BIOS...
| |
| 18:00 | <alkisg> The bios doesn't know about nvidia
| |
| 18:00 | <ogra_> the bios does know about the right INT call to enable the card
| |
| 18:00 | it wont configure it futher
| |
| 18:01 | but will give you basic graphics support
| |
| 18:01 | <vagrantc> alkisg: maybe you should take this to the linux list :P
| |
| 18:01 | <ogra_> haha
| |
| 18:01 | anyway, see my paste above
| |
| 18:01 | <alkisg> ogra_: it's the same one that I'm using to boot rpi here
| |
| 18:01 | <vagrantc> alkisg: basically, that's how it is ... it's kind of pointless to argue here :P
| |
| 18:01 | <ogra_> that is what your fat partition (first partition on the SD) needs to contain
| |
| 18:01 | <alkisg> I'm not arguing, i'm trying to understand
| |
| 18:02 | <vagrantc> alkisg: there are more busses that are probe-able on x86 architecture
| |
| 18:02 | <alkisg> Could you guys comment on what the person that helped with u-boot siad?
| |
| 18:02 | I asked him if there are any drawbacks to netbooting rpis with uboot as opposed to with a local kernel/initrd, and then netboot. He said:
| |
| 18:02 | "there is one: you can't do device tree parameters easily with u-boot, because as i learned yesterday, those are specific to the pi bootloader
| |
| 18:03 | <vagrantc> alkisg: x86 architecture is far more standardized ... so they solved the issue by building hardware that was virtually identical ... in the ARM world, you have to have a definition somewhere to describe what you're booting, rather than auto-probing a lot of things...
| |
| 18:03 | <ogra_> the boot goes: start.elf -> fixup.dat (they are the blob) -> load config.txt and basic dtb (bcm2709-rpi-2-b.dtb for the rpi2) -> load dtbs from overlay dir if config.txt defined them -> laod uboot.bin (teh binary needs to be padded with the rpi kernel script) ... then switch to uboot ...
| |
| 18:03 | <alkisg> He later said that users could do it by "or you can build a whole new device tree blob" and passing that one to u-boot
| |
| 18:03 | ...but I didn't quite understand if there are real drawbacks in booting with u-boot or not
| |
| 18:04 | <vagrantc> alkisg: ARM is far less standardized from a hardware point of view, basically.
| |
| 18:04 | <ogra_> in uboot you need to call "fdt addr 0x100" at some point to load the dtb from ram where the blob has placed it
| |
| 18:05 | <alkisg> ogra_: we can also tell u-boot to download an fdt via tftp and pass it to the kernel. Does that mean that I don't need an overlay dir in the sd card?
| |
| 18:05 | <ogra_> and as i said, loading another dtb via uboot will make the kernel switch back to ATAGs and disable dtb support altogether
| |
| 18:05 | <vagrantc> ogra_: and loading to ram from u-boot itself to the same address doesn't work?
| |
| 18:05 | <ogra_> so tftp'ing it isnt an option
| |
| 18:05 | vagrantc, failed for me every time i tried
| |
| 18:05 | <alkisg> The raspberrypi person there did it with fdt from tftpd
| |
| 18:06 | <ogra_> not sure what the blob does to it exactly but it seems to be different to how uboot does it
| |
| 18:06 | <vagrantc> so the binary blob firmware is probably mangling it in some bizarre way
| |
| 18:06 | <ogra_> alkisg, and you are 100% it didnt just switch back to ATAGs ?
| |
| 18:06 | <alkisg> I've no idea what ATAGs are
| |
| 18:06 | <ogra_> it would still boot but with degraded peripherials
| |
| 18:07 | <alkisg> ogra_, so basically do you think that I shouldn't bother with u-boot, and let the kernel+initrd in the sd card for netbooting ltsp in rpi?
| |
| 18:07 | Because of those ^ issues that you pointed?
| |
| 18:08 | <vagrantc> nothing quite like experimentation to figure it out for sure :)
| |
| 18:08 | <ogra_> either that or tftp the dtb, fatwrite and reboot again to get the dtb in the right places
| |
| 18:08 | *place
| |
| 18:09 | <vagrantc> hrm... apparently the raspi2 kernel doesn't have the patches separated out ...
| |
| 18:09 | <alkisg> vagrantc: I wouldn't know how to distinct between normal and degraded peripherals mode. If the screen, keyboard and network work, I don't know what else to test, I've no experience with I2C bus or touch screens etc etc...
| |
| 18:09 | * vagrantc just dumps a patchset from git | |
| 18:10 | <vagrantc> alkisg: it was rather obvious to me ... resolution was 640x480 max on a 1280x720 screen
| |
| 18:10 | (and the screen worked fine when booting without u-boot)
| |
| 18:12 | <ogra_> vagrantc, it has a git tree somewhere on kernel.ubuntu.com
| |
| 18:12 | <vagrantc> probably also reading the kernel boot logs it would say something obvious, moreorless
| |
| 18:12 | <ogra_> the base should be the ubuntu generic kernel (which we use for all other arm arches )
| |
| 18:12 | like the debian multiarm kernel
| |
| 18:15 | * vagrantc nods | |
| 18:18 | <ogra_> well, the resolution is passed to the blob from config.txt ... so if you want higher resolution you will have to define it there
| |
| 18:19 | stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 268 seconds) | |
| 18:19 | <alkisg> Meh when I put the u-boot.bin that that person gave me, I get a blank screen. Is it possible that it needs a different firmware version? I have the one from ubuntu, and he used the one from raspbian/jessy afaik...
| |
| 18:23 | <vagrantc> it's very possible that you need a different firmware version.
| |
| 18:26 | FrankBlues has left IRC (FrankBlues!~alex@c-67-171-127-41.hsd1.ut.comcast.net, Ping timeout: 252 seconds) | |
| 18:28 | stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org) | |
| 18:32 | <alkisg> Nah, I give up on u-boot for now. His files/documentation are in http://al.robotfuzz.com/~al/random/rpipxe.tar.bz2 in case anyone wants to try netbooting rpi2 with u-boot.
| |
| 18:32 | Automatic kernel upgrades work fine, good enough for me, both for rpi and for cases where ipxe doesn't support the nic
| |
| 18:32 | vagrantc: ah, about the other thing with the alternate dhcp ports etc
| |
| 18:33 | How would you feel if we supported some method of using ipv6 only in the initramfs?
| |
| 18:33 | I.e. if we passed some parameter in the cmdline, "i-have-no-control-over-the-dhcp", then it could use the classic static ipv6 addresses, and locate the server again in a static ipv6 address
| |
| 18:34 | After it contacts the server and gets ROOTSERVER, ROOTPATH etc, it would continue with ipv4, the ipv6 part would only be there to help in initramfs
| |
| 18:35 | stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 252 seconds) | |
| 18:38 | <vagrantc> alkisg: using ipv6 did cross my mind ... but if you have a network that actually uses ipv6 ... then what?
| |
| 18:40 | <alkisg> vagrantc: then don't use the i-have-no-control-over-the-dhcp flag
| |
| 18:40 | And use a real dhcp server
| |
| 18:40 | vagrantc: also, we don't support ipv6 booting anyway, do we?
| |
| 18:41 | The static ipv6 addresses in the initramfs would be valid
| |
| 18:41 | We wouldn't break his network...
| |
| 18:41 | <vagrantc> the addresses would be valid, but if the network has dhcpv6 or something configured ... what methods are we using to discover the ip address of the server?
| |
| 18:42 | <alkisg> wget <static-server-ip> ==> gives us the dynamic ipv4 server ip
| |
| 18:42 | <vagrantc> do we have a static server ip address that will be valid?
| |
| 18:43 | <alkisg> In ipv6, we can have a lot of static ipv6 addresses, like the extended version of 192.168.67.1
| |
| 18:43 | And multiple IPs etc as well
| |
| 18:43 | <vagrantc> having more ip addresses doesn't seem to resolve the issue
| |
| 18:43 | <alkisg> I'll check for the exact address/private range that we can use
| |
| 18:43 | FrankBlues has joined IRC (FrankBlues!alex@2601:681:4401:1c00:75d4:62e4:e3b2:e5f1) | |
| 18:44 | * vagrantc didn't think ipv6 had private ranges | |
| 18:44 | <alkisg> I read about them a while ago, but I've never used ipv6 so I don't remember all that I've read
| |
| 18:46 | Hyperbyt1: I think you're good with networks, do you have ipv6 experience?
| |
| 18:46 | * alkisg reads https://en.wikipedia.org/wiki/Private_network#Private_IPv6_addresses ... | |
| 18:47 | <alkisg> actually link-local was a better match for our case if I remember correctly
| |
| 18:47 | stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org) | |
| 18:48 | Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas) | |
| 18:49 | <alkisg> https://en.wikipedia.org/wiki/Link-local_address#IPv6
| |
| 18:50 | <vagrantc> but link-local addresses are automatically assigned and cannot, by definition, be static.
| |
| 18:50 | <alkisg> hey may be assigned by automatic (stateless) or stateful (e.g. manual) mechanisms.
| |
| 18:55 | danau111 has joined IRC (danau111!~durban@66.251.57.114) | |
| 18:55 | stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 240 seconds) | |
| 19:00 | danau111 has left IRC (danau111!~durban@66.251.57.114) | |
| 19:01 | gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: mv /proc/self $HOME) | |
| 19:02 | <alkisg> When the client is at `break=mount`, I can do from the server: `ping6 -I eth1 fe80::5054:ff:fe25:e337`, and it replies fine, i.e. ipv6 is already initialized at that stage by ipconfig
| |
| 19:02 | busybox wget claims to support ipv6 since many years ago, that's ok too...
| |
| 19:08 | FrankBlues has left IRC (FrankBlues!alex@2601:681:4401:1c00:75d4:62e4:e3b2:e5f1, Ping timeout: 240 seconds) | |
| 19:14 | <alkisg> Hrm, it might actually make sense to use ipv6 local addresses for the nbd connection as well
| |
| 19:16 | They don't need leases etc, they're not routable, they might even persist if one does "dhclient eth0" to re-initialize networking...
| |
| 19:17 | stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org) | |
| 19:25 | stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 268 seconds) | |
| 19:26 | stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org) | |
| 19:28 | <alkisg> The bandwidth dropped from 94.1 to 92.8, ok the overhead is small...
| |
| 19:28 | !nbd-client
| |
| 19:28 | <ltsp`> nbd-client: To try mounting the NBD image from the client initramfs: nbd-client 192.168.67.1 -N /opt/ltsp/i386 /dev/nbd0
| |
| 19:37 | * vagrantc seems to recall some surprises with link-local addresses | |
| 19:38 | <vagrantc> maybe you can only reach link-local addresses on the same switch ... chained switches or something had issues?
| |
| 19:39 | doesn't seem to be the case here...
| |
| 19:40 | FrankBlues has joined IRC (FrankBlues!~alex@c-67-171-127-41.hsd1.ut.comcast.net) | |
| 19:42 | <alkisg> I can't make nbd-server listen on ipv6, while it's supposed to do that by default
| |
| 19:43 | It's listening on 0.0.0.0 only, that doesn't include ipv6, right? E.g. sshd listens on :::22 as well...
| |
| 19:50 | <quinox> our nbd only does ipv4 as well ATM
| |
| 19:52 | <vagrantc> IPv6 support was supposedly added to NBD in 2.9.15
| |
| 19:54 | bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy) | |
| 20:00 | danau11 has joined IRC (danau11!~durban@66.251.57.114) | |
| 20:03 | <vagrantc> confirmed on debian stretch ...
| |
| 20:03 | * vagrantc reports a bug | |
| 20:04 | * vagrantc wonders if it would listen on a network with routeable ipv6 | |
| 20:14 | <alkisg> quinox: "our nbd", which one do you mean?
| |
| 20:15 | The normal nbd-server in your local installation, or some other nbd-server variant?
| |
| 20:16 | <vagrantc> https://bugs.debian.org/803795
| |
| 20:17 | <alkisg> Thanks vagrantc :)
| |
| 20:17 | <vagrantc> if it's a relatively easy fix, wouter will probably have it fixed in a few days ... though that doesn't really help older versions.
| |
| 20:18 | <alkisg> preparing for ltsp6... :D
| |
| 20:19 | * vagrantc would love for ltsp6 to support ipv6 | |
| 20:19 | <vagrantc> it only seems natural.
| |
| 20:20 | <alkisg> ouch, it will take a lot of time for epoptes to support ipv6 then :D (epoptes v6...)
| |
| 20:23 | <vagrantc> well, we worked hard to support IPv6 when we released LTSP5.
| |
| 20:23 | er, oops.
| |
| 20:23 | * vagrantc broke a joke. | |
| 20:23 | <vagrantc> well, we worked hard to support IPv5 when we released LTSP5.
| |
| 20:23 | <alkisg> So I'm guessing that if we're using ipv6 link local addresses to access the root disk and swap, we could even let dhclient and network manager do their job normally, similar to aoe
| |
| 20:23 | <vagrantc> of course, excellent projects sometimes add support before their time
| |
| 20:24 | as long as they don't died when reconfiguring other parts of the network interface...
| |
| 20:24 | <alkisg> ltsp is a mostly a glue for other people's projects, so we can only support ipv6 when all of those other projects do
| |
| 20:25 | * vagrantc nods | |
| 20:25 | klausade has joined IRC (klausade!~klaus@cm-84.215.169.187.getinternet.no) | |
| 20:27 | <alkisg> Goodnight all :)
| |
| 20:27 | alkisg is now known as work_alkisg | |
| 20:28 | <quinox> I meant "the nbd that we have running"
| |
| 20:29 | it's whatever Ubuntu ships
| |
| 20:35 | so if I want to upgrade the server and clients to 15.10, what would be the best way to get LTSP working again?
| |
| 20:35 | the last 6 or so upgrades using the default LTSP package worked great, except for the very last one (15.04)
| |
| 20:36 | the overlayfs thingy
| |
| 20:37 | with your help (greatly appreciated) we managed to make it working again by hacking the early boot-mount-script-thingies
| |
| 20:41 | with <15.04 I would upgrade the server, delete /opt/ltsp/amd64, run ltsp-build-client, manually fix a few custom things (LDM skin, packages such as skype) and voilà
| |
| 20:43 | (actually, with 14.10 I had to switch to the ltsp-build-client from trunk to fix the 'missing file' error #1387773)
| |
| 20:46 | We've been happily using LTSP since before 2010-10-12 :D
| |
| 20:47 | that's the date of our first proper LTSP documentation entry, before that we had some misconfigured / hacked LTSP that couldn't be upgraded without a lot of voodoo
| |
| 20:51 | stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 264 seconds) | |
| 21:02 | stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org) | |
| 21:08 | stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 268 seconds) | |
| 21:28 | stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org) | |
| 21:33 | stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 268 seconds) | |
| 21:35 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:51 | stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org) | |
| 21:57 | stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Changing host) | |
| 21:57 | stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber) | |
| 21:57 | bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Remote host closed the connection) | |