libera/#devuan/ Monday, 2019-05-20

systemdletegnarface (or others):  This makes little sense to me.  But then again, I am still conquering iptables: https://pastebin.com/gaZLMUMF05:35
systemdleteIt looks to me like some of the rules would never match.05:35
systemdleteHold on, here, with line numbering: https://pastebin.com/SCK4b2LH05:37
systemdleteit looks like rule 1 would match before rule 8 or 905:37
systemdleteand 4 would match before 11.05:38
systemdleteetc.05:38
systemdleteSo 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
systemdleteThe 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
systemdletePlease 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
systemdleteThis 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
systemdleteNow, 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
systemdleteI 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
systemdleteI should probably ask this on the centos channel, but I'm kind of done there.  They'll tell me to upgrade to CentOS-systemd 705:46
systemdlete(no thanks)05:46
xrogaanI don't understand the question al3xu5 posted on the mailing list.06:54
Evilhamsystemdlete: 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 doing10:12
systemdleteThat is a good idea, thank you.  Yes, I've heard folks talking about nftables and how simple they are to work with.10:13
Evilhamsystemdlete: in any case, rule 1 uses packet state, meaning it'll remember connections and let those through if they are related or established10:16
systemdleteI shall look into them presently...10:16
EvilhamIt's not accepting *any* packet10:16
EvilhamOh, nvmd I see your point about 8 and 910:17
systemdlete(thank you SOOO much for looking at this.  It is boggling my mind)10:17
systemdleteI've spent the last 2 days learning iptables, and today, I started looking at bridging.  But that's for another day.10:17
EvilhamIn total I may have spent many months of my life with those things XD10:18
EvilhamIt's kinda frustrating and interesting at the same time10:18
systemdleteThe 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
systemdletebut idk.  I'm newb at this...10:19
systemdleteand ty for confirming that for me.  I thought it was just me.10:19
systemdleteI'm smart enough I guess, but not too much so.10:19
EvilhamOk, my guess is that since this is auto-generated, it's somewhat redundant10:20
systemdleteonly somewhat, huh?10:20
systemdleteok, 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
systemdleteI can't think of a scenario which would result in a packet being DROPd or REJECTd10:24
systemdleteAt any rate, I thought maybe bridging the whole deal would be easier, but I ran into headaches with that approach also.10:24
EvilhamMy brain iptables module is not too fresh, but yeap, it looks like it allows forwarding always10:24
systemdletethank you.10:25
EvilhamUnless there is another interface10:25
systemdleteand, to boot, it appears it never gets called10:25
EvilhamAka eth0, is that a thing?10:25
systemdleteyes, in fact there are 4 all together10:26
EvilhamIn that case, incoming packets from eth0 to any other interface shouldn't be forwarded10:26
EvilhamThey should match the reject10:27
systemdletethere 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 devices10:27
EvilhamIt's a weird way to have it though10:27
systemdleteyou mean, the auto-gen'd rules?10:27
* enyc meows10:28
* enyc hrrms, devuan box want rebooting and so on10:28
EvilhamYup, the rules could make it more explicit10:29
EvilhamAlso: uncommented firewall rules are terrible :-D10:29
systemdletetbh, I am using ufw now to build a new set of rules and chains10:29
systemdleteI didn't not comment them.  That non-activity was someone else's fault.10:30
EvilhamOne 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 should10:30
systemdlete(just sayin)10:30
EvilhamYeah, wasn't implying, just that it makes sense you are having a rough time with it10:30
systemdleteI have no intention of going back to CentOS once I get Devuan full up and working for my needs.10:31
EvilhamThese things do require time and effort :-)10:31
systemdleteSo that table is, at this point, kinda ... well, sort of done10:31
systemdleteBut 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
EvilhamI 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 :-D10:32
systemdleteI agree with you that learning this stuff is both fascinating and frustrating.  Part of it is the lack of thorough, understandable docs.10:32
systemdleteAt least, that has always been my gripe.10:33
systemdletenftables.   I'm looking at these now.10:33
systemdleteon the debian wiki10:33
Evilham(it's all secretly black magic and that's why nobody talks about networking)10:34
systemdleteaha!10:34
systemdleteI always thought so.   :)10:34
systemdletenew, intersting problem.  I have multiple interfaces (3) on my PC.  Each time I boot, there is a chance that15:07
systemdletethese 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
systemdleteagain, tia15:08
systemdleteI have swapped the cables umpteen times, and I am getting tired of that game.15:08
systemdleteLOL15:08
fsmithredsystemdlete, if you add net.ifnames=1 to boot command, you'll get "predictable" names15:14
fsmithredenpsxxxx and so on15:15
systemdletewhy can't good ol' ethX names be predictable too?15:15
* systemdlete asks somewhat rhetorically15:15
fsmithredI think you can do stuff in /etc/udev/rules.d/70-net... for that15:16
fsmithredgotta go. bye15:16
systemdleteyes, I am following the advice you gave another user in a post to the devuan forum15:16
systemdletethanks15:16
EvilhamNote that the "predictable" interface names are actually not predictable15:30
EvilhamThe documentation will mention that very discretely15:30
fsmithredI thought you could just open up the box and look inside to see where the network cards are plugged in.15:37
fsmithredthe 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 wicd15:37
fsmithredanyway, thunderstorms predicted for today, and I'm going out. Will shut down.15:38
systemdletecould not read from '/sys/module/pcc_cpufreq/initstate16:15
systemdletecame 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
systemdletejust an FYI16:15
telmichgood morning16:55
telmichIn 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
buZztelmich: nice article17:38
jaromilyep, retwitted immediately :) good job17:43
buZzgood idea ;) RT'd aswell17:45
slvrtelmich: You made it to the front page of hackernews.19:13
barrett9hso, I'm getting some strange networking error. is this the place to ask for help?19:14
barrett9hsometimes I can't access github.com, not even ping works.19:17
barrett9hother sites works ok.19:17
barrett9hI tried bootint from a usb stick (linuxmint), and it worked. back to my devuan system, and it doesn't.19:17
barrett9hI haven't messed with anything about the networking configuration19:17
systemdletewhen 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
systemdleteI don't recall this problem a few days ago when I installed it originally.19:26
KatolaZbarrett9h: do you have an ipv6 config?19:27
KatolaZ(a half-working one could be enough)19:27
barrett9hKatolaZ: not that I know of19:28
barrett9hI just followed the Devuan installer, didn't messed with anything19:33
barrett9hwhen I run `ifconfig`, it shows both ipv4 and ipv6 addresses19:35
systemdleteSo!  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
Evilhambarrett9h: it may be a link-local address, doesn't mean you have ipv6 connectivity20:14
Evilhamyou can e.g. curl -6 ifconfig.io20:15
Evilhamif that doesn't time out, you have ipv6 connectivity20:15
Evilhamand it'll show you your external ipv6 address20:15
Evilham(well, your "not private" ipv6 address :-p those are global unicast)20:15
barrett9hcurl: (7) Couldn't connect to server20:16
Evilhamthen you don't have ipv620:16
Evilhamit shouldn't have affected github.com though, as it is ipv4 only20:16
barrett9h:-(20:16
Evilhamin any case: can you "make it happen"?20:17
barrett9hmake what happen?20:17
Evilhamthe issue :-D20:18
Evilhamis it just random?20:18
barrett9hit's random20:18
sixwheeledbeastor use an online ipv6 test like https://ipv6-test.com/20:18
slvrMaybe it happens while a lease is being renewed...20:18
barrett9hsometimes it works, most of the time it doesn't20:18
slvrCould be a time synch issue too20:18
Evilhamor mtu :-D networking is black magic20:19
sixwheeledbeastlink-local would normally start with fe8020:19
barrett9hindeed20:19
barrett9hI'll try to check the time sync issue20:20
Evilhambarrett9h: github.com has a TTL of 60 seconds, *maybe* it's just DNS20:21
Evilhamtry testing your DNS servers20:21
sixwheeledbeasthttps://www.whatsmydns.net/ maybe useful20:22
Evilhamnot necessarily, that's useful to follow propagation, here it could be that one of the DNS servers on barrett9h's system is being buggy20:23
Evilhamand by having such a low TTL, they randomly see the effect20:23
barrett9hbut 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 github20:25
barrett9hand when I try to traceroute, it doesn't even reach my local gateway (the modem)20:27
slvr...ARP poison?20:28
slvrdo you have an ip conflict with another machine?20:29
barrett9hdon't think so20:29
* systemdlete there goes Evilham with more of that networking "black magic" ... lol20:29
systemdletebarrett9h: I just dealt with nearly 2 straight day of networking heck.  I feel you brutha20:29
gnarfacetraceroute and ping should be both using ICMP by default20:30
gnarfacemaybe try traceroute -T20:30
gnarfacealso tell us what ip github resolves to for you20:31
barrett9h192.30.253.11320:31
gnarfacethat's the same i'm getting here20:31
gnarfaceso it's not DNS20:31
gnarfaceARP 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 firewall20:33
gnarfaceso 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
gnarfacefailing this way on purpose would seem to need deep packet inspection20:34
gnarfacetry the traceroute -T20:34
barrett9hI 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 stick20:35
barrett9hso it's not hardware either20:35
gnarfacemight it be your own firewall?20:36
gnarfaceare you selectively filtering only some ICMP messages, but not others?  you might be selecting the wrong ones accidentally...20:36
barrett9hI grepped /etc, no mention of github20:36
barrett9hI never messed with networking configuration (I don't even know how), just followed the installer20:37
gnarfaceweird20:37
barrett9hyep20:37
barrett9hmaybe I'll just reinstall the system :-(20:37
gnarfacei doubt that would help20:37
systemdleteEvilham, 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
gnarfacesystemdlete: glad to hear it20:38
gnarfacebarrett9h: buggy ethernet driver perhaps?   got your upgrades and firmware?20:39
systemdleteand, 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
Evilhamsystemdlete: too bad you didn't jump to nftables :-p20:44
Evilhamgnarface: maybe tcpdump could help barrett9h?20:44
systemdleteOh, no.  I intend to learn them.  I just needed something to just work until that day.20:44
EvilhamI can't really help with that now, but it's an idea :-)20:44
gnarfacebarrett9h: 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 updates20:45
systemdletenah, nw.  I have already started reading nftables.20:45
systemdleteOnce 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
barrett9hascii, with backports security and updates.  all up-to-date20:47
systemdleteyep20:47
systemdletenone other.20:47
systemdleteoh20:47
systemdletenvm20:47
* systemdlete always talking to himself, even in public. Really needs to take his pill.20:48
gnarfacebarrett9h: and it's the same problem whether you ping or traceroute by IP, or is it just happening with DNS names?20:52
barrett9hthe same20:52
barrett9htraceroute to 192.30.253.112 (192.30.253.112), 30 hops max, 60 byte packets20:53
barrett9h 1  bambu.lan (192.168.1.114)  3053.270 ms !H  3053.253 ms !H  3053.249 ms !H20:53
gnarfaceuh20:54
gnarfacewhat is bambu.lan ?20:54
barrett9hping gives this: From 192.168.1.114 icmp_seq=1 Destination Host Unreachable20:54
gnarfacesomething is going wrong with that host badly if it's taking 3 seconds to respond to a ping20:54
barrett9hit's my machine20:54
barrett9h.1.114 is my local ip20:55
gnarface3053 ms is not right20:55
gnarfacewhat ethernet device is that?20:55
gnarfaceyou can't even ping yourself20:56
systemdleteis this multiple ifaces by any chance?20:56
barrett9hRTL-8100/8101L/8139 PCI Fast Ethernet Adapter20:56
gnarfacesomething has gone severely wrong20:57
barrett9hI can ping myself, the gateway, google, anything. just not github20:57
systemdleteif it is, then barrett9h might have the same issue I did.20:57
systemdleteif so, maybe i can help20:57
gnarfacebarrett9h: the traceroute you just pasted showed it taking 3 seconds just to find itself.  that shouldn't ever happen.20:58
gnarfacebarrett9h: what if you ping 192.168.1.114 directly?  i thought that was what the pasted ping error represtented20:59
gnarface*represented20:59
barrett9hwhen I traceroute ipconfig.io, it takes 138ms to finish all the tracerouting20:59
barrett9hnope, when I ping github.com, it says "From 192.168.1.114 icmp_seq=1 Destination Host Unreachable"20:59
gnarfaceyea, now ping that ip too21:00
gnarfaceping 192.168.1.11421:00
barrett9hit works21:00
gnarfacehow long does it take to respond?21:00
barrett9h0.0221:00
barrett9hms21:00
gnarfaceoh github's ip looks like a private ip, i got confused21:00
gnarfacesomething still wrong at your first hop though somehow21:01
barrett9hyep, it's weird starting with 192.21:01
gnarfacedoes dmesg complain about missing firmware at boot up?21:01
buZzinging that ip works fine on my ascii install21:02
buZzpinging*21:02
barrett9hacpi PNP0A03:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-7f] only partially covers this bridge  ???21:02
gnarfacehmmm, looks weird21:03
gnarfacegoogle says that's about the video card though21:05
barrett9hoh21:05
barrett9hit's so weird that all other sites works ok, only github fails21:06
barrett9h(at least all I have tried)21:06
barrett9hguess 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
barrett9hthanks you all, anyway21:08
gnarfacelet us know if you find anything new out21:08
gnarfacei guess i wouldn't put it beyond nouveau to be causing this somehow21:08
gnarfacebut it would be weird21:08
gnarfaceit could be something you got from backports too21:08
barrett9hI added backports just yesterday, and I'm having this issue for quite some time now21:09
barrett9halways assumed it was with the ISP, or github itself. just now realized it's something wrong on my setup21:10
Evilhamgnarface: that ping said *from*, so it's not resolving github to a local address, that's barrett9h's local IP :-)21:14
gnarfaceEvilham: 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 times21:17
gnarfaceobviously it still takes too long though21:18
EvilhamI'm seeing .1.114 is bambu.lan,not guthub.com21:18
EvilhamOn the traceroute paste21:18
gnarfaceyea.  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 bug21:19
gnarfacekernel or driver21:19
gnarfaceor maybe a firewall misconfiguration like systemdlete suggested21:19
gnarfaceeither way really weird that it's only affecting github too21:20
systemdletedoes barrett9h have multiple interfaces?21:20
EvilhamYup :-D it could be sth silly21:20
barrett9hyep21:20
systemdleteah!21:20
EvilhamLike: github.com's IP does happen to be 192.30.253.11221:20
systemdleteit's possible you have the same issue I had, but I am not certain.21:20
KatolaZbarrett9h: who is 192.168.1.114?21:20
barrett9hthere's the onboard eth, that I don't use21:20
KatolaZis it your router?21:20
systemdleteyour interfaces are named like "eth0" "eth1" etc?21:20
KatolaZbbl21:21
gnarfaceKatolaZ: that's him.  his local ip itself21:21
EvilhamMaybe someone was clever and said 192.X.X.X is local21:21
barrett9hifconfig shows just eth021:21
EvilhamWhich, is kot true21:21
systemdleteok21:21
barrett9hI think the onboard one is disabled21:21
systemdletewhat if you do ifconfig -a?21:21
EvilhamSo, go check that firewall21:21
barrett9hjust eth0 and lo21:21
systemdleteor better yet, ip addr21:21
barrett9h1: lo  2: eth021:22
systemdleteso it sounds like just one PHY interface21:22
Evilham(and the subnet)21:22
systemdlete"lo" is not a physical device though.21:22
gnarfaceif 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
systemdleteso nvm me then.21:23
systemdletewouldn't ip addr show all the phy devices?21:23
systemdleteregardless of their disposition?21:23
gnarfacemaybe, i'm not sure21:23
systemdletehmmm.  no, maybe not.21:24
gnarfacebut 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 LAN21:24
systemdleteI seem to recall phy devs going away, maybe with ifdown21:24
systemdletewith me, what was happening is that eth1 and eth2 were "swapping" on boot... SOMETIMES21:25
systemdletewhich is what got me to thinking that maybe this was similar.21:25
gnarfacethat 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
systemdleteooh.21:26
systemdleteGlad my issue was not that tough.21:26
gnarfacethis would be a new one for me to see nouveau doing, but i've seen it do some weird stuff so it would be believable21:26
gnarfaceCPU registry corruptions , to be clear21:27
gnarfaceregister i mean i guess21:27
systemdletedid you see that one error I posted from a recent boot.  A one-off'er21:27
systemdletehaven't seen it again21:27
systemdleteor before21:27
gnarfacei'm not sure i did21:27
systemdletecould not read from '/sys/module/pcc_cpufreq/initstate21:28
systemdletedoes that fall under that category you referred to just then?21:29
gnarfacehmmm. maybe21:29
gnarfaceif it's intermittent i could only speculate that's some sort of race condition error at boot up time21:29
systemdleteit's an ASUS M5A7L USB3/M21:29
systemdletebut I don't see any notices about missing firmware, drivers, etc21:31
gnarfacecpufreq is the part that handles changing CPU power states21:32
systemdletethat ladder biz?21:32
systemdleteladder and governor I think I recall21:32
systemdleteI 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 all21:33
systemdleteso I got curious and started reading about the board and what all this has to do with the kernel21:33
gnarfacegrep -ni '.' /sys/devices/system/cpu/cpu0/cpufreq/*21:34
gnarfaceyes, governors21:34
systemdletebut it's all a blur now.  I think the last time I was looking at it was maybe 10 years ago.21:34
gnarfacespeed/powermanagement21:34
* systemdlete nods21:34
gnarfacethe 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 later21:35
systemdletepossibly.  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
systemdleteBut I still have the dmesg file; it was only 2 boots back I think.21:37
systemdletePlease don't laugh.  I do not mean to insinuate anything, but the main power button on this case is broken.21:38
systemdleteIt's a blue (and black) Centurion (model 5 I think) and I love it.21:38
systemdleteI haven't seen anything like it recently at Fry's21:39
systemdleteBut,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
systemdleteI see a message for radeon power management initialized, but not for cpu21:43
gnarfaceyou can check the contents of this file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor21:44
systemdlete"ondemand" it says21:45
systemdletebut, of course, we are mixing up boots here.21:45
gnarfaceondemand suggests that power management is enabled21:46
systemdletethe dmesg file with that error was from the boot before the current one I am in now.  So I am not sure it is relevant21:46
gnarfaceyou have acpid installed and running, right?21:46
systemdleteno.21:47
* systemdlete ducks21:47
gnarfacereally?21:47
gnarfacehmm, you probably want that21:47
gnarfacethe core of the power management daemon21:48
gnarfacewell it IS the power management daemon21:48
gnarfaceone of the parts that systemd absorbed21:48
systemdleteinstalling now...21:48
gnarfaceif you're missing that you were probably missing lm-sensors too, which you'll no doubt want21:49
slvrgnarface: reading the power management code as it was and the new code was pretty eye-popping...21:49
systemdleteoh yes.  Good old lm-sensors21:49
gnarfaceslvr: i believe you, though i haven't really looked into either at that level of detail21:50
slvrI was like, uh, you ported bash to C? That's like... dangerous... man....21:50
systemdletelm-sensors was installed with the system I think, or as a dependency of something else21:50
gnarfacesystemdlete: possible, but it was another one of the core system components that systemd absorbed then deprecated21:51
systemdletethat thing is like one of those creatures depicted in 1950's B movies where the monster comes and eats people and keeps getting bigger21:51
systemdletethe quality is about as good as one of those movies too21:54
gnarfaceheh, yea i think that's the literal business strategy21:55
systemdleteno one part of it gets totally completed before 5 more parts are rolled out, without fanfare, just thrust upon all21:56
slvrNIH in full force21:56
systemdleteok, 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
systemdleteI leave this guy up 24x7 pretty much.21:58
systemdleteIt'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'd21:58
systemdletebut usually I leave it up all the time.21:58
systemdlete(prob time to skip over to the fork channel)21:59
gnarfacesystemdlete: 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 features22:03
gnarface(they just sometimes also expose very unfortunate BIOS bugs)22:04
eyalrozI hope I don't get flamed for this, but here goes:23:28
eyalrozDevuan 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
eyalrozWhat 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
gnarfacedevuan beowulf is already in the repos23:31
gnarfaceyou can upgrade to it at your own risk23:31
gnarfaceif you only need it for gcc though, it might be a better idea to install it into a chroot23:32
eyalrozgnarface: I was only using GCC as an example, I sometimes use my own home-baked gcc 8.2 for C++17 stuff.23:34
eyalrozgnarface: 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
eyalrozgnarface: Also, how do I like my odds for apt-get dist-upgrade'ing from ascii to beowulf?23:38
gnarfaceyou'll have to talk to someone here who has tried it23:40
gnarfacethere are known complications but people have succeeded at it23:40
gnarfacethe process shouldn't be fundamentally different from upgrading to debian testing23:40
Xenguy.oO( Here there be dragons ? )23:40
fsmithredeyalroz, I've done a few upgrades from ascii to beowulf, and they were pretty easy23:47
fsmithredyou may run into some desktop things that don't work quite right23:47
fsmithredmaybe some other stuff here and there23:47
fsmithredbut mostly it's fine23:48
eyalrozfsmithred: I'm running into many desktop things that don't work right , already before the upgrade so I'm not deterred :-)23:48
fsmithredlol23:48
eyalrozI guess I'll probably back up my home folder and try it at some point23:49
fsmithredI did have trouble with encrypted lvm - that was a couple months ago23:49
fsmithredneed to try it again23:49
fsmithredIf I remember correctly, lvm is always a little flaky in testing23:50
eyalrozfsmithred: Ok, that's good to know.23:51
fsmithredand if you have uefi, watch out for the grub-signed package23:52
fsmithredif 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/!