IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 27 April 2015 (all times are UTC)
| 00:05 | jgalt has joined IRC (jgalt!47697af2@gateway/web/freenode/ip.71.105.122.242) | |
| 00:06 | <jgalt> just installed ltsp on debianant clientsv
| |
| 00:08 | get as far as pxe loading pxe linux.... then display "connection refused" ad infintium
| |
| 00:08 | how may the problem be found?
| |
| 00:47 | AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-bxrvrbfheyfsltie, Quit: Connection closed for inactivity) | |
| 00:58 | cstk421 has joined IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net) | |
| 01:03 | <vagrantc> jgalt: probably need to configure NFS in /etc/exports or /etc/exports.d/
| |
| 01:04 | "ltsp-config nfs" might work.
| |
| 01:07 | <jgalt> what does it need configured to?
| |
| 01:08 | <vagrantc> to allow mounting the LTSP root filesystem
| |
| 01:09 | unless you've configured your LTSP to use NBD or AOE instead of NFS, but NFS is the default on Debian
| |
| 01:10 | <jgalt> vagrantc: ok, also after the install name resolution quit. any ideas on that?
| |
| 01:11 | <vagrantc> jgalt: after running ltsp-build-client ??
| |
| 01:11 | jgalt: also, is this debian jessie, which was released yesterday?
| |
| 01:11 | for new installations, i'd definitely recommend going with jessie
| |
| 01:12 | <jgalt> yes, the host has been running jessie amd64 for about 4 months
| |
| 01:13 | <vagrantc> ok.
| |
| 01:13 | <jgalt> the build client step built the chroot for i386 as instructed.
| |
| 01:13 | <vagrantc> ok.
| |
| 01:16 | <jgalt> clients come up under pxe boot and show pxelinuxas having loaded then pretty much immediately show "connection reffused"
| |
| 01:16 | so yes, likely name resolution died sometime after running ltsp-build-client
| |
| 01:17 | <vagrantc> the server can't do name resolution, or the clients?
| |
| 01:17 | <jgalt> but not totally sure. the process asked for reboot and when I did that and logged in again it couldn't find (resolve) google.com, yahoo.com, or sparkfun.com but would ping ip addresses on mylan and the internet just fine.
| |
| 01:18 | Dsys has left IRC (Dsys!466ada6e@gateway/web/freenode/ip.70.106.218.110, Ping timeout: 246 seconds) | |
| 01:18 | <vagrantc> hard to imagine ltsp-build-cleint doing anything that would cause that problem...
| |
| 01:22 | <jgalt> ok, name resolution now works. started working again after "apt-get remove resolvconf" and reboot. seems the resolvconf program was getting in the way.
| |
| 01:23 | MarconM has joined IRC (MarconM!~Marcelo@unaffiliated/marconm) | |
| 01:23 | <jgalt> now to get the clients to netboot...... without "connection reffused"
| |
| 01:24 | MarconM has left IRC (MarconM!~Marcelo@unaffiliated/marconm, Read error: Connection reset by peer) | |
| 01:25 | <jgalt> I tried ltsp-config nfs and that does basicly nothing except output the help for ltsp-config
| |
| 01:25 | MarconM has joined IRC (MarconM!~Marcelo@unaffiliated/marconm) | |
| 01:25 | <vagrantc> ok, i guess i didn't get support into jessie for that ... gah.
| |
| 01:26 | jgalt: https://wiki.debian.org/LTSP/Howto
| |
| 01:27 | jgalt: step 4
| |
| 01:30 | <jgalt> vagrantc: followed those steps exactly, only difference being that I had to use dnsmasq because there is already a dhcp server running on the local lan and certain other users of this network would engage upon a witch hunt if I messed with that dhcpserver.
| |
| 01:31 | * vagrantc nods | |
| 01:31 | <vagrantc> my guess is then it's trying to connect to your router rather than the LTSP server.
| |
| 01:32 | <jgalt> unfortunately isc-dhcpd aparently won't do proxy-dhcp. I would have rather used the isc tools
| |
| 01:34 | <vagrantc> jgalt: you'll need to add nfsroot=ip.of.ltsp.server:/opt/ltsp/i386 to /opt/ltsp/i386/etc/ltsp/update-kernels.conf to CMDLINE_NFS="root=/dev/nfs ip=dhcp boot=nfs"
| |
| 01:34 | <jgalt> what is trying to connect to my router? do you mean the net-boot client is trying to connect to my router? the net-boot client displays the proper addresses for the tftp server
| |
| 01:34 | ah ok
| |
| 01:34 | <vagrantc> oh, also you can use IPAPPEND=3
| |
| 01:34 | then it won't make a second request ... might obviate the need to mess with specifying the ip address explicitly
| |
| 01:34 | MarconM has left IRC (MarconM!~Marcelo@unaffiliated/marconm, Read error: Connection reset by peer) | |
| 01:35 | MarconM has joined IRC (MarconM!~Marcelo@unaffiliated/marconm) | |
| 01:36 | <vagrantc> once you've edited update-kernels.conf, you'll need to run: ltsp-chroot /usr/share/ltsp/update-kernels
| |
| 01:36 | and then: ltsp-updatekernels
| |
| 01:36 | or rather: ltsp-update-kernels
| |
| 01:36 | <jgalt> in this case does it not need to make a second request? first request to get an ip address, then second request to get tftp server info?
| |
| 01:36 | <vagrantc> the first updates /opt/ltsp/i386/boot with the new values, the second copies the stuff from /opt/ltsp/i386/boot to your tftp dir.
| |
| 01:37 | well, it's an NFS, NBD or AOE server that the second request is looking for
| |
| 01:37 | but yes, IPAPPEND=3 re-uses the first DHCP request
| |
| 01:38 | there are typically two DHCP requests made, one for PXE boot, and one from the booted initramfs.
| |
| 01:38 | <jgalt> second request of the pxe bootloader or second request of pxe linux?
| |
| 01:39 | <vagrantc> pxelinux re-uses the PXE stack
| |
| 01:40 | 1. PXE makes a DHCP request, downloads pxelinux, which downloads it's configuration files
| |
| 01:40 | <jgalt> ah, ok. may need to rebootthis box to try.
| |
| 01:40 | <vagrantc> 2. pxelinux downloads kernel and initrd and executes them
| |
| 01:40 | 3. running initrd makes a DHCP request to find out it's root filesystem server
| |
| 01:41 | 4. initrd attempts to mount the root filesystem and execute init
| |
| 01:42 | <jgalt> ok, on a differen't but slightly related topic how is ltsp much different than setting up a bunch of diskless netbooting x-terms?
| |
| 01:42 | <vagrantc> it's a specific implementation of diskless netbooting x-terms.
| |
| 01:44 | <jgalt> ah, ok. so all software runs on the ltsp host and you are left with just an x-term display on your desk, correct?
| |
| 01:44 | <vagrantc> that's an option.
| |
| 01:44 | unforunately, there are a lot of confusing namespace clashes here, though.
| |
| 01:45 | <jgalt> how can I tell or control what runs where?
| |
| 01:46 | <vagrantc> well, i'm having a hard time with the terms you're using... x-term can mean about half a dozen different but related things
| |
| 01:46 | maybe i should just describe the typical LTSP use cases...
| |
| 01:46 | <jgalt> oh, sorry x11 display
| |
| 01:47 | hope that's clearer
| |
| 01:47 | <vagrantc> thin client: connects to the LTSP server and runs all applications on the LTSP server
| |
| 01:47 | fat client: boots off of LTSP server, authenticates against the LTSP server, but runs applications on the client hardware
| |
| 01:48 | thin client with localapps: runs most applications on LTSP server, but some applications on client hardware
| |
| 01:48 | fat client with remoteapps: runs most applications on client hardware, but some applications on the LTSP server
| |
| 01:48 | x11 display is also prone to great confusion :)
| |
| 01:49 | * vagrantc prefers to talk in terms of LTSP servers and LTSP clients | |
| 01:49 | <jgalt> ok, so after following the debian instructions referenced I end up with......? thin client?
| |
| 01:49 | <vagrantc> yup
| |
| 01:50 | LTSP by default uses LDM to connect to the server, which is effectively a GUI frontend to "ssh -X", although you can just use ssh for the authentication phase and use plain X11 traffic afterwards.
| |
| 01:51 | <jgalt> ok, probably what I wanted as I'm using a core2 duo to get some more life out of a bunch of p3's around the house. they are really snappy running as remote x displays.
| |
| 01:51 | <vagrantc> with the performance vs. security tradeoffs, of course
| |
| 01:51 | the available ram is almost more important than CPU for fat vs. thin clients
| |
| 01:52 | thin clients can squeak by with 128-256mb of ram, for a fat client you'll probably want at least 1GB ... more is better, of course.
| |
| 01:53 | cstk421 has left IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net, Read error: Connection reset by peer) | |
| 01:53 | <vagrantc> (which doesn't seem particularly thin to someone who first started doing thin clients with 8MB of ram and servers with 256MB ...)
| |
| 01:53 | <jgalt> well some of those would be hurting to have 512MB of ram. more likely 128 or 256.
| |
| 01:54 | cstk421 has joined IRC (cstk421!~cstk421@173-14-40-58-Michigan.hfc.comcastbusiness.net) | |
| 01:55 | <vagrantc> if you can, look at how much power they draw ... i didn't do comparisons on pIII generation stuff, but P-4 vs. Pentium D vs. core2 systems was shocking.
| |
| 01:55 | pentium D barely performed better than a P-4, but drew 50% more power than either the p-4 or the core2
| |
| 01:59 | <jgalt> biggest thing is that the core2 will take about 4x the ram.
| |
| 02:00 | the p3's are crawling even running xp. this should be a nice upgrade for my housemates.
| |
| 02:01 | ....and a good way to get them running linux.
| |
| 02:02 | ...just set them to netboot their boxen as thin clients.
| |
| 02:04 | <vagrantc> nice
| |
| 02:06 | <jgalt> and if they complain too much, I can't be accused of removing windows from their prescious computers..... just reset the boot sequence and they are back to working as blisful snails.
| |
| 02:20 | rebooting.....
| |
| 02:23 | cstk421_ has joined IRC (cstk421_!~cstk421@ip-64-134-190-30.public.wayport.net) | |
| 02:24 | cstk421 has left IRC (cstk421!~cstk421@173-14-40-58-Michigan.hfc.comcastbusiness.net, Ping timeout: 245 seconds) | |
| 02:24 | cstk421 has joined IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net) | |
| 02:25 | jgalt has left IRC (jgalt!47697af2@gateway/web/freenode/ip.71.105.122.242, Ping timeout: 246 seconds) | |
| 02:26 | cstk421__ has joined IRC (cstk421__!~cstk421@ip-64-134-190-30.public.wayport.net) | |
| 02:27 | MarconM has left IRC (MarconM!~Marcelo@unaffiliated/marconm, Quit: Leaving) | |
| 02:28 | cstk421_ has left IRC (cstk421_!~cstk421@ip-64-134-190-30.public.wayport.net, Ping timeout: 245 seconds) | |
| 02:28 | cstk421_ has joined IRC (cstk421_!~cstk421@173-14-40-58-Michigan.hfc.comcastbusiness.net) | |
| 02:29 | cstk421 has left IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net, Ping timeout: 250 seconds) | |
| 03:02 | cstk421 has joined IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net) | |
| 03:04 | cstk421_ has left IRC (cstk421_!~cstk421@173-14-40-58-Michigan.hfc.comcastbusiness.net, Ping timeout: 252 seconds) | |
| 03:21 | cstk421 has left IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net, Remote host closed the connection) | |
| 03:21 | cstk421 has joined IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net) | |
| 03:30 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 03:39 | Eric___ has joined IRC (Eric___!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net) | |
| 03:39 | Eric___ is now known as jgalt | |
| 03:46 | map7 has joined IRC (map7!~map7@teksup41.lnk.telstra.net) | |
| 04:00 | <jgalt> opt/ltsp/i386/etc/ltsp/update-kernels.conf : http://paste.debian.net/169225/
| |
| 04:02 | still having trouble after a chat with vagrantc earlier today getting clients to boot
| |
| 04:03 | IPAPPEND=3 seems tonot quite do it.
| |
| 04:04 | clients still sho a connection refused message.
| |
| 04:15 | jgalt has left IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net, Remote host closed the connection) | |
| 04:23 | jgalt has joined IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net) | |
| 04:26 | <jgalt> http://paste.debian.net/169231/
| |
| 04:27 | same problem.....
| |
| 04:28 | any idea as to what's wrong and why the client connection to the server is refused?
| |
| 04:28 | cstk421 has left IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net, Remote host closed the connection) | |
| 04:32 | jgalt has left IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net, Remote host closed the connection) | |
| 04:43 | jgalt has joined IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net) | |
| 04:55 | <vsuojane1> jgalt: if you are getting connection refused after loading pxelinux it mostly means that the server where nfs/nbd/aoe images are is not available for the client machine
| |
| 04:58 | <jgalt> vsuojane1: I'm a bit confused.... how is it "not available for the client machine"?
| |
| 04:59 | <vsuojane1> if you could first troubleshoot the network and dhcp setup you are able better resolve is there something -- what is wrong in the ltsp server
| |
| 04:59 | <jgalt> the client is netloading pxelinux from the same server
| |
| 05:00 | <vsuojane1> yes, how the client connection to the server is refused ?
| |
| 05:02 | pxelinux is downloaded with the dhcp client (the dhcp boot parametere are conffigured in the local dhcp or proxy dhcp)
| |
| 05:02 | <jgalt> the client when told to pxe boot finds the network dhcp server running on the router and gets assigned 192.168.1.4 with a /24 netmask
| |
| 05:03 | <vsuojane1> oh sorry pxelinux is loaded -- not downloaded
| |
| 05:04 | <jgalt> the dhcp server on the router that does that is unable to give info about the tftp server so the dnsmasq server running on the ltsp box works as a dhcp proxy and fills in that info.
| |
| 05:06 | <vsuojane1> ok.. you have dnsmasq configured on the ltsp server.
| |
| 05:06 | <jgalt> I can see the pxe boot client display the proper info for ip address dhcp server, gateway, netmask, tftp server, everything right
| |
| 05:06 | yes dnsmasq is configured on the ltspserver and seems to be working as it should.
| |
| 05:07 | pxelinux loads noproblem
| |
| 05:08 | then it displays, "connection refused" ad infintium
| |
| 05:08 | that's where it'sstuck
| |
| 05:10 | couldn't use isc-dhcp because there's already a dhcp server running on the network which I can't touch.
| |
| 05:10 | ....but that part seems to work.
| |
| 05:13 | vsuojane1: any ideas?
| |
| 05:15 | <vsuojane1> it doesn't get the connection to the client root system, thats the issue
| |
| 05:16 | <jgalt> yes, I'm aware. but why is the question.
| |
| 05:17 | <vsuojane1> and /opt/ltsp *(ro,no_root_squash,async,no_subtree_check)
| |
| 05:18 | do you have this on your ltsp server nfs exports ?
| |
| 05:18 | <jgalt> yes, you can look at pastebin think posted it.
| |
| 05:18 | sec I'll paste again
| |
| 05:19 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 05:20 | <jgalt> http://paste.debian.net/169236/
| |
| 05:21 | ^^ /etc/exports
| |
| 05:27 | <vsuojane1> can you mount the nfs exports from the server ? are you able to test the mount from different mahcine on the same network ?
| |
| 05:32 | work_alkisg is now known as alkisg | |
| 05:33 | <alkisg> jgalt: what's your pxelinux.cfg/default like?
| |
| 05:36 | <jgalt> alkisg: can you give a full path? looking at syslog it looks like that file may be missing but is that the same file?.... what's the path where it should be?
| |
| 05:36 | <alkisg> jgalt: /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
| |
| 05:37 | (or amd64, if appropriate)
| |
| 05:37 | <jgalt> vsuojane1: how would I mount the nfsmounts on another machine.... or on the ltsp server iself?
| |
| 05:38 | <vsuojane1> check alkisg thing first
| |
| 05:39 | <alkisg> Check nfs is useful too, both of those troubleshooting actions are
| |
| 05:40 | <jgalt> http://paste.debian.net/169243/
| |
| 05:40 | <vsuojane1> yes. but i would check first that pxe configs
| |
| 05:41 | <alkisg> jgalt: the server's ip didn't make it into that file
| |
| 05:41 | <jgalt> ^^var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
| |
| 05:41 | <alkisg> append ro initrd=initrd.img-3.16.0-4-586 init=/sbin/init-ltsp quiet root=/dev/nfs ip=dhcp boot=nfs nfsroot=192.168.1.3:/opt/ltsp/i386
| |
| 05:41 | jgalt: try changing it to this ^
| |
| 05:41 | Then reboot client
| |
| 05:41 | Or, change ipappend 2 to ipappend 3
| |
| 05:42 | One of them
| |
| 05:42 | <vsuojane1> hmmm. ipappend 2. is it reusing the dhcp or getting new from the default/authorative dhcp ?
| |
| 05:43 | <alkisg> ipappend 2 tells the client to use the same NIC as the one in PXE
| |
| 05:43 | Nothing more, it doesn't tell it to reuse the IP or the same server
| |
| 05:45 | (like ipappend 3 does)
| |
| 05:46 | <jgalt> should I not change /etc/ltsp/update-kernels.conf instead asit says to?
| |
| 05:47 | <alkisg> For the troubleshooting part, no
| |
| 05:47 | Later on to make it permanent, yes
| |
| 05:50 | <jgalt> brb - gotta reboot this box so I can test the client.
| |
| 05:50 | jgalt has left IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net, Remote host closed the connection) | |
| 06:11 | jgalt has joined IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net) | |
| 06:15 | <jgalt> changed all the ipappend 2 statements to ipappend 3 and it works.... now how to make it stay that way....
| |
| 06:16 | <alkisg> You need to run update-kernels inside the chroot
| |
| 06:17 | Try: ltsp-chroot -m /usr/share/ltsp/update-kernels
| |
| 06:17 | Then check if ipappend 3 made it to /opt/ltsp/i386/boot/pxelinux.cfg/ltsp
| |
| 06:23 | <jgalt> yes it did
| |
| 06:23 | <alkisg> OK then whenever your run `ltsp-update-kernels` now, it'll work as you want it to
| |
| 06:26 | <jgalt> ....but we seem to have 2 files escentially the same.... updating /etc/ltsp/update-kernels is what seems to have made it work
| |
| 06:27 | ...also what does ltsp-update-kernels do?
| |
| 06:29 | <alkisg> /etc/ltsp/update-kernels.conf in the chroot, right?
| |
| 06:29 | update-kernels in the chroot updates <chroot>/boot/pxelinux.cfg
| |
| 06:29 | stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Quit: leaving) | |
| 06:29 | <alkisg> ltsp-update-kernels outside of it copies it to tftp
| |
| 06:29 | man ltsp-update-kernels will tell you more
| |
| 06:30 | stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org) | |
| 06:30 | <jgalt> ok, thanks. so what do I need to do now to keep this maintained and up to date?
| |
| 06:31 | <alkisg> Nothing, just apt-get update, dist-upgrade etc
| |
| 06:31 | stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Changing host) | |
| 06:31 | stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber) | |
| 06:31 | <jgalt> sweet!
| |
| 06:32 | so the ltsp chroot.... why the chroot for ltsp?
| |
| 06:33 | <alkisg> You need a server and a template client
| |
| 06:33 | The chroot is the template client
| |
| 06:33 | You could use a VM for that instead, but people here preferred chroots
| |
| 06:33 | Personally I prefer reusing the server installation
| |
| 06:33 | !ltsp-pnp
| |
| 06:33 | <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
| |
| 06:34 | <jgalt> I would reuse the server install but the server is amd64 and the clients are 32bit p3 boxen.
| |
| 06:35 | <alkisg> Install i386 on the server then
| |
| 06:35 | It even saves RAM
| |
| 06:36 | <jgalt> hmm,so why does or should anyone run a 64bit linux install
| |
| 06:36 | <alkisg> Because they don't care about netbooted clients
| |
| 06:36 | You can a bit more speed in math applications, and waste a little ram, it's a tradeoff
| |
| 06:36 | In this case, i386 suits you better
| |
| 06:37 | <jgalt> yes, but does 64bit hardware/os get you something? if so what?
| |
| 06:37 | <alkisg> Also some don't know that with i386-pae kernels you can access more than 4gb ram
| |
| 06:37 | (09:36:40 πμ) alkisg: You can a bit more speed in math applications, and waste a little ram, it's a tradeoff
| |
| 06:37 | That's what
| |
| 06:37 | <jgalt> ah ok.
| |
| 06:39 | now at the riskof committing heresy can this same basic setup be used to netboot a client to M$ windows?
| |
| 06:39 | <alkisg> How do you netboot windows usually?
| |
| 06:40 | (because there are many methods, all of them officially unsupported, to see if the one you use can also be offered by a linux server)
| |
| 06:40 | <jgalt> I havn't really tried. just thinking a menu that gave a choice of os to netboot would be kinda nice.
| |
| 06:41 | <alkisg> The menu is the easy part, the hard part is that windows officially don't support netbooting
| |
| 06:41 | So people find workarounds with iscsi disks or VMs
| |
| 06:41 | <jgalt> ah,ok got that.
| |
| 06:42 | <alkisg> You can offer iscsi disks from linux, that's the easy part, google for it, it's not very related to ltsp except that you can reuse some dnsmasq settings
| |
| 06:42 | <jgalt> yes,more curious than anything else.
| |
| 06:42 | <alkisg> But if your PCs already have disks, I don't see why you would bother
| |
| 06:43 | LTSP has support for windows remote desktop, but that doesn't suit you either
| |
| 06:44 | <jgalt> another interesting related project I may tackle would be getting some old mac G4's (power pc architecture) to netboot and serve as thinclients as well. any thoughts there?
| |
| 06:44 | <alkisg> Another chroot
| |
| 06:45 | <jgalt> prettymuch just invoke ppc in the create step?
| |
| 06:47 | <alkisg> You need qemu to run ppc code under and amd64 processor
| |
| 06:47 | *an
| |
| 06:47 | <jgalt> rdp could work if one had a windows vm running somewhere.
| |
| 06:47 | <alkisg> Yes but it's slow
| |
| 06:47 | Kids will complain about not being able to play games
| |
| 06:48 | <jgalt> why would I be running ppc code under amd64? it should run native on the mac g4's
| |
| 06:49 | <alkisg> Then you'd need to install ltsp-server on the mac
| |
| 06:49 | In order to be able to run ltsp-build-client to generate the chroot
| |
| 06:49 | And then transfer the chroot to your main ltsp server, if you want to
| |
| 06:50 | <jgalt> even if I was using the g4's as thin clients?
| |
| 06:50 | <alkisg> The question is: how will you *create* the ppc chroot?
| |
| 06:50 | Not what will you do when it's ready
| |
| 06:50 | When it's ready, sure, you can use it to boot g4's as thin clients against an i386 server
| |
| 06:51 | <jgalt> ah, thought it just downloaded those files precompiled.
| |
| 06:51 | <alkisg> No, it executes code
| |
| 06:51 | So you need a ppc processor, either an emulated one (qemu) or a real one
| |
| 06:51 | <jgalt> hmm,when I did that step it went and downloaded a bunch of stuff for the chroot
| |
| 06:52 | <alkisg> It downloads packages and then executes them
| |
| 06:52 | It's like `apt-get install program`
| |
| 06:52 | That downloads program.deb _and_ executes it
| |
| 06:53 | <jgalt> ah,ok - needs to execute enough of it to configure packages.
| |
| 06:53 | <alkisg> That's why some .deb files are arch-specific
| |
| 06:55 | uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek) | |
| 06:55 | <jgalt> I'd expect them to be arch specific as they generally contain compiled binaries but I hadn't thought about the config scripts/binaries they contain/
| |
| 06:56 | the reality is that packages are more than just an archive- just realized that
| |
| 06:57 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 07:09 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 07:10 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 07:14 | khildin has joined IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be) | |
| 07:22 | <jgalt> alkisg: Thanks bunches for the help. 'bout to callit a night here in the pacific time zone.
| |
| 07:22 | <alkisg> You're welcome jgalt
| |
| 07:23 | <jgalt> yea, always nice on both sides when stuff finally works
| |
| 07:25 | jgalt has left IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net) | |
| 07:25 | syrius has left IRC (syrius!~syrius@thunder.stormtek.net, Ping timeout: 264 seconds) | |
| 07:25 | syrius has joined IRC (syrius!~syrius@thunder.stormtek.net) | |
| 07:29 | map7_ has joined IRC (map7_!~map7@two1000979.lnk.telstra.net) | |
| 07:52 | vsuojane1 has left IRC (vsuojane1!~valtteri@83-136-248-31.uk-lon1.host.upcloud.com, Quit: leaving) | |
| 07:57 | khildin has left IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be, Ping timeout: 264 seconds) | |
| 08:07 | map7_ has left IRC (map7_!~map7@two1000979.lnk.telstra.net, Ping timeout: 248 seconds) | |
| 08:08 | map7_ has joined IRC (map7_!~map7@two1000979.lnk.telstra.net) | |
| 08:19 | map7_ has left IRC (map7_!~map7@two1000979.lnk.telstra.net, Ping timeout: 264 seconds) | |
| 08:37 | khildin has joined IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be) | |
| 08:57 | vsuojanen has joined IRC (vsuojanen!~valtteri@83-136-248-31.uk-lon1.host.upcloud.com) | |
| 09:18 | muppis_ has left IRC (muppis_!muppis@takaisin.fi, Ping timeout: 256 seconds) | |
| 09:19 | muppis has joined IRC (muppis!~muppis@takaisin.fi) | |
| 09:42 | alkisg is now known as work_alkisg | |
| 09:43 | work_alkisg is now known as alkisg | |
| 10:21 | map7_ has joined IRC (map7_!~map7@two1000979.lnk.telstra.net) | |
| 10:48 | map7_ has left IRC (map7_!~map7@two1000979.lnk.telstra.net, Ping timeout: 252 seconds) | |
| 11:19 | Faith has joined IRC (Faith!~paty@unaffiliated/faith) | |
| 11:58 | andygraybeal has left IRC (andygraybeal!~andy@h34.62.188.173.dynamic.ip.windstream.net, Read error: Connection reset by peer) | |
| 12:09 | yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be) | |
| 12:09 | yanu_ has left IRC (yanu_!~yanu@d1F05B2CD.access.telenet.be, Read error: Connection reset by peer) | |
| 14:25 | khildin has left IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be, Ping timeout: 256 seconds) | |
| 14:43 | khildin has joined IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be) | |
| 15:08 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 15:10 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 15:10 | bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Read error: Connection reset by peer) | |
| 15:11 | bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy) | |
| 15:38 | bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Ping timeout: 256 seconds) | |
| 16:25 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 16:35 | Uzzi has joined IRC (Uzzi!5528630e@gateway/web/freenode/ip.85.40.99.14) | |
| 16:35 | <Uzzi> hi
| |
| 17:19 | Uzzi has left IRC (Uzzi!5528630e@gateway/web/freenode/ip.85.40.99.14, Ping timeout: 246 seconds) | |
| 17:40 | khildin has left IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be, Ping timeout: 265 seconds) | |
| 17:53 | bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy) | |
| 17:55 | khildin has joined IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be) | |
| 18:59 | <lee> .host aeogamer
| |
| 18:59 | erp
| |
| 19:06 | khildin has left IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 19:37 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 19:38 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 19:49 | <Hyperbyte> derp!
| |
| 20:14 | AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-vnmllosnljseqojp) | |
| 20:58 | Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo) | |
| 21:59 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |
| 23:27 | AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-vnmllosnljseqojp, Quit: Connection closed for inactivity) | |