I had the idea to present the user with a PXE menu to install Ubuntu. After researching the idea, I decided to forgo this option, and utilize instead a zenity menu that could also be accessed by epoptes: github.com/jphein/boxen/…
However if you are interested in the PXE boot menu, and netbooting into a Ubuntu install here is some great info:
<pre>#Add to MAC of second server your existing dhcp conf to tell it to run the installer by default when it PXE boots
#Log in remotely into second server, after install
ssh [email protected]<ip from dhcp syslog> -p ubuntu
* Create PXE menu installer for both client and server.
* Client –> LTSP menu (default)
* Install boxen baby (wifi or vpn remote) client — ubuntu bionic desktop minimal install with xfreerdo-ngihtly
* Install boxen brain server — preseeded ubuntu with boxen install script
* Boot first HD
* netboot.xyz netboot.xyz/booting/tftp…
#ltsp: This is the place for support of LTSP. Ask your question and hang around for an answer. Check IRC logs at http://irclogs.ltsp.org [19:56] == jphein [[email protected]/web/freenode/ip.126.96.36.199] has joined #ltsp [19:56] -ChanServ- [#ltsp] Welcome to the Linux Terminal Server Project's irc channel [19:58] Hello to everyone. =] I have a nice LTSP install in KVM. It's using Ubuntu 18.04.1, with the chrootless dnsmasq proxy method [19:59] However, when I run ltsp-update-kernels my pxe config doesn't pick up the changes I make in /etc/ltsp/udpate-kernels.conf [20:00] my /var/lib/tftpboot/amd64pxelinux.cfg/ directory remains unchanged [20:01] When I make the changes directly in the files it works well [20:09] Am I missing something? [21:56] jphein: yes, /usr/share/ltsp/update-kernels [21:56] This transfers /etc/ltsp/update-kernels.conf to /boot/pxelinux.cfg/default [21:56] Then ltsp-update-image puts it in /opt/ltsp/images/amd64.img [21:57] And finally ltsp-update-kernels gets it from amd64.img and puts it to tftp [21:57] Thank you! I'll try it out. =] [21:57] It's so complicated that I wanted to get rid of it and just use a static file :D [21:59] hahaha [22:08] So it never goes to /var/lib/tftpboot/ltsp/amd64/pxelinux.cfg/ ? [22:17] I'd like to install Ubuntu as a pxe option before my ltsp menu [22:32] jphein: sure, it goes to pxelinux.cfg after the 4 steps I mentioned above [22:38] lol!
#ltsp: This is the place for support of LTSP. Ask your question and hang around for an answer. Check IRC logs at http://irclogs.ltsp.org [21:36] == jphein [[email protected]/web/freenode/ip.188.8.131.52] has joined #ltsp [21:36] -ChanServ- [#ltsp] Welcome to the Linux Terminal Server Project's irc channel [21:37] Hello! =] Does anyone know where I would put my install-ubuntu kernels so that update-kernels picks them up and presents them on the PXE menu? [21:39] Or, do I have to edit the pxelinux.cfg/default symlink manually? [21:39] == vagrantc [[email protected]/vagrantc] has joined #ltsp [21:41] This is my https://github.com/jphein/boxen/blob/master/etc/ltsp/update-kernels.conf [21:44] I suppose I can edit my dnsmasq.d/ to add the mac address of the client I'd want to install. With the ubuntu-install pxe boot config. [21:48] I'm also having issues with the chrootless method in the Azure cloud. Seems the Azure kernel may not have all the right input drivers for KVM? [22:25] jphein: I'm not sure what you're asking; why do you need more than one kernel? [22:25] If you only keep one kernel, then ltsp will pick them up [22:26] Now if you want multiple kernels, ltsp will pick up the latest [22:26] Sorry, let me rephrase that. Do you know of a simple way to present the PXE client user with a menu to install Ubuntu? [22:26] So if e.g. azure has 4.1, and you manually install 4.15, then the server will have 4.1 and the clients 4.15, without involving any configs [22:26] cool [22:26] jphein: ah sure, you just expose the .iso etc [22:27] But the "ltsp way to install a client" is to netboot it and cp -a /run/initramfs/rofs /target [22:27] I.e. to clone the ltsp image... [22:27] that's exactly what i want [22:28] You can also easily netboot it, and run: kvm -cdrom /path/to/windows -hda /dev/sda, so that you can even install windows while booted as an ltsp client [22:28] All those don't involve pxelinux at all [22:28] You do those via epoptes after the client boots normally via ltsp [22:28] oh yes kvm [22:28] (or locally) [22:29] with epoptes [22:29] nice [22:29] I usually don't want to leave my chair, so I do all clients via epoptes [22:29] haha =] [22:29] So I can be installed 3 different OSes on 3 clients without me going there [22:30] *I can install, meh [22:30] I can be installing. OK, got it :P [22:30] thank you , again! [22:30] np [22:30] I like that solution a lot. [22:31] Do you know the simplest way to preseed an Ubuntu installation with a few changes? [22:32] wcp -a /run/initramfs/rofs /target [22:32] Do I make a screen script? [22:33] jphein: let's clear something up [22:34] cp is for cloning the ltsp image [22:34] kvm is for installing ubuntu from an .iso [22:34] preseeding only applies to the iso [22:34] So which one are you asking about? [22:35] hahaha, I'm just very curious [22:35] =] [22:35] i like all of them [22:35] but I want to know more about the cp -a [22:35] it's a simple as that? [22:36] cloning [22:36] I don't make screen scripts for such simple things; I do make scripts that I run either from epoptes or directly from the client [22:36] cp, add user, install grub [22:36] You can also have a vm on the server, and use dd, to avoid all that [22:36] oh i see [22:37] using qcow? [22:37] or raw img [22:37] E.g. I have bionic-mate in vbox, then i expose it via nbd, and I dd if=/dev/nbd2 of=/dev/sda on the clients, and it's ready [22:37] Both can be done, qemu-nbd supports qcow and vdi and vmdk and raw [22:38] so many ways [22:38] that is the one i'll use since I already have the vm [22:38] You can even login normally as a user on the client, so that your image is accessible by sshfs in /home/username [22:38] So then you do dd if=/home/username/vms/myvm of=/dev/sda, done [22:38] No scripts, no screen scripts, nothing [22:39] You may only need to resize2fs /dev/sda1 afterwards, so that it extends to all the disk size [22:39] right [22:41] and you're doing this in a user with sudo privledges or something? [22:41] yes [22:41] Yup, with LDM_HASH_PASSWORD=True; or via epoptes :) [23:34] Which commands do you run after a cp -a /run/initramfs/rofs /target ? Install grub? [00:16] jphein: mount /dev/sda1 /mnt; cd /mnt; for d in proc sys dev dev/pts; do mount --bind /$d $d; done; chroot . dpkg-reconfigure grub-pc; umount dev/pts dev sys proc