IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 26 September 2021 (all times are UTC)
| 02:44 | vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100b, Quit: leaving) | |
| 09:02 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 12:04 | lucascastro has left IRC (lucascastro!~lucascast@177-185-130-122.dynamic.isotelco.net.br, Ping timeout: 252 seconds) | |
| 12:05 | woernie has joined IRC (woernie!~werner@2001:9e8:e25c:2a00:acd7:3003:a217:1742) | |
| 12:09 | woernie has left IRC (woernie!~werner@2001:9e8:e25c:2a00:acd7:3003:a217:1742, Client Quit) | |
| 14:29 | superdad has joined IRC (superdad!~wrender@cpe7824af7d7910-cmf0f249403bc0.cpe.net.cable.rogers.com) | |
| 14:37 | <superdad> hi, so here is what we are looking to do: in an air-gapped environment, I have a bunch of servers with no hard disks. Some virtual machines that do have hard disks. I want to ipxe boot ubuntu 20.04 (minimal version with no gui if possible) into memory. I'm open to using NFS for initial boot, but we need it so that if our NFS server goes offline, the servers filesystem and OS still runs fine out of memory. Right
| |
| 14:37 | on what value LTSP adds, is the server portion needed?, how I would install that in an airgapped. I think we would want to use the chroot like this: https://github.com/ltsp/ltsp/wiki/chroots but I'm confused on how that would be able to load the entire filesystem into ram. When I tested it it seemed to be dependant on the NFS server being up at all times.
| |
| 14:37 | fottsia[m] has joined IRC (fottsia[m]!~fottsiama@2001:470:69fc:105::48bb) | |
| 14:45 | <alkisg> You need to install ltsp to create the additional initrd, ltsp.img, that contains the netbooting code
| |
| 14:45 | so "some" server is needed
| |
| 14:47 | Then that same ltsp.img can netboot any image
| |
| 14:48 | No nfs server is needed if you use IMAGE_TO_RAM ltsp.conf parametr
| |
| 14:49 | Then plain http can be used
| |
| 14:50 | <superdad> OK. We have a SAN that does NFS/HTTP. And dedicated hardware that does DHCP/DNS/TFTP
| |
| 14:51 | So the IMAGE_TO_RAM would allow booting over HTTP, and then if the HTTP/NFS SAN goes down the servers are all running in memory filesystem?
| |
| 14:54 | <alkisg> Yes
| |
| 14:54 | You can do that either with nfs or http
| |
| 14:54 | It will load the initial image, then keep it in ram
| |
| 14:55 | <superdad> ok. fantastic
| |
| 14:55 | I'm just setting up a test vm for ltsp right now.
| |
| 15:04 | So I need all of these on the server from the LTSP PPA? apt install --install-recommends ltsp ltsp-binaries dnsmasq nfs-kernel-server openssh-server squashfs-tools ethtool net-tools epoptes
| |
| 15:19 | <alkisg> No, probably just ltsp, binaries and squashfs-tools
| |
| 15:19 | <superdad> Ok. THanks. I'm just looking at where to put the IMAGE_TO_RAM setting now
| |
| 15:19 | <alkisg> !ltsp.conf
| |
| 15:19 | <ltspbot> ltsp.conf: Configuration file for LTSP: https://ltsp.org/man/ltsp.conf/
| |
| 15:20 | <superdad> Thanks, just put it in client section
| |
| 15:21 | So I used debootstrap to go to /srv/ltsp/focal
| |
| 15:21 | So then I can just run "ltsp image focal"
| |
| 15:21 | and ltsp ipxe, and then ltsp initrd?
| |
| 15:21 | <alkisg> chroot focal apt install ltsp
| |
| 15:22 | At a minimum, you need the squashfs module
| |
| 15:22 | It's not there in debootstrap, it's there in cloud images and cds
| |
| 15:22 | ltsp installs it
| |
| 15:22 | <superdad> I did all of the commands here: https://github.com/ltsp/ltsp/wiki/chroots Except for the xfce4 , since we don't want gui
| |
| 15:23 | So in my chroot at /srv/ltsp/focal I did : apt install --install-recommends ltsp
| |
| 15:23 | <alkisg> No
| |
| 15:23 | Ah ok
| |
| 15:23 | But no servers needed inside the chroot, ok
| |
| 15:24 | <superdad> Right no, ltsp server components you mean?
| |
| 15:24 | Just the ltsp client package?
| |
| 15:24 | <alkisg> Yes, no dnsmasq, no ssh-server etc
| |
| 15:24 | Yes, just a tiny client package is enough
| |
| 15:24 | And livecd/client images don't even need that at all
| |
| 15:25 | You can also just manually put the squashfs module in the initramfs if you prefer, but ltsp does that automatically, so why bother
| |
| 15:25 | <superdad> yup. my chroot /srv/ltsp/focal is just minbase, with the ltsp, linux-generic, initramfs-tools
| |
| 15:25 | <alkisg> You did install a kernel in the chroot, right?
| |
| 15:25 | OK
| |
| 15:25 | Sounds good
| |
| 15:25 | <superdad> So now I do ltsp image focal?
| |
| 15:25 | <alkisg> So now it should be bootable over nfs or http, with IMAGE_TO_RAM support
| |
| 15:25 | <superdad> To generate the image?
| |
| 15:26 | <alkisg> Yes
| |
| 15:26 | <superdad> ok, and then ltsp ipxe to generate the ipxe files?
| |
| 15:26 | <alkisg> Then, since you don't want the ltsp server to also be proxydhcp, you'll need to configure your main dhcp server
| |
| 15:26 | (or do you? want the ltsp server to be proxydhcp, which is easier?)
| |
| 15:27 | LTSP needs two initrds, the main and the extra ltsp.img, where the magic happens
| |
| 15:27 | <superdad> hmmm. good question
| |
| 15:27 | <alkisg> So the usual server configuration now needs a couple of extra directives
| |
| 15:27 | <superdad> I don't think we would want to proxy through this
| |
| 15:27 | <alkisg> Do you know what a proxydhcp is? The name is a bit misleading
| |
| 15:27 | It just provides the boot filename, it doesn't proxy the requests elsewhere...
| |
| 15:28 | If you're in test mode, just install dnsmasq and put the client in an internal subnet for now
| |
| 15:28 | It'll make your test faster
| |
| 15:28 | <superdad> oh, no i don't know what it does. I just don't want to mess with dhcp on the network and have the infra guys kill me
| |
| 15:28 | <alkisg> So, ltsp server ip = 192.168.67.1, ltsp client = internal subnet, install dnsmasq, and run `ltsp dnsmasq` and `ltsp ipxe`, and it will work
| |
| 15:29 | E.g. if your ltsp server is a VM, you can put 2 NICs on it, an internet-facing one, and an internal one
| |
| 15:29 | <superdad> hmmm
| |
| 15:30 | Ok. So you are saying I need to add another nic to my ubuntu ltsp server?
| |
| 15:30 | <alkisg> There are many many methods
| |
| 15:30 | I don't know your setup. In SOME cases, that MIGHT be faster
| |
| 15:30 | If you provide more information, I can help better
| |
| 15:30 | E.g. "is your ltsp server a VM"?
| |
| 15:30 | Do your clients already have ipxe on them?
| |
| 15:30 | <superdad> Well, i'm just at my home test setup right now
| |
| 15:31 | Not at the office
| |
| 15:31 | <alkisg> Are the clients a VM? etc etc
| |
| 15:31 | So you have a typical home router, right? Then just go for proxy mode
| |
| 15:31 | <superdad> Ya, So I have a dhcp/tftp server already setup. With dhcp option to point to the
| |
| 15:31 | <alkisg> I.e. the default, just install dnsmasq and run ltsp ipxe
| |
| 15:31 | Where do you have the dhcp server?
| |
| 15:31 | On the ltsp server?
| |
| 15:31 | <superdad> So I already have a full ipxe boot environment chain loading the ipxe working fine...
| |
| 15:31 | no. on a seperate server
| |
| 15:32 | <alkisg> isc-dhcp or dnsmasq?
| |
| 15:32 | <superdad> dnsmasq on my router which is just an asus ac68u with merlin firmware
| |
| 15:33 | <alkisg> Do you have access to a dnsmasq.conf?
| |
| 15:33 | <superdad> Ya, on my router I can edit DNSmasq. I already had to do that to setup my ipxe boot
| |
| 15:33 | <alkisg> Yes but not to send the second ltsp.img
| |
| 15:34 | <superdad> oh. One sec, let me send you what I have on my router
| |
| 15:34 | dhcp-boot=undionly.kpxe,ubuntu-server,192.168.1.142
| |
| 15:34 | <alkisg> Here's what a typical "external dnsmasq" looks like: https://github.com/ltsp/ltsp/discussions/529#discussioncomment-1336771
| |
| 15:35 | Nah, read mine instead :)
| |
| 15:35 | It contains support for bios, uefi, rpi, everything and the kitchen sink
| |
| 15:35 | <superdad> Then on my ubuntu-server at 192.168.1.142, I have the undionly-kpxe file that I am chainloading
| |
| 15:35 | <alkisg> And it loads the second ltsp.img as well
| |
| 15:35 | OK so at the end of the day you need to make the client load ltsp.ipxe, the ipxe script at /srv/tftp/ltsp/ltsp.ipxe
| |
| 15:35 | <superdad> Ok. Interesting
| |
| 15:35 | <alkisg> If you do that, you're good to go
| |
| 15:36 | <superdad> The only problem is, in my production environment I have Infoblox DHCP/TFTP that I need to work with
| |
| 15:36 | <alkisg> If you disable the boot options in your router, then ltsp dnsmasq takes care of that for you, via the proxydhcp protocol
| |
| 15:36 | That link that I sent you is for infoblox
| |
| 15:36 | Give it a read; back in 20'...
| |
| 15:36 | <superdad> ok. great ok
| |
| 15:38 | I'm a little confused on what exact options I need right now on my router's dhcp
| |
| 15:39 | <alkisg> Then disable all boot options and let ltsp take care of netbooting
| |
| 15:39 | By using proxydhcp
| |
| 15:40 | Or read that file/link, it should work immediately
| |
| 15:40 | <superdad> I'm just looking through it now. Would be good to have my home test setup similar to the infoblox at office, so that I can learn how it works
| |
| 15:51 | be back shortly. Thanks for all the help so far!
| |
| 15:59 | so to keep things simple. If I run "ltsp dnsmasq"
| |
| 15:59 | Then what do I setup on my router's dnsmasq to properly ipxe boot these images?
| |
| 16:00 | KeerthiS[m] has left IRC (KeerthiS[m]!~keerthiva@2001:470:69fc:105::e344, Quit: You have been kicked for being idle) | |
| 16:01 | <alkisg> You need to remove all dhcp-boot and pxe-service directives
| |
| 16:02 | I.e. all netbooting related ones
| |
| 16:02 | No boot filename, nothing
| |
| 16:24 | <superdad> How would the servers know where to ipxe boot from then?
| |
| 16:27 | <alkisg> Client requests IP, router sends IP, ltsp server sends boot filename (=proxy)
| |
| 16:27 | That's the meaning of proxydhcp
| |
| 16:28 | <superdad> ahh, ok. so the proxydhcp is responds to the initial dhcp request?
| |
| 16:28 | <alkisg> Yes
| |
| 16:28 | <superdad> nat
| |
| 16:28 | neat
| |
| 16:30 | Is it possible to boot this stuff using my own TFTP, and HTTP server though?
| |
| 16:30 | Without using the ltsp server ?
| |
| 16:31 | <alkisg> Yes, read the initial link that I sent you
| |
| 16:31 | You'd just copy ltsp.img in that case, the additional netbooting code that needs to be injected
| |
| 16:32 | <superdad> Sorry what link was that?
| |
| 16:32 | <alkisg> I think you should first try the easiest way to do it, THEN move on to all the restrictiions and harder ways. Now you lack some knowledge and you don't see how to more easily do your end goal
| |
| 16:32 | The one with ltsp discussions and dnsmasq.conf for infoblox (or any other external dnsmasq)
| |
| 16:34 | <superdad> Ok. I'll go ahead and try the easy way then
| |
| 16:36 | So I removed the boot entries from the dnsmasq config on my router
| |
| 16:36 | And then pxe booted a test virtualbox vm
| |
| 16:36 | And I can see "focal.img and focal" as the menu options
| |
| 16:37 | But when I select one it just says "could not select: Exect format error"
| |
| 16:37 | and Could not boot image: Exect format error
| |
| 16:40 | <alkisg> This either means "bad ipxe, with no bzimage support, e.g. from qemu/virtualbox", or "32bit client trying to boot a 64bit image"
| |
| 16:41 | <superdad> I think maybe for this reason, I had to chain load ipxe before to get it working
| |
| 16:42 | <alkisg> If you describe your setup better, we'll help you more easily.
| |
| 16:42 | For virtualbox, use ipxe.iso, it's better/faster
| |
| 16:42 | <superdad> In my home test environment I just have windows 10 with Virtualbox 6.1
| |
| 16:43 | At work. vsphere, esxi, and also Cisco UCS hosts
| |
| 16:43 | <alkisg> At home, yeah download ipxe.iso and boot from that one
| |
| 16:47 | <superdad> Just boot it from the virtual cd drive?
| |
| 16:49 | ok. that worked thanks
| |
| 16:50 | It seems to hang at NFS over TCP not avaialble from 192.168.1.226 (my ltsp server)
| |
| 16:52 | says right before that error. /init: line 235: dhclient: not found
| |
| 16:53 | Just tryint to re-go through these steps: https://github.com/ltsp/ltsp/wiki/chroots
| |
| 16:56 | <alkisg> The default steps need an nfs server
| |
| 16:56 | While then you can move on and download the image over http
| |
| 16:58 | <superdad> hmmm. I thought I enabled the nfs server
| |
| 16:58 | I ran "ltsp nfs"
| |
| 16:58 | <alkisg> apt install nfs-server; ltsp nfs
| |
| 16:58 | And was it succeful?
| |
| 16:59 | <superdad> ya, says nfs server was already installed
| |
| 17:00 | maybe i caused a problem when I ran debootstrap with --varient=minbase ?
| |
| 17:00 | I just re-did that without minbase
| |
| 17:01 | worked now!
| |
| 17:03 | Strange, I can't seem to login with the root passwd I set in the chroot
| |
| 17:05 | But everything else seems to boot the os correctly
| |
| 17:05 | <alkisg> ltsp has a cleanup phase
| |
| 17:05 | It erases sensitive things like passwords
| |
| 17:05 | !hash
| |
| 17:05 | <ltspbot> I do not know about 'hash', but I do know about these similar topics: 'LDM_PASSWORD_HASH', 'ROOT_PASSWORD_HASH'
| |
| 17:06 | <superdad> ahhh, that explains it thanks!
| |
| 17:06 | <alkisg> !ROOT_PASSWORD_HASH
| |
| 17:06 | <ltspbot> ROOT_PASSWORD_HASH: To be able to login as root in vt1, with password "qwer1234", put this in lts.conf: INIT_COMMAND_ROOT_HASH="sed 's!^root:[^:]*:!root:\$6\$p2LdWE6j\$PDd1TUzGvvIkj9SE8wbw1gA/MD66tHHlStqi1.qyv860oK47UnKcafSKqGp7cbgZUPlgyPv6giCVyCSCdJt1b0:!' -i /etc/shadow"
| |
| 17:06 | <alkisg> Wait this needs fixing
| |
| 17:07 | !forget ROOT_PASSWORD_HASH
| |
| 17:07 | <ltspbot> The operation succeeded.
| |
| 17:07 | <alkisg> !learn ROOT_PASSWORD_HASH as To be able to login as root in vt1, read the last example in https://ltsp.org/man/ltsp.conf/
| |
| 17:07 | <ltspbot> The operation succeeded.
| |
| 17:12 | <superdad> hmm. I added that, can't seem to login still with qwer1234
| |
| 17:13 | vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100b) | |
| 17:15 | stappers has joined IRC (stappers!~stappers@gpm.stappers.nl) | |
| 17:20 | <superdad> think I was missing running: ltsp initrd after modifying /etc/ltsp/ltsp.conf
| |
| 17:22 | hmmm. still can't set the root password for some reason
| |
| 17:26 | <alkisg> Maybe the help page is wrong, try to set your own hash
| |
| 17:28 | <vagrantc> yeah, remembering to run "ltsp initrd" has often been my pitfall lately :)
| |
| 17:34 | <superdad> Ok. Ya, alkisg, looks like the documentation has a mistake
| |
| 17:34 | I can do a pull request to fix it?
| |
| 17:35 | So my diskless server booted great, see everything running in ram
| |
| 17:36 | <alkisg> Sure you can do a PR
| |
| 17:36 | <superdad> I'll have to try and think of how this will integrate at work with infoblox, and nfsserver
| |
| 17:42 | * alkisg waves to vagrantc | |
| 17:43 | <alkisg> Although in this case its' the man page that's wrong
| |
| 17:43 | I think it maps to a different password, not to qwer1234
| |
| 17:46 | * vagrantc waves back at alkisg | |
| 18:46 | <superdad> oh. in that case ignore my pull request
| |
| 18:47 | So now that I have this booting using the ltsp server. How would I go about booting this over HTTP at the office?
| |
| 18:50 | so would want the infoblox to initiate the ipxe boot, and then it would go to an Dell EMC based nfs server.
| |
| 18:51 | Also, any way to install ltsp offline/air gapped?
| |
| 19:02 | <alkisg> superdad: you can install any debian package by running `apt install package --print-uris`; it will give you a list of .deb package URLs; then you can download them from elsewhere, and put them in /var/cache/apt/archives
| |
| 19:03 | I didn't understand the http/nfs question though; if it's an nfs server, why do you want http?
| |
| 19:03 | <superdad> Ok. I think I can use apt-mirror to create offline
| |
| 19:03 | Sorry, one one setup, I have an NFS server avail, on another I can only do over HTTP
| |
| 19:05 | <alkisg> For http-only, you'd need to read this PR: https://github.com/ltsp/ltsp/issues/75
| |
| 19:05 | kvaps there has similar needs to yours; the PR wasn't merged, I postponed it in order to implement it more cleanly, but you can still use it
| |
| 19:06 | <superdad> Just taking a look
| |
| 19:06 | <alkisg> So, the reason I proposed LTSP is that you can inject code in the initramfs. You now have a way to add a "wget" call in the appropriate place, without even remastering an iso or a squashfs
| |
| 19:06 | It's very very flexible
| |
| 19:07 | You put your code in ltsp, it then puts it in ltsp.img and it gets to the client as the additional initrd
| |
| 19:07 | So even if the cloud images don't have netbooting code, you can use ltsp to netboot them
| |
| 19:07 | <superdad> Well, I don't think I need to use the cloud images
| |
| 19:07 | <alkisg> You don't :)
| |
| 19:08 | (if I understood your use case correctly :))
| |
| 19:08 | <superdad> So how would i go about serving the image files, off of our custom http server
| |
| 19:08 | And ipxe booting those using the Infoblox
| |
| 19:08 | <alkisg> Read the PR, its' the exact use case
| |
| 19:09 | An http in dnsmasq and a wget in ltsp.img is all that's needed
| |
| 19:09 | wget is already available in the initrd, it's an applet of "busybox"
| |
| 19:10 | <superdad> But this is doing it on the ltsp server?
| |
| 19:10 | <alkisg> wget can target any IP
| |
| 19:10 | The only reason that you'll have an "ltsp server" is to run ltsp initrd and create ltsp.img
| |
| 19:10 | It won't be serving anything...
| |
| 19:11 | (and maybe ltsp image, if you want to maintain the chroots on the ltsp server)
| |
| 19:11 | <superdad> Ok. Right. Yes, I think we only want to maintain the chroots, which will probably be automated with jenkins
| |
| 19:12 | Just trying to get my head around the steps
| |
| 19:14 | So we already have our own undionly.kpxe and snponly.efi that goes to an ipxe boot file over http. And it gets the menu for CentOS 7, CoreOS and other operating systems.
| |
| 19:15 | Is it possible for me to take the ipxe code from /srv/tftp/ltsp/ltsp.ipxe that is booting the images, and adapt that into our menu?
| |
| 19:25 | <vagrantc> alkisg: did you have troubles with multiple initrds with pxelinux ? i know you switched to ipxe eventually
| |
| 19:26 | the syntax apparently accepts them as initrd first.img,second.img ... and it seems to work ... but not hugely reliably
| |
| 19:32 | <superdad> @alkisg. I think I answered my question. I just tested setting up my routers/dnsmasq, and my own custom http server/nfs server. And then chainloaded this in: https://pastebin.com/vsBSN0a5
| |
| 19:32 | works like charm!
| |
| 19:33 | So ya, I see the ltsp.img initrd is doing the heavy lifting.
| |
| 19:36 | <vagrantc> alkisg: as in ... sometimes the initrd just isn't read at all ...
| |
| 19:42 | <alkisg> Back, reading...
| |
| 19:42 | > Is it possible for me to take the ipxe code from /srv/tftp/ltsp/ltsp.ipxe that is booting the images, and adapt that into our menu? ==> sure, once you see how ltsp works, you can reproduce it elsewhere
| |
| 19:43 | > did you have troubles with multiple initrds with pxelinux ? i know you switched to ipxe eventually ==> no the main issue was uefi support (pxelinux had many issues there), and configuration abilities (ipxe has a scripting language)
| |
| 19:43 | > as in ... sometimes the initrd just isn't read at all ... ==> vagrantc : nah I didn't have any issues with initrd not getting read
| |
| 19:44 | Where are you seeing this, BIOS, UEFI, PC, uboot... ?
| |
| 19:47 | Aaah you meant if I had problems with pxelinux itself, not with ipxe
| |
| 19:47 | I haven't tested multiple initrds in pxelinux a lot, as I stopped using it when it failed to boot with many uefi scenarios
| |
| 19:47 | <vagrantc> alkisg: yes ... in this case i'm trying to load ltsp from syslinux for ... reasons
| |
| 19:48 | <alkisg> I wouldn't mind having an `ltsp syslinux` applet :)
| |
| 19:48 | <vagrantc> mostly for BIOS clients (for uefi, we're just using ipxe) ... and mostly tested using virtual machines using qemu+ipxe
| |
| 19:48 | <alkisg> There are few cases where ipxe doesn't work with the internal PXE stack, while syslinux does work; in those cases currently we're chainloading ipxe.pxe over undionly.kpxe
| |
| 19:49 | <vagrantc> but the real-world deployment would be on real hardware, of course :)
| |
| 19:49 | i wonder if the answer will be to switch to ipxe for all cases ... which is maybe doable
| |
| 19:49 | <alkisg> Note that the ipxe that is included in vbox is missing a lot of features, so if you go qemu > ipxe > pxeilnux, it might break due to the ipxe code...
| |
| 19:49 | <vagrantc> was trying to keep old-style LTSP environments concurrent with new-style ones and minimizing the differences
| |
| 19:50 | <alkisg> They limit things to reduce the size so that it's embeddable in ROMs
| |
| 19:50 | <vagrantc> i haven't touched virtualbox in over a decade :)
| |
| 19:50 | * alkisg did that too for a few months, then completely dropped old-style ltsp | |
| 19:51 | <vagrantc> basically trying to maintain 3 or 4 concurrent LTSP generations in one environment :/
| |
| 19:51 | <alkisg> I mean, I do know this is a problem with vbox, so maybe it's a similar problem with qemu too, but I haven't tested qemu a lot so I don't know for sure
| |
| 19:51 | Hehe, 3-4 generations would be ... 10+ years! :D
| |
| 19:52 | <vagrantc> oh, this goes all the way back :)
| |
| 19:52 | it's "fun" trying to figure out how to do this well
| |
| 19:52 | <alkisg> What was the first name again?
| |
| 19:52 | <vagrantc> ?
| |
| 19:53 | <alkisg> lessdisk or something?
| |
| 19:53 | The one you were using before ltsp
| |
| 19:53 | <vagrantc> hah, yeah, lessdisks was my earlier project ... this doesn't go *that* far back
| |
| 19:53 | <alkisg> (and developing)
| |
| 19:54 | <vagrantc> i stopped working on lessdisks ~2005, when i switched to working on ltsp
| |
| 19:57 | <alkisg> Last weekend at the sea for this ...summer :) A wonderful but also tiring day; going to bed early, good night all!
| |
| 19:58 | * vagrantc waves | |
| 20:56 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:40 | <superdad> Thanks for all the help @alkisg. So great to have all this stuff loading into memory with ltsp.
| |