You are not logged in.
Would you mind drop the outputs of two commands:
# ls /sys/class/net
# ip link
That should provide exact information of the link level, and possibly point to where a problem might be.
Btw, are you sure you are using lightdm and not slim which is the default in Devuan ?
If the latter, you'll rather need to edit /etc/slim.conf to have default_user and auto_login set up.
Yes, "crickets" is a meaningful outcome. The follow-on testing would be
a) try running /usr/sbin/expressvpnd as root (I failed to highlight that before).
Then b) look into the end of the file /var/log/syslog for traces of that run; esp. if there is anything near a good statement of why it is failing. In particular, if it's an apparmor issue, then it would show up there I think.
Also b2), check whether there might be a dedicated log file for expressvpn in /var/log.
Perhaps it should say [SeatDefaults] rather than [Seat:*] ?
The init script you installed is fine, but there is obviously a problem for the expressvpnd daemon program.
Try running /usr/sbin/expressvpnd from the command line; it may tell you why it fails to start.
Perhaps you are using apparmor restrictively and it needs some permissions set up?
Thanks. I'm not sure if or where there is a problem, but a prompt like this is useful for the repo admins. I do know that there has been some recent amprolla improvement attempts, and perhaps they have "back-fired"... Keep checking.
When setting up a bluetooth speaker it got set up as a USB device, and I had to manually chwon /dev/bus/usb/001/002 to me in order gain access to it; maybe you have the same issue?
This guy, https://gist.github.com/rometsch/dfd24f … 3dc1481aaa, talks about it; looks constructive but no warranty from me.
Yeah, I've read many threads here and still haven't worked out any regular formula for when "advice to search" is administered.
There obviosuly should be a constent rule for it as otherwise any poster might feel left out or fingered; especially those that do search first and don't get any credit for that, as well as those who don't search first and thus suffer an amount of face loss.
Looks like an install script bug at /usr/lib/fheroes2-pkg/b-i_fheroes2.sh:20
Change that line to be
echo # dpkg -i /dev/zero 2>/dev/null
to make it build more happily.
I don't use this feature myself, but I have a private stash of useful information. Esp, some "random documentation" that says (far down):
.... If the month is t, the entry applies to all months of the year.
That is, the entry would then look like the following
&%%(diary-float t 4 2) time for my shower
Perhaps that works?
Yes.
As you see wth apt policy wine, the backports version(s) have priority 100 which is less than the 500 of the version(s) currently installed. That 100 is the default priority for backports on the basis that they should not be installed unless explicitly asked for or being an update of what is currently installed. As is, the 500 of the currently installed version(s) win.
You as @rolfie says probably want to leave the priorities like that, and just install manually, with
apt-get install --no-install-recommends -t ascii-backports wine
The -t ascii-backports part tells apt-get to for sure install the nominated package and its dependencies from ascii-backports as if it had priority 1000 (or something above 500).
If later ascii-backports gets another, newer version, the installed version will be an unsupported version at priority 100, and therefore a plain upgrade will result in it being upgraded.
Perhaps this was due to the service pkginfo.devuan.org not being available on ipv6, which now it is.
ok ... seems to lead out of my comfort zone. The product id (0x094b) is not listed in http://www.linux-usb.org/usb.ids, and afaict it's also not among the entries for libmtp (http://libmtp.sourceforge.net/).
So it appears that making it work is slightly more than plug-n-play. I'm not aware of any possible shortcut, but maybe someone else knows better.
That device, 054c:094b, does not appear to yet be listed among known devices, but it might work by identifying it explicitly for jmtpfs, i.e. if your mount point is /media/camera you'd use:
jmptfs -d 001,003 /media/camera
Perhaps it needs exfat-fuse (and maybe exfat-utils) whcih I don't think are installed by default.
Perhaps jmtpfs works for you.
@bbatten: iptables on beowulf (or buster, really) doesn't require arptables or ebtables, but it recommends nftables.
Upon installation, it gets set up to use the iptables-nft alternative implementation and then it provides syntax transparency via /usr/sbin/xtables-nft-multi so as to use the "traditional" iptables rules language for manipulating and reviewing the rules.
It also gives you the option to change it to use the iptables-legacy implementation through update-alternatives.
Doesn't that work for you?
You might also want to reinstall iptables without nftables; perhaps something like
# apt-get install --reinstall nftables- iptables
That should give you a set up that allows the "normal" iptables rules.
💁 ... someone just made this forum full utf8... enjoy
https://unicode.org/emoji/charts/full-emoji-list.html
@gu_1: as was indicated by @Head_on_a_Stick the domain name br.deb.devuan.org resolves to the domain name pkgmaster.devuan.org which is Devuan's own repository server and not to the round-robin domain name deb.devuan.org.
Thus, by using br.deb.devuan.org you don't take advantage of any mirroring, and always get packages served by pkgmaster.devuan.org.
Whilst that is fine for any individual case, it's something we generally want people to avoid doing, since it accumulates into a reduced service for everyone. Therefore the advice is that you should really use deb.devuan.org.
If you do want to use some particular server, or a subset of the round-robin servers, then the way to go is to edit your /etc/hosts to resolve deb.devuan.org to that server/subset. For example, you might add these lines to /etc/hosts:
# My preferred package sources
192.80.24.194 deb.devuan.org devuan.dcc.uchile.cl
200.236.31.1 deb.devuan.org devuan.c3sl.ufpr.br
2801:82:80ff:8000::2 deb.devuan.org devuan.c3sl.ufpr.br
Those particular lines would make apt use only the two servers devuan.dcc.uchile.cl and devuan.c3sl.ufpr.br as package sources (for ipv6, only the latter). (see man hosts for details about /etc/hosts)
Note: you may refer to https://pkgmaster.devuan.org/mirror_list.txt to find out which servers are in the round-robin, and you may use the host or dig commands to determine their IP addresses.
Devuan has a system in place to monitor round-robin servers with respect to their Devuan package service. You find graphs detailing status e.g. at http://veritas.devuan.org/apt-panoptico … pticon_cgp.
Yes;
afaiui there is a hotplug event generated when the "kvm subsystem" (Kernel-based Virtual Machine) has been initialized. That event is (like all) handled by the hotplug handler (aka udev/eudev) via that "rule", which directs the handler to create the device node "/dev/kvm" with the particular permissions and group.
The same actions by hand would be these:
# mknod /dev/kvm c 10 232
# chmod 0666 /dev/kvm
# chgrp kvm /dev/kvm
Commenting out the rule will result in the absence of the device node, but not the sub system itself of course. This should be fine until there's some software needing it; eg qemu or virtualbox or whatever. Under an ideal modularization principle, the device node would rather be created as needed by that software, but few things are ideal.
To avoid the complaint and be without a "kvm" group, some surgery of /lib/udev/rules.d/50-udev-default.rules might be sufficient; perhaps just removing the GROUP="kvm", bit, or that whole line, whichever feels more pleasing. The effects would be either that a /dev/kvm device node gets created with group root without complaint, or that it doesn't get created at all.
I should apologise for suggesting that anyone here would be "an idiot". It's an unnecessarily offensive labelling which I don't think should be applied to any contributor. I did use it, but merely as a "literary short cut" to emphasize my view about certain ways of acting on this forum; namely that of deleting and/or destroying ones previous posts. However, it was not meant to be a value judgement against anyone's contribution(s), in the past or in the the future.
Now, due to my praiseworthy effort, that way of acting is no longer possible. Well rather, it is now a restricted ability available only to those who sports the role of Administrator, as well as of course, to those who have access to the server.
I see that @Vernon, and probably others, think of this differently from me. Since we (including me) want this to be a forum that in principle is owned by its contributors, I will want to pursue this discussion a bit to understand what the difference is. Especially if I am supposed to dive into the code again to make a variation or retraction of my improvements.
My start point was that I see all threads and posts as valuable, and therefore it should not be available for posters to change or delete their posts once they've made them, except for a grace period for the purpose spelling and grammar corrections. Perhaps it should even be stronger than now; that deletion should only be available until there is a subsequent post.
Maybe this is influenced by mailing lists which have that nature.
I don't think the idea of saving threads elsewhere ("if someone in the community feels a thread is valuable") is a workable approach, because I think this site is supposed to be that archive of Devuan-related discussions. That is indeed the reason why changing posts to me is outside of agreeable activity.
What else is this forum if not an archive of Devuan-related discussions?