[00:00] tripelb: yes, I saw that earlier, it confirms the settings were accepted so if they are not making an improvement that avenue seems to be a dead end too. it's 1am in the morning here [00:02] oh my, you might be in berlin. [00:02] TIll some other day then. [00:02] pjs: someone else (Debian) with the same plugdev ownership: https://superuser.com/questions/1043394/after-systemd-upgrade-why-does-dev-null-always-have-the-wrong-permissions [00:02] tripelb: In England [00:03] I was in London in July.. for a day. Teddington maybe. [00:04] tharkun, thx, from some google search it seems that mariadb builds that library, you sure it is not included in mariadb? [00:04] TJ-, thanks.. reading.. [00:05] TJ-, You see my note about /dev/tty1, that has to be an issue right? My buddy has tty1 owned by gdm [00:06] pjs: yes, I saw that a few hours ago [00:06] pjs: I assumed you'd got a console log-in on tty1 [00:06] TJ-, of course :) I missed it (also ofcourse lol) [00:06] TJ-, yes I did. manually started X [00:08] fassl_: /usr/lib/x86_64-linux-gnu/mariadb18/plugin is the plugin dir and that file is not there [00:08] pjs: I'm suspecting you've installed something that has changed the way ubuntu configures; is i3 the only local build/install you've done? [00:09] fassl_: a friend on #mysql seems to know of a rename of that file. [00:09] TJ-, that and i3lock-color (replaced i3lock).. [00:09] tharkun, does it complain about not being able to load that file? it might have been linked in statically === [1]MrMobius is now known as MrMobius [00:10] pjs: I don't see anything in the i3 source that plays about in this way; the fact everything in /dev/ is root:plugdev points to udev [00:11] TJ-, On the link you sent me, the "fix" was manually changed /dev/null to group root, rebooting, then magically everything was owned correctly lol [00:12] pjs: do you have any udev over-rides in /etc/udev/ ? [00:12] pjs: hmmm, was it? that'd suggest on shutdown the ownership was saved to be recreated on boot - doesn't sound right ! [00:13] TJ-, in /etc/udev/ruled.d I have just these 2: 60-brother-libsane-type1-inst.rules 70-snap.core.rules [00:13] TJ-, otherwise udev.conf is a commented out single line and hwdb.d has no files [00:13] pjs: you're using IRC from the problem system now? [00:14] TJ-, grep null or plugdev in those 2 rules files shows nothing [00:14] TJ-, no, tmux from one of my fbsd servers [00:14] TJ-, but yes I'm ssh'd from the problem system.. but I can reboot and ssh in from my macbook [00:15] pjs: OK, I'm wondering if we can do a partial boot of it so it drops to the busybox shell in initramfs after it has mounted the real rootfs but before calling init... adding "break=init" to the kernel cmdline in the GRUB boot options. You'll need to be able to use the local physical console for that unless you've got network-KVM though [00:15] TJ-, no problem. It's sitting right in front of me [00:15] pjs: I'm thinking we should check if the root:plugdev ownership is already set in the initramfs [00:16] pjs: if it is, it narrows down the search massively [00:16] pjs: whilst you do that I'll make a cuppa to keep me awake :) [00:16] TJ-, ok.. I'm ready [00:18] TJ-, no rush. I hit ESC at grub boot and have the grub shell.. I'll wait for you to guide me here ;) === bhalithan1 is now known as bhalithan [00:19] Hi, i just installed bionic and nautilus doesn't create thumbnails of video files. Restricted extras are installed. Do i need anything else? [00:20] pjs: highlight the entry, press 'e' to edit it, navigate down to the line beginning "linux ..." and add to the end of it "break=init" then press Ctrl+X or F10 to boot with that change [00:20] ah ok [00:20] pjs: if you're in the shell do "exit" to return to the menu [00:22] TJ-, I'm in initramfs shell [00:26] TJ-, /dev/null is crw-rw-rw- 1 1, 3 /dev/null [00:26] pjs: hmmm [00:28] pjs: that's weird, no ownership info? [00:28] TJ-, nope that's exactly what it says.. all of /dev/ is like that [00:29] pjs: oh, hang on, does this report anything: "echo $rootmnt" [00:29] TJ-, actually ls -l of anything doesn't actually have names.. just numbers (id?) [00:29] let me see [00:29] TJ-, /root [00:29] pjs: I don't think it has pivoted to the real root at this point. Try "ls -l /root/dev/null" [00:30] TJ-, I was just exploring /root, I just checked /root/dev/null and it's the same as what I typed a second ago [00:30] TJ-, but it IS o+rw which it isn't in normal boot [00:30] pjs: OK, which release of ubuntu is that supposed to be!? 18.04 ? [00:30] TJ-, hah yup. It is 18.04 [00:32] pjs: what version of busybox? "/bin/busybox --help" [00:32] TJ-, 1.27.2 [00:34] pjs: trying it here too [00:34] TJ-, ok cool [00:35] pjs: right, it's a busybox ls thing [00:36] TJ-, ah ok [00:36] pjs: do "stat /dev/null" instead [00:36] pjs: I see Access: 0666 uid 0 gid 0 [00:36] TJ-, all I did was the boot.. should I have started busybox or something? [00:37] busybox is what is running [00:37] TJ-, my shell prompt is "(initramfs) " [00:37] TJ-, ah ok [00:38] pjs: busybox provides /bin/sh and all the other tools, as cut down versions (to save space) and they're all statically linked in the single /bin/busybox executable [00:38] pjs: so if your 'stat' output matches mine, we know the :plugdev and possibly other things are done when system init starts [00:38] TJ-, so after boot I didn't need to start sh or something right? I just did ls -l straight from there [00:39] TJ-, because uid: 1, gid: 1 and perms are different in busybox than in normal system [00:39] pjs: correct. what happens is the kernel executes /init which is a shell script, which causes the kernel to call "/bin/sh /init" and /bin/sh is a symlink to /bin/busybox [00:40] pjs: you're seeing uid 1 gid 1 !? [00:40] pjs: that from stat? [00:41] TJ-, no I just did "ls -l /dev/null" (also /root/dev/null) [00:41] TJ-, using stat I also see 0666, uid: 0, gid: 0/unknown [00:42] can you: "inotifywait -s -m -e attrib /dev/null -o /var/log/syslog" and see in the syslog when the perms change to narrow it down? [00:42] pjs: phew! [00:43] fassl_: no, because it looks like it changes due to the init system which we cannot get in front of [00:44] pjs: right, so, now let's try something different. I want you to reboot, enter GRUB again, edit the entry again, but this time add "init=/bin/bash" and then press Ctrl+X - this will boot without systemd, to bash, and then you can check the ownership of /dev/null again [00:44] yeah, a script in the initramfs to monitor that is not possible? [00:45] fassl_: no, the last thing the /init script does is exec another process, which replaces the init script [00:45] TJ- ok [00:45] ah ok [00:45] Hey, how's it going, guys? [00:47] TJ-, 666, root, root [00:47] TJ-, for /dev/null [00:47] pjs: we're making (slow) progress then [00:47] pjs: we'll restart into the usual init system in a moment, but first I want to check if what is required to have udevd log [00:49] TJ-, ok cool [00:49] pjs: so, reboot to GRUB again, edit the entry, this time add "rd.udev.log_priority=debug udev.log_priority=debug" then Ctrl+X - this logs from the initrd (rd) and after systemd starts [00:50] two of my Thinkpads run Ubuntu trusty. on one of them, recently the ethernet port started having its LEDs always on (or blinking at a rate I can't see), and Network Manager continues to try all my ethernet IP configs in rotation, each failing because there's no cable in the ethernet port. what might be broken? [00:50] pjs: messages should go to the kernel log [00:50] Sven_vB: link detect I think [00:51] TJ-, ok.. I couldn't "reboot" so I typed "exit" and got a kernel panic lol [00:51] Sven_vB: is the port dirty or got broken pins? [00:51] on the other one, the ethernet port is empty as well, and it seems to know there's no cable. LEDs off and no syslog activity about ethernet. [00:51] TJ-, might be dusty. I'll try and clean it. [00:51] pjs: right - you only had bash running so no system services [00:52] pipe air blew out some dust but no change in the LEDs. [00:52] Sven_vB: does the PC dual-boot with Windows? [00:53] so would this mean there's an electrical failure inside the notebook? nope, no other OS installed. [00:53] Sven_vB: it sounds like it could be electrical, yes. [00:53] TJ-, ok booted [00:53] lots of logs this time :) [00:54] thanks! [00:54] pjs: I thought there would be. let's figure out if we can catch them [00:54] Sven_vB: try "ethtool" see what it reports for the port [00:54] Sven_vB: e.g. ethtool eth0" and if you can pastebin the output we'll look [00:55] pjs: how about "journalctl -b | wc -l " - how many lines does it report? [00:56] TJ-, 5262 [00:56] pjs: ouch, maybe a bit much for pastebin [00:56] pjs: give it a try though! "pastebinit <( journalctl -b )" [00:57] TJ-, woot, http://paste.ubuntu.com/p/jVm2DPgbb2 [00:58] pjs: ... I may be some time... [00:59] TJ-, no worries [00:59] thank you! [00:59] TJ-, ethtool output is mostly "No such device" https://paste.debian.net/plain/1048191 [01:00] does it use another namespace than "ip link"? [01:01] pjs: not alot there really. does "ls -l /dev/null" still show root:plugdev ? [01:01] Sven_vB: you need to replace "eth0" with the name of your actual device [01:02] Sven_vB: "ip link show" will report them [01:02] TJ-, yea, same perms too [01:02] TJ-, yeah, that's why I included the ip link output in the paste, to show that eth3 somewhat exists. [01:03] the only other devices ip link shows are lo and wifi [01:08] Sven_vB: I don't know what is going on there but even with the interface down, ethtool can read it here. I suspect there may be a clue in the kernel log. Show us "pastebinit <( dmesg )" [01:08] what would be a good way to tell NetworkManager to temporarily ignore eth3 completely? ideally easier to toggle than a kernel module blacklist entry. [01:08] pjs: Let's do a brute-force search of the local settings "sudo grep -rni plugdev /etc/" [01:09] TJ-, ok [01:09] the only dmesg entry with keyword "eth" is [6335720.058795] e1000e 0000:00:19.0 eth3: Hardware Error [01:09] Sven_vB: there might be other messages that lead up/follow that one, that is what I need to see [01:11] TJ-, nothing interesting.. http://paste.ubuntu.com/p/FWcVnQ9vxw [01:12] I have been able to create a WAV format file from text using espeak. The next step is to convert the WAV file to a 44.1 KHz MP3 file. [01:12] When I try that with lame, it converts a "normal" voice to "helium-gas" speak. [01:12] TJ-, I'll try that again tomorrow. today there's too much other info near the eth message that I'd rather not publish. [01:13] pjs: getting weirder! [01:13] on centos at least you can configure it in /etc/sysconfig/network or whatever, NM_CONTROLLED=no [01:14] TJ- haha [01:14] TJ-, so I tried manually changing it and rebooting.. the perms/ownership reverted [01:15] pjs: reverted to root:root or root:plugdev / [01:16] Soundconverter loses its mind reading a WAV file produced by espeak and Ubuntu keeps throwing up panels with "the application terminated abnormally". [01:16] Sven_vB: you can use /etc/NetworkManager/NetworkManager.conf adding "no-auto-default=eth3" [01:16] Might someone offer a hint on how to convert WAV to MP3 ? [01:16] TJ-, thanks! [01:17] TJ-, and then reload NM? [01:17] TJ-, root:plugdev [01:20] not to channel log readers: no-auto-default goes into the [main] secion, says man NetworkManager.conf [01:20] *note [01:22] Sven_vB: yes, restart NM after adding that change [01:22] pjs: yes, that is expected. devtmps (/dev/) is recreated at each boot, it isn't static [01:22] pjs: which is why we are searching for what is making the change [01:22] well, restart was what I tried to avoid. =) well then, brb [01:22] pjs: remind me; is "ls -ld /dev" ownership root:root ? [01:22] Sven_vB: restart the service [01:23] Sven_vB: as in "sudo systemctl reload-or-restart network-manager" [01:24] yeah, I did. wifi connection was thus reconnected. I'm surprised my IRC connection survived that. +1 for TOR as a romaing service. [01:24] TJ-, root:root [01:25] pjs: something must be executing a command that in a shell would be "chmod :plugdev /dev/*" so lets see if we can find that. "sudo grep -rni plugdev /usr |& tee /tmp/plugdev.log" [01:26] TJ-, running... [01:26] pjs: same here ... takes some time :) [01:26] haha [01:27] pjs: nothing stands out here; mostly standard stuff for useradd and base-passwd [01:29] TJ-, same.. though there is some stuff from udiskie README, but I thought I uninstalled that [01:29] TJ-, seems to not have helped. I was just notified via toast popup that eht3 had lost connectivity. [01:29] I wonder what it was connected to. [01:29] probably a translation issue. [01:30] ah, no, it said it's now not connected. it didn't say it was connected before. [01:30] I mean, that's good to know, but once per session would be enough. [01:31] TJ-, http://paste.ubuntu.com/p/NyycVdy3jn (if you're interested) [01:31] pjs: there is something unusual on that system; besides the self-build of i3 have you installed anything from PPAs at any time [01:32] TJ-, yes. Slack, Signal Desktop, Mongodb, google chrome and skype [01:32] oh also ubiquiti (manages my wifi AP) [01:32] pjs, no VLC PPA? [01:33] Sven_vB: I do have vlc installed but no external repo added for vlc [01:33] ok [01:34] What does PPA stand for? [01:34] pjs: let's search the packages install scripts: "grep -rni plugdev /var/lib/dpkg/info" [01:34] pjs: Personal Package Archive [01:34] !ppa | pjs [01:34] pjs: A Personal Package Archive (PPA) can provide alternate software not normally available in the offical Ubuntu repositories - Looking for a PPA? See https://launchpad.net/ubuntu/+ppas - WARNING: PPAs are unsupported third-party packages, and you use them at your own risk. See also !addppa and !ppa-purge [01:35] TJ-, entries for usbmuxd and base-passwd [01:35] pjs: can you pastebin for me? [01:35] TJ-, thanks [01:35] TJ-, http://paste.ubuntu.com/p/myty6fCfNn [01:36] guys [01:37] i have a problem with maintenence mode [01:37] pjs: same as here; so no joy there either. Now let's try local stuff: "sudo grep -rni plugdev /usr/local" [01:37] TJ-, no matches [01:38] i have already known how to scroll up n down, but obviously some earlier output on screen would be cleared, especially on some commands which outputs a lot like dpkg --list [01:39] ok then can't you do an early inotify systemd service? [01:39] so how can i see all those output? [01:39] command | less [01:43] pjs: I've just gone through the systemd-udev source; don't see anything there either. It's important to note that "plugdev" group is a Debian/Ubuntu specific construct [01:44] TJ-, this is strange [01:45] TJ-, this is a process list of all "normal" running proc's: http://paste.ubuntu.com/p/G3zfrkcfG6/ [01:45] pjs: does this exist? "ls -l /etc/udev/rules.d/device-permissions.rules" [01:46] TJ-, nope. I asked you if it should earlier. Saw something on SO or something [01:47] pjs: it existed in 16.04 but should be removed; I just wondered if it had been left behind [01:49] pjs: actually, I don't see it in 16.04 either. I was wondering if it had been inherited, but no [01:49] TJ-, right.. I thought about adding it just to see what happens but I didn't obviously :) [01:50] pjs: we know something is changing the permissions of almost all nodes under /dev/ so this is not specific to /dev/null. We also do not know if this is related to the apt-key issue or not but it is the only slender lead we have [01:51] pjs: I have to suspect some of those PPA packages you've got installed, although I cannot think what one would be doing to change permissions on /dev/* - and it would have to be something running as root user to be able to do it [01:52] TJ-, yea nothing is running as root that I can think of.. Let me check ubiquiti [01:54] TJ-, ok so Unifi (by ubiquiti) seems to be [01:54] it's started by systemd [01:54] though it's currently disabled [01:55] TJ-, let me uninstall it [01:57] TJ-, this also removed mongodb (which was only needed by unifi) [02:03] pjs: I didn't see anything obvious in the ps list [02:04] pjs: I'm trying to think if there's a way we can get systemd to tell us what touches dev; later in boot I'd use inotifywait. "plugdev" is an Ubuntu construct so I think it is something caused by some installed package [02:04] pjs: was this system upgraded from 14.04 > 16.04 > 18.04 ? [02:05] TJ-, no. fresh install of 18.04. I've only had the laptop since July [02:07] pjs: really? oh... that makes thing even more perplexing! [02:08] pjs: from the extensive searches we've done it suggests whatever is changing the group is inside a binary, rather than being in plain sight. we also know it must run as 'root' (uid 0) at some point early on [02:09] pjs: try rebooting, going to GRUB menu, choosing Advanced sub-menu then boot the first Recovery option. Get to a shell there and check "ls -l /dev/null" - that only starts a very reduced set of services, which might help us narrow down where the change happens [02:09] TJ-, hrmm [02:10] TJ-, ok cool I'll try it [02:10] pjs: that'll also only be in single-user mode === BgLamersTeam is now known as Dreaman [02:15] pjs: not sure if I linked to this earlier, but someone (on Debian) with the identical problem attributed to systemd package upgrade. Seems very weird since systemd has no mention of plugdev in its entire sourcecode [02:15] pjs: https://superuser.com/questions/1043394/after-systemd-upgrade-why-does-dev-null-always-have-the-wrong-permissions [02:17] TJ-, yea you did. I read all the answers but basically it was manually change it and reboot.. and like magic, it was resolved [02:17] pjs: there was no solution on that one [02:18] TJ-, well no accepted solution but if you read the comments, the OP said that's what "resolved" it [02:19] did you check anything in /etc/systemd might say plugdev ? or /var/lib/systemd ? [02:19] fassl_: we've grep-ed the entire file-system ! [02:19] ah didnt see that sorry [02:19] fassl_: hehehe no worries... I'm forgetting now we've done so much. [02:20] pjs: did you get into single-user mode? [02:20] TJ-, doing so now [02:20] pjs: OK ... because after that we'll use fassl's suggestion about /var/lib/ since I cannot remember if we covered that one! [02:21] if its fine for rescue, we can test multi-user, and if it is still fine, then graphical.target does this nasty stuff [02:21] pjs: the only thing I could think of is the group is being changed by number, not name, and the number just happens to the plugdev group. What gid is that? "getent group plugdev" [02:22] ehm at least thats the ones i know about, there are more :P [02:22] TJ-, 666, root:root /dev/null :) [02:22] pjs: Yay! [02:22] pjs: so, it is happening in some job between recovery.target and multi-user.target [02:23] TJ-, gid is 46 for plugdev [02:23] pjs: it is for me too - I think it probably is on most clean installs since packages install in the same order [02:24] you can just systemctl isolate multi-user - check -- systemctl isolate graphical - check [02:24] pjs: it isn't booting to a GUI is it? you start the GUI manually? [02:26] TJ-, start manually [02:29] "systemd-analyze critical-chain" can tell you the order of targets, i would traverse them and just check when the perms change [02:32] fassl_: idea! with the system booted to recovery we could start an "inotifywait -m /dev/null" with a timeformat string to capture when the changes happen, combine that with having "systemd.log_level=debug" on the kernel command-line and we could later match the timestamps to figure out what was active when the attributes are changed ? [02:33] fassl_: we can change the system default.target and reload the daemon so it continues running the additional jobs, I think [02:34] TJ-, yes that sounds good. would you wait for syslog and log there or wait for local-fs or something and log there? [02:34] fassl_: to a file in a tmpfs [02:34] I think /run/ should be mounted at that point [02:36] pjs: fassl_ I'll test that procedure here to ensure it works as we want [02:36] TJ-, ok cool [02:38] oh great! recover mode stalls in kernel on an RCU and sends an NMI! [02:38] TJ-, i have here a service skeleton which you could use if you need it [02:41] right, it worked this time. seems it didn't like "nomodeset" for some reason [02:41] actually we dont even need to deal with timestamps, it will be in journal [02:41] fassl_: what will? the inotifywait timestamp? [02:42] stdout of the systemd service === patr0clus is now known as s3nd1v0g1us [02:42] fassl_: I want to correlate the attribute change of /dev/null to something in the log [02:45] https://pastebin.com/aBaz2TXe [02:45] should work? [02:45] fassl_: yes, we need to add the timeformat too [02:46] TJ-, nah, it will be in journal, it has the stamp already? [02:46] and even if not, it will be in between two lines [02:49] With a zabbix server, does anyone have opinions on using snmp vs a zabbix agent to monitor an ubuntu box? Pros/Cons? [02:49] I have problem displaying text editor [02:50] Geo: not really a support question [02:50] Well, let me send a screenshot [02:50] fassl_: hmmm, yeah, that might be sufficient [02:52] pjs: are you able to Ctrl+D to continue booting so you can download that system unit fassl_ created, and install it in /etc/systemd/system/ (is that correct fassl_ ? ) [02:52] yes [02:52] TJ-, Oh I rebooted normally.. I can grab it [02:52] and then systemctl enable whatever_you_called_it.service [02:52] pjs: ^^^^ then reboot again normally [02:53] ok [02:53] doing... [02:53] *drumroll* [02:54] * TJ- nods off to sleep :) [02:54] but also apt install inotify-tools [02:55] if havent done so already [02:55] fassl_: oh, good point! I'm so used to having them :D [02:55] yeah me going too soon ;) [02:55] I'ts 4am here [02:55] TJ-, me rarely needs it :) [02:55] 5 here [02:55] heh good I didn't have them :) [02:56] ok it installed into multi-user.target.wants, that ok? [02:56] yep should be i guess TJ- ? [02:57] pjs: yes, I think so [02:57] hehehe: "2018-10-19 19:01:34 TJ- pjs: how long do you have to work on it?" [02:57] if that doesnt turn out well we might use network-pre.target [02:57] TJ-, haha! I was just thinking that [02:58] ok so I just reboot? [02:58] pjs: I think so, yes... fassl_ ? [02:58] ya [02:58] ok here we go.. do I need to do anything in grub? or just boot up normally [02:58] normal [02:58] I generally deal with the weirdest issues we get here, and this one is really heading for the top 5! [02:59] booting [02:59] TJ-, leave it to me :) [02:59] its probably background radiation flipping your bits to 48 [02:59] or whatever gid that was [02:59] TJ-, I haven't run a Linux or BSD workstation in like 15 years. Since ditching my MBA in July, it's been fun getting back into it.. until this issue :) [03:00] pjs: is this the same system that on the 16th I was helping you with sound issues? [03:00] TJ-, yes :) [03:00] TJ-, all this started that day.. All these weird issues [03:00] TJ-, fassl_, booted up [03:00] waiting for the .bashrc which contains the chmod... :D [03:01] hahahaha [03:01] pjs: really!? now that IS interesting. I best re-read my log file [03:01] fassl_: oh don't say that! we never searched the user's dir! [03:01] TJ-, I did [03:01] search user dir [03:01] fassl_: that was an amateur mistake on my part... but it would need sudo/pkexec permissions to do that [03:02] journalctl -xe --no-pager | grep ATTRIB [03:02] or just journalctl -xe through it [03:02] TJ-, happens to the best ;) [03:02] no results with grep [03:03] systemctl status whatever_you_called_it [03:03] fassl_: to let you know what the original report on 16th was... [03:03] 2018-10-16 19:15:46 pjs hey all.. Been having strange issues since yesterday but as of now my mic/speakers aren't recognized. I have a think [03:03] pad x1c6, the only thing I did was plug in a headset yesterday (first time doing so, newish laptop) and now the built in mic/speakers don't work. Ho [03:03] w can I restart alsa-utils, pulse etc.? I tried using service and it says they're masked (not even sure what that means) [03:03] fassl_: says it's active and running [03:04] TJ-, fassl_, http://paste.ubuntu.com/p/Hr22sVzPCR [03:04] TJ-, what the... pjs got some issues man :D, never stops [03:05] fassl_: hahahaha that was resolved [03:05] pjs, does the status say something else? like log lines [03:05] TJ-, fassl_, http://paste.ubuntu.com/p/ZvxPG5h9Th [03:06] ^ everything from systemctl status ... [03:06] ok then systemctl disable whatever_you_called_it [03:06] and change the WantedBy lines to network-pre.target [03:06] then enable again and reboot again [03:07] fassl_: right, it needs to start a lot earlier I guess [03:07] TJ-, yeah we could copy the recovery thing? [03:08] rebooting... [03:09] TJ-, fassl_, http://paste.ubuntu.com/p/jfQR48y8mR <- journalctl -xe [03:10] no matched for grep ATTRIB [03:10] ok disable that again and [03:10] systemctl status says it's active. similar to previous [03:10] ok [03:10] disabled [03:11] try this one instead https://pastebin.com/t82Lvyuk [03:12] can we get it before apparmor? it is still starting quite late [03:12] TJ-, are we fine in recovery? the settings are copied from recovery [03:14] yes should be [03:14] so enable and reboot? [03:14] yep [03:15] rebooting... [03:16] TJ-, fassl_, http://paste.ubuntu.com/p/XPp3yHxfH9 <- journalctl -xe [03:16] we have a hit for ATTRIB :) [03:17] yay [03:17] looks like udevd [03:19] i saw this earlier and discounted it, but now I wonder: "thinkpad systemd-udevd[485]: invalid key/value pair in file /lib/udev/rules.d/99-adb.rules on line 2, starting at character 60 (',')" [03:20] I cannot find that file via apt-file search either, although I'm sure earlier I did confirm it was in a package [03:21] pjs: can you "pastebinit /lib/udev/rules.d/99-adb.rules" [03:21] TJ-, ahhhh! yes, I had to add that for adb (android thing).. [03:21] sure [03:21] s [03:21] sure [03:21] shit sorry lol [03:22] TJ-, fassl_, http://paste.ubuntu.com/p/WfxMM3Prjj - adb.rules [03:23] pjs: Grrrr! [03:23] TJ-, *hangs head in shame* [03:23] was this the cause? [03:23] you've split it across lines... which means each line is executed! [03:24] pjs: you're doing "MODE="0664", GROUP="plugdev" " for everything ! [03:24] pjs: delete all the linefeeds so it is all on one line, then try a reboot [03:24] fuuuuck! [03:24] ajajajaja ouch xD [03:25] at least I think that is it; I don't recall rules being able to cross lines [03:25] rebooting... [03:26] TJ-, now that I think of it, when all this started was after the first reboot since adding that file (I added it Oct 9th) :( [03:26] pjs: *spank* with a big wet fish [03:26] TJ-, omg.. 666, root:root /dev/null :) [03:26] * TJ- falls over [03:26] zfs root snapshots! ;) [03:26] TJ-, please send me your venmo or Paypal.. seriously [03:27] * TJ- makes pjs do 100 laps of the country! [03:27] TJ-, all perms in /dev are normal now :) [03:27] congrats you guys [03:27] pjs: so now test apt! [03:27] fassl_: thanks to you too - without your systemd foo I'd have faded, brain has almost stopped working [03:28] pjs: hopefully now apt-key doesn't throw an error [03:28] no apt-key errors! [03:28] wow [03:28] you were too long at it i guess [03:28] pjs: you are banned from making changes for a year :D [03:28] fassl_: yes, thanks to you! [03:28] TJ-, lmfao rightfully so [03:28] TJ-, fassl_ thank you both so much! [03:29] pjs: this explains all the random errors since that rule was being run on almost everything [03:29] yw [03:29] !cookie | TJ- [03:29] TJ-: Wow! You're such a great helper, you deserve a cookie! [03:29] Bashing-om: you're still spectating? :D [03:29] TJ-, yes it does! oh man [03:30] pjs: wierd how our earlier greps didn't focus on it... I looked, but thought 'yeah' it is valid to set the group to plugdev for an android device, but the file I looked at here was all on one line! [03:30] TJ-: Still on that learning curve - never pass an opportunity to look over your shoulder :P [03:31] we really need to loose all this 'plugdev' group stuff; it's wrong. we just need to be using TAG+="uaccess" on such devices [03:31] TJ-, yea I had no idea about the lines.. I just copied/pasted that file from Google [03:31] gnight guys, and "break all the things!" [03:32] g'night fassl and thanks [03:32] fassl: goodnight! thank you again [03:32] it's time for my breakfast [03:35] I have recently upgraded to Cosmic, which has Kernel 4.18 and Mesa 18.2, but my Hades Canyon NUC(8i7HVK) still reports using llvmpipe when running `glxinfo | grep "OpenGL"` [03:37] I'm trying to find some resources to help me figure out what else I need to do to enable the Vega M GPU [03:37] I've inspected the microcode, and it seems to be exactly the same as the latest master [03:40]