| ralphy | The suspend issue also is present on the old installation kernel 6.1.0.10 | 00:27 |
|---|---|---|
| ralphy | On the second installation I am upgrading now to Excalibur to see whats happening. | 00:30 |
| rrq | why does "cron" refuse to work if there is a hardlink to any of its configuration files? what's the danger with such a hadrlink? | 02:29 |
| rrq | .. and why should the s/w have code to worry about it? | 02:32 |
| fluffywolf | I don't have a full answer, but googling, it seems like a hardlink to it would allow anyone in the same group as cron to use it to run things as root? | 03:03 |
| rrq | ?? how ?? | 03:03 |
| fluffywolf | or the same user as any daemon with a crontab file, or something... | 03:04 |
| fluffywolf | I'm not sure. I didn't think hardlinks could bypass permissions, but maybe they can? lol | 03:04 |
| rrq | obviously anyone who can edit a confguration file can make it do whatever... but having hardlinks doesn;t change that one way or the other, does it? | 03:05 |
| rrq | and setting a hardlink requires root | 03:06 |
| rrq | the | 03:08 |
| rrq | the s/w has code to refuse if the hardlink count != 1... it's s/w patched in by debian (doesn;t exist in upstream) | 03:10 |
| rrq | happend in 2015 | 03:10 |
| fluffywolf | it was done upstream in 2000 from what I've read. | 03:10 |
| rrq | mmm the debian project has it as a patch that was added in 2015 | 03:12 |
| fluffywolf | it seems like normal users could create hardlinks to the crontab in a place that some other privleged program could edit them, clobbering crontab with malicious content. so a user hardlinks /tmp/anamethatadaemonwilluse to /etc/crontab. the user still can't edit /tmp/anamethatadaemonwilluse. but when a root-running daemon goes to write /tmp/anamethatadaemonwilluse, it instead overwrites crontab. | 03:13 |
| fluffywolf | the user will, of course, make sure the daemon tries writing at least one line that looks like a valid crontab entry, so it gets run, as root... | 03:13 |
| rrq | but only root can create a hardlink | 03:14 |
| fluffywolf | there's actually a bug report that this hardlink check doesn't work nearly as well as it should, if the user can just delete the hardlink after crontab gets clobbered... | 03:14 |
| fluffywolf | no, all users can create hardlinks, it seems. | 03:15 |
| fluffywolf | I've never actually tried. lol. I always use symlinks. but I just created one with a normal user account to check. | 03:15 |
| rrq | hmm yes; I could create a local hardlinks without problem | 03:17 |
| rrq | but I can't link /etc/crontab | 03:17 |
| fluffywolf | the permissions should be such that normal users can't hardlink to /etc/crontab; there's distro-specific bugs about poor permissions letting people hardlink to it, thus letting any user trip the anti-hardlink protection and disable cron. | 03:18 |
| rrq | so the argument is that in some broken systems, hardlinks to /etc/crontab is possible, and therefore cron should refuse to run | 03:20 |
| fluffywolf | because refusing to run and having cron break is preferable to privledge escalation attacks. | 03:21 |
| rrq | that's backward thinking to me.. if the system is broken in that way there are many other things one could do... | 03:23 |
| rrq | why should just cron worry about it then? | 03:23 |
| fluffywolf | my question is... in what context did you find out this check exists? :P | 03:24 |
| rrq | I made a snapshot of /etc | 03:24 |
| rrq | using the good old "cp al" | 03:25 |
| rrq | "cp -al" | 03:25 |
| fluffywolf | heh, that's how a couple of the threads I found discovered it too... | 03:26 |
| fluffywolf | including a /etc in a container's directory with hardlinks and such | 03:26 |
| rrq | :) ... yes it would seem like a perfectly good way of creating a time series of a directory tree | 03:27 |
| rrq | but (only!) cron gets upset | 03:28 |
| fluffywolf | time series? | 03:28 |
| fluffywolf | if you edit one, you edit all of them... not exactly a record. lol | 03:28 |
| rrq | it does rely on update-by-replace, yes ... so you're right about that | 03:29 |
| rrq | so I'll need to do differently... but it surprised me that cron was programmed in that way | 03:35 |
| rrq | stupid side-constraints that don't belong to its function | 03:35 |
| rrq | but at least it doesn't use dbus yet... | 03:37 |
| fluffywolf | reading a thing from 2002, another factor is programs that monitor /tmp for old files and remove them... if it declares a file to be old and deletes it, but the daemon that created it then attempts to use it further, that gives you an easy window for creating a hardlink that does evil. | 03:37 |
| fluffywolf | also, implementations of mkstemp() using predictable names | 03:38 |
| rrq | not sure how that breaks to uid/gid barrier | 03:41 |
| fluffywolf | if a daemon that runs as root owns/creates the tmpfile, it will have root access to whatever the hardlink points to, even if a regular user created the hardlink. | 03:43 |
| fluffywolf | it might be more of a theoretical attack than one widely used in the wild, but it does seem plausible. | 03:44 |
| rrq | but the uid/gid cannot set the hardlink | 03:45 |
| fluffywolf | ? | 03:46 |
| rrq | at I get "invalid cross-device link" as result when trying to set a link to a root-owned file in /tmp | 03:46 |
| fluffywolf | your /tmp is probably tmpfs, and thus a different filesystem. it's not always this way. | 03:48 |
| rrq | even in /tmp I get "Operation not permitted" | 03:49 |
| fluffywolf | also, there's protections to keep you from making evil hardlinks on modern systems. lol | 03:49 |
| fluffywolf | most of what I'm finding about this attack dates from 2000-2002 or so... | 03:49 |
| rrq | I can set a link in /tmp to one of same uid/gid but can't set one to root/root without being root | 03:50 |
| rrq | looks like "bad hardlinks" are prohibited, which is good, but doesn;t support the idea that cron should have that code (refusing if there are hardlinks) | 03:51 |
| fluffywolf | https://docs.kernel.org/admin-guide/sysctl/fs.html#protected-hardlinks | 03:52 |
| fluffywolf | it's a modern linux feature | 03:52 |
| fluffywolf | while the same cron program has been used on everything (including bsds) since 1987 or so... | 03:53 |
| rrq | ok. the git history starts at 1999 | 03:56 |
| fluffywolf | https://rachelbythebay.com/w/2022/03/15/link/ the second attack it mentions | 03:56 |
| fluffywolf | it does seem like the hardlink check in cron is unneeded on modern, correctly configured linux systems... but the same upstream is used for older, incorrectly configured, and non-linux environments as well. | 03:57 |
| fluffywolf | it was originally implemented in 2000 from what I saw. | 03:57 |
| rrq | if a user can set a hardlink willy-nilly, can they also change permissions? | 04:01 |
| fluffywolf | and there's very, very rarely momentum for removing security checks that may be relevant on some systems and the drawbacks of the check are only observed by a few people trying to do weird things. :P | 04:01 |
| fluffywolf | no, the hardlink still has the original permissions | 04:01 |
| rrq | doesn't that then stop infusng badness into the file? | 04:04 |
| fluffywolf | the trick is to name the hardlink something that a root program will write to | 04:05 |
| fluffywolf | tons of things create files in /tmp, not all of them with unpredictable names. | 04:05 |
| rrq | and daemons trust files in /tmp? | 04:06 |
| rrq | ... and on such a system you can hardlink /tmp/knowname to /bin/sh I guess | 04:07 |
| fluffywolf | *in theory*, they should use securely random files created with protections for race conditions. | 04:07 |
| fluffywolf | getting a proper binary executable written to a temp file by a random daemon is a lot harder than getting one line that looks like a crontab entry somewhere in a file written... | 04:07 |
| fluffywolf | the page I read earlier gave two examples of non-secure /tmp usage... systems with a daemon that cleans old files combined with daemons that may use a file for longer than what it considers old, and systems where mkstemp() is predictable, or at least predictable enough you can spam thousands or tens of thousands of likely names at the right time. | 04:09 |
| fluffywolf | and then, of course, there's daemons that just use hardcoded names, but that's been considered insecure for long enough you don't see it anymore... | 04:10 |
| fluffywolf | the example it gave was one that names temp files with a hash of the pid and the time; since you can look up the pid, and predict the time you'll trigger the daemon, you could spam a hardlink for every microsecond time in the range you were expecting, and it'd end up using one of them. | 04:11 |
| rrq | I suppose in general one could have that any daemon that writes to a file should first ensure that file not being hardlinked | 04:15 |
| fluffywolf | and avoid race conditions where you create the file after it does its checks and before it goes to create the file... one page mentioned intentionally hammering the disk at the right moment to create a longer time window to exploit this... | 04:16 |
| fluffywolf | (attackers are clever!) | 04:16 |
| fluffywolf | start a thousand threads to read random blocks, and the race condition window suddenly goes from a few cycles to a few seconds... | 04:17 |
| rrq | are you saying it's deemed impossible for the writer to be sure that its writing does not end up on some pre-existing file? | 04:19 |
| fluffywolf | or at least difficult enough that it should be given serious consideration. | 04:21 |
| fluffywolf | checkiffilexists() createfile() is subject to the race condition problem | 04:22 |
| fluffywolf | you can squeeze into that window and create it yourself | 04:22 |
| fluffywolf | everything running as root these days should be creating completely unpredictably named files. | 04:23 |
| rrq | but checking the link status would be after opening the file | 04:23 |
| fluffywolf | yeah, but that depends on every daemon doing it. | 04:24 |
| rrq | yes. pushing this to the reader is more flawed since it uses the content regardless of how it got there | 04:26 |
| fluffywolf | the fact that there's like six different mechanisms to prevent these attacks shows that they were important at one point. lol | 04:29 |
| rrq | yeah... thanks for sharing ... I may still hold the view that it's wrong, but in any case my approach to what I was doing needs to be different so I shouldn't stay bothered about it | 04:34 |
| fluffywolf | some of it I already knew (I'm old enough to remember the days where /tmp naming conflicts were actually exploited), but everything cron-specific I just learned myself. lol | 04:36 |
| rwp | Hmm... Maybe related? https://bugs.debian.org/210467 CRON: Does not work with symlinks anymore (2003) | 04:39 |
| fluffywolf | related in that it's one of a large number of hardening steps over the years. | 04:43 |
| rwp | I almost always have / and /var and /home on different partitions. That blocks any attempt at creating hardlinks to /etc/crontab | 04:54 |
| rwp | But trying to create a hardlink where I think it should work I see that the Linux kernel blocks this due to one of the newer hardening limits. | 04:54 |
| rwp | But I can't see why. I can't see an attack that can make use of that ability. So blocking it seems gratuitous. | 04:55 |
| fluffywolf | I think I mentioned several above... | 04:56 |
| fluffywolf | and linked to the docs on the linux protection | 04:56 |
| rwp | Sorry. I'm a little distracted here IRL. I'll read through the scrollback when I get quiet time later tonight. | 04:57 |
| rwp | fluffywolf, I have read the scrollback and the proposed attacks are, keeping a copy of suid programs so that in the future if they become vulnerable one might still keep a copy. | 06:30 |
| rwp | That's an interesting attack. Which requires someone to have a writable location in which to store those files that sysadmin won't notice. That's the tricky part. Where on a multiuser machine like a corporate machine or a uni machine with multiple users would someone be able to stash linked setuid binaries that sysadmin would not notice? | 06:31 |
| fluffywolf | that was just one of the attacks, not the one we spent the other 95% of the time talking about. lol | 06:31 |
| rwp | Of course it does not matter on a personal laptop which is the one most likely to have such a spot. | 06:31 |
| fluffywolf | their home directory? a directory named "Powerpoint Presentation Backup 2021"? | 06:31 |
| rwp | Well... The other attack was to link into a place that another root program, which is written stupidly, will do something totally vulnerable in. | 06:32 |
| rwp | I rather discounted that attack. | 06:32 |
| fluffywolf | yes. that other attack is one that was exploited for a very long time. | 06:32 |
| rwp | All programs that open temporary files should be using a "safe" way of opening a temporary file. O_EXCL for one. | 06:32 |
| fluffywolf | malicious stuff in /tmp was a real problem | 06:32 |
| fluffywolf | isn't that a GNUism? | 06:33 |
| rwp | Also /tmp always has the sticky bit 't' set so that means if you don't own the file you can't remove the file. So one would be stuffing a bunch of hardlinked setuid files there. And I think sysadmin would notice that. And /tmp is most usually on a different file system blocking that too. | 06:34 |
| rwp | O_EXCL a GNUism? | 06:34 |
| fluffywolf | you're confusing "modern linux" with "all *nixes"... | 06:34 |
| fluffywolf | old linux had tons of insecure tempfile issues | 06:35 |
| rwp | https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html | 06:35 |
| rwp | Oh sure... If we go back to HP-UX days I could almost always find some security exploit in it. But that's not a free software system. It was impossible to get fixes fixed there. | 06:35 |
| rwp | I once had a trivially fixed bug I filed with a patch to a .h file only get fixed more than 10+ years after I filed it. | 06:36 |
| fluffywolf | https://capec.mitre.org/data/definitions/149.html | 06:37 |
| rwp | 06:38 | |
| rwp | CAPEC | 06:38 |
| rwp | Common Attack Pattern Enumeration and Classification | 06:38 |
| rwp | A Community Resource for Identifying and Understanding Attacks | 06:38 |
| rwp | 06:38 | |
| rwp | New to CAPEC? Start Here | 06:38 |
| rwp | Home > CAPEC List > CAPEC-149: Explore for Predictable Temporary File Names (Version 3.9) | 06:38 |
| rwp | ID Lookup: | 06:38 |
| rwp | Home | 06:38 |
| rwp | Search | 06:38 |
| rwp | 06:38 | |
| rwp | Oops. Sorry. irssi keybinding fail. | 06:38 |
| rwp | Anyway... Predictable file names. That means we have some program like Sendmail from 1985 or something which is definitely riddled with exploitable bugs. | 06:38 |
| rwp | Any program opening a temporary file should be using O_EXCL and if it doesn't then it's a bug. | 06:39 |
| rwp | And I was also going to complain that the CAPEC-149 uses such vague terms. Predictable file names. I really want to see a concrete example of a root priv program which is vulnerable to this problem. So that it can be patched and fixed. | 06:41 |
| fluffywolf | https://www.cvedetails.com/cve/CVE-2021-46705/ lol, even grub2 has bugs for insecure /tmp files... that one lets you use grub2 to clobber arbitrary files you link to... from 2022... | 06:43 |
| fluffywolf | it may be a bug, but it's a thing that continues to happen to this day, in major packages that run as root. | 06:43 |
| rwp | Ah... Good concrete example! The code for it is linked to here: https://bugzilla.suse.com/show_bug.cgi?id=1190474 | 06:44 |
| fluffywolf | not taking systemwide precautions is silly | 06:44 |
| rwp | That's definitely a pretty buggy bit of code there! Excellent example. | 06:45 |
| fluffywolf | the topic above is whether cron itself should take its own protections, or rely on systemwide protections. | 06:45 |
| rwp | For the lurkers the code is basically "> /var/tmp/grub2-cleanup-once" to create an empty file there. | 06:46 |
| fluffywolf | given as rrq managed to trip cron's protections accidentally, and there's bugs documented where you can DoS cron by hardlinking to crontabs ( like https://bugs.gentoo.org/164466 ), and that the same upstream is used on non-linux platforms, it seems reasonable that cron shouldn't just depend on the system. | 06:47 |
| rwp | I believe in the system wide protections. So I don't think cron /needs/ to take gratuitous precautions. | 06:47 |
| rwp | But cron by adding these gratuious checks opened itself up to the denial of service attack of that gentoo but 164466 which is that then if someone can ln then they can cause cron to decide to ignore the valid file. | 06:49 |
| fluffywolf | the bugs show that default installs on some distros have, at least in the past, allowed hardlinking to crontabs, and thus cron's internal protection may have been protecting systems. | 06:49 |
| fluffywolf | but if it didn't protect itself, you could, say, ln /var/tmp/grub2-cleanup-once /etc/crontab.... :P | 06:50 |
| rwp | Most laptop installs are all in one partition and before Linux added those restrictions to the system kernel back a few years ago it was possible to hardlink between etc and home in that case. | 06:50 |
| rwp | Agreed. But then the bug is in grub not cron. | 06:50 |
| rwp | And it requires everything in one partition. Something typical of laptops. Something not typical on multiuser server systems. | 06:51 |
| fluffywolf | it's a mental bug to assume that everyone else will avoid bugs... | 06:51 |
| rwp | If someone wants to shoot themself in the foot I say let them. It will be a good experience for them. | 06:51 |
| rwp | In any case Linux has been blocking this from happening for some time now. | 06:52 |
| rwp | I don't disable that protection but there is another protection that I think is totally bad and I do disable it. fs.protected_regular | 06:53 |
| fluffywolf | the cron upstream source is used *all over the place*, not just linux. | 06:53 |
| rwp | When set to 1 fs.protected_regular blocks open O_CREAT on files that we don't own in world writable sticky directories, unless they are owned by the owner of the directory. | 06:53 |
| rwp | That's a convoluted bit of logic but the hole is that it does not block O_APPEND or O_TRUNC or chmod. So root can still O_TRUNC and then O_APPEND and have no effect. | 06:54 |
| rwp | And of course root can chmod too bypassing the whole thing. And if root uses "cp" to copy to the file then cp has this same effect too and doesn't even notice. So the entire thing for fs.protected_regular is pretty silly. | 06:55 |
| rwp | It is one of the things I trip over routinely so I always disable fs.protected_regular. | 06:56 |
| fluffywolf | oh well, it's now irrelevant, as systemd has taken over cron's job. :P | 06:56 |
| rwp | There is that! | 06:56 |
| fluffywolf | supposedly debian (and everyone else's) cron is still based off the original 1992 source... | 06:57 |
| rwp | For Vixie Cron Paul Vixie has orphaned it twenty years ago and has not made any updated release since. All of the distros just coordinate patches upon it. | 06:58 |
| rwp | But it's a mature bit of code and has no need of significant changes. That doesn't mean people don't still dork with it though. | 06:58 |
| rwp | A few releases ago someone thought it was be a good idea if it complained if the cronjob did not exit 0. Well... Lots of cronjobs do not exit zero! It opened a flood of noise across the unix-verse! | 06:59 |
| rwp | That patch got reverted. Thankfully. | 06:59 |
| fluffywolf | all the bsds and macos use vixie cron too, apparently | 06:59 |
| rwp | And just recently in Unstable someone decided to make "crontab -l" produce random colors in the listing output. That was truly horride! | 06:59 |
| fluffywolf | it's reasonable for upstream not to assume linux... | 07:00 |
| rwp | Fortunately that color patch was reverted too. It was truly awful. | 07:00 |
| rwp | I find it really strange but yes the BSDs also use Vixie Cron too. Mostly because it provides /etc/cron.d/* and the original BSD cron did not. | 07:00 |
| rwp | System V cron provided for /var/spool/cron/crontabs for user individual crontabs and did not provide /etc/crontab (IIRC). | 07:00 |
| fluffywolf | I have absolutely no idea how macos handles /tmp. lol | 07:01 |
| rwp | BSD cron provided ONLY a /etc/crontab file and no user crontabs. | 07:01 |
| rwp | Vixie Cron provided both of those and also provided /etc/cron.d/* system level files too. And also things like @reboot and */2 and stuff. So it was just a nice set of features. So everyone picked it up. | 07:01 |
| rwp | Regarding Mac OS and /tmp it is a BSD kernel so BSD kernels assume a setgid bit setting on every directory. So that's a little odd. /tmp is group wheel so all files in /tmp are group wheel regardless of who created them. | 07:03 |
| mason | BSDish. It's Mach. | 07:03 |
| rwp | I believe it behaves the same with regard to directories though. And also /tmp and /var/tmp are 't' bit sticky too which enables those behaviors. | 07:03 |
| rwp | Speaking of different crons though doesn't Red Hat use one of the other crons? It's dcron(?) or something? Pretty sure they don't use vixie-cron there. | 07:05 |
| fluffywolf | https://www.cvedetails.com/cve/CVE-2020-8027/ openldap fixed tmpfile names... https://www.cvedetails.com/cve/CVE-2020-1733/ no idea what ansible is, but fixed /tmp directories with no checking... https://www.cvedetails.com/cve/CVE-2018-17955/ suse's yast, core of the system, fixed tmpfile names... https://www.cvedetails.com/cve/CVE-2018-6705/ mcafee, supposedly improving security, instead insecure tmpfiles... | 07:09 |
| fluffywolf | https://www.cvedetails.com/cve/CVE-2012-2666/ lol, golang creates insecure tmpfiles and then runs them as scripts... | 07:11 |
| fluffywolf | so, yeah, tmp issues are still a thing with a variety of software. | 07:11 |
| rwp | All of those predictable file names are bugs though. Regardless of whether hardlinks are allowed or not. They are fully exploitable without using hardlinks at all. | 07:13 |
| mason | fluffywolf: Funny thing, systemd provides PrivateTmp for this, but unlike what the name suggests, what it actually does is drop the whole process into a private filesystem namespace. | 07:13 |
| fluffywolf | looks like redhat uses "cronie" | 07:13 |
| rwp | OMG but RHEL takes forever to boot up and look to see what cron it is running! It took all of this time to do it. They are running cronie, which is actually a fork of vixie-cron it seems. | 07:14 |
| fluffywolf | and cronie is a fork of vixie | 07:14 |
| rwp | Looks like we were both digging into Red Hat at the same time. :-) | 07:16 |
| rwp | Basically systemd saw Unix and said, I love you! You are perfect! Now let me change every possible aspect of you! | 07:17 |
| rwp | I am sure though that systemd did something good. I am sure it did. | 07:17 |
| rwp | Don't rush me. Give me another few minutes. I am sure I can think of something. Eventually. | 07:18 |
| mason | rwp: There was something good I saw once. | 07:18 |
| mason | I'm forgetting what it was, but there was definitely something. | 07:18 |
| fluffywolf | could be different amounts of soil moisture, could be thickness of topsoil over clay, could be composition of the topsoil, could be a lack of organic matter due to having less growing on it in the past, could be compacted, could be replacement fill from other construction, could be over-farmed and depleted, could be salty or high/low ph, ... | 07:18 |
| fluffywolf | grr, wrong window | 07:18 |
| rwp | Ha! The other day I was sure someone was adding soil to my garden too. The plot thickens! :-) | 07:19 |
| * rwp I hear icecream calling to me... | 07:20 | |
| fluffywolf | someone in another channel was asking why things don't grow as well in one part of their yard, and I was pointing out it could be a whole lot of things. | 07:22 |
| rwp | All of this while I thought we were in -offtopic and just now realized it was otherwise. (oh well...) | 07:29 |
| fluffywolf | bbl, bedtime | 07:59 |
| brocashelm | need help with this error for 4.18: xfce4-power-manager: symbol lookup error: xfce4-power-manager: undefined symbol: up_client_get_devices2 | 10:04 |
| brocashelm | i have tried reinstalling the whole suite, and nothing | 10:05 |
| gnarface | missing some acpi dependency maybe? | 10:07 |
| brocashelm | hmm... acpi is already installed on the laptop; i upgraded it from ascii to beowulf to chimaera to daedalus | 10:09 |
| brocashelm | i wonder if the usb wifi thing is causing this, as it gets faulty and i switch different usb ports (works fine if on other laptops) | 10:09 |
| rrq | causing undefined symbol? | 10:12 |
| rrq | my google friend points at a missing UpClient ... whatever that means | 10:13 |
| gnarface | you did dist-upgrade not just upgrade right? | 10:15 |
| gnarface | in general on a stable release, undefined symbol errors usually are fundamentally related to version mismatches | 10:17 |
| gnarface | like missing or partially upgraded packages, or maybe release/distro mix+matching | 10:17 |
| brocashelm | i did both upgrade and dist-upgrade each time | 10:34 |
| brocashelm | aptitude full-upgrade has no leads | 10:36 |
| rrq | what about: apt list --installed | grep -v /stable | 10:38 |
| brocashelm | solved it by downgrading libupower-glib3 to 0.99.20-2 (from 1:0.99.4-4+devuan3) and reinstalling xfce4-power-manager | 10:44 |
| brocashelm | now it works | 10:44 |
| brocashelm | i think this was a bug from ascii (apt thinks that version is newer) for upower | 10:45 |
| brocashelm | thanks | 10:46 |
| gnarface | ah, yea probably | 10:57 |
| gnarface | no problem | 10:57 |
| arity | what to do? "locale: Cannot set LC_CTYPE to default locale: No such file or directory" | 11:03 |
| xwindows | What is a full output of your `locale` command? | 11:04 |
| xwindows | (This looks like a symptom of one specifying nonexistent or non-installed locale; so the locale string in question has to be known first) | 11:08 |
| arity | xwindows yes i uncommented locale.gen en_US.utf8 | 11:11 |
| arity | when i installed i installed different locales | 11:11 |
| arity | what is the proper way to change locales | 11:12 |
| brocashelm | sudo dpkg-reconfigure locales | 11:12 |
| arity | thanks brocashelm | 11:12 |
| brocashelm | np | 11:12 |
| arity | nice, i have problem with hdmi | 11:16 |
| arity | everything working fine | 11:16 |
| arity | wait brb | 11:16 |
| arity | when i plug in hdmi cable to port the display says no signal | 11:23 |
| arity | the laptop has optimus | 11:23 |
| arity | im on nvidia-driver | 11:23 |
| xwindows | Once it was plugged in, what does `xrandr --verbose` say? | 11:23 |
| arity | http://0x0.st/XqiG.txt | 11:23 |
| arity | wait i will post the output. the upper paste is lspci | 11:24 |
| arity | http://0x0.st/Xqik.txt | 11:25 |
| xwindows | "HDMI-1 disconnected", hm, you're sure about the cabling, right? | 11:26 |
| arity | xwindows yes | 11:26 |
| arity | when i dont plug in cable the monitor says | 11:26 |
| arity | "Check signal cable" but when i plug in the monitor goes blank and then says "No Signal" | 11:27 |
| arity | i think the Hdmi port is bad on the laptop | 11:27 |
| xwindows | Have you ever getting it working before? | 11:28 |
| arity | yes like a month back the with void | 11:28 |
| xwindows | And I saw both Intel card and Nvidia card on your `lspci` output; is this a mybrid graphics laptop? | 11:30 |
| arity | yes it is hybrid graphics | 11:30 |
| arity | optimus | 11:30 |
| arity | im using nvidia-driver | 11:31 |
| xwindows | I'm not familiar with Nvidia-Intel hybrid graphics setup, do they have an easy way to switch between Intel and Nvidia GPU? | 11:32 |
| arity | i understand,yes there is a way. i will see how to do it. | 11:33 |
| xwindows | You might have to wait for someone familar with Nvidia to answer. | 11:34 |
| xwindows | I asked that because I have read some "rumors" that such hybrid graphics configuration requires the Nvidia GPU to be the active one for HDMI to work. | 11:35 |
| xwindows | (Don't quote me, I don't know jack about Nvidia) | 11:36 |
| xwindows | But if you don't have an easy way to test, then it might be better if someone who knows would shime in. | 11:36 |
| arity | yes you are right. thats how i did it before by making the nvidia default. | 11:37 |
| xwindows | (Side note for anyone else reading, this is where I head about the existence of such "rumors": https://www.linux.org/threads/hdmi-not-working-with-nvidia-gtx1050-on-ubuntu-18-04.24833/ ) | 11:38 |
| gnarface | arity: i can think of a few different things that can cause this... cables can go bad, especially the knock-off ones... nvidia drivers fail a lot... but the first thing you should check is plug in the monitor and actually try to enable it with xrandr; it may just be off by default, which i think is also expected behavior unless your window manager takes over and does stuff | 15:03 |
| gnarface | if it's not configured to actually send display output to that hdmi port, then dpms would turn off the monitor and it would say no signal, that would also be expected | 15:05 |
| gnarface | but if you check the xrandr man page it should be fairly easy to do, actually i think nvidia-settings has a gui that can do the same thing it just puts configurations in a different place | 15:06 |
| systemdlete | christmas in June? I just looked at the changelog for the chimaera kernel updates--the list of fixes is almost endless!!! | 22:58 |
| systemdlete | is there a similar motherload coming down for daedalus? | 22:59 |
| rwp | I would expect that most of those have already been posted to Daedalus previously and Chimaera is catching up. | 23:05 |
| systemdlete | actually, upon closer inspection, it is giving me the history all the way back to 5.10.1!!! | 23:10 |
| systemdlete | so, nvm. But it looks like there is still quite a few updates | 23:10 |
| systemdlete | yeah, I thought so, rwp. Usually the older releases seem to get updated after the most current one, which makes sense. | 23:11 |
| systemdlete | Recently, I have started taking a closer look at updates/upgrades to see what they are all about. I never did that in the past, so I am learning how these changelogs are arranged as I go. | 23:11 |
| systemdlete | sorry for my foolish post here | 23:12 |
| rwp | More people should look into the changes as they are posted. | 23:12 |
| rwp | Some of those are of the OMG variety that we know must be fixed immediately if not sooner. | 23:12 |
| systemdlete | I think it was gnarface who suggested I do so. | 23:13 |
| rwp | Some of those are of the variety, wait... that's not a bug or a vulnerability. That's just someone messing with things. | 23:13 |
| systemdlete | I follow thehackernews.com a little bit, so I have some idea of what to expect. | 23:13 |
| systemdlete | "messing with things?" | 23:13 |
| systemdlete | like sifting in a malware bug or two here and there? | 23:14 |
| systemdlete | or more like, ooh ooh, I can re-wrte that to save 4 bytes. | 23:14 |
| * systemdlete hopes others will excuse their sardonic attitude | 23:15 | |
| rwp | People introduce "features" which I might call "thrash and churn". They are not features I need. I don't want them. But now they are there. And they introduce bugs. Bugs introduce vulnerabilities. But also there are bugs like "rm removed my file, that's a security vulnerabilty" but no it's not. | 23:15 |
| systemdlete | how much testing is done to these changes? (Or do I NOT want to know, save my mental health?) | 23:16 |
| systemdlete | or is T*st*ng a word I should not use in public here? | 23:17 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!