=== chris14_ is now known as chris14 [03:22] 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] or, if your provisioning operations are driven by systemd services you could order those units After=cloud-init.target` [03:25] either would be easier than trying to remove cloud-init from the booted image and replicate the operations is performs. [03:25] *it performs [04:38] blackboxsw: Oh, awesome! Thank-you!! [04:50] 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] 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] Did you check the file to validate it's unmodified? [18:14] 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] libkeyutils1* [18:16] 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] this was while compiling weechat, which was last time compiled successfully on Feb 29 [18:23] there is /var/log/dpkg.log* [18:23] and /var/log/apt/* [18:26] I don't seem to find anything with grep related to libkeyutils1 [18:26] that would be really strange if you just tried to re-install it? [18:27] this is all I got: https://0bin.xyz/raw/DDHFT4IMR6EQY4VA2Z3CL7IMB4 [18:33] this already happened on another VPS, but it had no data and I resinstalled Ubuntu [18:33] on this server, I can't do that. I have almost 200GB worth of data [18:40] 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] seems to be okay? [18:47] which package is it from? [18:48] keyutils, probably? [18:49] dpkg -S /lib/x86_64-linux-gnu/libkeyutils.so.1.9 [18:50] this is what I got: libkeyutils1:amd64: /lib/x86_64-linux-gnu/libkeyutils.so.1.9 [18:51] https://packages.ubuntu.com/mantic/amd64/libkeyutils1/filelist ... I thought that included checksums; it does not [18:51] but still ... you can download that file and be absolutely sure it's the exact same checksum [18:53] how do I check that? [18:54] because I have absolutely no idea on hoe to proceed [18:55] 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] there are checksums in /var/lib/dpkg/info/libkeyutils1\:amd64.md5sums [18:55] ^ that's better [18:56] gosh. this confuses me too much [18:56] 'debsums' is a tool you can use https://manpages.ubuntu.com/manpages/trusty/man1/debsums.1.html [18:56] 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] it happened on another VPS but no one was able to help and I reinstalled the OS [18:57] I can't do that here [18:57] also, did you try if re-installing that package helped? [18:58] tried in both cases to no avail [18:58] when compiling you would also need 'libkeyutils-dev' I presume [18:59] if it's a dependency [19:00] (but that seems unrelated) [19:00] wait. I need to build manually? [19:00] you said it happened while compiling weechat? [19:02] anyway, first use debsums to check if those files changed [19:03] 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] ? [19:04] you don't have to build system packages [19:07] just install debsums and run: debsums libkeyutils1 [19:08] it returned OK in all [19:08] (3 checks) [19:09] then at least those files weren't changed [19:09] do you still have the same problem you had at the start? [19:11] yes. can't compile weechat. I acn try to compile something else that failed on the other machine [19:12] weechat fails on "make": https://0bin.xyz/LS44PZWGRX7GC46WD5YTJIIJ3Q [19:14] weirdly, another program that failed on the other VPS doesn't fail now [19:15] what does the following command say: ls -l /lib/x86_64-linux-gnu/libkeyutils.so.1 [19:17] lrwxrwxrwx 1 root root 20 Mar 7 20:02 /lib/x86_64-linux-gnu/libkeyutils.so.1 -> libkeyutils.so.1.9 [19:20] 20:02 was the last time I've reinstalled libkeyutils1 [19:21] what Ubuntu version is this? [19:22] Ubuntu 22.04.4 LTS [19:22] I wonder why the length of that is 20 instead of 18 [19:23] no idea, tbh [19:23] run a fsck ? [19:23] can I `fsck` with the server booted? [19:23] i read back you triwed to reinstall, on the troubled machine? [19:23] -w [19:24] 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] 18 being the correct size, maybe that's OK [19:25] except it's still 20 on their system... [19:25] the issue came out of the blue, tbh [19:26] last time I've installed weechat, all was good. I can reboot the server but I doubt that it will change anything [19:31] I wonder if deleting that symlink before re-installing the package would fix it? [19:31] I'm open to any ideas [19:32] I'm assuming you're talking about /lib/x86_64-linux-gnu/libkeyutils.so.1 ? [19:32] yes [19:35] nope. rm'ed it, used `apt install --reinstall libkeyutils1` to no avail [19:36] it recreates it with 20 as size? [19:37] yup, exactly [19:37] that's the size shown with `ls -l /lib/x86_64-linux-gnu/libkeyutils.so.1` [19:39] I need to get dinner and I'll be back in a bit [19:44] I suppose the size might differ based on file system; do you use something other than ext4 ? [19:48] (I'm on phone) this is what I get with `df -T`: https://termbin.com/9fu6 [19:48] shows /dev/md2 as ext4 [19:48] (which is the main disk) [20:24] so, any other ideas folks? [20:44] 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] rfm_: https://termbin.com/ud8p [20:54] as for the curl command: https://filehost.0bin.xyz/O03iVcsBkMrG.1 [20:54] couldn't upload to 0x0.st, getting "Segmentation fault" [21:34] I'm completely ¯\_(ツ)_/¯ [21:49] sorry guys, but my migraine is getting worse. I'll continue this tomorrow