=== chris14_ is now known as chris14
=== genius3k is now known as genius3000
=== LewisCawte is now known as Lcawte
=== rpocase_ is now known as rpocase
=== Kuraokam1 is now known as Kuraokami
=== shokohsc51083 is now known as shokohsc5108
[12:08] <Grabunhold__> hey guys! I'm using an autoinstaller for ubuntu 20.04, and just today it stopped working. I'm using curl in the user-data field "late-commands", and it quits with "curl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /snap/subiquity/5004/usr/lib/x86_64-linux-gnu/libpsl.so.5)"
[12:08] <Grabunhold__> any ideas? :)
[12:13] <weedmic> upi can remove "snap subiquity" and install the real "ubiquity" from muon.  
[12:13] <weedmic> you not upi fingres in wrong plejc
[12:14] <Grabunhold__> i'm not sure what that means
[12:15] <Grabunhold__> what's upi?
[12:16] <weedmic> you are using snap subiquity - I am suggesting you uninstall it and replace with with ubiquity (but install it via muon so it installs correctly).  NOTE:  muon is the software manager with ubuntu
[12:17] <weedmic> might also be synaptic - unsure how some get one or the other.
[12:17] <tomreyn> weedmic: i think muon is a graphical package manager for kde
[12:17] <tomreyn> subiquity is the (snap based) ubuntu server installer
[12:18] <tomreyn> which comes with the ubuntu server installer iso
[12:18] <weedmic> ty - but his snap version is not working - I suggested he use ubiquity instead of the snap version
[12:18] <rbasak> Grabunhold__: there's a guide here
[12:18] <rbasak> https://ubuntu.com/server/docs/install/autoinstall-quickstart
[12:19] <rbasak> Grabunhold__: what you describe sounds like a bug, but it isn't clear without exact steps to reproduce please
[12:19] <Grabunhold__> what i'm doing: i'm fetching the ubuntu server ISO, place it on a http server along with the "user-data" file for the autoinstaller, extract kernel and initramfs from the serve that via pxe / tftp with kernel arguments pointing to the iso file 
[12:21] <Grabunhold__> here are the kernel parameters: kernel casper/vmlinuz initrd=initrd root=/dev/ram0 ramdisk_size=1500000 ip=dhcp fsck.mode=skip url=http://192.168.2.1/ubuntu-20.04.6-live-server-amd64.iso autoinstall ds=nocloud-net;s=http://192.168.2.1/autoinstall/ubuntu/20.04/ cloud-config-url=http://192.168.2.1/autoinstall/ubuntu/20.04/nullfile
[12:22] <Grabunhold__> in the autoinstall/ubuntu/20.04 directory are the meta-data and user-data files for the autoinstaller
[12:23] <Grabunhold__> my user-data starts with:
[12:23] <Grabunhold__> autoinstall:
[12:23] <Grabunhold__>   version: 1
[12:23] <Grabunhold__>   refresh-installer:
[12:23] <Grabunhold__>     update: yes
[12:23] <Grabunhold__> ##
[12:23] <Grabunhold__> i have tried changing that to "no", but then the installer won't even get to the "late-commands" stage
[12:24] <rbasak> dbungert: does this look like a bug to you? ^
[12:28] <Grabunhold__> if i use wget instead of curl in my late-commands, everything is working
[12:29] <Grabunhold__> i ssh'd into the live environment after the autoinstaller failed, and curl isn't even usable from the cli there. same error.
[12:29] <Grabunhold__> i can post the whole autoinstaller log to nopaste if it helps to debug
[12:29] <weedmic> try "which curl" on the live environment
[12:32] <Grabunhold__> oops, i can't any more - reinstall is in progress with the wget-variant...
[12:34] <weedmic> fyi, you can open many terminals at once
[12:34] <weedmic> well, unless you mean OS reinstall :o
[12:37] <rbasak> Grabunhold__: if you boot the vanilla ISO, does curl work from there?
[12:37] <rbasak> If not, I think it's worth a bug report - https://bugs.launchpad.net/subiquity/+filebug
[12:44] <Grabunhold__> weedmic: i meant OS reinstall ;)
[12:45] <Grabunhold__> the setup is an intel nuc minicomputer connected to an RPi, the RPi serving as the dhcp / pxe / tftp & web server
[12:45] <Grabunhold__> the nuc then netboots into the autoinstaller
[12:45] <Grabunhold__> rbasak: i'll try in a virtual machine
[12:47] <weedmic> ouch, but... it only takes about 10 mins +/- so why not have a clean start
[12:47] <weedmic> first thing after the install, do "which curl" to see if it is there at all
[12:50] <Grabunhold__> weedmic: the machine was being reinstalled anyway, that was the reason for starting the autoinstaller in the first place ;)
[12:52] <weedmic> I like to tweak new machines to perfection, sometimes harden them too, then I clone the drives before use - so if I screw it up later, i have a quick way to restore to prefection.
[12:54] <Grabunhold__> my approach is autoinstaller + ansible
[12:58] <Grabunhold__> okay, i just booted a virtual machine with the ubuntu server iso, let the installer update itself via snap, changed to a shell and "curl" still works in there
[12:58] <Grabunhold__> so it must be something specific to the autoinstall environment
[12:59] <tomreyn> i just did the same and confirm
[13:01] <Grabunhold__> it was reproducible when i used the autoinstaller. steps taken:
[13:01] <Grabunhold__>  - boot into autoinstaller via netboot
[13:01] <Grabunhold__>  - let autoinstaller update itself
[13:01] <Grabunhold__>  - run through OS installation (no errors here)
[13:01] <Grabunhold__>  - get to "late-commands" portion of the autoinstall, curl fails with the aforementioned glibc symbol error
[13:01] <Grabunhold__>  - ssh into the "installer" account, curl fails on that shell too with the same error
[13:15] <tomreyn> hmm, i'm trying to repro that via ssh login, but always end up in the installer (can spawn a shell from there again, but this is not the same environment as the late commands one, as discussed above)
[13:18] <ogra> smells like a packaging error of the installer snap ... this is a classic snap and the packager needs to make 100 sure that the environments of the host vs the snap never leak into each other, the libc error is a clear indicator for exactly this happening 
[13:19] <ogra> *100%
[14:11] <dbungert> curl in the install iso is not related in any way to the snap of subiquity
[14:25] <Grabunhold__> what ogra says feels like it matches the situation. i can't easily reproduce any more, the workaround with wget got the system up and running and i'm busy doing the rest of the provisioning work
[14:27] <dbungert> Grabunhold__: I just ran a reproduce attempt on this and wasn't able to see a problem.  If the environment is an issue, you may have better luck with "env -i curl ..." - don't feel obligated but if you do get enough info for a bug report please file.  Thanks.
[14:32] <Grabunhold__> dbungert: okay, let's see if i can reproduce it later on. now that the production machine in question was installed successfully, i'd have to set up a testing environment with a spare machine to try and reproduce
[14:35] <dbungert> Grabunhold__: no rush, thank you
[14:42] <Grabunhold__> dbungert: i still have a "screenshot" (taken by my coworker who is at the office with the machines, I'm remote): https://imgur.com/a/nNGycxw
[14:42] <Grabunhold__> the error noted in the /var/crash log was "curl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /snap/subiquity/5004/usr/lib/x86_64-linux-gnu/libpsl.so.5)", and when pressing enter to activate a shell curl was broken in the same way, too
[14:44] <dbungert> Grabunhold__: ok, I have a reproducer, you don't need to setup a testing environment
[14:44] <Grabunhold__> dbungert: oh cool!
[14:45] <Grabunhold__> so it's not only me, that always feels good :D
[14:52] <dbungert> yes, env -i fixes it, so I know the next steps.  Thanks again Grabunhold__ for reporting.
[14:52] <Grabunhold__> dbungert: if it isn't too much of a hassle, could you explain what happened?
[14:53] <dbungert> commands that live outside the snap should be running with an environment that does not use stuff inside the snap.  In this case it was a mix of libraries from inside the snap + curl outside, which went poorly.
[14:54] <dbungert> so {early,late}-commands should be run with a clean environment, which might be interesting if we're trying to run something provided in the snap
[15:06] <Grabunhold__> dbungert: so the curl command comes from the live env, but the ld search path includes stuff from the subiquity snap, leading to the glibc mismatch?
[15:06] <dbungert> Grabunhold__: I believe so yes, not confirmed though
[15:07] <Grabunhold__> dbungert: okay, understood. but you are able to reproduce it now if i understood correctly?
[15:08] <dbungert> Grabunhold__: yes, without question.  I will file a bug later today and I hope to get this fixed in time for 23.10.  Depends what happens if the user is intending to run something inside the snap, otherwise the fix is straightforward.
[15:10] <Grabunhold__> dbungert: cool. shoot me a link to the bugreport if you file, i'll be interested to follow along!
[15:12] <dbungert> Grabunhold__: https://bugs.launchpad.net/subiquity/+bug/2032961 - here's an empty bug report, I'll fill in the details after meetings
[15:12] -ubottu:#ubuntu-server- Launchpad bug 2032961 in subiquity "late-commands in focal iso may fail with symbol errors" [Undecided, New]
[15:12] <Grabunhold__> dbungert: fantastic, many thanks for your time and expertise
=== shokohsc51083 is now known as shokohsc5108
[21:30] <l3vi> hi, i have a few Ubuntu servers and would love to pay for Pro. Can I use a personal Pro on a server? 
[21:34] <sarnold> l3vi: "personal" usually means one of the free tiers, with five machines
[21:37] <l3vi> thanks, sarnold! Can the free tier be used on personal servers?
[21:38] <sarnold> l3vi: yup :)
[21:40] <l3vi> and if I have 6 servers, can I pay $25/year and use that on the sixth server?
[21:44] <sarnold> l3vi: that's a good question ;) I don't know. based on what I see in my personal ubuntu pro dashboard it feels like that's exactly how it works.
=== shokohsc51082 is now known as shokohsc5108