[00:05] <hggdh> Guest64: sudo dmesg |less
[00:09] <xMopx> i have a ubuntu 20.04 box who's main ethernet interface is named `p119p1`
[00:10] <xMopx> i just did a dist-upgrade and it was renamed to eth0 which was annoying because it broke my network config
[00:10] <xMopx> not a big deal to fix, but why did it change?
[00:11] <xMopx> it's a bare metal install so i am certain the MAC didn't change
[00:14] <sixwheeledbeast> it shouldn't have changed from the above.
[00:16] <xMopx> fwiw i originally installed the box on 14.04 and have been upgrading it over time
[00:16] <xMopx> but it was 20.04 before and after the problem upgrade
[00:16] <sixwheeledbeast> they should be fixed "Predictable Names" MAC address wouldn't be used unless set manually
[00:18] <sixwheeledbeast> https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
[00:18] <tomreyn> "p119p1" does not seem to match this specification, though, unless i'm missing something
[00:22] <tomreyn> xMopx: do you know how the name "p119p1" was assigned originally?
[00:22] <sixwheeledbeast> p119p1 doesn't sound right. Maybe it fell back to classic eth0 for some reason?
[00:22] <xMopx> tomreyn: no more details besides that it was assigned automatically when i installed the original os
[00:22] <xMopx> i recall being annoyed it *wasnt* called eth0 at the time, heh
[00:23] <tomreyn> was it running on bare metal back then as well?
[00:23] <xMopx> yes
[00:23] <xMopx> hm, possibly a different motherboard, but definitely the same model of motherboard
[00:23] <tomreyn> hmm, weird, i can't think of why it would have taken this name in the old naming scheme either.
[00:24] <xMopx> certainly a replacement motherboard, now that I think about it
[00:24] <xMopx> however, that was years ago and probably when i was on 16.04 or 18.04
[00:26] <tomreyn> https://samiux.blogspot.com/2015/07/howto-protect-my-home-network-with.html "Since the network interfaces of Asrock Rack C2750D4I are Intel i210, the name of the interfaces on Ubuntu 14.04 is p119p1 and p121p1."
[00:27] <tomreyn> chances are you were using a network interface driver provided by intel then, maybe because there was no in kernel support for those NICs, yet
[00:27] <xMopx> that's my exact motherboard
[00:27] <xMopx> ahha
[00:28] <tomreyn> vendior drivers may sometimes assign weird names to NICs
[00:28] <tomreyn> other than meaning you'll need to search and replace your firewall script, is there other impact now that it was renamed?
[00:30] <tomreyn> the goal of the new naming scheme is to provide stability from hereon, so that those network interfaces will always have the same name, for the same interface, even with multiple interfaces managed by the same driver, with ever reboot.
[00:32] <tomreyn> i see how it's bad that a non release upgrade applied the new naming scheme, i'm not sure why that would have happened. maybe you're on the HWE kernel and got a newer kernel which now supports this interface.
[00:32] <xMopx> no impact besides my network config file
[00:32] <xMopx> i've got a second identical box to do next, though :)
[00:32] <tomreyn> hmm, i think i210 has been supported for a long time, though
[00:33] <tomreyn> xMopx: does this output much?   apt list --installed | grep ',local\]$' | nc termbin.com 9999
[00:34] <xMopx> is i210 related to kernel module "cp210x"?  i see that being removed comparing lsmods between the boxes
[00:34] <tomreyn> should be igb
[00:34] <xMopx> igb present on both boxes
[00:34] <xMopx> checking that commmand
[00:34] <tomreyn> cp210x is a usb to serial module
[00:36] <xMopx> tomreyn: diff of that cmds output https://pastebin.com/zfD0h0N8
[00:36] <xMopx> updated box is the latter
[00:37] <tomreyn> hah, that's some old stuff there
[00:37] <xMopx> puppet and nagios i know is old but what else?
[00:37] <tomreyn> biosdevname is a remainder from 14.04, i think
[00:37] <xMopx> and i guess gcc 4.8 is old too
[00:38] <xMopx> ah that sounds like the relevant package haha
[00:38] <tomreyn> none of these packages are available from any of the currently configured (on your respective systems) apt repositories
[00:39] <xMopx> i've been doing `dist-upgrade` somewhat regularly, why did it stick around until now?
[00:39] <tomreyn> you probably had a semi failed do-release-upgrade at some point. when this happens, packages aren't cleaned up in the end.
[00:40] <xMopx> that sounds right, 18.04 to 20.04 was rough
[00:40] <tomreyn> or maybe some of those packages were just missed (i.e. release upgrade bug) on 14.04 -> 16.04, and those packages weren't actually removed by do-release-upgrade
[00:41] <tomreyn> old systems will often have those remainder packages unless those were cleaned up later
[00:42] <xMopx> gotcha, that seems like it
[00:44] <xMopx> /var/log/dist-upgrade/main.log:2021-05-24 19:36:17,849 DEBUG Obsolete: biosdevname <snip>
[00:44] <tomreyn> so make sure you remove / purge all those packages that you have not installed on purpose, knowing it will be compatible to your current ubuntu release
[00:45] <tomreyn> hmm yes it should probably have removed it then
[00:45] <tomreyn> but already the release upgrade before that
[00:46] <tomreyn> (i assume 2021-05-24 is when you did 18.04 -> 20.04)
[00:46] <xMopx> that's right, and some aspect of my mirror made it trouble
[00:46] <xMopx> 14->16->18 has been too long for me to remember any details
[00:47] <tomreyn> lspci -knn | grep -EA3 '(Network|Ethernet) controller'    should tell you which driver is currently in use for the intel NICs
[00:47] <xMopx> igb on both boxes
[00:53] <xMopx> tomreyn: i appreciate you taking a look. Certainly seems like an old-box edge case 😅
[00:56] <tomreyn> yes, that's my guess, too.
[00:57] <tomreyn> if you have it properly puppetized, a fresh install may be a good thing to do
[00:58] <xMopx> unfortunately not completely but i'm a fan of 'puppetized' as an adjective
[01:18] <oops> during using bind9 host domain, there has one step is putting "search my-doman.com" in "/etc/resolv.conf", my os is 20.04, the /etc/resolv.conf can't be changed manually
[01:33] <Marz> Anyone saw Pig?
[01:34] <sarnold> Marz: pig isn't in my lastlog, probably 10k lines
[01:34] <Marz> Wrong channel
[01:36] <pikapika> How do I start a shell from thunar actions?
[01:39] <pikapika> a shell script rather
[01:49] <pikapika> ...I can probably do with calling a zenity dialog from a C program for this case I guess
[01:58] <GSMarquis> I have a HDD as a secondary storage device. It randomnly unmounts between suspend sessions. Internal sata.
[02:52] <Guest3735> Trying to transfer stuff to a SD card but the speed is 0 bytes/second with 596,523 hours left
[03:04] <guiverc> Guest3735, have you checked logs for errors?  you didn't give OS & release details but I'd look for clues in systemd journal, dmesg etc
[03:07] <Guest3735> I'm not seeing any errors
[03:08] <Guest3735> This is also not a new problem as I've had it with other cards in the past. Just annoying me now because I really need to transfer this
[03:15] <Bashing-om> Guest3735: How is the card mounted ? What does ' mount ' show for the mount point ?
[03:17] <Guest3735> ?
[03:21] <[code]> i'd check dmesg/journalctl
[03:22] <Guest3735> Already did, no errors
[04:21] <oops> what's the exactly email in SOA record , i don't know how to fill that email address, some tutorial is "admin.domain.com" ,and ubuntu server guide is "root.domain.com", i order a domain like" caill.top" with myself 5421545@qq.com email,then which is the right form among" admin.caill.top /  root.caill.top / 5421545.qq.com."
[07:29] <sricaren> Hello
[07:29] <sricaren> Can i get help
[07:29] <sricaren> Helloo=
[07:30] <sricaren> My mic plays some scratchy noise but my voice isn't heard
[07:33] <sricaren> Please help
[09:37] <moha> after installing ntp server, should we set time zone, or it should be handled client-side?
[09:40] <nucc1> if i wanted to customise the systemd unit file for apache2, do I simply edit the one that's installed in /lib/systemd/system ?
[09:41] <nucc1> nevermind, i found that if i create an equivalent service in /etc/systemd/system/ it will be treated as an overrride.
[10:18] <Doob> after great research and work I have achieved joining my first chatroom
[10:21] <tomreyn> moha: timezone is set on each system individually
[10:32] <Doob> anyone there? still figuring out how to use hexchat
[10:32] <Doob> not sure if i did this right
[10:32] <moha> tomreyn: So the ubu+
[10:33] <moha> So the ubuntu clock does not have effect on clients and ntp?
[10:36] <moha> tomreyn: people are asking me to set ntp on time zone; I;m going to say it's impossible, right?
[10:36] <moha> on local time*
[10:48] <cbreak> I don't see a reason to set a time zone for a time server
[10:49] <TJ-> NTP uses UTC; clients then use their own TZ setting to calculate the local time
[10:49] <tomreyn> moha: i don't know whether it's impossible, but it's most likely not something you ever want
[10:51] <tomreyn> moha: this might help you progress (and make them happy, too): why are they asking for it to use local time?
[11:03] <amosbird> Hmm, ubuntu-mate is pronounced as maatei?
[11:09] <VIA> :S
[11:15] <Mekaneck> amosbird: keep in mind that this is a support channel. Your question hasn't anything to do with asking for support with Ubuntu. so either go over to #ubuntu-discuss or #ubuntu-offtopic.
[11:16] <Mekaneck> and how to pronounce MATE can be found on the web
[11:19] <sixwheeledbeast> amosbird: https://en.wikipedia.org/wiki/Yerba_mate
[11:19] <Mekaneck> sigh...
[11:29] <xx> I have xubuntu-20.04.2-desktop-amd64.iso but xubuntu-20.04.2.0-desktop-amd64.iso exists. What are the differences?
[11:39] <BinarySavior> hi, I'm having trouble with libGL.  I tried reinstalling video drivers and that didn't work.  Here is the libGL error: https://paste.ubuntu.com/p/G2gPZskQ5Q/
[11:40] <BinarySavior> this stopped working after i tried to remove a kubuntu-desktop installation from my stock ubuntu 20.04 OS
[11:43] <Mekaneck> xx: the 20.04.2.0 is the correct one, it was a respin due a criticatl bug that was found last minute in the 20.04.2 iso
[11:44] <Mekaneck> the respin was done for all Ubuntu flavours
[11:45] <xx> Mekaneck: so I should scrap my cd that I was planning on using and download the new one then
[11:45] <xx> is there some info about the critical bug somewhere?
[11:45] <xx> it didn't reach any tech news sites
[11:45] <tomreyn> BinarySavior: i told you this yesterday, did you read it? <tomreyn> your easiest approach is probably a fresh install. <tomreyn> make backups of your home directory beforehand
[11:46] <tomreyn> oh yes, you read it.
[11:47] <BinarySavior> tomreyn, i have that in the back of my mind, but i'd rather not reinstall the OS completely unless I absolutely cannot figure out this issue
[11:47] <Mekaneck> xx: can't remember what the bug was, sorry
[11:47] <BinarySavior> everything appears to be working except a game I play in wine
[11:48] <Mekaneck> xx: just use teh 20.04.2.0 iso and you'll be fine
[11:49] <tomreyn> BinarySavior: the immediate issue you're trying to solve now is that your (opengl) graphics acceleration isn't working, probably because the right graphics driver did not load for some reason.
[11:50] <tomreyn> BinarySavior: kubuntu has some key differences to gnome (which the default ubuntu desktop is based off), it's just not easy switching back and forth properly.
[11:50] <Mekaneck> xx: i found this https://fossnoobs.com/ubuntu-20-04-2-lts-has-a-oem-install-bug/
[11:53] <xx> Mekaneck: thank you. I wasn't planning on making an OEM installation, so I should be fine with the older iso.
[11:54] <manwhowouldbekin> Greetings, all. I seem to have messed up my Ubuntu 20.04 system to the point of where fixing it is beyond my knowledge. Is this a good place to ask some technical questions about troubleshooting issues?
[11:54] <tomreyn> BinarySavior: gnome-shell/mutter and even gdm run X under a restricted user account (and both default to xwayland since Ubuntu 21.04, previously just gdm does; all of this is unless you are using nvidia proprietary graphics drivers) whereas sddm/kde (plasma) still run Xorg as root (as far as i know). each have a massive stack of dependencies, and diufferent ones.
[11:55] <tomreyn> manwhowouldbekin: you've some to a good place for this.
[11:56] <tomreyn> manwhowouldbekin: start by describing what doe snot work as expected, what may have caused it, what you have done so far in an attempt to fix it.
[11:56] <manwhowouldbekin> tomteyn: I actually wrote up an issue on Ask Ubuntu on it. Would a link help?
[11:57] <BinarySavior> tomreyn, i am running nvidia proprietary
[11:57] <BinarySavior> also I have ubuntu 20.04
[11:59] <tomreyn> manwhowouldbekin: that or explaining the problem here, yes
[12:00] <manwhowouldbekin> tomereyn: Thanks! Here is is: https://askubuntu.com/questions/1353781/broken-ubuntu-20-04-trying-to-remove-libc-bin
[12:00] <tomreyn> BinarySavior: i see. this will complicate matters. but maybe not by much.
[12:04] <tomreyn> manwhowouldbekin: wouldn't a fresh installation take a lot less time than trying to fix this? by the time you "messed" with libc6, this is usually the best approach.
[12:05] <BluesKaj> Hi all
[12:05] <BinarySavior> perhaps
[12:05] <manwhowouldbekin> tomreyn: Well, that is certainly an option. I was just trying to figure out if that is the only one available before I act.
[12:06] <tomreyn> manwhowouldbekin: it may not be the only option. it may be the fastest solution.
[12:07] <tomreyn> this would never happen unless you mixed apt repositories made for different ubuntu releases: "I encountered some issues with package libc6 being version 2.31 instead of 2.33"
[12:07] <tomreyn> try not to do so in the future
[12:08] <manwhowouldbekin> tomereyn: Yeah, I was definitely in over my head there.
[12:09] <tomreyn> each ubuntu release uses exactly one version of libc6, whichever kernel version you have installed or whatever. "focal" (20.04 LTS) uses 2.31
[12:09] <Mekaneck> xx: no, the older iso is the one with the bug
[12:09] <Mekaneck> you'll be fine with 20.04.2.0 as i said before
[12:13] <manwhowouldbekin> tomereyn: Got it. On the point of restoring, if I have an Aptik license, can do some damage control and try to back up as much data, settings and apps as possible, while avoiding the damaged bits? What would be the things to avoid?
[12:13] <manwhowouldbekin> tomreyn: https://teejeetech.com/aptik-3/
[12:16] <speedy67> 'lo
[12:18] <speedy67> I'm looking for help about installing Ubunu 20.04 LTS on a 2006's macbook pro 2,1 with ati radeo 1600 and 32bits efi
[12:18] <TJ-> manwhowouldbekin: doesn't look that bad to me :)
[12:18] <speedy67> cpu : core2duo 64 bits
[12:19] <manwhowouldbekin> TJ-: What's not bad? You think there is a chance to fix it? How? :-)
[12:19] <speedy67> for the moment I successfully boot from the livecd put on a usb stick
[12:19] <tomreyn> manwhowouldbekin: i'm not familiar with this software, but i think teejee does provide support for it
[12:19] <TJ-> manwhowouldbekin: well, from what I can see, you've 'simply' removed/replaced a couple of packages
[12:19] <tomreyn> manwhowouldbekin: you should probably back up your home directory most of all
[12:20] <TJ-> manwhowouldbekin: can you show us "pastebinit /var/log/apt/history.log"
[12:20] <tomreyn> manwhowouldbekin: if TJ- (not teejee) is offering you help to get out of this, i recommend working with him
[12:21] <TJ-> :P
[12:21] <speedy67> but after installing on hard disk, I get a black screen after grup despite the nomodeset option
[12:21] <tomreyn> sorry TJ- ;)
[12:21] <speedy67> grup =grub
[12:21] <TJ-> tomreyn: damning reccommedation :)
[12:21] <manwhowouldbekin> tomreyn: Yes, let me try with him. Thank you for YOUR help! :-)
[12:22] <tomreyn> TJ-: i said "if", i don't know that you do ;)
[12:22] <speedy67> I'm wondering about two kinds of issues : gpu driver
[12:22] <manwhowouldbekin> TJ-: Btw, I get this when running that command:
[12:22] <speedy67> EFI partition
[12:22] <manwhowouldbekin> Reading package lists... Done
[12:22] <manwhowouldbekin> Building dependency tree
[12:22] <manwhowouldbekin> Reading state information... Done
[12:22] <manwhowouldbekin> You might want to run 'apt --fix-broken install' to correct these.
[12:22] <manwhowouldbekin> The following packages have unmet dependencies:
[12:22] <manwhowouldbekin>  libc-bin : Depends: libc6 (< 2.32) but 2.33-0ubuntu5 is to be installed
[12:22] <manwhowouldbekin>  libc-dev-bin : Depends: libc6 (< 2.32) but 2.33-0ubuntu5 is to be installed
[12:22] <manwhowouldbekin>  libc6 : Recommends: libnss-nis but it is not installable
[12:22] <manwhowouldbekin>          Recommends: libnss-nisplus but it is not installable
[12:22] <manwhowouldbekin>          Breaks: libc6:i386 (!= 2.33-0ubuntu5) but 2.31-0ubuntu9.2 is to be installed
[12:22] <TJ-> manwhowouldbekin: stop!
[12:22] <manwhowouldbekin>  libc6:i386 : Breaks: libc6 (!= 2.31-0ubuntu9.2) but 2.33-0ubuntu5 is to be installed
[12:22] <tomreyn> !paste | manwhowouldbekin
[12:22] <manwhowouldbekin>  libc6-dbg : Depends: libc6 (= 2.31-0ubuntu9.2) but 2.33-0ubuntu5 is to be installed
[12:22] <manwhowouldbekin>  libc6-dev : Depends: libc6 (= 2.31-0ubuntu9.2) but 2.33-0ubuntu5 is to be installed
[12:22] <manwhowouldbekin>  locales : Depends: libc-bin (> 2.33)
[12:22] <manwhowouldbekin> E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
[12:23] <TJ-> manwhowouldbekin: you got that report from executing "pastebinit /var/log/apt/history.log" !?
[12:23] <TJ-> manwhowouldbekin: wait for yourself to be un-muted before replying
[12:24] <speedy67> to create the install usb stick, I've applied this tuto :
[12:24] <speedy67> https://mesom.de/efi32boot/index.html
[12:25] <speedy67> I took the iso here : https://mattgadient.com/linux-dvd-images-and-how-to-for-32-bit-efi-macs-late-2006-models/
[12:26] <TJ-> manwhowouldbekin: try now!
[12:26] <manwhowouldbekin> TJ-: Sorry about that. I got that message after I ran "sudo apt install pastebinit"
[12:27] <manwhowouldbekin> TJ-: https://paste.ubuntu.com/p/fWTbdHFmR6/
[12:27] <TJ-> manwhowouldbekin: oh!!! that'd do it oops. I always assume it is already installed
[12:27] <TJ-> manwhowouldbekin: let's do it another way
[12:28] <TJ-> manwhowouldbekin: "cat /var/log/apt/history.log | nc termbin.com 9999"
[12:28] <manwhowouldbekin> TJ-: can I "cat" that file?
[12:29] <manwhowouldbekin> TJ-: Here it is: https://termbin.com/1csgf
[12:29] <ledeni[m]> manwhowouldbekin: use sudo
[12:30] <TJ-> manwhowouldbekin: can you confirm this is the point you started on this path? " Start-Date: 2021-07-22  16:12:25 "
[12:30] <TJ-> manwhowouldbekin: "Commandline: apt-get install git fakeroot build-essential ncurses-dev xz-utils libssl-dev bc flex libelf-dev bison"
[12:32] <gebbione> hi, i have asked a few times here but never got an answer. Files (nautilus) gets stuck when I perform a search. I need to kill it and restart it but never manage to run a search from it
[12:33] <manwhowouldbekin> TJ-: I believe so, yes. That was the point at which I installed tools to compile the kernel.
[12:33] <TJ-> gebbione: do you have some network file-systems configured? That can happen when/if they're unavailable
[12:34] <TJ-> manwhowouldbekin: OK ... I've read to the end and (reading between the lines) I suspect you also installed some software without using apt/dpkg/software-centre - am I correct?
[12:34] <TJ-> manwhowouldbekin: as in, the history.log doesn't show anything to break the system in the way it is
[12:34] <gebbione> it is an hardisk
[12:34] <TJ-> manwhowouldbekin: or you tried to remove/install some .deb file manually using dpkg
[12:35] <manwhowouldbekin> TJ-: I broke it when I booted from Live USB. I am not sure whether it would be in this log or not. I did chroot to my system's actual root when in Live USB mode.
[12:35] <TJ-> gebbione: have you checked the kernel log in case there are disk I/O errors? "journalctl -k -n 50" just after you've killed the hung process might reveal something
[12:35] <TJ-> manwhowouldbekin: aha!
[12:36] <TJ-> manwhowouldbekin: OK, that points me to what we need to look at. Are you OK me seeing the root account's bash shell history (it ought to show the commands you used whilst doing the chroot)
[12:36] <manwhowouldbekin> TJ-: That's fine for me.
[12:37] <ioria> gebbione, search for a 'tracker ' thing in the log ( maybe you need to set debug=ALL)
[12:39] <TJ-> manwhowouldbekin: "sudo cat /root/.bash_history | nc termbin.com 9999"
[12:40] <manwhowouldbekin> TJ-: https://termbin.com/yenvw
[12:41] <gebbione> i dont see anything special here ? https://termbin.com/yi0d do you?
[12:42] <ioria> gebbione, G_MESSAGES_DEBUG=all nautilus    ans start a search
[12:42] <TJ-> manwhowouldbekin: basically your problem is you've installed packages from 21.04 not 20.04!
[12:42] <TJ-> manwhowouldbekin: better show us also "cat /etc/apt/sources.list | nc termbin.com 9999"
[12:43] <manwhowouldbekin> TJ-: That sounds about right.
[12:43] <gebbione> ioria, you mean this? -> (nautilus:1258): Tracker-DEBUG: 13:43:23.014: Waiting for service to become available...
[12:43] <TJ-> manwhowouldbekin: and this is the smoking gun: "wget archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6_2.33-0ubuntu5_amd64.deb"
[12:43] <ioria> gebbione, yes
[12:43] <gebbione> do i need to kill this?
[12:43] <manwhowouldbekin> TJ-: https://termbin.com/s73w
[12:44] <ioria> nope
[12:44] <gebbione> is it tracker miner?
[12:44] <ioria> yep
[12:44] <gebbione> i see it running
[12:44] <manwhowouldbekin> TJ-: :D I was doing some stupid things, weren't I?
[12:45] <ioria> gebbione, check 'tracker --help' ; might be 'tracker reset -e' what you need
[12:45] <TJ-> manwhowouldbekin: obviously you were tasked with testing me!
[12:46] <gebbione> ** (nautilus:1258): WARNING **: 13:45:51.172: Could not establish a connection to Tracker: Failed to load SPARQL backend: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying
[12:46] <gebbione> ok that worked ioria
[12:46] <TJ-> manwhowouldbekin: OK, let's fix it. "sudo -i" so you're UID 0, then "mkdir /tmp/fix; cd /tmp/fix" then "wget http://archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc-bin_2.31-0ubuntu9.2_amd64.deb" then "dpkg -i *.deb"
[12:46] <gebbione> thank you
[12:46] <ioria> ok
[12:46] <gebbione> but shouldnt this be a bug for either nautilus or tracker miner?
[12:47] <ioria> probably both
[12:47] <gebbione> the search works without
[12:47] <TJ-> manwhowouldbekin: then, if that replaces the 21.04 libc-bin correctly, try "apt install --fix-broken" again and lets see how far it gets
[12:47] <gebbione> i mean after restarting tracker miner
[12:48] <tomreyn> TJ-: i feel bad now ;-) - i did suggest to manwhowouldbekin that he should just reinstall,, because it would be the fastest approach. i guess there's no problem with returning to that approach.
[12:49] <manwhowouldbekin> TJ-: After running dpkg, I get this: https://paste.ubuntu.com/p/CHHNgdyVD4/
[12:49] <TJ-> tomreyn: this is faster, we're not far off fixing it now
[12:49] <TJ-> manwhowouldbekin: OK, I forgot to wget the other package!
[12:49] <tomreyn> alright, good luck there
[12:49] <manwhowouldbekin> tomreyn: No worries! You gave your opinion. All good :)
[12:50] <TJ-> manwhowouldbekin: "wget http://archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6_2.31-0ubuntu9.2_amd64.deb" and then "dpkg -i *.deb"  again
[12:51] <manwhowouldbekin> TJ-: After I get both packages and try dpkg: https://paste.ubuntu.com/p/tNp2p8yQTV/
[12:51] <BinarySavior> does encrypted installation of ubuntu effect performance?
[12:54] <TJ-> manwhowouldbekin: retry with "dpkg -i --force-all *.deb"
[12:54] <gebbione> sent this out https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1937900
[12:54] <TJ-> BinarySavior: very unlikely unless the system is exceptional slow
[12:55] <tomreyn> BinarySavior: which hardware is this on?
[12:55] <BinarySavior> SSD & MSI mobo
[12:55] <TJ-> BinarySavior: if the system were constantly reading entire storage systems that would be the most demanding, but for normal use you'll not notice it
[12:56] <TJ-> BinarySavior: I've been using full disk encryption (LUKS) since 2007 and never had an issue
[12:56] <tomreyn> BinarySavior: so an intel or amd cpu of the amd64 architecture, most likely. those cpus all provide crypto acceleration which can be used for this prupose so it will hardly be noticeable.
[12:57] <vlm> when using zfs, if turn on compression after the pool have been filled with data, will zfs still compress data or is it only data arriving after compression is activated?
[12:58] <manwhowouldbekin> TJ-: this was the outcome of that. https://paste.ubuntu.com/p/2p5WMyyPMH/
[12:58] <ravage> Only new data will be compressed
[12:59] <TJ-> manwhowouldbekin: now retry the "apt install --fix-broken"
[13:00] <BinarySavior> my processor is Intel Core i5-4690K
[13:00] <manwhowouldbekin> TJ-: Did that. Should I go ahead? https://paste.ubuntu.com/p/VbYvXcKhVH/
[13:00] <TJ-> manwhowouldbekin: yes :D
[13:01] <manwhowouldbekin> TJ-: It has processed without errors.
[13:01] <TJ-> manwhowouldbekin: then you can try to remove, or replace, those other 21.04 packages you installed manually. You're back to a sane system right now
[13:01] <manwhowouldbekin> TJ-: Should I do it in similar manner we just did?
[13:01] <TJ-> tomreyn has a script to identify packages that are orphaned - those that don't have an entry in the package lists. tomreyn can you give a link to it
[13:02] <TJ-> manwhowouldbekin: wait for tomreyn's script - it'll make the job of identifying what doesn't match easier
[13:02] <tomreyn> manwhowouldbekin: the easiest approach is this:  apt list --installed | grep ',local\]$' | nc termbin.com 9999
[13:02] <TJ-> usually it is used to identify packages from PPAs
[13:02] <TJ-> ^^^
[13:03] <manwhowouldbekin> TJ-: https://termbin.com/srli
[13:04] <tomreyn> manwhowouldbekin:  also show your configured apt sources:   sudo grep -hEv '^([ ]*#.*)?$' /etc/apt/sources.list{,.d/*.list} 2>&1 | nc termbin.com 9999
[13:04] <TJ-> manwhowouldbekin: good! of those, only 1 needs downgrading to 20.04 version: "apt install locales-all=2.31-0ubuntu9.2"
[13:05] <manwhowouldbekin> tomreyn: Here they are https://termbin.com/5kbm
[13:05] <TJ-> tomreyn: sources.list looked fine earlier
[13:05] <tomreyn> ah i missed that
[13:05] <TJ-> manwhowouldbekin: of the others, those are the mainline kernel packages + some from 21.04 which you can manually remove
[13:06] <TJ-> manwhowouldbekin: what does "uname -r" report as the currently running kernel?
[13:06] <manwhowouldbekin> TJ-: 5.12.0-051200-generic
[13:07] <TJ-> manwhowouldbekin: oh, there's another package needs downgrade. "apt install libfakeroot=1.24-1"
[13:07] <manwhowouldbekin> TJ-: When you say some from 21.04 do you mean the entries toward the bottom?
[13:07] <tomreyn> this looks ancient:   deb [arch=i386,amd64] http://linux.dropbox.com/ubuntu disco main
[13:08] <tomreyn> https://linux.dropboxstatic.com/ubuntu/dists/disco/main/binary-amd64/
[13:08] <manwhowouldbekin> TJ-: Downgraded libfakeroot successfully.
[13:08] <TJ-> manwhowouldbekin: no, libfakeroot and locales-all had versions from 21.04 so we've downgraded them to the expected 20.04 versions
[13:08] <TJ-> manwhowouldbekin: right now your system is again sane
[13:09] <manwhowouldbekin> TJ-: sounds good! I am gonna try to restart and see what happens. Thanks very much y'all! You are magicians. And this channels is a find!
[13:12] <tomreyn> hmm, apparently microsoft just likes this specific 09-Sep-2001 date somehow, the repo does provide packages from 2020
[13:22] <BinarySavior> tomreyn, when making up the tarball should i ignore ~/snap directory?
[13:22] <BinarySavior> or will copying that over install my snap apps
[13:26] <tomreyn> BinarySavior: yes, you can ignore that
[13:26] <tomreyn> just remember which snaps you had installed
[13:27] <tomreyn> "snap list" should list them
[13:29] <TJ-> trying to decide if manwhowouldbekin is fine, or can't reboot and get back to report!
[13:30] <lue> d
[13:30] <lue> ij
[13:31] <tomreyn> TJ-: i assume he'll reinstall if needed. ;-)
[13:31] <TJ-> hehehehe
[13:39] <XV8> Will having two btrfs balance operations going at the same time on the same volume cause any obvious issues? For example, I accidentally ran the balance unprivileged, but gave me an error, then ran as sudo, but checking ps -eaf | grep btrfs shows both balance jobs running
[13:40] <XV8> Disregard, I see it is running as root for both processes and the 2nd non-sudo string is actually a fork of the sudo process.
[13:40] <manwhowouldbekin> Could someone tell if there are known issues with NVIDIA drivers and kernel 5.12? I was able to restart the system and it does seem quicker and a lot more stable. However, I am still unable to get the NVIDIA driver working. :/
[13:42] <tomreyn> manwhowouldbekin: how did you install linux 5.122, and why?
[13:42] <tomreyn> * 5.12
[13:42] <TJ-> manwhowouldbekin: that's the linux-image-unsigned-5.12.0-051200-generic ?
[13:43] <manwhowouldbekin> tomreyn: I installed it because I had read somewhere that it has some fixes for PCIe passthrough issues that my then current 5.8 didn't have. I am pretty sure I installed it by getting four .deb files and doing "dpkg -i *.deb" on them.
[13:43] <TJ-> manwhowouldbekin: usuaally out-of-tree drivers need to use the DKMS (Dyanmic Kernel Module Service) to build against different kernel versions locally
[13:44] <TJ-> I've stopped using anything Nvidia a long time ago so not sure how Ubuntu provides the nvidia-* kernel module now - I'd assume still DKMS
[13:44] <TJ-> manwhowouldbekin: show us "pastebinit <( lspci -nnk -d ::0300)"
[13:49] <manwhowouldbekin> TJ-: I hear ya. I would like to get a good AMD card, but with current prices I am playing a wait game. Got a stopgap GeForce 710 :-)
[13:50] <manwhowouldbekin> Tj-: I am getting "Failed to contact the server: HTTP Error 405: Method Not Allowed
[13:50] <manwhowouldbekin> "
[13:51] <TJ-> manwhowouldbekin: typical! server failure
[13:51] <TJ-> manwhowouldbekin: show us " lspci -nnk -d ::0300 | nc termbin.com 9999"
[13:51] <manwhowouldbekin> TJ-: https://termbin.com/ha57
[13:52] <TJ-> man OK, so there is no module driving the GPU right now
[13:54] <tomreyn> i'd expect the nvidia drivers to only work with the GA and maybe the HWE kernel (possibly with some delay after it was published)
[13:54] <TJ-> manwhowouldbekin: if you want the correct nvidia driver, use "sudo ubuntu-drivers devices" then follow-up with installing the correct driver with "sudo ubuntu-drivers install"
[13:55] <TJ-> tomreyn: surely the kernel module is DKMS packaged?
[13:55] <manwhowouldbekin> tomreyn: What is a GA kernel? HWE?
[13:56] <tomreyn> GA=general availability / vanilla, the kernel version this release was originally released with
[13:56] <TJ-> GA = Generally Available; HWE = HardWare Enablement (later kernel/Xorg GUI backported to earlier releases)
[13:57] <tomreyn> TJ-: i... don't remember. i think so, but it's a mixture of open source and proprietary, right? the proprietary part might not be able to adapt to new ABIs. but i'm not into nvidia enough to tell.
[13:57] <tomreyn> s/proprietary/closed source/
[13:57] <manwhowouldbekin> Tj-: This is the result of running those commands. It appears that it thinks there already is a driver installed? https://paste.ubuntu.com/p/G5fVjS9wX7/
[13:58] <TJ-> man looks like it reccommends the 470 driver; not sure if you need to pass that to the 'install' option or not
[13:59] <TJ-> the help... isn't very
[14:00] <tomreyn> "9 not upgraded"
[14:00] <TJ-> manwhowouldbekin: maybe "sudo ubuntu-drivers install nvidia:470" or possibly "... install nvidia-driver:470"
[14:01] <manwhowouldbekin> TJ-: When I do that, it shows an almost identical message. A warning and 0 installed, 0 upgraded.
[14:01] <TJ-> tomreyn: right; manwhowouldbekin  as tomreyn  points out you need to do "sudo apt full-upgrade" as well to bring things fully up to date
[14:02] <tomreyn> doesn't    sudo ubuntu-drivers list    list the recommended driver series?
[14:02] <TJ-> manwhowouldbekin: OK, do the full-upgrade then show us "apt list --installed '*nvidia*' | nc termbin.com 9999"
[14:02] <TJ-> tomreyn: devices did too, '470'
[14:02] <TJ-> tomreyn: but the help isn't clear on how you actually specify the 'driver'
[14:02] <tomreyn> ooops i missed it
[14:03] <tomreyn>   install      Install a driver [driver[:version][,driver[:version]]]
[14:03] <TJ-> deprecating autoinstall was a big mistake for that tool, plus not publishing a man-page for it
[14:03] <tomreyn> but that's from my 18.04 system
[14:04] <tomreyn> yes, man pages can be useful
[14:04] <TJ-> [:version] implies the 470/460/etc choice, but is driver "nvidia" or "nvidia-driver" since the package name is "nvidia-driver-470"
[14:05] <manwhowouldbekin> TJ-: full-upgrade successful and here is the other command's output: https://termbin.com/u20e
[14:05] <tomreyn> oh, i understood this as driver = "nvidia-driver-470" and version = "470.57.02-0ubuntu0.20.04.1"
[14:06] <TJ-> tomreyn: obviously confusing then
[14:06] <tomreyn> yes, you're right
[14:06] <TJ-> manwhowouldbekin: good, it has the DKMS package "nvidia-dkms-470" so now show us "dkms status | nc termbin.com 9999"
[14:07] <hendry> hi, I've noticed in Github workflows "apt install" https://github.com/tclssg/tclssg/blob/master/.github/workflows/ci.yml ... shouldn't it be `apt-get install`??
[14:07] <TJ-> hendry: no, 'apt' is the 'human friendly' front-end whereas apt-get is for scripts
[14:07] <manwhowouldbekin> TJ-: https://termbin.com/ck5bm
[14:08] <TJ-> hendry: or in other words, apt output can't be reliably parsed because it may change, but apt-get guarantees its output will be consistent
[14:08] <tomreyn> TJ-: but ubuntu-drivers is *not* just for nvidia drivers, and there are other drivers it would manage, which have no 'series version', e.g. "backport-iwlwifi-dkms", so i assume 'driver' really refers to the apt package name, and 'version' really refers to the apt package version. i am guessing, though.
[14:08] <TJ-> manwhowouldbekin: aha, not installed, just added. "sudo dkms install nvidia/470.57.0"
[14:08] <hendry> TJ-: i see, thanks
[14:09] <TJ-> tomreyn: right, but unless you already know what other packages u-d may install it's impossible to forecast that
[14:09] <tomreyn> that for sure
[14:09] <TJ-> manwhowouldbekin: we hope the DKMS build will not fail. if it does you'll get a message with the path to the build log, which we will need to see
[14:09] <manwhowouldbekin> TJ-: Is DKMS basically a gasket between the kernel and third parties? A dynamic rebuildable gasket?
[14:10] <TJ-> manwhowouldbekin: yes
[14:10] <TJ-> manwhowouldbekin: the DKMS package contains the source-code which is compiled and linked against the kernel(s) on the system
[14:11] <TJ-> manwhowouldbekin: wouldn't be needed if all kernel modules (drivers) were in the mainline kernel
[14:11] <manwhowouldbekin> TJ-: So when a new kernel is installed, it does it autoamtically? Hence, the same source code of NVIDIA should theoretically work on a newer kernel?
[14:11] <manwhowouldbekin> TJ-: When I run that command, I get "Directory: /usr/src/nvidia-470.57.0 does not exist."
[14:12] <TJ-> manwhowouldbekin: yes; DKMS has a hook in /etc/kernel/postinst.d/ that builds against a kernel that was just installed
[14:12] <hendry> i'm looking for common mark, and I get `E: Unable to locate package cmark` in Github's ubuntu-latest. Am I missing something?
[14:13] <TJ-> manwhowouldbekin: aha! "sudo apt install --reinstall nvidia-driver-470 nvidia-dkms-470"
[14:13] <TJ-> manwhowouldbekin: oh no, I typoed the version earlier!! doh
[14:13] <TJ-> manwhowouldbekin: "sudo dkms install nvidia/470.57.02"
[14:14] <manwhowouldbekin> So, try this now? "sudo dkms install nvidia/470.57.02"
[14:14] <TJ-> yes
[14:15] <manwhowouldbekin> TJ-: Looks like headers are missing? https://paste.ubuntu.com/p/YmXMYWywMN/
[14:18] <TJ-> hmmm, earlier we saw installed "linux-headers-5.12.0-051200/now 5.12.0-051200.202104252130 all [installed,local]"
[14:19] <TJ-> oh, you missed the -generic parent package!
[14:21] <TJ-> "mkdir /tmp/fix; cd /tmp/fix; wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.12/amd64/linux-headers-5.12.0-051200-generic_5.12.0-051200.202104252130_amd64.deb ; sudo dpkg -i *.deb"
[14:21] <TJ-> manwhowouldbekin: if that works, retry the dkms command
[14:22] <manwhowouldbekin> TJ-: Just to clarify, are you saying run this right now? "sudo apt install --reinstall nvidia-driver-470 nvidia-dkms-470"
[14:22] <TJ-> no
[14:22] <TJ-> manwhowouldbekin: "sudo dkms install nvidia/470.57.02" /after/ installing the linux-headers .deb
[14:26] <manwhowouldbekin> TJ-: Here is what happens. I actually recall having something similar when I was trying to install 5.13. https://paste.ubuntu.com/p/5bdmKxfVxK/
[14:28] <TJ-> manwhowouldbekin: aha! so, the later mainline kernels are being built on a more recent build host that has a later version of libc
[14:29] <manwhowouldbekin> TJ-: Good to know :-) That's what lead me to break the system in the first place. I was trying to by-pass this error and force the 5.13 into my system.
[14:29] <TJ-> bear with me, just been hit with an NMI!
[14:30] <TJ-> Uhhuh. NMI received for unknown reason 2c on CPU 4. Do you have a strange power saving mode enabled? Da30d and confused, but trying to continue
[14:30] <TJ-> I'm trying to continue but if I disappear or start typing rubbish you'll know why!
[14:31] <manwhowouldbekin> What's NMI?
[14:31] <TJ-> manwhowouldbekin: the solution is to build the kernel from the kernel source locally; isn't too difficult but takes the CUP a n hour or so
[14:31] <ioria> https://askubuntu.com/questions/1334633/mainline-kernel-now-depends-on-libc6-2-33-non-installable-in-focal
[14:31] <TJ-> manwhowouldbekin: Non Maskable Interrupt - a serious hardware error
[14:32] <TJ-> manwhowouldbekin: are you up for building from the mainline source code?
[14:32] <manwhowouldbekin> TJ-: YES!!! I actually wanted to learn that. That is how this mess started originally :-)
[14:32] <TJ-> manwhowouldbekin: it's actually pretty simple - about 7 commands
[14:33] <TJ-> manwhowouldbekin: OK; create a nice environment for it first: "mkdir ~/SourceCode; cd ~/SourceCode; sudo apt install git; git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ; cd linux"
[14:36] <manwhowouldbekin> TJ-: Is there a linux kernel and Ubuntu kernel? I have seen various guides clone from different addresses.
[14:37] <TJ-> manwhowouldbekin: yes; Ubuntu adds some SAUCE patches on top of mainline.
[14:37] <TJ-> manwhowouldbekin: what you're doing now will allow you to test the latest (or any other version) of the mainline kernel
[14:38] <manwhowouldbekin> TJ-: In this case we are doing a barebones linux kernel?
[14:38] <TJ-> manwhowouldbekin: no, it'll be equivalent - it'll use the ubuntu kernel config
[14:38] <TJ-> manwhowouldbekin: I run all our systems with custom builds like this
[14:39] <manwhowouldbekin> TJ-: I see about the config. Makes sense. As to the previous comment, what will allow me to do that? The fact that it is custom built?
[14:40] <TJ-> manwhowouldbekin: because you have a copy of the entire latest mainline kernel code, you can build any version from it
[14:40] <manwhowouldbekin> TJ-: I see. It is on the cutting edge. That is what you mean.
[14:41] <TJ-> manwhowouldbekin: git source-code repositories have a concept of 'tags' which, in linux, are kernel versions, e.g. v5.12
[14:41] <manwhowouldbekin> TJ-: repo has been cloned.
[14:41] <TJ-> manwhowouldbekin: yes, but you can still checkout a specific version tag and build that versions
[14:42] <TJ-> manwhowouldbekin: good; now we'll configure things so this is an out-of-tree build - that means the generated files are not mixed in with the source-code. We put it in a different directory.
[14:42] <TJ-> manwhowouldbekin: "mkdir -p ../builds/amd64"
[14:43] <manwhowouldbekin> TJ-: Interesting. Makes sense. Done.
[14:44] <TJ-> manwhowouldbekin: from what I saw of your apt history.log you should already have all the build-dependencies installed, with the possible exception of openssl-dev
[14:45] <manwhowouldbekin> TJ-: Install that? "sudo apt install openssl-dev"?
[14:46] <BinarySavior> if i crtl+c a tar compression then run the same command will it continue where it left off?
[14:46] <TJ-> manwhowouldbekin: "sudo apt install libssl-dev"
[14:47] <manwhowouldbekin> Tj-: https://paste.ubuntu.com/p/SgN32PHcn8/
[14:47] <TJ-> manwhowouldbekin: oh, forgot to remove it! "sudo dpkg --remove linux-headers-5.12.0-051200-generic"
[14:48] <manwhowouldbekin> TJ-: Ok, removed the headers package successfully.
[14:49] <TJ-> manwhowouldbekin: now you need to 1) copy the current kernel config into the target build directory and 2) update it with any new config options in the latest kernel
[14:50] <TJ-> manwhowouldbekin: so, assuming current directory is still ./linux: "cp /boot/config-$(uname -r) ../builds/amd64/.config"
[14:50] <TJ-> manwhowouldbekin: then we update it by running the first stage of the build: "make O=../builds/amd64 olddefconfig"
[14:51] <manwhowouldbekin> TJ-: Did that. https://paste.ubuntu.com/p/6FB9yHyJsV/
[14:51] <TJ-> manwhowouldbekin: then I want you to install a patch I carry to avoid building VERY LARGE and time consuming debug packages
[14:52] <manwhowouldbekin> TJ-: Sure, lets do that. Btw, do we have a say on whether we want a generic or low-latency version?
[14:52] <TJ-> manwhowouldbekin: so "pushd ../builds; wget https://iam.tj/projects/ubuntu/linux-deb-no-debug.patch ; popd"
[14:53] <TJ-> manwhowouldbekin: it'll be whatever the current kernel is for now. You an alter things later once I've taken you through the entire process, if you want to tinker
[14:54] <TJ-> manwhowouldbekin: is this tool installed? "which patch"
[14:54] <manwhowouldbekin> TJ-: Sounds good. The no-debug patch is in ../builds
[14:54] <manwhowouldbekin> TJ-: Yes, it is. /usr/bin/patch
[14:55] <TJ-> manwhowouldbekin: great. "patch -p1 <../builds/linux-deb-no-debug.patch"
[14:55] <TJ-> man this will apply the patch. you can view the change it has made with "git diff"
[14:56] <TJ-> manwhowouldbekin: you'll see I've added an additional environment variable PKG_DEBUG which, when set, prevents the creation of debug packages when building the debianised packages
[14:56] <TJ-> manwhowouldbekin: so each time you reopen a shell to build you need to do this, as now, "export PKG_DEBUG=1"
[14:57] <manwhowouldbekin> TJ-: Yes, see that. So do we need to set that VAR?
[14:57] <manwhowouldbekin> TJ-: Got it.
[14:57] <TJ-> manwhowouldbekin: now you get to do the build itself. How many cores does your CPU have?
[14:57] <manwhowouldbekin> TJ-: set the var.
[14:57] <TJ-> I usually tell make to use 1 less than the total, so here I have 8, I use 7 to build the kernel
[14:57] <manwhowouldbekin> TJ-: I am on an 8 core Ryzen.
[14:57] <TJ-> same here
[14:58] <TJ-> manwhowouldbekin: so let's go and then sit back and have a nap! "make -j7 O=../builds/amd64 bindeb-pkg |& tee /tmp/kernel-build.log"
[14:59] <TJ-> manwhowouldbekin: I've added logging so if it fails you can share the log with me
[14:59] <manwhowouldbekin> TJ-: Running. ETA? Last time I didn't know how to specify cores. It took about 1.5 hrs on one core :D
[15:00] <TJ-> manwhowouldbekin: possibly about 20 minutes
[15:00] <manwhowouldbekin> TJ-: Sounds good. Man, this is awesome.
[15:01] <TJ-> as it is doing an ubuntu config build, that selects hundreds of modules that aren't ever going to be sued by your specific system, but it is easier doing this than trying to figure out what to disable!
[15:01] <TJ-> manwhowouldbekin: this will generate 3 .deb files in ../builds/ which you'll be able to install with dpkg -i
[15:02] <manwhowouldbekin> TJ-: got it. Why is there a fourth file sometime?
[15:02] <manwhowouldbekin> TJ-: Build complete :D So fast!
[15:02] <TJ-> manwhowouldbekin: my general workflow is: "ls -latr ../builds/*.deb" (to check there is a linux-image*, linux-modules*, and linux-libc*) then I'll do something like "sudo dpkg -i ../builds/*.deb"
[15:03] <TJ-> manwhowouldbekin: without my PKG_DEBUG it builds another package full of modules with debug symbols in
[15:03] <TJ-> manwhowouldbekin: that file is often over 1GiB
[15:03] <TJ-> manwhowouldbekin: that was too quick!
[15:03] <manwhowouldbekin> We did have an error :/ https://paste.ubuntu.com/p/XSmd5R8KY2/
[15:03] <TJ-> manwhowouldbekin: aha
[15:04] <manwhowouldbekin> TJ-: Should I show you the log?
[15:06] <TJ-> manwhowouldbekin: no, I'll tell you the file I need to see.
[15:06] <TJ-> manwhowouldbekin: "cat ../builds/amd64/debian/rules | nc termbin.com 9999"
[15:07] <TJ-> manwhowouldbekin: we may be missing some tool!
[15:07] <manwhowouldbekin> TJ-: https://termbin.com/iomh
[15:10] <TJ-> manwhowouldbekin: we may be missing some build-depends; try this "sudo apt install kernel-package"
[15:13] <TJ-> manwhowouldbekin: then restart the build (this will re-use the already built parts):  "make -j7 O=../builds/amd64 bindeb-pkg |& tee /tmp/kernel-build.log"
[15:13] <manwhowouldbekin> What should we do here? https://paste.ubuntu.com/p/crRxpY7fhp/
[15:14] <manwhowouldbekin> TJ-: I get the above when installing "kernel-package"
[15:14] <TJ-> manwhowouldbekin: show the differences, but I think it is safe to  'install the package version'
[15:14] <TJ-> manwhowouldbekin: probably the difference is due to those other kernel installs you did
[15:15] <TJ-> manwhowouldbekin: I suspect the 'diff' is minor
[15:16] <manwhowouldbekin> TJ-: Looks like one is empty? https://paste.ubuntu.com/p/bpZ2FyzzKj/
[15:16] <ice9> shouldn't apt autoremove, remove old kernels and leave the most recent 2?
[15:17] <TJ-> manwhowouldbekin: install! no problems
[15:18] <manwhowouldbekin> TJ-: Installed kernel-package. Restart the build?
[15:18] <TJ-> ice9: it depends on what's protected in /etc/apt/apt.conf.d/01autoremove-kernels
[15:18] <TJ-> manwhowouldbekin: yes
[15:19] <ice9> TJ-, this is what's in the file "APT::LastInstalledKernel "5.11.0-25-generic";" however old kernels still exists
[15:20] <manwhowouldbekin> TJ-: Still hitting an error https://paste.ubuntu.com/p/c6cr74mvzY/
[15:20] <TJ-> manwhowouldbekin: better, issue is "No rule to make target 'debian/canonical-certs.pem', needed by 'certs/x509_certificate_list"
[15:21] <manwhowouldbekin> TJ-: I believe I had also seen this my first time through ...
[15:23] <TJ-> manwhowouldbekin: " scripts/config --file ../builds/amd64/.config --disable SYSTEM_TRUSTED_KEYS "
[15:24] <TJ-> manwhowouldbekin: then restart the build :)
[15:24] <TJ-> manwhowouldbekin: that was because we copied the Ubuntu config
[15:25] <manwhowouldbekin> TJ-: Additional X.509 keys for default system keyring (SYSTEM_TRUSTED_KEYS) [] (NEW)
[15:25] <manwhowouldbekin> TJ-: Accept the default?
[15:25] <TJ-> yes
[15:26] <manwhowouldbekin> TJ-: Alright. The build is proceeding.
[15:27] <TJ-> manwhowouldbekin: did I say 20 minutes!?
[15:29] <manwhowouldbekin> TJ-: Yes, you did!
[15:32] <RaimondRaj> RaimondRaj is not in the sudoers file.  This incident will be reported.
[15:32] <RaimondRaj> please help
[15:33] <ice9> "APT::LastInstalledKernel "5.11.0-25-generic" is the only entry in  /etc/apt/apt.conf.d/01autoremove-kernels but apt autoremove doesn't remove older kernels, any idea?
[15:34] <TJ-> ice9: is there no "APT::NeverAutoRemove ..." section?
[15:34] <ice9> TJ-, no
[15:34] <TJ-> RaimondRaj: that means your user isn't privileged. you can check with "groups"
[15:36] <TJ-> ice9: how about the glob wildcards in /etc/apt/apt.conf.d/01autoremove
[15:36] <RaimondRaj> TJ : i dont find any
[15:36] <RaimondRaj> TJ : any other way
[15:37] <ice9> TJ-, there is no wildcards at all, only the line I mentioned
[15:38] <RaimondRaj> %sudo   ALL=(ALL:ALL) ALL
[15:39] <RaimondRaj> whatsapp is not in the sudoers file.  This incident will be reported.
[15:40] <TJ-> ice9: I've referred to 2 separate files; I think you may not be looking in the file I mentioned
[15:41] <TJ-> RaimondRaj: if you user isn't in the sudo group then it cannot use sudo. another user that is would need to add your other users to the sudo group
[15:41] <RaimondRaj> tj : can u guide me to do so
[15:42] <ice9> !paste
[15:42] <manwhowouldbekin> TJ-: It looks like it has hit another error: https://paste.ubuntu.com/p/B7XJqzxrzQ/
[15:43] <TJ-> RaimondRaj: see https://ubuntu.com/server/docs/security-users
[15:43] <ice9> TJ-, sorry about that, this is the file content: https://paste.ubuntu.com/p/z9bX3McgZT/
[15:44] <TJ-> manwhowouldbekin: another to install! "sudo apt install dwarves" and restart build after
[15:45] <manwhowouldbekin> TJ-: https://paste.ubuntu.com/p/GrJgddhsCt/
[15:46] <TJ-> ice9: that makes sense then. The file you've just pasted prevents almost any kernel package from being removed, and because the 01autoremove-kernels is empty APT::NeverAutoRemove isn't replaced. Try running "sudo /etc/kernel/postinst.d/apt-auto-removal" to regenerate 01autoremove-kernels
[15:47] <TJ-> manwhowouldbekin: grrrr! so we have to disable it
[15:47] <TJ-> manwhowouldbekin: " scripts/config --file ../builds/amd64/.config --disable CONFIG_DEBUG_INFO_BTF " and the restart the build
[15:48] <TJ-> manwhowouldbekin: my local config that has been with my for over a year obviously doesn't have these new-fangled options enabled so I don't hit those failures
[15:48] <ice9> TJ-, i executed that cmd and now the entry is APT::LastInstalledKernel ""; but apt autoremove still doesn't list the older kernels for removal
[15:48] <manwhowouldbekin> TJ-: we are given a choice here: https://paste.ubuntu.com/p/b3FyJNtj55/
[15:49] <TJ-> ice9: did that command add any entries to the 01autoremove-kernels APT::NeverAutoRemove ?
[15:49] <TJ-> manwhowouldbekin: option 1
[15:49] <ice9> TJ-, not at all, it just replaced the old entry with APT::LastInstalledKernel "";
[15:50] <TJ-> ice9: something screwy going on there! what does this show? "pastebinit <( apt list --installed 'linux-image*' )"
[15:51] <ice9> TJ-, https://paste.ubuntu.com/p/h7mDv9CCvF/
[15:52] <TJ-> ice9: hmm! I get the feeling the logic in the scripts controlling this has changed a lot between 20.04 (which I'm looking at) and your 21.04 install
[15:55] <TJ-> ice9: according to the changelog for apt 2.2.0 there were changes made; you may have found a bug. "kernels: Avoid std::regex for escaping '.' and '+'"
[15:55] <TJ-> ice9: see the "Ubuntu changelog" link on the right of https://packages.ubuntu.com/hirsute/apt
[16:02] <TJ-> ice9: source seems to confirm it has changed how it works https://salsa.debian.org/apt-team/apt/-/blob/main/debian/apt.auto-removal.sh
[16:04] <TJ-> ice9: see https://salsa.debian.org/apt-team/apt/-/commit/04085f46dea9a95dd86123ac00187a63cc4ba2c0
[16:07] <TJ-> manwhowouldbekin: how's the build progressing?
[16:07] <manwhowouldbekin> TJ-: So far so good. Still going.
[16:14] <manwhowouldbekin> TJ-: I has finished. No errors, from what I can tell. :-)
[16:14] <TJ-> manwhowouldbekin: whooohooo!
[16:15] <TJ-> manwhowouldbekin: "ls -latr ../builds/*.deb | nc termbin.com 9999"
[16:15] <manwhowouldbekin> TJ-: Am I correct to understand that we have build 5.14.rc2?
[16:16] <manwhowouldbekin> TJ-: https://termbin.com/ua7n3
[16:17] <TJ-> manwhowouldbekin: nice! "sudo dpkg -i ../builds/linux*5.14.0-rc2+-2*.deb"
[16:18] <TJ-> manwhowouldbekin: do it with a version in since if you do many builds and don't remove the older .deb files, you'll ned up re-installing older .debs
[16:20] <manwhowouldbekin> TJ-: It looks like there was a DKMS issue with NVIDIA https://paste.ubuntu.com/p/Nfg7ncKPfd/
[16:20] <TJ-> manwhowouldbekin: once installed we need to do some 'stuff' with dkms to get that nvidia module build too
[16:20] <TJ-> manwhowouldbekin: aha, it auto-tried, good!
[16:21] <TJ-> manwhowouldbekin: cat /var/lib/dkms/nvidia/470.57.02/build/make.log | nc terbmin.com 9999"
[16:21] <TJ-> manwhowouldbekin: this happens with most new kernel versions because nvidia are always behind the curve with their packages
[16:23] <manwhowouldbekin> TJ-: nc: getaddrinfo for host "terbmin.com" port 9999: Name or service not known
[16:23] <TJ-> oh correct my typo!
[16:23] <TJ-> termbin not terbmin !
[16:23]  * TJ- is getting tired :)
[16:24] <manwhowouldbekin> TJ-: https://termbin.com/qifw
[16:25] <TJ-> manwhowouldbekin: oh, not that problem again! let's try to dig out the fix. I've forgotten what it is
[16:25] <manwhowouldbekin> TJ-: You have seen this before? :-)
[16:33] <TJ-> manwhowouldbekin: I was wrong, the real problem is much deeper. Basically, the internal kernel interface/structure has changed and because nvidia is out-of-tree it hasn't been kept in sync.
[16:34] <TJ-> manwhowouldbekin: current->state has become current->__state
[16:35] <manwhowouldbekin> TJ-: Do we hack it manually? Or build a more compliant kernel version?
[16:35] <TJ-> manwhowouldbekin: it /looks/ like we can do a simple string replace
[16:36] <TJ-> manwhowouldbekin: "pushd /usr/src/nvidia-470.57.02; git init; git add .; git commit -m 'original source' "
[16:36] <manwhowouldbekin> TJ-: That would be on NVIDIA side, right? Kernel stays as-is?
[16:36] <mago> Hello
[16:36] <TJ-> manwhowouldbekin: this takes us into the nvidia source code, creates a local git repository, adds all files and commits them so we can easily undo any changes
[16:37] <mago> How do i install unreal engine in ubuntu 20.04?
[16:38] <manwhowouldbekin> TJ-: Done.
[16:38] <TJ-> manwhowouldbekin: now we break things :D
[16:38] <manwhowouldbekin> TJ-: :D
[16:39] <TJ-> manwhowouldbekin: "grep -rn 'current->state' | nc termbin.com 9999"
[16:40] <manwhowouldbekin> TJ-: https://termbin.com/y606
[16:40] <tomreyn> mago: that's kind of OT here. but instructions are at https://forums.unrealengine.com/t/how-to-install-ue4-on-ubuntu/92827 - i think you will need to build it from source.
[16:40] <TJ-> man only 2 to change, that's good.
[16:41] <mago> tomreyn im trying to convert a ply point cloud to fbx file, any ideas?
[16:41] <TJ-> manwhowouldbekin: reproduced here - just checking the fix
[16:41] <tomreyn> mago: there used to be an unreal engine related channel on freenode, maybe it mopved to libera. ask alis about it
[16:41] <tomreyn> mago: no idea there, no. i don'T even know what this is
[16:42] <mago> Hello alis , do you know about unreal engine channel?
[16:42] <tomreyn> !alis | mago
[16:42] <manwhowouldbekin> TJ-: Wait, have you been following all along? :O Or did you just install the NVIDIA driver?
[16:44] <tomreyn> BinarySavior: no, you'll need to re-create it.
[16:44] <TJ-> manwhowouldbekin: just installed the source. here's the fix
[16:44] <TJ-> manwhowouldbekin: "sudo sed -i 's/\(current->\)\(state\)/\1__\2/' common/inc/nv-time.h"
[16:45] <TJ-> manwhowouldbekin: "sudo sed -i 's/\(current->\)\(state\)/\1__\2/' nvidia-uvm/uvm_linux.h"
[16:45] <TJ-> manwhowouldbekin: "sudo dkms install nvidia/470.57.02"
[16:45] <TJ-> manwhowouldbekin: for me that builds and installs the modules
[16:46] <tomreyn> RaimondRaj: you will need to have someone who has root access to this computer grant this user you're working with root access as well.
[16:47] <manwhowouldbekin> TJ-: Prior to that dkms command, should try to install the kernel packages again?
[16:47] <TJ-> manwhowouldbekin: no
[16:47] <TJ-> manwhowouldbekin: you can fix that after, if nividia dkms builds/installs. You'd then do "sudo apt install --fix-broken"
[16:48] <TJ-> manwhowouldbekin: and before rebooting commit these changes you know will work: "git add .; git commit -m 'fixes for v5.13+' "
[16:48] <manwhowouldbekin> TJ-: This is why I asked https://paste.ubuntu.com/p/7hXg9G75Sg/
[16:49] <TJ-> manwhowouldbekin: my mistake! we have to tell dkms which kernel versions we're building for now
[16:49] <TJ-> manwhowouldbekin: "sudo dkms install nvidia/470.57.02 -k 5.14.0-rc2+"
[16:52] <TJ-> manwhowouldbekin: you don't need to do the "apt install --fix-broken" now, but still do the git add/commit
[16:53] <manwhowouldbekin> TJ-: It is erroring https://paste.ubuntu.com/p/cbCTn943J7/
[16:53] <TJ-> manwhowouldbekin: best check the log! "cat /var/lib/dkms/nvidia/470.57.02/build/make.log | nc termbin.com 9999"
[16:54] <TJ-> manwhowouldbekin: it built for me here with v5.13 so maybe something else is changed in 5.14
[16:54] <manwhowouldbekin> TJ-: https://termbin.com/hv1x
[16:55] <TJ-> manwhowouldbekin: oh, an error in the middle "/var/lib/dkms/nvidia/470.57.02/build/nvidia-drm/nvidia-drm-drv.c:925:14: error: ‘struct drm_device’ has no member named ‘pdev’; did you mean ‘dev’?"
[16:58] <tomreyn> hendry: the cmark package is available from the universe repository. maybe this is not activated by default on the system you are referring to.
[16:58] <tomreyn> !universe | hendry
[16:59] <TJ-> manwhowouldbekin: bear with me; needing to do some deep reading
[17:00] <manwhowouldbekin> TJ-: This is amazing to me. I really appreciate all the teaching you are doing. I have learned more in 2 hours about Linux than I did in several years of using it. :)
[17:04] <TJ-> manwhowouldbekin: this is the commit that removed it; the message gives a clue on how to work around it. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/drm/drm_device.h?id=b347e04452ff6382ace8fba9c81f5bcb63be17a6
[17:07] <manwhowouldbekin> TJ-: do we just change it to dev->dev ?
[17:08] <TJ-> manwhowouldbekin: assuming you're still in the /usr/src/nvidia-.... directory do this and you'll see all the places 'pdev' is mentioned. Examining them shows that most are referring to a different struct pci_dev which is fine. I only see one mention of a ->pdev member of a drm_dev, and that is only nvidia /setting/ it. I don't see any use of it, so we can simply remove that setter (I think!). "grep
[17:08] <TJ-> -rn pdev ."
[17:09] <TJ-> manwhowouldbekin: I think this is the only one we have to deal with: "./nvidia-drm/nvidia-drm-drv.c:925:        dev->pdev = to_pci_dev(device);"
[17:09] <manwhowouldbekin> TJ-: So just strike it out?
[17:13] <TJ-> manwhowouldbekin: "sed -i '924,927 d' nvidia-drm/nvidia-drm-drv.c" will delete those 4 lines
[17:13] <TJ-> manwhowouldbekin: then repeat "sudo dkms install nvidia/470.57.02 -k 5.14.0-rc2+"
[17:16] <manwhowouldbekin> TJ-: DKMS: install completed. !
[17:16] <TJ-> manwhowouldbekin: wooo!
[17:16] <manwhowouldbekin> TJ-: So, git commit now?
[17:16] <TJ-> manwhowouldbekin: and before rebooting commit these changes you know will work: "git add .; git commit -m 'fixes for v5.13+' "
[17:16] <TJ-> manwhowouldbekin: oh, change that commit mesg a bit though
[17:17] <TJ-> manwhowouldbekin:  "git add .; git commit -m 'fixes for v5.14+' "
[17:18] <TJ-> manwhowouldbekin: when you reboot it should start with this new kernel since its version is higher than any other, but to be sure you may want to tap Esc key to get to the GRUB menu and make sure!
[17:18] <TJ-> manwhowouldbekin: it'll be in the Advanced sub-menu
[17:18] <TJ-> manwhowouldbekin: it should also be the default entry of course
[17:19] <manwhowouldbekin> TJ-: Alright! Committed! See you on the other side :D
[17:20] <TJ-> manwhowouldbekin: good luck
[17:23] <manwhowouldbekin> TJ-: uname -r
[17:23] <manwhowouldbekin> 5.14.0-rc2+
[17:23] <manwhowouldbekin>  ! :) Graphics works, too!
[17:24] <TJ-> manwhowouldbekin: not bad for 3 hours work!
[17:26] <manwhowouldbekin> TJ-: I am probably the only one with this setup at the moment haha
[17:26] <TJ-> manwhowouldbekin: you're unique :)
[17:26] <manwhowouldbekin> TJ-: Thank you for all your help!
[17:27] <manwhowouldbekin> Does anyone know if Hexchat saves history? I would consider writing this up as a guide on my blog, if I could get the history.
[17:27] <TJ-> !logs
[17:28] <manwhowouldbekin> TJ-: Thank you!
[17:29] <manwhowouldbekin> TJ-: If you don't mind my asking, do you work at Ubuntu? Your skills are incredible. Once again, much appreciated.
[17:29] <TJ-> manwhowouldbekin: no, I just hack on stuff
[17:30] <manwhowouldbekin> TJ-: Good man. Bye for now :-)
[17:31] <TJ-> manwhowouldbekin: have fun :)
[17:32] <TJ-> manwhowouldbekin: before you go... do you want to know how to keep up to date?
[17:50] <TJ-> manwhowouldbekin: hoping you see this. To keep the linux repo up to date, in its base directory ./linux you'd do "git pull" which will fetch the latest upstream changes and merge them into your current working directory
[17:51] <TJ-> manwhowouldbekin: also, if you want to tinker with kernel options, "make O=../builds/amd64 menuconfig" - there is a lot of help in there. For almost every option if you choose the 'help' it'll explain the option
[18:53] <manwhowouldbekin> TJ-: "before you go... do you want to know how to keep up to date?" Just saw your message. Thanks! :-)
[18:54] <manwhowouldbekin> TJ-: Every time I pull changes, I would need to rebuild the kernel and install it, right?
[18:56] <TJ-> manwhowouldbekin: yes... and first run "make O=../builds/amd64 olddefconfig" in case new config options have been added
[18:56] <TJ-> 'olddefconfig' means take the current (old) .config and add to it all new configs with their 'def'ault setting
[18:59] <manwhowouldbekin> TJ-: Got it. In general, what's the benefit of keeping up with the changes? Is it in getting the most recent changes and bug fixes?
[18:59] <TJ-> manwhowouldbekin: that, possible performance improvements, new features
[18:59] <TJ-> manwhowouldbekin: new device support of course
[19:02] <manwhowouldbekin> TJ-: What's the typical lag between what's currently cutting edge in the repo and what is released officially by Ubuntu?
[19:03] <TJ-> manwhowouldbekin: well, security fixes get backported almost immediately, but each ubuntu release settles on a specific versions and sticks with it. We introduced the HardWare Enablement kernels to provide more recent kernels to older releases since LTSes are supported for 5 years+
[19:04] <TJ-> HWEs come from a newer ubuntu release and are installable on the older releases
[19:04] <TJ-> manwhowouldbekin: typical mainline cadence is 3-4 months for each development cycle, usually with up to 7 release candidates
[19:43] <morgans> Yesterday a child came out to wonder
[19:43] <morgans> Caught a dragonfly inside a jar
[19:43] <morgans> Fearful when the sky was full of thunder
[19:43] <morgans> And tearful at the falling of a star
[19:43] <morgans> oh sorry. I have to switch what gets loaded first on hexchat.
[19:46] <alram> So.... Now I have two bricked Ubuntu RPi4B's, since the latest FW update screwed things up on both of them.
[19:46] <alram> Just a heads up people
[19:47] <alram> I tried warning about the apt update for the firmware bricking things up more than a week ago
[19:47] <alram> to no avail.
[19:48] <alram> I'm a bit disheartened by this
[19:49] <alram> Is there any kind of guide on how to redo the uboot stuff and so forth for the RPi4B?
[20:28] <Kon> Friend of mine just installed 21.04 and he can't boot into graphical session. I got him on tty and he's getting some USB errors on device 9-1, code -71
[20:28] <Kon> Here's his boot log https://dpaste.com/DY8YQR4ZR
[20:28] <Kon> Here is the output of lsusb https://cdn.discordapp.com/attachments/866874481640079360/868588886849355836/20210724_162201.jpg
[20:29] <Kon> I'm having him unplug things and restart. In the mean time, any ideas?
[20:32] <TJ-> Kon: "kernel: nvidia-gpu 0000:0a:00.3: i2c timeout error e0000000"
[20:32] <toddc> Kon: usb should not stop a gui  check video card as a possibility (nvidia) yes install with nomodet option then addl drivers
[20:33] <TJ-> Kon: also, "kernel: ucsi_ccg 0-0008: i2c_transfer failed -110" -- that is the Cypress USB-C controller - the common issue seems to be failure to bring up the i²c bus
[20:33] <Kon> Ah, nice catch guys
[20:34] <TJ-> Kon: unrelated but of concern, earlier: "grub-editenv[979]: /usr/bin/grub-editenv: error: invalid environment block"
[20:35] <TJ-> Kon: and also several, for different devices, "alsactl[964]: alsa-lib parser.c:260:(error_node) UCM is not supported for this HDA model (HDA NVidia at 0xfc080000 irq 126)"
[20:36] <Kon> So that last one is Nvidia HDMI audio
[20:37] <Kon> You identified his USB-C controller as being an odd duck
[20:37] <Kon> I'm not sure what that grub-editenv error is
[20:37] <Kon> But we'll start with Nvidia drivers and restart from there
[20:39] <TJ-> start with the failure of i²c - that is the problem
[20:39] <TJ-> it is used to communicate with functions on the GPU, and the USB controller
[20:40] <TJ-> Kon: there are only 3 mentions of i²c in that entire log - we'd expect to see an  i²c controller discovered first
[20:44] <Kon> Thanks TJ-
[20:45] <TJ-> Kon: according to this PCI device 00:14.0 is an i²c controller https://linux-hardware.org/?probe=7e1033e8f3&log=lspci
[20:47] <TJ-> Kon: this patch may be related https://marc.info/?l=linux-i2c&m=162638752918480&w=2
[20:48] <Kon> Interesting, so there's ongoing issues with this part
[20:48] <TJ-> looks like the IO ports are behind the MMIO so need to be enabled
[20:49] <Kon> And that requires a kernel patch to do?
[20:49] <Kon> If this has landed I can probably get him to install mainline
[20:49] <TJ-> Kon: looks like it - that patch isn't in Linus' mainline repo as yet
[20:50] <TJ-> I talked someone through building latest mainline earlier - it's not too difficult to build
[20:54] <TJ-> Kon: not in the i²c tree yet either: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/
[20:55] <Kon> Meh. So it was "signed off" by reviewer but not merged yet
[20:55] <TJ-> by author
[20:56] <TJ-> Shouldn't take much to add that patch
[21:04] <TJ-> download the raw email as a file, then use git-am path/to/file.patch to apply it on the tree
[21:12] <neurochrome> How can I recreate the required file(s), such as "modules.order" located in /lib/modules/4.15.0-151-generic/ ?
[21:12] <neurochrome> There is no initrd folder or kernel folder in that location, like there are for other kernel versions.
[21:13] <neurochrome> This means I cannot boot into this kernel version.
[21:13] <neurochrome> I've tried re-installing the image and headers packages for this kernel, but that doesn't resolve the issue or recreate these missing files.
[21:14] <neurochrome> So, at the moment if I try `sudo update-initramfs -k 4.15.0-151-generic -u`, I get the error `depmod: WARNING: could not open /var/tmp/mkinitramfs_x4xcgC/lib/modules/4.15.0-151-generic/modules.order: No such file or directory`
[21:15] <TJ-> neurochrome:  use 'apt-file search path/to/file' to find out if some package ships that file. I think you're missing a package
[21:15] <neurochrome> I've tried the HWE kernel, which boots fine, but then my keyboard (keychron) doesn't work! <facepalm>
[21:17] <TJ-> neurochrome: is that on 18.04?
[21:17] <neurochrome> yeah
[21:17] <TJ-> ahhh, explains why I can't find it in 20.04 !
[21:18] <neurochrome> Never had any issues with kernels up until recently, when the latest kernel didn't load my nvidia drivers and basically locked up.
[21:18] <neurochrome> Having a nightmare ever since.
[21:18] <Saxle> You could try the hwe edge kernel too neurochrome
[21:18] <Saxle> It's on 5.11
[21:19] <neurochrome> Yep, tried that
[21:19] <neurochrome> Oh, hold up
[21:19] <neurochrome> The edge version just seemed to be the same as the HWE version.
[21:19] <neurochrome> I only have one 5* kernel installed
[21:19] <Saxle> should be 18.04-hwe-edge or 20.04-hwe-edge
[21:20] <neurochrome> linux-image-generic-hwe-18.04-edge => 5.4.0.80.90~18.04.72
[21:20] <neurochrome> linux-image-generic-hwe-18.04 => 5.4.0.80.90~18.04.7
[21:20] <neurochrome> both the same
[21:21] <neurochrome> That doesn't load my keyboard, and I have to use onscreen keyboard to type
[21:21] <TJ-> neurochrome: you need the linux-modules- packages to match those
[21:21] <neurochrome> linux-modules-4.15.0-151-generic is already the newest version (4.15.0-151.157).
[21:21] <neurochrome> :(
[21:21] <Saxle> check you got all the right modules packages too
[21:22] <TJ-> neurochrome: those should contain the file. Do "dpkg -S modules.order"
[21:22] <Saxle> linux-modules-5.x
[21:22] <neurochrome> BOOM... sudo apt install --reinstall linux-modules-4.15.0-151-generic
[21:23] <TJ-> neurochrome: I thought you'd done that?
[21:23] <neurochrome> After that `sudo update-initramfs -k 4.15.0-151-generic -u` produces no error
[21:23] <TJ-> ahhh, only reinstalled the image and header packages
[21:23] <Saxle> Also, do you have linux-firmware package installed? neurochrome?
[21:23] <neurochrome> Nha, I've done that on the image and header packages
[21:23] <neurochrome> Saxle, yeah
[21:23] <TJ-> neurochrome: so you should be good to go now
[21:24] <neurochrome> sudo dpkg-reconfigure linux-firmware was complaining about the same  missing files earlier
[21:24] <Saxle> hmmm
[21:24] <neurochrome> Just running it again
[21:24] <neurochrome> Hopefully it won't error this time
[21:25] <neurochrome> No error \o/
[21:27] <neurochrome> Still not sure why the HWE kernel doesn't load my Keychron C2 keyboard
[21:27] <neurochrome> Gonna reboot and test the 4.15.0-15 kernel... wish me luck!
[21:27] <Saxle> Probably the module isn't in it, but I assume it should be there since it worked before
[21:27] <Saxle> Gl
[21:33] <neurochrome> well, neither of the newer kernels work for me.
[21:33] <TJ-> neurochrome: in what way?
[21:33] <neurochrome> one doesn't load my keyboard, the other doesn't even get to the login screen before locking up
[21:34] <TJ-> neurochrome: what driver does the keyboard use?
[21:34] <neurochrome> 4.15.0-147-generic is currently working for me though
[21:34] <neurochrome> good question, what's the command to find that out?
[21:35] <neurochrome> hid
[21:35] <TJ-> neurochrome: or "ls -l /sys/class/input/event*/device/device/driver"
[21:35] <neurochrome> usbhid,hid_apple,hid_generic
[21:35] <TJ-> so the keyboard is a generic USB HID class ?
[21:36] <neurochrome> yeah
[21:37] <neurochrome> I can switch between apple and windows mode, it's currently on windows mode though.
[21:37] <TJ-> neurochrome: does it work outside the GUI? for the GRUB menu for example?
[21:37] <neurochrome> yep
[21:37] <TJ-> neurochrome: so this may only be a GUI issue then, not kernel
[21:38] <neurochrome> Well, it works right now on 4.15.0-147-generic
[21:38] <TJ-> is it using Xorg (X11) or a wayland compositor?
[21:38] <neurochrome> Xorg
[21:38] <TJ-> and so likely also libinput ... check the Xorg log for the working session, compare with an earlier log for a session where the keyboard doesn't work.
[21:39] <neurochrome> I'm tempted to just install a newer distro.  I've been holding back because "Everything just works", but that is no longer the case!
[21:39] <neurochrome> Yeah, I'll do that.
[21:39] <neurochrome> I've seen way too many logs these last 48 hours.
[21:39] <Saxle> Try using a live usb of a newer ubuntu, does your keyboard work there?
[21:39] <TJ-> neurochrome: the problem is with the newer kernels? did you also install the HWE Xorg updates?
[21:40] <neurochrome> HWE Xorg updates? nope
[21:40] <neurochrome> Saxle, yeah, that's my intention.  I wouldn't want to install without testing first.
[21:40] <TJ-> HWE has kernels and xorg-server* etc updates usually
[21:41] <neurochrome> xorg-server-source-hwe-18.04 was not installed
[21:42] <neurochrome> Would I need that?
[21:42] <TJ-> source? I don't think so
[21:42] <TJ-> long time since I installed any HWE bits though
[21:43] <neurochrome> sudo apt-cache search xorg-server only brough up 3 packages and they were all -source
[21:43] <TJ-> neurochrome: try "apt-cache search -n hwe | grep -v linux"
[21:44] <neurochrome> Just looking at sudo apt-cache search xorg | grep -i 18.04
[21:44] <Saxle> neurochrome: do you have libinput installed? xserver-xorg-input-libinput
[21:44] <TJ-> something like "xserver-xorg-hwe-18.04" or "xserver-xorg-hwe-20.04" ?
[21:44] <Saxle> neurochrome: You could try xserver-xorg-input-evdev
[21:44] <TJ-> neurochrome: tip - sudo not required for apt-cache
[21:46] <neurochrome> OK, I've installed xserver-xorg-core-hwe-18.04 and xserver-xorg-input-all-hwe-18.04
[21:46] <neurochrome> Gonna reboot and see what happens on the latest 5 series kernel
[21:46] <neurochrome> brb
[21:47] <Saxle> I use evdev, but libinput is also good
[21:48] <neurochrome> PARTYTIME
[21:48] <neurochrome> I owe you folks a beer.  Many thanks :)
[21:48] <Saxle> nice congrats
[21:48] <neurochrome> TJ-, Saxle
[21:48] <neurochrome> ty
[21:50] <neurochrome> I've decided to skip the other problem kernel (4.15.0-151).  I'm not sure what's up with that, but I'm now rocking 5.4.0-80, so I'm not gonna worry too much about it.
[21:50] <neurochrome> Speaking of beer... I think I need on myself!
[21:50] <Saxle> There is a command to check the x server input : xinput --list and then you can do xinput list-props 'DEVICE NAME' to see what driver it is using, libinput or devdev
[21:50] <Saxle> *evdev
[21:51] <Saxle> xinput --list-props 'DEVICE NAME'
[21:51] <daekdroom> Hello, a shim-signed update resulted in a update-grub error, so I ran boot-repair, which reproduced the very same error I've seen during the upgrade, any thoughts? https://paste.ubuntu.com/p/2ZRcPrnSVd/
[21:55] <neurochrome> Saxle, weirdly that states that my Keychron is both a pointer and keyboard.
[21:56] <neurochrome> libinput is in use though
[21:56] <Saxle> interesting
[21:57] <neurochrome> Here's the model, in case you were wondering https://www.keychron.com/products/keychron-c2-wired-mechanical-keyboard
[21:58] <neurochrome> Anyhow, I'm gonna go relax for a bit. Thanks again peeps, and stay awesome! :)
[21:58] <webchat49> hi all
[21:59] <webchat49> pls I have  problem with ubuntu/mysql
[21:59] <webchat49> anyone help!!!!
[21:59] <webchat49> The job identifier is 39603 and the job result is done.
[21:59] <webchat49> Jul 24 17:53:48 webdb systemd[1]: Starting MySQL Community Server...
[21:59] <webchat49> -- Subject: A start job for unit mysql.service has begun execution
[21:59] <webchat49> -- Defined-By: systemd
[21:59] <Bashing-om> !ask | webchat49
[22:00] <Bashing-om> !paste | webchat49
[22:06] <webchat49> The job identifier is 39603 and the job result is done.
[22:06] <webchat49> Jul 24 17:53:48 webdb systemd[1]: Starting MySQL Community Server...
[22:06] <webchat49> -- Subject: A start job for unit mysql.service has begun execution
[22:06] <webchat49> -- Defined-By: systemd
[22:09] <TJ-> Kon: if you want v5.14-rc2 with that i²c patch pre-built: https://iam.tj/projects/ubuntu/kernel-v5.14-rc2/
[22:09] <webchat49> usrte@utyrded2332:/var/lib/mysql# /etc/init.d/mysql start
[22:09] <webchat49> Starting mysql (via systemctl): mysql.serviceJob for mysql.service failed because the control process exited with error code.
[22:09] <webchat49> See "systemctl status mysql.service" and "journalctl -xe" for details.
[22:09] <webchat49>  failed!
[22:09] <oerheks> webchat49, not again!
[22:10] <oerheks> you have been told to use pastebin
[22:10] <Saxle> I've only compiled 5.13 kernel, is 5.14 worth using?
[22:10] <TJ-> Saxle: if it fixes something yes !
[22:11] <webchat49> https://paste.ubuntu.com/p/HHRm74yMWR/plain/
[22:14] <speedy67> :PART
[22:17] <Bashing-om> webchat49: And ,,, ^^ "journalctl -xe" relates what ?
[22:18] <webchat49> https://paste.ubuntu.com/p/NX9WB8gVmf/plain/
[22:25] <oerheks> systemctl status mysql.server .. and why are you controlling mysql as user? not as root with sudo?
[22:25] <webchat49> with user, no root
[22:37] <Guest985> nigger
[22:37] <Guest985> sorry, wrong channel
[22:38] <TJ-> Guest985: we see you in other channels; not the 1st time
[22:38] <oerheks> !ops
[22:38] <Guest985> I'm sorry, we're playing hangman on another channel
[22:39] <Guest985> but turns out the word was actually "bigger"
[22:39] <oerheks> no, you are not. please leave or be quiet.
[22:45] <Kon> Thanks for the build TJ-, I'm going to have him test these shortly
[22:46] <TJ-> Kon: let me know if it works and I'll see if we can get that patch pulled into Ubuntu
[22:47] <Kon> Should hopefully have better results than earlier today https://cdn.discordapp.com/attachments/866874481640079360/868594510454722641/20210724_164423.jpg :)
[22:47] <TJ-> Kon: tell your friend to watch the NVME SMART counters carefully - the reports didn't look too healthy
[22:48] <TJ-> Kon: but that may be due to failed boots and forced power off
[22:48] <Kon> TJ-: Before he contacted me he said he had reinstalled from the Live ISO 20 times trying to fix his issue
[22:48] <TJ-> Kon: ouch
[22:48] <Kon> So I imagine it was a bit hot, and involved a few hard reboots
[22:50] <Kon> If we can resolve his issue it'll be the third Twitch streamer I've flipped to Linux, although not the biggest
[22:50] <Kon> All Ubuntu of course
[22:50] <TJ-> Most of my systems are pure Debian now
[22:51] <Kon> It makes sense if you're deep into packaging
[22:51] <TJ-> not that - to avoid the push to snaps and other things
[22:52] <Kon> Kubuntu I know has snapd but no snaps, not even core
[22:52] <Kon> Fair choice though
[22:53] <TJ-> lxd becoming snap-only made the choice for me; switched to systemd-nspawn and found it much better. Amongst other things it fully uses cgroups v2 which lxd still doesn't
[22:58] <BinarySavior> hi, my hi i'm trying to install ubuntu and it's currently "stuck" on "updates and other software"  i checked the box to download updates while installing and pressed continue and it's been "loading" for 15 minutes
[22:59] <BinarySavior> should i continue to wait or do you think it's encountered a bug
[22:59] <BinarySavior> ubuntu 17.04
[23:00] <BinarySavior> i didn't format the disk or anything beforehand, i currently have dual boot windows10 & ubuntu20.04
[23:01] <BinarySavior> i intend to use the installation gui to format the ubuntu20.04 partition and install there
[23:04] <Bashing-om> BinarySavior: 17.04 has no support and no software repository for the installer to access directly.
[23:04] <Bashing-om> !17.04 | BinarySavior
[23:04] <BinarySavior> sorry i mean 21.04 not 17.04
[23:05] <oerheks> boot again in live mode, see if you have a network connection
[23:10] <BinarySavior> oerheks, i'm sure i have a connection, it's cat5 connected
[23:10] <BinarySavior> or ethernet, not sure if it's still cat5 or w/e the newest ethernet cable is
[23:14] <BinarySavior> but i will try that anyway
[23:15] <BinarySavior> okay i booted into live mode, confirmed internet connection, now it seems to be working
[23:17] <Bashing-om> BinarySavior: The installer picked up where it had left off ? All good now ?
[23:17] <Kon> TJ-: My friend installed the kernel, headers, libc successfully but it can't boot when selected from GRUB because of invalid signature
[23:17] <Kon> I don't recall having run into that before
[23:18] <Kon> I wonder if he has Secure Boot on...
[23:18] <BinarySavior> Bashing-om, yes it picked up where it left off
[23:18] <Bashing-om> BinarySavior: \o/
[23:19] <BinarySavior> i didn't see an option for encrypted installation
[23:19] <Bashing-om> Kon: ' mokutil --sb-state ' should say .
[23:19] <BinarySavior> if i accidentally missed it, will I be able to encrypt my OS after it's installed?
[23:20] <oerheks> BinarySavior, no
[23:22] <oerheks> encrypted part is LVM + LUKS, in the installer, AFAIK
[23:22] <Kon> Yep, it was on
[23:24] <oerheks> some HP bios versions make you to grant access to a new instance in EFI