| rwp | This is one of the reasons why free-software is so much better. Can just look at the source in that case. Can then modify the source. | 00:00 |
|---|---|---|
| rwp | But you might be able to strace through and figure out what it is doing and then fix the next thing that is blocking it from working. | 00:00 |
| onefang | Hmmm, I'm almost sure that last time I checked my Devuan system DID have a /run/systemd/system in my systemD less Devuan system, but it doesn't now. It does have /run/systemd/ other things. | 00:00 |
| rwp | avbox24, Honestly none of the output in your paste https://paste.debian.net/1312113 makes sense to me in isolation. Those could mean anything. I am just unable to help with the problem shown by those messages. | 00:01 |
| onefang | Entirely possible I have since removed the package that did that. | 00:02 |
| rwp | onefang, Devuan has /run/systemd and I have run into buggy packages (spamassassin's spamd) that check for it rather than /run/systemd/system but only systemd actively running should have /run/systemd/system present. | 00:02 |
| onefang | Just call me suspicious about anything systemD. lol | 00:03 |
| rwp | And if you look at /usr/sbin/service then is_systemd is null-length and <<if [ -n "$is_systemd" ]; then>> then avoids running that bottom section which calls systemctl at all. It's skipped entirely. Then at the very bottom the run_via_sysvinit function defined above it earlier is called and it runs the /etc/init.d/foo script then and that's the normal path for everything on Devuan systems without systemd. | 00:04 |
| onefang | Yep, I did just look at it again. | 00:04 |
| rwp | It's kind'a a hokey way of doing things. But as we know the systemd diehards will try to block ANY non-systemd way of working. So we have to sneak in portability and compatibility where we can. And where we can't that's the reason it must be forked. That one is in init-system-helpers and not forked. So it is one that we know works on either system. Even if it is in a hokey way of working. | 00:06 |
| onefang | I'd still much prefer it if the preference was the other way around, then we wouldn't have had this conversation, and we can stop worrying. | 00:06 |
| rwp | Obviously I agree. And I would be a proponent of init-freedom such that there would be a defined way to call the init specific thing to call. That would be better. But systemd is not about getting along with others. | 00:07 |
| avbox24 | I was able to start mullvad-gui and I could go to another location, but it looks like I don't the firewall rules ar not ok: https://paste.debian.net/1312116/ | 00:07 |
| rwp | avbox24, What is in /usr/lib/systemd/system/mullvad-early-boot-blocking.service too? That was called first but wasn't sure I needed to ask then. But let's look there too. | 00:08 |
| rwp | In https://paste.debian.net/1312110/ we see that it calls bash. (In a portable way no matter where it is installed! I approve.) And then it calls "set -eu" which is bad scripting practice. The -e does not do what anyone wants it to do but people keep ignoring that and hoping it does. That causes the first systemctl which returns non-zero to exit the script. | 00:10 |
| rwp | The -u is almost always problematically trouble because no one writes for it. But the -u does not matter because there are no variables at all in that script. | 00:11 |
| avbox24 | rwp: https://paste.debian.net/1312117 but I don't see where the firewall rules really are. | 00:11 |
| rwp | Ah! ExecStart=/usr/bin/mullvad-daemon --initialize-early-boot-firewall | 00:12 |
| rwp | That's calling the daemon with a different option. And that option is telling it to --initialize-early-boot-firewall which I will guess is setting up the firewall that the other run is complaining is not there. | 00:12 |
| rwp | I would stop everything. Kill everything. Then do things again with --initialize-early-boot-firewall in the first run and -v --disable-stdout-timestamps in the second run. | 00:13 |
| avbox24 | rwp: Yes I think this is the point, I will investigate where the rules itself are, I think they do a os check and devuan is not there. | 00:13 |
| rwp | Another sometimes useful hack is to run "strings /usr/bin/mullvad-daemon" and then grep around and see what files it might be looking at. Does it look at /etc/os-release for example? | 00:14 |
| rwp | Also "strace -e trace=file" along with the other options will reduce the amount of noise in the trace to just operations that access files and that might show what files it is reading and then you know there too. | 00:15 |
| rwp | It might be possible to run mullvad-daemon in a Debian chroot. Since networking is in the kernel that might convince mullvad-daemon that it is on a Debian system, since then the files would all say Debian, and everything might (maybe?) still function correctly. I think it probably would. | 00:16 |
| avbox24 | rwp: strings /usr/bin/mullvad-daemon is very interesting, but it is too long and not really an ansi file. | 00:18 |
| rwp | The strings command might pull things out that are not ascii nor utf-8 strings, true. Using 'less' to keep that sane might be wise. I should have said that. But usually it is not needed. | 00:19 |
| rwp | I have stuff happening IRL and must run. BBIAB. Good luck! Happy Hacking! | 00:19 |
| avbox24 | rwp: had a look at the output, I see that was made with go and I have to assume that they hard coded the os in the program. But I think the publish the source code under https://github.com/mullvad/mullvadvpn-app, may be I find there more. But for today it is enough. At least using fdroid app and tethering it works. | 00:24 |
| avbox24 | One last note, I had a look at source, it really looks like the only accept ubuntu/debian and Fedora. | 00:30 |
| jirib | hi, i have an issue to start GDM (gdm3) on unstable devuan with runit | 14:58 |
| jirib | https://termbin.com/yco7 | 14:58 |
| jirib | iiuc gdm needs elogind, that's running, same for system dbus | 14:59 |
| gnarface | jirib: "permission denied" is usually pretty telling | 15:00 |
| gnarface | maybe something else is already using VT1 or... maybe your user just doesn't have permission? | 15:00 |
| jirib | gnarface: shouldn't elogind pass fd to gdm? | 15:00 |
| gnarface | i don't know | 15:01 |
| gnarface | i'd just try starting it as root first to see if that works | 15:01 |
| gnarface | if that doesn't work, maybe something else is already started that is using it | 15:02 |
| jirib | i previously tried lightdm with xfce and it was working fine | 15:02 |
| gnarface | well, make sure lightdm isn't still running | 15:02 |
| jirib | it's already uninstalled | 15:02 |
| gnarface | could be a runit issue, or just an unstable issue | 15:03 |
| gnarface | "permission denied" is usually just mundane filesystem permissions missing though | 15:03 |
| jirib | there's no even runit sv for gdm | 15:03 |
| jirib | it's started via /etc/init.d | 15:03 |
| gnarface | i do know that some of the alternate init systems are still piggybacking on the sysvinit scripts | 15:04 |
| gnarface | is your user in the video group? | 15:05 |
| gnarface | and is gdm starting as root? | 15:05 |
| jirib | eh? the login screen even does not start, so it's before any user could even login | 15:05 |
| gnarface | i understand that. that's irrelevant to those two questions | 15:06 |
| gnarface | is your regular user (the one you will eventually log in as) in the video group... some cases it doesn't matter but it also won't hurt | 15:06 |
| gnarface | and is gdm trying to be started as root (regardless of whether it's actually starting, i get that it's not successfully starting) | 15:07 |
| gnarface | maybe it would be a better idea for you to try this with the stable release first to make sure it's not just some transient bug in unstable | 15:08 |
| gnarface | i'm sorry that i don't know runit well enough to help you write configs for it | 15:08 |
| gnarface | if you stick around though, someone else here might | 15:08 |
| jirib | iiuc gdm switched to other use via /usr/share/gdm/generate-cofnig | 15:08 |
| jirib | gnarface: do you run gnome yourself? | 15:13 |
| gnarface | jirib: no, sorry, i don't even use a graphical login, but i do know that when lightdm was working for you, it was running as root. | 15:14 |
| gnarface | and i also know that unless your Xorg instance is also running as root (which is now only the default for the nvidia official binary-only drivers) then your user would need to be in the video group as well | 15:15 |
| gnarface | i can't be sure either of those things are what is causing the "permission denied" error here, but i'd check them first | 15:17 |
| gnarface | you should also know that unstable breaks a lot, and sometimes there isn't any recourse but to wait for them to fix it | 15:18 |
| jirib | i can only say that `echo needs_root_rights = yes > /etc/X11/Xwrapper.config' makes a difference but still Xorg is not loaded from GDM | 15:18 |
| gnarface | have you tried starting Xorg without the graphical login, by just running "startx" as your regular user? | 15:18 |
| gnarface | if that also fails, it might give you something better to go on | 15:20 |
| gnarface | and if it works, well, at least you'll have narrowed down where the problem is | 15:30 |
| gnarface | jirib: any progress? | 16:15 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!