whelp

Nov. 1st, 2017 05:06 pm
solarbird: (molly-thats-not-good-green)
definitely a kill everyone day

isc-dhcp-server isn't relaying packets properly after the power outage. why? WHO THE FUCK KNOWS, IT'S LINUX. (current Debian, to be specific.)

* Packets to door (the server) from DHCP machines get there 100% of the time. (Also true for packets from the fixed-IP LAN.)
* Packets originating on door get to all destinations 100% of the time.
* Packets to the fixed-IP LAN from DHCP machines (going though door) get there about 50% of the time.
* Packets to the modem itself (which has a fixed IP address on the same subnet as the fixed-IP LAN) from the same sources get through 10%-20% of the time. This is also the same card as the fixed-IP LAN. Why one address on the fixed-IP LAN is getting special treatment? FUCKIN' GOT ME. I presume it has something to do with being the gateway. But if we take out the exceptions in the router table for the servers, and send everything through said gateway, nothing changes. Packet failure at about the same rate across the same classes.
* No DHCP client packets get past the points described. (Zero packets to internet, even ones that reach the internet modem.)
* All servers (fixed-IP LAN) talk to the internet just fine.

WHAT. THE. FUCK.

eta: It gets stupider. door drops half of DHCP-sourced packets to newmoon (fixed-IP lan), but drops none to lodestone (web server). Didn't think to play with that there is zero reason for them to be different. And yet.

eta2: it's not the NICs. or the switches. don't ask. yes, three hardware iterations later, I'm sure. It's not hardware.

eta3: apt-get remove and apt-get install of isc-dhcp-server changed NOTHING. what. the. fuck.
solarbird: (molly-thats-not-good-green)
Okay this is intensely stupid because debian

network card assignment is being random, because debian

i'm blacklisting the drivers and trying to load them in /etc/modules in correct order so the device assignment is consistent

i blacklist e1000e and r8169 (so they don't autoload)

and then have them both in /etc/modules so they do load in a specific order, r8169 then e1000e

e1000e loads

r8169 doesn't

modprobe r8169 loads fine

what. the. fuck. do. i. do. here.
solarbird: (molly-kill-everyone-with-sticks)
So far, I have to say, Debian Jessie is a trainwreck. Certainly as a mail server.

Current dovecot likes DELETING 90% OF YOUR MAIL ON FIRST ENCOUNTER. Gone. Poof. SO LONG. Something between the version we had been running and this version changed something about index numbers, and it's supposed to fix that silently, and the second time you show it your old mail queue it does. But I sure hope you kept that backup, because the first time, it just DELETES 90% OF YOUR MAIL.

Or in mine and Anna's cases, 100% of your mail. Seems to depend upon where the index conflict occurs. It seems to let you keep as much as 10% of it tho' if you have enough mail in your inbox.

And milter-greylist, holy hell.

So it's not just that the init.d startup for milter-greylist doesn't work, and it's not just that it fails silently with a false success report, and it's not just that it's wrong, I mean, just, completely, wrong, as in the environment variables are set to different values than the defaults in the default-for-senamil config file, and hey! They! Won't! Work! Together!, it's 1) it appears to be some sort of screen for whatever is actually silently failing to start milter-greylist, because 2) when you can manage to get it to produce any output at all, it's clearly not generated by anything in the startup script itself, and 3) if you edit out code that does things like "check for this being disabled in defaults because your check is ignoring the actual data and reporting disabled when it's not," some version of that code somewhere still runs even though you have deleted it, and still comes up with the wrong result without fail.

And! AND! Even if you start it yourself, as root, and it runs for a little while just fine? As soon as it tries to write the database file out to disk the first time, it crashes. Dead.

Open Source is the Future of Pain
solarbird: (pindar-most-unpleasant)

I have triumphed over the Open Sources and have made the nvidia GT520 driver work. I am now running a new kernel along the way, but hey. I also discovered bugs in Xorg -configure, as well as the nvidia configuration tool, and it only took 11 hours.

I can also now build the latest 3.2 Linux core, but that’s just kind of a side effect.

And this is for the official nvidia driver. Don’t believe me? Here are the instructions on how to install it, from nvidia themselves.


Madness

They do tell you that you have to have a full development environment and sources and headers for your kernel. They don’t tell you their driver doesn’t work with the realtime kernel and will fail without error. (Or panic your machine – one of those, depending.)

So will the open-source drivers, by the way. That’s fun.

Honestly, figuring that “this will always fail silently forever except when crashing your machine despite what the build instructions say” part out was the biggest hurdle. There’s a patch you can apply for the 3.4 downstream realtime kernel, but that’s even more out of phase with the rest of Ubuntu 12.04LTS than my previous custom realtime kernel was, so, yeah, no.

RANDR still fails so the GUI for monitor preferences still crashes if you try to run it, but I don’t use that anyway and I think that’s because I’m running Xinema mode – it was true for my previous card setup to. Both monitors started individually run RANDR and the GUI just fine.

“Ready for the desktop” HAHAHAHAHAHAHAHAHAHAHAHAHAHAHA sobs

(The Windows install was more a matter of “here’s the driver” “yup that’s a driver” and “no I want this monitor on the right” “okay” and done. DO YOU KNOW WHAT IT TAKES TO GET ME TO SING THE PRAISES OF WINDOWS?! I mean goddamn.)

But it’s all working. Anyone playing Elder Scrolls online?

Mirrored from Crime and the Blog of Evil. Come check out our music at:
Bandcamp (full album streaming) | Videos | iTunes | Amazon | CD Baby

May 2025

S M T W T F S
    123
45678 9 10
1112 13 14151617
18192021222324
25262728293031

Most Popular Tags

Syndicate

RSS Atom