[03:22] <blackboxsw> Just a thought: you can see the typical content fed to cloud-init via userdata on first boot by looking at `sudo cat /etc/cloud/cloud.cfg.d/99-installer.cfg` after first boot. Generally it's as you said, initial locale/timezone and primary user creation.  If you are performing firstboot provisioning operations and don't want to collide with cloud-init there a `cloud-init status --wait` would block until cloud-init is done
[03:24] <blackboxsw> or, if your provisioning operations are driven by systemd services you could order those units After=cloud-init.target`
[03:25] <blackboxsw> either would be easier than trying to remove cloud-init from the booted image and replicate the operations is performs.
[03:25] <blackboxsw> *it performs
[04:38] <MTecknology> blackboxsw: Oh, awesome! Thank-you!!
[04:50] <MTecknology> heh .. there's only instance-id, the locale being (re-)configured, and the user account that I don't want. It looks like it should be trivial to just not run this at first startup.
[18:10] <PeGaSuS> so, on a machine that was working perfectly and that I always keep updated, I'm getting: /usr/bin/ld: error: /lib/x86_64-linux-gnu/libkeyutils.so.1: file too short
[18:11] <MTecknology> Did you check the file to validate it's unmodified?
[18:14] <PeGaSuS> I didn't modified it for sure.. reinstalling ibkeyutils1 throws a `dpkg: warning: symbolic link '/lib/x86_64-linux-gnu/libkeyutils.so.1' size has changed from 20 to 18`
[18:15] <PeGaSuS> libkeyutils1*
[18:16] <PeGaSuS> all I've been doing is `apt update` and `apt dist-upgrade` most of the time. is there any logs I can check about the libkeyutils1 package update or something like that?
[18:16] <PeGaSuS> this was while compiling weechat, which was last time compiled successfully on Feb 29
[18:23] <JanC> there is /var/log/dpkg.log*
[18:23] <JanC> and /var/log/apt/*
[18:26] <PeGaSuS> I don't seem to find anything with grep related to libkeyutils1
[18:26] <JanC> that would be really strange if you just tried to re-install it?
[18:27] <PeGaSuS> this is all I got: https://0bin.xyz/raw/DDHFT4IMR6EQY4VA2Z3CL7IMB4
[18:33] <PeGaSuS> this already happened on another VPS, but it had no data and I resinstalled Ubuntu
[18:33] <PeGaSuS> on this server, I can't do that. I have almost 200GB worth of data
[18:40] <PeGaSuS> the command `file /lib/x86_64-linux-gnu/libkeyutils.so.1.9` returns: /lib/x86_64-linux-gnu/libkeyutils.so.1.9: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=ff27227afa5eeddccab180dd29bd7fcff94aea7c, stripped
[18:40] <PeGaSuS> seems to be okay?
[18:47] <MTecknology> which package is it from?
[18:48] <PeGaSuS> keyutils, probably?
[18:49] <MTecknology> dpkg -S /lib/x86_64-linux-gnu/libkeyutils.so.1.9
[18:50] <PeGaSuS> this is what I got: libkeyutils1:amd64: /lib/x86_64-linux-gnu/libkeyutils.so.1.9
[18:51] <MTecknology> https://packages.ubuntu.com/mantic/amd64/libkeyutils1/filelist ... I thought that included checksums; it does not
[18:51] <MTecknology> but still ... you can download that file and be absolutely sure it's the exact same checksum
[18:53] <PeGaSuS> how do I check that?
[18:54] <PeGaSuS> because I have absolutely no idea on hoe to proceed
[18:55] <MTecknology> a) apt-get source libkeyutils1  b) http://archive.ubuntu.com/ubuntu/pool/main/k/keyutils/keyutils_1.6.3-2.dsc  c) wget http://archive.ubuntu.com/ubuntu/pool/main/k/keyutils/keyutils_1.6.3.orig.tar.gz && tar ..
[18:55] <JanC> there are checksums in /var/lib/dpkg/info/libkeyutils1\:amd64.md5sums  
[18:55] <MTecknology> ^ that's better
[18:56] <PeGaSuS> gosh. this confuses me too much
[18:56] <JanC> 'debsums' is a tool you can use https://manpages.ubuntu.com/manpages/trusty/man1/debsums.1.html
[18:56] <MTecknology> Just because you don't remember modifying a file, doesn't mean you didn't do that at some point. If you're seeing similar behavior elsewhere, that's a good indication that it's not some random hardware hiccup
[18:57] <PeGaSuS> it happened on another VPS but no one was able to help and I reinstalled the OS
[18:57] <PeGaSuS> I can't do that here
[18:57] <JanC> also, did you try if re-installing that package helped?
[18:58] <PeGaSuS> tried in both cases to no avail
[18:58] <JanC> when compiling you would also need 'libkeyutils-dev' I presume
[18:59] <JanC> if it's a dependency
[19:00] <JanC> (but that seems unrelated)
[19:00] <PeGaSuS> wait. I need to build manually?
[19:00] <JanC> you said it happened while compiling weechat?
[19:02] <JanC> anyway, first use debsums to check if those files changed
[19:03] <PeGaSuS> sorry guys, but here's the thing: I have no idea how to use any of those tools, how to compile system packages, etc
[19:03] <JanC> ?
[19:04] <JanC> you don't have to build system packages
[19:07] <JanC> just install debsums and run: debsums libkeyutils1
[19:08] <PeGaSuS> it returned OK in all
[19:08] <PeGaSuS> (3 checks)
[19:09] <JanC> then at least those files weren't changed
[19:09] <JanC> do you still have the same problem you had at the start?
[19:11] <PeGaSuS> yes. can't compile weechat. I acn try to compile something else that failed on the other machine
[19:12] <PeGaSuS> weechat fails on "make": https://0bin.xyz/LS44PZWGRX7GC46WD5YTJIIJ3Q
[19:14] <PeGaSuS> weirdly, another program that failed on the other VPS doesn't fail now
[19:15] <JanC> what does the following command say: ls -l /lib/x86_64-linux-gnu/libkeyutils.so.1
[19:17] <PeGaSuS> lrwxrwxrwx 1 root root 20 Mar  7 20:02 /lib/x86_64-linux-gnu/libkeyutils.so.1 -> libkeyutils.so.1.9
[19:20] <PeGaSuS> 20:02 was the last time I've reinstalled libkeyutils1
[19:21] <JanC> what Ubuntu version is this?
[19:22] <PeGaSuS> Ubuntu 22.04.4 LTS
[19:22] <JanC> I wonder why the length of that is 20 instead of 18
[19:23] <PeGaSuS> no idea, tbh
[19:23] <oerheks> run a fsck ?
[19:23] <PeGaSuS> can I `fsck` with the server booted?
[19:23] <oerheks> i read back you triwed to reinstall, on the troubled machine?
[19:23] <oerheks> -w
[19:24] <PeGaSuS> yes, I did.. and it gave me a `dpkg: warning: symbolic link '/lib/x86_64-linux-gnu/libkeyutils.so.1' size has changed from 20 to 18`
[19:25] <sdeziel> 18 being the correct size, maybe that's OK
[19:25] <JanC> except it's still 20 on their system...
[19:25] <PeGaSuS> the issue came out of the blue, tbh
[19:26] <PeGaSuS> last time I've installed weechat, all was good. I can reboot the server but I doubt that it will change anything
[19:31] <JanC> I wonder if deleting that symlink before re-installing the package would fix it?
[19:31] <PeGaSuS> I'm open to any ideas
[19:32] <PeGaSuS> I'm assuming you're talking about /lib/x86_64-linux-gnu/libkeyutils.so.1 ?
[19:32] <JanC> yes
[19:35] <PeGaSuS> nope. rm'ed it, used `apt install --reinstall libkeyutils1` to no avail
[19:36] <JanC> it recreates it with 20 as size?
[19:37] <PeGaSuS> yup, exactly
[19:37] <PeGaSuS> that's the size shown with `ls -l /lib/x86_64-linux-gnu/libkeyutils.so.1`
[19:39] <PeGaSuS> I need to get dinner and I'll be back in a bit 
[19:44] <JanC> I suppose the size might differ based on file system; do you use something other than ext4 ?
[19:48] <PeGaSuS> (I'm on phone) this is what I get with `df -T`: https://termbin.com/9fu6
[19:48] <PeGaSuS> shows /dev/md2 as ext4
[19:48] <PeGaSuS> (which is the main disk)
[20:24] <PeGaSuS> so, any other ideas folks?
[20:44] <rfm_> PeGaSuS, well, I'd be interested in seeing "readlink libkeyutils.so.1 | od -xc" to see what those extra two bytes contain.  But I'd still have no idea how they got there..
[20:47]  * MTecknology curl -F'file=@/lib/x86_64-linux-gnu/libkeyutils.so.1' https://0x0.st
[20:52] <PeGaSuS> rfm_: https://termbin.com/ud8p
[20:54] <PeGaSuS> as for the curl command: https://filehost.0bin.xyz/O03iVcsBkMrG.1
[20:54] <PeGaSuS> couldn't upload to 0x0.st, getting "Segmentation fault"
[21:34] <PeGaSuS> I'm completely ¯\_(ツ)_/¯
[21:49] <PeGaSuS> sorry guys, but my migraine is getting worse. I'll continue this tomorrow