IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 5 June 2019 (all times are UTC)
| 00:18 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 00:21 | <Sleaker> hmm my old ltsp setup had an asound.conf.
| |
| 00:21 | I don't think this is correct anymore.
| |
| 00:24 | oh hmm, maybe it is.
| |
| 00:58 | ah nevermind it's working just like before, just have to change the configured device
| |
| 01:37 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com) | |
| 01:39 | gdi2k__ has left IRC (gdi2k__!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com, Ping timeout: 245 seconds) | |
| 02:05 | josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Quit: Ping timeout (120 seconds)) | |
| 02:06 | josefig has joined IRC (josefig!~josefig@unaffiliated/josefig) | |
| 02:19 | Sleaker has left IRC (Sleaker!quasselcor@2604:880:a:7::e1b, Ping timeout: 252 seconds) | |
| 02:19 | Sleaker has joined IRC (Sleaker!quasselcor@2604:880:a:7::e1b) | |
| 02:19 | ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 246 seconds) | |
| 02:56 | adrianor1 has joined IRC (adrianor1!~adrianorg@177.156.226.14) | |
| 02:59 | adrianorg has left IRC (adrianorg!~adrianorg@177.18.179.192, Ping timeout: 272 seconds) | |
| 04:28 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:a895:839f:87b0:61d8) | |
| 04:40 | quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: WeeChat 2.4) | |
| 04:42 | quinox has joined IRC (quinox!~quinox@ghost.qtea.nl) | |
| 05:09 | os_a has joined IRC (os_a!~Thunderbi@195.112.116.22) | |
| 05:12 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 05:46 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 248 seconds) | |
| 06:03 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 06:37 | woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de) | |
| 06:43 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 08:42 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 09:44 | statler has joined IRC (statler!~Georg@gwrz3.lohn24.de) | |
| 09:45 | Jose__ has joined IRC (Jose__!53384ca6@gateway/web/freenode/ip.83.56.76.166) | |
| 09:45 | <Jose__> How do I install the hard drive on the client?
| |
| 09:47 | hola?
| |
| 09:48 | Jose__ has left IRC (Jose__!53384ca6@gateway/web/freenode/ip.83.56.76.166, Client Quit) | |
| 09:48 | Jose__ has joined IRC (Jose__!53384ca6@gateway/web/freenode/ip.83.56.76.166) | |
| 09:48 | <Jose__> hola
| |
| 09:49 | queria preguntar como hago para auto montar el disco duro local en el cliente?
| |
| 09:49 | I wanted to ask how do I auto mount the local hard drive on the client?
| |
| 09:50 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 09:50 | ogra has joined IRC (ogra!~ogra_@ubuntu/member/ogra) | |
| 09:51 | <alkisg> Hi Jose__
| |
| 09:51 | <Jose__> hello
| |
| 09:52 | I wanted to ask how do I auto mount the local hard drive on the client?
| |
| 09:52 | <alkisg> You can put an FSTAB_0="xx" command in lts.conf
| |
| 09:52 | Is it a thin or a fat client?
| |
| 09:53 | <Jose__> client fat
| |
| 09:54 | <alkisg> OK, use FSTAB_0="/dev/sda1 /mnt ext4 errors=remount-ro 0 1" etc then
| |
| 09:54 | An fstab line there
| |
| 09:54 | <Jose__> gracias
| |
| 09:54 | <alkisg> Normally, users in the sudo group can mount internal disks by just clicking on them in the file manager
| |
| 09:54 | You're welcome
| |
| 09:55 | <Jose__> Would this serve for all customers?
| |
| 09:55 | <alkisg> If they all have sda1 and not different partitions
| |
| 09:55 | What do the internal disks have?
| |
| 09:55 | Windows? Ntfs? linux? ext4? home?
| |
| 09:57 | <Jose__> the discs are clean, it's just so they can use them. I'm doing a school project
| |
| 09:57 | <alkisg> If they're clean, you can't mount them
| |
| 09:57 | You need to format them first
| |
| 09:57 | How are you going to format them, ntfs, ext4?
| |
| 09:57 | <Jose__> I have them in ext4
| |
| 09:58 | <alkisg> OK then the FSTAB_0 line above should work
| |
| 09:58 | <Jose__> the problem is that to mount them it asks for the root account
| |
| 09:58 | <alkisg> It's because they're not in the "sudo" group; use FSTAB_0
| |
| 09:58 | <Jose__> in the client
| |
| 10:01 | I have put the line FSTAB_0 = "/ dev / sda1 / mnt ext4 errors = remount-ro 0 1" etc then and it does not load the disk
| |
| 10:02 | <alkisg> You didn't put it correctly, you used spaces
| |
| 10:03 | <Jose__> Spaces are added when copying
| |
| 10:05 | <alkisg> Did you put this in lts.conf, and did you reboot the client?
| |
| 10:06 | <Jose__> yes
| |
| 10:07 | <alkisg> What's the output of this command, from the client? cat /etc/fstab | nc termbin.com 9999
| |
| 10:09 | <Jose__> it was sda0, the disk is mounted but it does not appear in the file manager
| |
| 10:10 | <alkisg> There's no sda0
| |
| 10:10 | Numbering starts from 1
| |
| 10:11 | <Jose__> sorry sda
| |
| 10:11 | <alkisg> OK, please paste what I asked
| |
| 10:12 | <Jose__> what?
| |
| 10:12 | <alkisg> (01:07:28 PM) alkisg: What's the output of this command, from the client? cat /etc/fstab | nc termbin.com 9999
| |
| 10:12 | Run this command on the client and tell me the output
| |
| 10:14 | <Jose__> nc: getaddrinfo: Temporary failure in name resolution
| |
| 10:14 | <alkisg> Internet doesn't work on the clients?
| |
| 10:15 | <Jose__> yes
| |
| 10:15 | <alkisg> Do you have epoptes installed?
| |
| 10:16 | <Jose__> yes
| |
| 10:16 | <alkisg> OK, vnc to me to help you
| |
| 10:16 | !vnc-edide
| |
| 10:16 | <ltsp> vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
| |
| 10:16 | <alkisg> From the server
| |
| 10:21 | Jose__: everything is fine
| |
| 10:21 | Internal disks that are mounted in fstab don't show up like external disks in nautilus
| |
| 10:21 | They show up where you mounted them, e.g. now you mounted it in /mnt
| |
| 10:22 | (I closed VNC)
| |
| 10:22 | Jose__ has left IRC (Jose__!53384ca6@gateway/web/freenode/ip.83.56.76.166, Quit: Page closed) | |
| 10:25 | antares_ has joined IRC (antares_!c1929682@gateway/web/freenode/ip.193.146.150.130) | |
| 10:30 | <alkisg> ...you're welcome :)
| |
| 11:08 | GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net) | |
| 11:37 | woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 11:53 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 13:00 | gdi2k__ has joined IRC (gdi2k__!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com) | |
| 13:02 | gdi2k_ has left IRC (gdi2k_!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com, Ping timeout: 252 seconds) | |
| 13:59 | os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Quit: os_a) | |
| 15:58 | GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 245 seconds) | |
| 16:52 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 17:04 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-187.isotelco.net.br) | |
| 17:12 | <Sleaker> alkisg: what's the remote support thing in epoptes?
| |
| 17:14 | oh hmm.
| |
| 17:14 | does it only support VNC and console?
| |
| 17:14 | <alkisg> Sleaker: nah, telepathy too
| |
| 17:14 | :P
| |
| 17:14 | Yeah, just graphics and terminal, nothing more
| |
| 17:14 | <Sleaker> doesn't work with RDP though?
| |
| 17:14 | * vagrantc thought telepathy fell out of favor | |
| 17:15 | <alkisg> Nope, it's about screen sharing, not remote desktop
| |
| 17:15 | rdp is mostly remote desktop, not screen sharing
| |
| 17:15 | <Sleaker> ahh ok
| |
| 17:16 | seems like it's getting pretty close to having the same functionality as like teamviewer.
| |
| 17:17 | <alkisg> Eh, it's not commercial, so it mostly have the basics; but the best parts are that it doesn't involve a teamviewer server, and that it supports handling multiple clients at once (e.g. launching a URL in 20 clients)
| |
| 17:18 | vagrantc: I have two options: (1) nfsroot=/srv/ltsp/vm, and put the squashfs image in /srv/ltsp/vm/ltsp.img, or (2) nfsroot=/srv/ltsp, and put the squashfs image e.g. in /srv/ltsp/images/vm.img
| |
| 17:18 | <vagrantc> alkisg: i think i like the latter
| |
| 17:18 | <alkisg> I went for option (1); when using chroot, it's a bit annoying to have ltsp.img in your root dir, but I think it's better than (2)
| |
| 17:18 | <vagrantc> hah
| |
| 17:18 | :)
| |
| 17:19 | <alkisg> Because (2) isn't intuitive for chroots; the nfsroot should be /srv/ltsp/vm, not /srv/ltsp
| |
| 17:19 | <vagrantc> hmmm..
| |
| 17:19 | <alkisg> And, we'll mostly be using VMs not, not chroots
| |
| 17:19 | <Sleaker> yah just reminded me that I was wanting to look for a free tool that mirrored a lot of the functionality of teamviewer
| |
| 17:19 | <alkisg> So it'll be e.g. /srv/ltsp/buster/buster.vbox and /srv/ltsp/buster/ltsp.img
| |
| 17:20 | <vagrantc> alkisg: sounds fine too
| |
| 17:20 | <Sleaker> alkisg: so how does the remote assistance thing work. what's the requirement on the host side?
| |
| 17:21 | <alkisg> Great; so now the command line is just root=/dev/nfs nfsroot=${srv}:/srv/ltsp/${img}, and it automatically uses chroot/vm/squashfs; if automatic isn't desired, one can specify ltsp.mount=path/to/image
| |
| 17:21 | <vagrantc> all the epoptes clients connect to a server you've configured, so you need epoptes-client installed on all the clients
| |
| 17:21 | <alkisg> Sleaker: I spent a couple of days writing documentation; try it! http://www.epoptes.org/installation
| |
| 17:22 | <vagrantc> alkisg: have you used epoptes over a WAN ?
| |
| 17:22 | <alkisg> vagrantc: I overview my schools that way
| |
| 17:22 | <Sleaker> alkisg: I'm specifically talking about the remote-assistance menu
| |
| 17:22 | doesn't seem to connect to a host.
| |
| 17:22 | <alkisg> Sleaker: you installed it and it doesn't work?
| |
| 17:23 | <Sleaker> I already have an install working with ltsp clients
| |
| 17:23 | <alkisg> !vnc-edide
| |
| 17:23 | <ltsp> vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
| |
| 17:23 | <alkisg> Try it ^
| |
| 17:23 | <Sleaker> sorry, that definitely violates company stuff.
| |
| 17:23 | <alkisg> I'm running this: (port forward 5500): xvnc4viewer -listen
| |
| 17:23 | <Sleaker> ahhh ok
| |
| 17:24 | so you have to run vnc in listen mode
| |
| 17:24 | <alkisg> So you just reverse connect with your x11vnc -connect to me
| |
| 17:24 | Right
| |
| 17:24 | <Sleaker> that's the missing piece
| |
| 17:24 | <vagrantc> alkisg: so the new code searches for various images and falls back to just using the NFS mount?
| |
| 17:25 | <alkisg> vagrantc: priority: chroot (if /proc exists), then image, then vm; that's only in "simple" mode, this is an advanced example:
| |
| 17:25 | root=/dev/nfs nfsroot=${srv}:/srv/ltsp/cd ltsp.loop=ubuntu-mate-18.04.1-desktop-i386.iso,fstype=iso9660,loop,ro,,casper/filesystem.squashfs,fstype=squashfs,loop,ro
| |
| 17:25 | This loop mounts two things, one inside the other
| |
| 17:25 | <vagrantc> alkisg: why default to chroot ?
| |
| 17:25 | alkisg: why mostly it won't be used?
| |
| 17:26 | <alkisg> It's just the priority; of course the others will be automatically used too
| |
| 17:26 | So if someone has a chroot and an image, I assume he'd want to use the chroot, for fast testing, and then specify the image when he switches to production
| |
| 17:26 | <Sleaker> alkisg: cool, working
| |
| 17:26 | <vagrantc> alkisg: so you've got loop mounts within loop mounts? :)
| |
| 17:27 | <alkisg> Right, and that way I'm able to boot an iso with ltsp code, or boot my computer from a vbox vm image!
| |
| 17:27 | <vagrantc> very nice
| |
| 17:27 | <alkisg> Or from an older installation at /srv/older-ubuntu
| |
| 17:28 | Now the syntax there is a bit tricky, but I didn't find anything better
| |
| 17:28 | commas for mount options; two commas to separate mount commands; and special fstype=xxx options instead rootfstype, as now I support multiple commands so one rootfstype isn't enough
| |
| 17:29 | <vagrantc> alkisg: why not ltsp.loopN where it mounts them in increasing order?
| |
| 17:29 | <alkisg> The same command can be used in ltsp-update-image
| |
| 17:29 | And in the ltsp-update-image.conf configuration file
| |
| 17:30 | <vagrantc> alkisg: the double-comma seems like the ugliest part
| |
| 17:30 | <alkisg> I thought about colon, but it's used in ipv6, in protocols etc
| |
| 17:30 | <vagrantc> semicolon?
| |
| 17:31 | <alkisg> ltsp image bla;bla
| |
| 17:31 | that second bla is a command, I hope noone names his image rm :P
| |
| 17:31 | <vagrantc> right
| |
| 17:31 | <alkisg> Same for |, &, >...
| |
| 17:32 | <vagrantc> still a little shaky in my understanding as to why you can't pass multiple arguments ... ?
| |
| 17:32 | <alkisg> ltsp image one two, usually would mean "update two images", not "find image two inside image one"
| |
| 17:33 | The most important part is to keep this simple: ltsp image i386
| |
| 17:33 | For the advanced things, they can just copy/paste from the docs
| |
| 17:33 | <vagrantc> "ltsp image" does what now?
| |
| 17:34 | <alkisg> That's ltsp-update-image
| |
| 17:34 | `ltsp kernel` is ltsp-update-kernels etc
| |
| 17:34 | <vagrantc> it generates the cpio archive to append to the initramfs ?
| |
| 17:34 | <alkisg> The squashfs image
| |
| 17:34 | ltsp image = ltsp-update-image
| |
| 17:34 | ltsp kernel = ltsp-update-kernels
| |
| 17:34 | <vagrantc> oh, i thought if you're mounting a loop device within a loop device, you wouldn't generate a squashfs image
| |
| 17:35 | since you'd just copy the iso from your distro of choice
| |
| 17:36 | <alkisg> I can't change the syntax depending on the use case; what you're saying is true if one wants to boot an .iso, but not if one wants to create a squashfs out of it for some reason
| |
| 17:36 | E.g. suppose that I want to create a squashfs image from the second partition of my fedora-vm; it still needs a tricky syntax
| |
| 17:36 | <vagrantc> just trying to wrap my head around the issues
| |
| 17:37 | lucascastro has left IRC (lucascastro!~lucascast@177-185-139-187.isotelco.net.br, Quit: Leaving) | |
| 17:37 | * alkisg did spend a lot of days on this; and he's happy that the simple cases are very simple: nfsroot=/srv/ltsp/vm, and `ltsp image vm` | |
| 17:37 | <vagrantc> ok, so you wouldn't necessarily just copy the partition wholesale ... you might want to make a sanitized image that they actually boot
| |
| 17:37 | <alkisg> Right; with cleanup and everything
| |
| 17:37 | <vagrantc> alkisg: yeah, just trying to catch up with you :)
| |
| 17:38 | <alkisg> The same code is used for extracting kernels, for generating squashfs images, and for nfsroot mounting
| |
| 17:38 | And, in kernel cmdline, bash cmdline, and configuration files
| |
| 17:38 | So there's a lot of different demands from all these
| |
| 17:38 | <vagrantc> right
| |
| 17:39 | <alkisg> So to boot a different image than the defaults, it would be e.g.: nfsroot=/srv/ltsp/vm ltsp.image=vm-flat.vmdk
| |
| 17:39 | What sounds better there? ltsp.image, ltsp.loop, or ltsp.mount=xxx?
| |
| 17:39 | Usually it'll be a simple image, but the same parameter will also support crazy multiple commands
| |
| 17:40 | <vagrantc> i think loop is too specific ... image or mount
| |
| 17:40 | <alkisg> +1, I'm between those too
| |
| 17:40 | <vagrantc> are there anything that would be mounted that isn't an image?
| |
| 17:40 | <alkisg> Sure, for example to boot from a subdirectory, one can specify that one
| |
| 17:41 | <vagrantc> then i'd lean towards mount
| |
| 17:41 | <alkisg> E.g. if you have /srv/old-ubuntu in some partition, you can specify that in some submount
| |
| 17:41 | Great
| |
| 17:41 | Although `ltsp image [mount]` sounds a bit worse than `ltsp image [image]`
| |
| 17:41 | <vagrantc> hmmmm...
| |
| 17:42 | <alkisg> Tricky :P
| |
| 17:42 | <vagrantc> they both have their challenges
| |
| 17:42 | <alkisg> I'd love to use "root" there, but noone uses "root"; when we have a root in a subdir, we even call it "chroot", not "root"...
| |
| 17:43 | <vagrantc> well, "root" is an overloaded word already
| |
| 17:43 | could mean the user root, could mean the rootfs
| |
| 17:44 | <alkisg> Yeah
| |
| 17:44 | <vagrantc> now i'm waffling and preferring ltsp.image=...
| |
| 17:45 | <alkisg> set nfs_image root=/dev/nfs nfsroot=${srv}:/srv/ltsp/${img} ltsp.image=ltsp.img
| |
| 17:45 | That's what I currently settled on too :)
| |
| 17:45 | And in the extreme case someone needs a double loop, oh well, he'll understand
| |
| 17:45 | <vagrantc> a chroot can be thought of as an image anyways ... it's not a huge leap
| |
| 17:46 | if they're doing multiple layers of loop mounts, let's just say they had better be able to understand what they're doing
| |
| 17:46 | <alkisg> `ltsp image chroot` actually means " generate a squashfs image from that root", so it's ok,
| |
| 17:46 | while in kernel cmdline, it's just nfsroot=${srv}:/srv/ltsp/${img}, without specifying ltsp.image
| |
| 17:46 | <vagrantc> ltsp.image is just for the complicated multi-level loop mounts?
| |
| 17:46 | <alkisg> Right
| |
| 17:47 | That's why I default to chroot first
| |
| 17:47 | This whole ltsp image thing was strange; I spend a few days writing man pages, then code commends, then walking and thinking... and after that, coding was done in a day
| |
| 17:47 | Design time >>> programming time
| |
| 17:47 | <vagrantc> so you call "ltsp image chroot" it builds an image in /srv/ltsp/chroot/chroot.img ?
| |
| 17:48 | <alkisg> /srv/ltsp/chroot/ltsp.img
| |
| 17:48 | <vagrantc> always named ltsp.img ?
| |
| 17:48 | <alkisg> And I put ltsp.img in ltsp-update-image.excludes
| |
| 17:48 | Yes
| |
| 17:48 | And there's ltsp.old too (or ltsp.img~ if you prefer)
| |
| 17:48 | <vagrantc> earlier you had mentioned /srv/ltsp/buster/buster.img ?
| |
| 17:48 | * vagrantc prefers .old | |
| 17:48 | <alkisg> buster-flat.vbox is the vm, if one uses vbox fms
| |
| 17:48 | *vms
| |
| 17:49 | so it's chroot, squashfs = ltsp.img, or vm = chroot-flat.vm
| |
| 17:49 | Since vbox names it that way by using the GUI, I special-cased it
| |
| 17:49 | If someone asks for qemu/libvirt/whatever names, I can special-case them too
| |
| 17:49 | <vagrantc> and the correlary to "ltsp-update-image --cleanup /" ?
| |
| 17:50 | they're usually just DISK.img
| |
| 17:50 | <alkisg> I'm between `ltsp image --cleanup /` or forcing them to use a symlink first, to have a name
| |
| 17:50 | Not very important, code-wise...
| |
| 17:52 | About special dirs, I support 3 of them, BASE_DIR (the VMs/chroots), EXPORT_DIR (the nfs export+squashfs), and the TFTP_DIR; they all default to /srv/ltsp
| |
| 17:53 | I may rename BASE_DIR to IMAGE_DIR
| |
| 17:55 | Btw, if someone feels like triaging bugs that affect ltsp... https://bugs.busybox.net/show_bug.cgi?id=11941
| |
| 18:00 | (08:50:05 PM) vagrantc: they're usually just DISK.img ==> ok another reason to prefer ltsp.img then, to avoid clashes
| |
| 18:00 | <vagrantc> where DISK could be any arbitrary thing
| |
| 18:01 | including "ltsp"
| |
| 18:01 | <alkisg> if they do want to shoot themselves in the foot, we can't prohibit that
| |
| 18:01 | <vagrantc> typically whatever you named the virtual machine
| |
| 18:01 | <alkisg> One could also name their vbox vm /opt/ltsp/images/i386.img, and try to generate a squashfs to overwrite it :P
| |
| 18:02 | <vagrantc> well, i don't think it's unreasonable for a virtual machine that is your LTSP server to be named "ltsp"
| |
| 18:02 | <alkisg> /srv/ltsp/ltsp is the tftp dir
| |
| 18:02 | So they'd overwrite the tftp dir there
| |
| 18:02 | <vagrantc> well, these images will typically be in /var/lib/libvirt/images/ anyways
| |
| 18:02 | <mwalters> alkisg: a while back I was mucking about with uefi booting and had an issue where after loading grub, it was suuuuuuper slow to boot, and you pointed me at something and that fixed it... any chance you remember what that "something" was??? ;)
| |
| 18:02 | * vagrantc mostly uses LVM anyways | |
| 18:03 | <vagrantc> alkisg: so if the images aren't typically stored in the /srv/ltsp/ tree, is it even an issue?
| |
| 18:03 | <alkisg> Ah, btw, for images I'll only support flat images for now; no qcow, no lvm
| |
| 18:04 | <mwalters> Basically: I've got that wireless site set up... but as right after selecting the OS from the grub menu, it only hits at most 50Mbps, where I know the link is capable of much more (and once fully booted, is waaaay faster)
| |
| 18:04 | <vagrantc> lvm are just partitions like any other
| |
| 18:04 | <alkisg> No not at all; one would just have to define BASE_DIR or pass it as a parameter to ltsp
| |
| 18:04 | vgchange isn't available by default in initramfs's
| |
| 18:04 | Additional code is needed to handle lvm
| |
| 18:04 | It's not just losetup + mount
| |
| 18:04 | <vagrantc> alkisg: it is if the machine it's booting uses lvm
| |
| 18:05 | <alkisg> Yes, but ltsp image may not have it
| |
| 18:05 | We're not strictly inside an initramfs now
| |
| 18:06 | <vagrantc> alkisg: the hard part is you've been in this so deep you may have specific mental terminology that i'm not sharing :)
| |
| 18:06 | so i'm having a hard time following
| |
| 18:06 | overall i trust where it's going, though
| |
| 18:07 | <alkisg> I started with using qemu-nbd, which supports lvm and qcow and all, but it got too complicated too fast
| |
| 18:07 | So I thought I'd start with plain flat images first, and we might add support for lvm etc later
| |
| 18:07 | <vagrantc> well, i'm thinking you could generate the image from an lvm volume no different than if you generated it from a raw partition ... am i missing something?
| |
| 18:08 | are we talking about the same thing?
| |
| 18:08 | <alkisg> The lvm volume isn't loop0p1, it's /dev/mapper/things
| |
| 18:08 | And it can't be unmounted with umount/losetup, it needs lvchange and things
| |
| 18:09 | It can be done, but I think that if we're going there at some point, we'd better use qemu-nbd or libguestfs
| |
| 18:09 | So as to support compression and different image types too, vdi, qcow and all
| |
| 18:10 | <vagrantc> i'm not sure at what phase in the process you're saying it can't be done, if the system has /dev/mapper/PARTITION, then you can use it just like /dev/sda ... no other code required
| |
| 18:11 | are you talking about an image that contains partitions that contain lvm volumes?
| |
| 18:12 | right now, i can run "ltsp-update-image --cleanup /" on a system where /dev/mapper/SOMENAME is mounted as /
| |
| 18:12 | are you saying that is non-trivial?
| |
| 18:12 | or something else?
| |
| 18:14 | and of course, feel free to postpone this :)
| |
| 18:22 | statler has left IRC (statler!~Georg@gwrz3.lohn24.de, Remote host closed the connection) | |
| 18:30 | <alkisg> vagrantc: I'm saying that managing /dev/mapper needs code
| |
| 18:30 | Once it's there, it's trivial; but to mount/unmount it, it needs different commands
| |
| 18:30 | E.g. lvchange -an or something to unmount it, if I remember well
| |
| 18:31 | ltsp image needs to mount and umount everything inside the image, so it needs lv* commands
| |
| 18:32 | <vagrantc> you just use mount and umount on the /dev/mapper/NAME
| |
| 18:32 | lvchange is used to make them active or inactivate them
| |
| 18:33 | <alkisg> Of course if someone writes a wrapper that sets up /dev/mapper/*, then runs `ltsp image`, then umounts /dev/mapper/*, it'll work
| |
| 18:33 | So you can do it with just losetup and mount, without using lv* ?
| |
| 18:33 | <vagrantc> you run your own udev inside the image? how do you get normal device nodes?
| |
| 18:33 | <alkisg> I tried it with the fedora vm and it needed vg*
| |
| 18:34 | Let's focus on `ltsp image`; this runs outside the vm
| |
| 18:34 | <vagrantc> i'm just wondering about the simple case where the server is using lvm, and you currently do "ltsp-update-image --cleanup /" and it doesn't need any special mounting
| |
| 18:35 | all the device nodes are already populated, etc.
| |
| 18:35 | <alkisg> / is a dir, it doesn't involve the loop code
| |
| 18:35 | I'm talking about `ltsp image /path/to/vm-with-lvm.img`
| |
| 18:35 | <vagrantc> ok
| |
| 18:36 | yes, supporting lvm inside of an image will be harder, but such images should already have all the tools needed to handle itself ... but not activation of the nodes and such.
| |
| 18:36 | <alkisg> They'll have the code inside the image, not on the server where it will be needed
| |
| 18:37 | <vagrantc> ok, after all that, i get what you're saying now
| |
| 19:18 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 20:44 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 21:37 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 258 seconds) | |
| 21:39 | GodFather has joined IRC (GodFather!~rcc@143.59.184.72) | |
| 21:41 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
| 21:51 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Excess Flood) | |
| 21:52 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |