systemdlete | gnarface (or others): This makes little sense to me. But then again, I am still conquering iptables: https://pastebin.com/gaZLMUMF | 05:35 |
---|---|---|
systemdlete | It looks to me like some of the rules would never match. | 05:35 |
systemdlete | Hold on, here, with line numbering: https://pastebin.com/SCK4b2LH | 05:37 |
systemdlete | it looks like rule 1 would match before rule 8 or 9 | 05:37 |
systemdlete | and 4 would match before 11. | 05:38 |
systemdlete | etc. | 05:38 |
systemdlete | So I don't get the point to these rules. They were generated by CentOS 6's firewall program, by selecting eth1 and eth2 to be "trusted interfaces" (I get that part, btw) | 05:38 |
systemdlete | The other thing is, why is the default policy ACCEPT, but every rule that would match yields ACCEPT. Even if rule 11 fails, the packet is still accepted. | 05:39 |
systemdlete | Please explain what I am not getting. I've looked high and low for a thorough tutorial on iptables and got little that was any real use. | 05:40 |
systemdlete | This FORWARD chain does exactly what I wanted on CentOS (but why, idk), but it clearly does not work on ascii. | 05:40 |
systemdlete | (if anyone can recommend a well-written -- as in clear English -- doc on the web re: iptables, I would appreciate it) | 05:43 |
systemdlete | Now, if these rules worked in reverse (rule 11 first, rule 1 last), it might make a little more sense. But I'm pretty sure rule 1 is sought for a match, then 2, etc. | 05:44 |
systemdlete | I also note that not one of the rules has ever had a hit, per pkts column. Which means the FORWARD chain is not even being visited. (I did not check this on CentOS) | 05:45 |
systemdlete | I should probably ask this on the centos channel, but I'm kind of done there. They'll tell me to upgrade to CentOS-systemd 7 | 05:46 |
systemdlete | (no thanks) | 05:46 |
xrogaan | I don't understand the question al3xu5 posted on the mailing list. | 06:54 |
Evilham | systemdlete: may I recommend taking a look at nftables? :-D I find it easier to parse and debug, specially for the kind of things you seem to be doing | 10:12 |
systemdlete | That is a good idea, thank you. Yes, I've heard folks talking about nftables and how simple they are to work with. | 10:13 |
Evilham | systemdlete: in any case, rule 1 uses packet state, meaning it'll remember connections and let those through if they are related or established | 10:16 |
systemdlete | I shall look into them presently... | 10:16 |
Evilham | It's not accepting *any* packet | 10:16 |
Evilham | Oh, nvmd I see your point about 8 and 9 | 10:17 |
systemdlete | (thank you SOOO much for looking at this. It is boggling my mind) | 10:17 |
systemdlete | I've spent the last 2 days learning iptables, and today, I started looking at bridging. But that's for another day. | 10:17 |
Evilham | In total I may have spent many months of my life with those things XD | 10:18 |
Evilham | It's kinda frustrating and interesting at the same time | 10:18 |
systemdlete | The default policy as set up by the CentOS tool is ACCEPT. So, what is the point of all these rules being "ACCEPT" also? I'd think the default would be DROP in this case. | 10:18 |
systemdlete | but idk. I'm newb at this... | 10:19 |
systemdlete | and ty for confirming that for me. I thought it was just me. | 10:19 |
systemdlete | I'm smart enough I guess, but not too much so. | 10:19 |
Evilham | Ok, my guess is that since this is auto-generated, it's somewhat redundant | 10:20 |
systemdlete | only somewhat, huh? | 10:20 |
systemdlete | ok, given the scenario, which packets would NOT be accepted in processing FORWARD? | 10:20 |
systemdlete | (which is also weird, because from what I can tell, it never gets called. See the counters.) | 10:21 |
systemdlete | (sorry for sarcasm there) | 10:21 |
systemdlete | I can't think of a scenario which would result in a packet being DROPd or REJECTd | 10:24 |
systemdlete | At any rate, I thought maybe bridging the whole deal would be easier, but I ran into headaches with that approach also. | 10:24 |
Evilham | My brain iptables module is not too fresh, but yeap, it looks like it allows forwarding always | 10:24 |
systemdlete | thank you. | 10:25 |
Evilham | Unless there is another interface | 10:25 |
systemdlete | and, to boot, it appears it never gets called | 10:25 |
Evilham | Aka eth0, is that a thing? | 10:25 |
systemdlete | yes, in fact there are 4 all together | 10:26 |
Evilham | In that case, incoming packets from eth0 to any other interface shouldn't be forwarded | 10:26 |
Evilham | They should match the reject | 10:27 |
systemdlete | there is eth0, which is attached to the VM running the actual firewall (Ipfire), the vboxnet0 interface for the VM and other VMs, and 2 PHY ifaces for two sub nets that connect to other devices | 10:27 |
Evilham | It's a weird way to have it though | 10:27 |
systemdlete | you mean, the auto-gen'd rules? | 10:27 |
* enyc meows | 10:28 | |
* enyc hrrms, devuan box want rebooting and so on | 10:28 | |
Evilham | Yup, the rules could make it more explicit | 10:29 |
Evilham | Also: uncommented firewall rules are terrible :-D | 10:29 |
systemdlete | tbh, I am using ufw now to build a new set of rules and chains | 10:29 |
systemdlete | I didn't not comment them. That non-activity was someone else's fault. | 10:30 |
Evilham | One thing is to check intent marchea defjnition another one is to figure out intent and see if that makes sense and is actually doing what it should | 10:30 |
systemdlete | (just sayin) | 10:30 |
Evilham | Yeah, wasn't implying, just that it makes sense you are having a rough time with it | 10:30 |
systemdlete | I have no intention of going back to CentOS once I get Devuan full up and working for my needs. | 10:31 |
Evilham | These things do require time and effort :-) | 10:31 |
systemdlete | So that table is, at this point, kinda ... well, sort of done | 10:31 |
systemdlete | But it is nice that you confirmed I don't need to up my nightly dosage, and that I will probably live a few more years. | 10:32 |
Evilham | I hope you can manage soon :-). Do take a look at nftables, I bet you can rewrite those tables in a nicer way quicker than you would audit these iptables :-D | 10:32 |
systemdlete | I agree with you that learning this stuff is both fascinating and frustrating. Part of it is the lack of thorough, understandable docs. | 10:32 |
systemdlete | At least, that has always been my gripe. | 10:33 |
systemdlete | nftables. I'm looking at these now. | 10:33 |
systemdlete | on the debian wiki | 10:33 |
Evilham | (it's all secretly black magic and that's why nobody talks about networking) | 10:34 |
systemdlete | aha! | 10:34 |
systemdlete | I always thought so. :) | 10:34 |
systemdlete | new, intersting problem. I have multiple interfaces (3) on my PC. Each time I boot, there is a chance that | 15:07 |
systemdlete | these will be ordered differently, resulting in eth1 and eth2 being "swapped" -- how can I get rid of this problem? Are the rules files for persistence still valid with eudev? I was unable to find doc on this. | 15:08 |
systemdlete | again, tia | 15:08 |
systemdlete | I have swapped the cables umpteen times, and I am getting tired of that game. | 15:08 |
systemdlete | LOL | 15:08 |
fsmithred | systemdlete, if you add net.ifnames=1 to boot command, you'll get "predictable" names | 15:14 |
fsmithred | enpsxxxx and so on | 15:15 |
systemdlete | why can't good ol' ethX names be predictable too? | 15:15 |
* systemdlete asks somewhat rhetorically | 15:15 | |
fsmithred | I think you can do stuff in /etc/udev/rules.d/70-net... for that | 15:16 |
fsmithred | gotta go. bye | 15:16 |
systemdlete | yes, I am following the advice you gave another user in a post to the devuan forum | 15:16 |
systemdlete | thanks | 15:16 |
Evilham | Note that the "predictable" interface names are actually not predictable | 15:30 |
Evilham | The documentation will mention that very discretely | 15:30 |
fsmithred | I thought you could just open up the box and look inside to see where the network cards are plugged in. | 15:37 |
fsmithred | the predictable names actually work well for live-usb with persistence - when you go from one machine to another, the card gets the same name so you don't have to change it in wicd | 15:37 |
fsmithred | anyway, thunderstorms predicted for today, and I'm going out. Will shut down. | 15:38 |
systemdlete | could not read from '/sys/module/pcc_cpufreq/initstate | 16:15 |
systemdlete | came up during boot, as a one-off incident. I rebooted and did not see this again. It's been reported a few times already. | 16:15 |
systemdlete | just an FYI | 16:15 |
telmich | good morning | 16:55 |
telmich | In case you haven't seen it already, we just posted a list of distributions w/o sytemd: https://ungleich.ch/en-us/cms/blog/2019/05/20/linux-distros-without-systemd/ | 16:56 |
buZz | telmich: nice article | 17:38 |
jaromil | yep, retwitted immediately :) good job | 17:43 |
buZz | good idea ;) RT'd aswell | 17:45 |
slvr | telmich: You made it to the front page of hackernews. | 19:13 |
barrett9h | so, I'm getting some strange networking error. is this the place to ask for help? | 19:14 |
barrett9h | sometimes I can't access github.com, not even ping works. | 19:17 |
barrett9h | other sites works ok. | 19:17 |
barrett9h | I tried bootint from a usb stick (linuxmint), and it worked. back to my devuan system, and it doesn't. | 19:17 |
barrett9h | I haven't messed with anything about the networking configuration | 19:17 |
systemdlete | when I install the package "elog" it installs everything except the conf file for it. (/etc/elog.conf). When I do a dpkg -V elog, it confirms that it is the only file that did not install. | 19:25 |
systemdlete | I don't recall this problem a few days ago when I installed it originally. | 19:26 |
KatolaZ | barrett9h: do you have an ipv6 config? | 19:27 |
KatolaZ | (a half-working one could be enough) | 19:27 |
barrett9h | KatolaZ: not that I know of | 19:28 |
barrett9h | I just followed the Devuan installer, didn't messed with anything | 19:33 |
barrett9h | when I run `ifconfig`, it shows both ipv4 and ipv6 addresses | 19:35 |
systemdlete | So! Purging the removed package allows for a clean install (re-install). | 19:35 |
systemdlete | (/etc/elog.conf was already gone though. Maybe this is due to files under /var/lib/elog, which are created by the running elog system) | 19:36 |
Evilham | barrett9h: it may be a link-local address, doesn't mean you have ipv6 connectivity | 20:14 |
Evilham | you can e.g. curl -6 ifconfig.io | 20:15 |
Evilham | if that doesn't time out, you have ipv6 connectivity | 20:15 |
Evilham | and it'll show you your external ipv6 address | 20:15 |
Evilham | (well, your "not private" ipv6 address :-p those are global unicast) | 20:15 |
barrett9h | curl: (7) Couldn't connect to server | 20:16 |
Evilham | then you don't have ipv6 | 20:16 |
Evilham | it shouldn't have affected github.com though, as it is ipv4 only | 20:16 |
barrett9h | :-( | 20:16 |
Evilham | in any case: can you "make it happen"? | 20:17 |
barrett9h | make what happen? | 20:17 |
Evilham | the issue :-D | 20:18 |
Evilham | is it just random? | 20:18 |
barrett9h | it's random | 20:18 |
sixwheeledbeast | or use an online ipv6 test like https://ipv6-test.com/ | 20:18 |
slvr | Maybe it happens while a lease is being renewed... | 20:18 |
barrett9h | sometimes it works, most of the time it doesn't | 20:18 |
slvr | Could be a time synch issue too | 20:18 |
Evilham | or mtu :-D networking is black magic | 20:19 |
sixwheeledbeast | link-local would normally start with fe80 | 20:19 |
barrett9h | indeed | 20:19 |
barrett9h | I'll try to check the time sync issue | 20:20 |
Evilham | barrett9h: github.com has a TTL of 60 seconds, *maybe* it's just DNS | 20:21 |
Evilham | try testing your DNS servers | 20:21 |
sixwheeledbeast | https://www.whatsmydns.net/ maybe useful | 20:22 |
Evilham | not necessarily, that's useful to follow propagation, here it could be that one of the DNS servers on barrett9h's system is being buggy | 20:23 |
Evilham | and by having such a low TTL, they randomly see the effect | 20:23 |
barrett9h | but when I try to ping github, ping shows the numeric address. and it's the same address on the other machines of my network, and all of them can ping and connect to github | 20:25 |
barrett9h | and when I try to traceroute, it doesn't even reach my local gateway (the modem) | 20:27 |
slvr | ...ARP poison? | 20:28 |
slvr | do you have an ip conflict with another machine? | 20:29 |
barrett9h | don't think so | 20:29 |
* systemdlete there goes Evilham with more of that networking "black magic" ... lol | 20:29 | |
systemdlete | barrett9h: I just dealt with nearly 2 straight day of networking heck. I feel you brutha | 20:29 |
gnarface | traceroute and ping should be both using ICMP by default | 20:30 |
gnarface | maybe try traceroute -T | 20:30 |
gnarface | also tell us what ip github resolves to for you | 20:31 |
barrett9h | 192.30.253.113 | 20:31 |
gnarface | that's the same i'm getting here | 20:31 |
gnarface | so it's not DNS | 20:31 |
gnarface | ARP poisoning theoretically could be possible, but that doesn't explain traceroute and ping behaving differently. they both use ICMP so it would be weird for them to poison your ARP cache only to point it at a host with a busted firewall | 20:33 |
gnarface | so you can't rule out hardware failure, ISP incompetence, or the router getting hacked by someone who doesn't know WTF they're doing... | 20:34 |
gnarface | failing this way on purpose would seem to need deep packet inspection | 20:34 |
gnarface | try the traceroute -T | 20:34 |
barrett9h | I know it's on this system, because other machines on my network use the same ISP/router/DNS/etc, and are all working. And this machine works too, when I boot from a usb stick | 20:35 |
barrett9h | so it's not hardware either | 20:35 |
gnarface | might it be your own firewall? | 20:36 |
gnarface | are you selectively filtering only some ICMP messages, but not others? you might be selecting the wrong ones accidentally... | 20:36 |
barrett9h | I grepped /etc, no mention of github | 20:36 |
barrett9h | I never messed with networking configuration (I don't even know how), just followed the installer | 20:37 |
gnarface | weird | 20:37 |
barrett9h | yep | 20:37 |
barrett9h | maybe I'll just reinstall the system :-( | 20:37 |
gnarface | i doubt that would help | 20:37 |
systemdlete | Evilham, gnarface: Thanks for all the hard work you guys did helping me. In the end, it was just a matter of tossing those CentOS fw rules that didn't make any sense anyway. I used gufw to generate a new set, and it is working just fine. | 20:37 |
gnarface | systemdlete: glad to hear it | 20:38 |
gnarface | barrett9h: buggy ethernet driver perhaps? got your upgrades and firmware? | 20:39 |
systemdlete | and, I found I needed to be very specific with the ordering of my (multiple) interfaces, so upon fsmithred's suggestion (thanks to you also!) in a post on the devuan forum, I created a persistence rules file that specified each interface by MAC address. That seems to have worked, but only tine will tell. I find that the ordering (using the ethX approach) is inconsistent from boot to boot). | 20:40 |
Evilham | systemdlete: too bad you didn't jump to nftables :-p | 20:44 |
Evilham | gnarface: maybe tcpdump could help barrett9h? | 20:44 |
systemdlete | Oh, no. I intend to learn them. I just needed something to just work until that day. | 20:44 |
Evilham | I can't really help with that now, but it's an idea :-) | 20:44 |
gnarface | barrett9h: depending on exactly how you did the install, and which image you installed from, you could have outdated software on there still if you didn't correct your sources.list and re-run the updates | 20:45 |
systemdlete | nah, nw. I have already started reading nftables. | 20:45 |
systemdlete | Once i get through the whole shebang, I'll try them out on my hyperbola partition first, since it needs some kind of packet forwarding, and a chance to see how it works without corrupting my Devuan which does work, despite the iptables issues. | 20:46 |
barrett9h | ascii, with backports security and updates. all up-to-date | 20:47 |
systemdlete | yep | 20:47 |
systemdlete | none other. | 20:47 |
systemdlete | oh | 20:47 |
systemdlete | nvm | 20:47 |
* systemdlete always talking to himself, even in public. Really needs to take his pill. | 20:48 | |
gnarface | barrett9h: and it's the same problem whether you ping or traceroute by IP, or is it just happening with DNS names? | 20:52 |
barrett9h | the same | 20:52 |
barrett9h | traceroute to 192.30.253.112 (192.30.253.112), 30 hops max, 60 byte packets | 20:53 |
barrett9h | 1 bambu.lan (192.168.1.114) 3053.270 ms !H 3053.253 ms !H 3053.249 ms !H | 20:53 |
gnarface | uh | 20:54 |
gnarface | what is bambu.lan ? | 20:54 |
barrett9h | ping gives this: From 192.168.1.114 icmp_seq=1 Destination Host Unreachable | 20:54 |
gnarface | something is going wrong with that host badly if it's taking 3 seconds to respond to a ping | 20:54 |
barrett9h | it's my machine | 20:54 |
barrett9h | .1.114 is my local ip | 20:55 |
gnarface | 3053 ms is not right | 20:55 |
gnarface | what ethernet device is that? | 20:55 |
gnarface | you can't even ping yourself | 20:56 |
systemdlete | is this multiple ifaces by any chance? | 20:56 |
barrett9h | RTL-8100/8101L/8139 PCI Fast Ethernet Adapter | 20:56 |
gnarface | something has gone severely wrong | 20:57 |
barrett9h | I can ping myself, the gateway, google, anything. just not github | 20:57 |
systemdlete | if it is, then barrett9h might have the same issue I did. | 20:57 |
systemdlete | if so, maybe i can help | 20:57 |
gnarface | barrett9h: the traceroute you just pasted showed it taking 3 seconds just to find itself. that shouldn't ever happen. | 20:58 |
gnarface | barrett9h: what if you ping 192.168.1.114 directly? i thought that was what the pasted ping error represtented | 20:59 |
gnarface | *represented | 20:59 |
barrett9h | when I traceroute ipconfig.io, it takes 138ms to finish all the tracerouting | 20:59 |
barrett9h | nope, when I ping github.com, it says "From 192.168.1.114 icmp_seq=1 Destination Host Unreachable" | 20:59 |
gnarface | yea, now ping that ip too | 21:00 |
gnarface | ping 192.168.1.114 | 21:00 |
barrett9h | it works | 21:00 |
gnarface | how long does it take to respond? | 21:00 |
barrett9h | 0.02 | 21:00 |
barrett9h | ms | 21:00 |
gnarface | oh github's ip looks like a private ip, i got confused | 21:00 |
gnarface | something still wrong at your first hop though somehow | 21:01 |
barrett9h | yep, it's weird starting with 192. | 21:01 |
gnarface | does dmesg complain about missing firmware at boot up? | 21:01 |
buZz | inging that ip works fine on my ascii install | 21:02 |
buZz | pinging* | 21:02 |
barrett9h | acpi PNP0A03:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-7f] only partially covers this bridge ??? | 21:02 |
gnarface | hmmm, looks weird | 21:03 |
gnarface | google says that's about the video card though | 21:05 |
barrett9h | oh | 21:05 |
barrett9h | it's so weird that all other sites works ok, only github fails | 21:06 |
barrett9h | (at least all I have tried) | 21:06 |
barrett9h | guess I'll just scp the code to other machine, and git push from there. can't waste time with this, lot of work to do.. | 21:07 |
barrett9h | thanks you all, anyway | 21:08 |
gnarface | let us know if you find anything new out | 21:08 |
gnarface | i guess i wouldn't put it beyond nouveau to be causing this somehow | 21:08 |
gnarface | but it would be weird | 21:08 |
gnarface | it could be something you got from backports too | 21:08 |
barrett9h | I added backports just yesterday, and I'm having this issue for quite some time now | 21:09 |
barrett9h | always assumed it was with the ISP, or github itself. just now realized it's something wrong on my setup | 21:10 |
Evilham | gnarface: that ping said *from*, so it's not resolving github to a local address, that's barrett9h's local IP :-) | 21:14 |
gnarface | Evilham: no i just literally hallucinated that first paste of traceroute output as saying "traceroute to 192.168.1.114..." until i'd re-read it a few times | 21:17 |
gnarface | obviously it still takes too long though | 21:18 |
Evilham | I'm seeing .1.114 is bambu.lan,not guthub.com | 21:18 |
Evilham | On the traceroute paste | 21:18 |
gnarface | yea. but obviously 3s is still too long for that to take, so if a live usb stick confirms it's not physical hardware failure, there's not many possibilities left except a kernel bug | 21:19 |
gnarface | kernel or driver | 21:19 |
gnarface | or maybe a firewall misconfiguration like systemdlete suggested | 21:19 |
gnarface | either way really weird that it's only affecting github too | 21:20 |
systemdlete | does barrett9h have multiple interfaces? | 21:20 |
Evilham | Yup :-D it could be sth silly | 21:20 |
barrett9h | yep | 21:20 |
systemdlete | ah! | 21:20 |
Evilham | Like: github.com's IP does happen to be 192.30.253.112 | 21:20 |
systemdlete | it's possible you have the same issue I had, but I am not certain. | 21:20 |
KatolaZ | barrett9h: who is 192.168.1.114? | 21:20 |
barrett9h | there's the onboard eth, that I don't use | 21:20 |
KatolaZ | is it your router? | 21:20 |
systemdlete | your interfaces are named like "eth0" "eth1" etc? | 21:20 |
KatolaZ | bbl | 21:21 |
gnarface | KatolaZ: that's him. his local ip itself | 21:21 |
Evilham | Maybe someone was clever and said 192.X.X.X is local | 21:21 |
barrett9h | ifconfig shows just eth0 | 21:21 |
Evilham | Which, is kot true | 21:21 |
systemdlete | ok | 21:21 |
barrett9h | I think the onboard one is disabled | 21:21 |
systemdlete | what if you do ifconfig -a? | 21:21 |
Evilham | So, go check that firewall | 21:21 |
barrett9h | just eth0 and lo | 21:21 |
systemdlete | or better yet, ip addr | 21:21 |
barrett9h | 1: lo 2: eth0 | 21:22 |
systemdlete | so it sounds like just one PHY interface | 21:22 |
Evilham | (and the subnet) | 21:22 |
systemdlete | "lo" is not a physical device though. | 21:22 |
gnarface | if there is a bios-disabled ethernet device it won't be in the way, but if it's only disabled in the system configuration, it will still show up in the output of "ifconfig -a" | 21:23 |
systemdlete | so nvm me then. | 21:23 |
systemdlete | wouldn't ip addr show all the phy devices? | 21:23 |
systemdlete | regardless of their disposition? | 21:23 |
gnarface | maybe, i'm not sure | 21:23 |
systemdlete | hmmm. no, maybe not. | 21:24 |
gnarface | but i do think that if it is unconfigured and present without an IP address, it could be causing routing complications if it has a working physical link to another machine on the LAN | 21:24 |
systemdlete | I seem to recall phy devs going away, maybe with ifdown | 21:24 |
systemdlete | with me, what was happening is that eth1 and eth2 were "swapping" on boot... SOMETIMES | 21:25 |
systemdlete | which is what got me to thinking that maybe this was similar. | 21:25 |
gnarface | that forum entry i found about the firmware error being about nouveau though, suggested it could be causing registry corruptions that mimic bad RAM behavior (system instability, lockups, crashes, random segfaults, even weirder stuff... etc) | 21:25 |
systemdlete | ooh. | 21:26 |
systemdlete | Glad my issue was not that tough. | 21:26 |
gnarface | this would be a new one for me to see nouveau doing, but i've seen it do some weird stuff so it would be believable | 21:26 |
gnarface | CPU registry corruptions , to be clear | 21:27 |
gnarface | register i mean i guess | 21:27 |
systemdlete | did you see that one error I posted from a recent boot. A one-off'er | 21:27 |
systemdlete | haven't seen it again | 21:27 |
systemdlete | or before | 21:27 |
gnarface | i'm not sure i did | 21:27 |
systemdlete | could not read from '/sys/module/pcc_cpufreq/initstate | 21:28 |
systemdlete | does that fall under that category you referred to just then? | 21:29 |
gnarface | hmmm. maybe | 21:29 |
gnarface | if it's intermittent i could only speculate that's some sort of race condition error at boot up time | 21:29 |
systemdlete | it's an ASUS M5A7L USB3/M | 21:29 |
systemdlete | but I don't see any notices about missing firmware, drivers, etc | 21:31 |
gnarface | cpufreq is the part that handles changing CPU power states | 21:32 |
systemdlete | that ladder biz? | 21:32 |
systemdlete | ladder and governor I think I recall | 21:32 |
systemdlete | I had a board a way back that would toggle power, and you could watch these 4 blue LEDs inside the case changing with the phase and all | 21:33 |
systemdlete | so I got curious and started reading about the board and what all this has to do with the kernel | 21:33 |
gnarface | grep -ni '.' /sys/devices/system/cpu/cpu0/cpufreq/* | 21:34 |
gnarface | yes, governors | 21:34 |
systemdlete | but it's all a blur now. I think the last time I was looking at it was maybe 10 years ago. | 21:34 |
gnarface | speed/powermanagement | 21:34 |
* systemdlete nods | 21:34 | |
gnarface | the real trick would be to figure out if on the boots where it complains about /sys/module/pcc_cpufreq/initstate anything else goes missing, functionality-wise, or if it manages to populate that and read from it fine moments later | 21:35 |
systemdlete | possibly. In my haste to get this box fixed (the problems I mentioned earlier), I didn't really want to go down that rabbit hole also. | 21:36 |
systemdlete | But I still have the dmesg file; it was only 2 boots back I think. | 21:37 |
systemdlete | Please don't laugh. I do not mean to insinuate anything, but the main power button on this case is broken. | 21:38 |
systemdlete | It's a blue (and black) Centurion (model 5 I think) and I love it. | 21:38 |
systemdlete | I haven't seen anything like it recently at Fry's | 21:39 |
systemdlete | But,sadly, the power button has broken off. I don't know why; I rarely use it! Mainly when I move, and occasionally for maintenance, cleaning, etc. | 21:40 |
systemdlete | I see a message for radeon power management initialized, but not for cpu | 21:43 |
gnarface | you can check the contents of this file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor | 21:44 |
systemdlete | "ondemand" it says | 21:45 |
systemdlete | but, of course, we are mixing up boots here. | 21:45 |
gnarface | ondemand suggests that power management is enabled | 21:46 |
systemdlete | the dmesg file with that error was from the boot before the current one I am in now. So I am not sure it is relevant | 21:46 |
gnarface | you have acpid installed and running, right? | 21:46 |
systemdlete | no. | 21:47 |
* systemdlete ducks | 21:47 | |
gnarface | really? | 21:47 |
gnarface | hmm, you probably want that | 21:47 |
gnarface | the core of the power management daemon | 21:48 |
gnarface | well it IS the power management daemon | 21:48 |
gnarface | one of the parts that systemd absorbed | 21:48 |
systemdlete | installing now... | 21:48 |
gnarface | if you're missing that you were probably missing lm-sensors too, which you'll no doubt want | 21:49 |
slvr | gnarface: reading the power management code as it was and the new code was pretty eye-popping... | 21:49 |
systemdlete | oh yes. Good old lm-sensors | 21:49 |
gnarface | slvr: i believe you, though i haven't really looked into either at that level of detail | 21:50 |
slvr | I was like, uh, you ported bash to C? That's like... dangerous... man.... | 21:50 |
systemdlete | lm-sensors was installed with the system I think, or as a dependency of something else | 21:50 |
gnarface | systemdlete: possible, but it was another one of the core system components that systemd absorbed then deprecated | 21:51 |
systemdlete | that thing is like one of those creatures depicted in 1950's B movies where the monster comes and eats people and keeps getting bigger | 21:51 |
systemdlete | the quality is about as good as one of those movies too | 21:54 |
gnarface | heh, yea i think that's the literal business strategy | 21:55 |
systemdlete | no one part of it gets totally completed before 5 more parts are rolled out, without fanfare, just thrust upon all | 21:56 |
slvr | NIH in full force | 21:56 |
systemdlete | ok, thanks again gnarface. acpid now up and running. My utility company will thank you, as will I next time I see the bill. | 21:57 |
systemdlete | I leave this guy up 24x7 pretty much. | 21:58 |
systemdlete | It's been rebooted and on and off again over the past few days while I struggled to get Alpine, then Hyperbola, and finaly Deuvuan installed and config'd | 21:58 |
systemdlete | but usually I leave it up all the time. | 21:58 |
systemdlete | (prob time to skip over to the fork channel) | 21:59 |
gnarface | systemdlete: no problem. on the odd chance acpid or lm-sensors cause stability issues, they are both easy to disable. but in a fair world they provide useful powermanagement features | 22:03 |
gnarface | (they just sometimes also expose very unfortunate BIOS bugs) | 22:04 |
eyalroz | I hope I don't get flamed for this, but here goes: | 23:28 |
eyalroz | Devuan 2 was released a year ago; Debian Stretch was released 2 years ago, with a GCC version from 3 years ago. Debian buster is now in full freeze. | 23:28 |
eyalroz | What are the chances of us seeing a buster-based, "testing"-like release of Devuan 3 ? | 23:28 |
eyalroz | (I mean, over the next few months) | 23:29 |
gnarface | devuan beowulf is already in the repos | 23:31 |
gnarface | you can upgrade to it at your own risk | 23:31 |
gnarface | if you only need it for gcc though, it might be a better idea to install it into a chroot | 23:32 |
eyalroz | gnarface: I was only using GCC as an example, I sometimes use my own home-baked gcc 8.2 for C++17 stuff. | 23:34 |
eyalroz | gnarface: So let me rephrase my question. How "at your own risk" are we talking here? Is it undergoing a process similar to buster's (other than through what buster is undergoing)? | 23:35 |
eyalroz | gnarface: Also, how do I like my odds for apt-get dist-upgrade'ing from ascii to beowulf? | 23:38 |
gnarface | you'll have to talk to someone here who has tried it | 23:40 |
gnarface | there are known complications but people have succeeded at it | 23:40 |
gnarface | the process shouldn't be fundamentally different from upgrading to debian testing | 23:40 |
Xenguy | .oO( Here there be dragons ? ) | 23:40 |
fsmithred | eyalroz, I've done a few upgrades from ascii to beowulf, and they were pretty easy | 23:47 |
fsmithred | you may run into some desktop things that don't work quite right | 23:47 |
fsmithred | maybe some other stuff here and there | 23:47 |
fsmithred | but mostly it's fine | 23:48 |
eyalroz | fsmithred: I'm running into many desktop things that don't work right , already before the upgrade so I'm not deterred :-) | 23:48 |
fsmithred | lol | 23:48 |
eyalroz | I guess I'll probably back up my home folder and try it at some point | 23:49 |
fsmithred | I did have trouble with encrypted lvm - that was a couple months ago | 23:49 |
fsmithred | need to try it again | 23:49 |
fsmithred | If I remember correctly, lvm is always a little flaky in testing | 23:50 |
eyalroz | fsmithred: Ok, that's good to know. | 23:51 |
fsmithred | and if you have uefi, watch out for the grub-signed package | 23:52 |
fsmithred | if so, and you find that you can't boot, either get into the system in a chroot and install the unsigned package, or else just rename EFI/devuan to EFI/debian. | 23:53 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!