You are not logged in.
Try installing resolvconf. openvpn (whether being used by itself or as a backend) sometimes needs it for setting up DNS.
@crankypuss - Leave linux because it tends to respect your freedom and makes distinction between free and non-free software? Strange.
This should be a relatively easy problem to fix. Your Broadcom BCM4352 wireless card requires the wl kernel module in order to function. Try this:
1. Add non-free to /etc/apt/sources.list file, so that it looks like this:
deb http://deb.devuan.org/merged ascii main non-free2. Give your computer a wired internet connection, then:
sudo apt update && sudo apt install linux-headers-$(uname -r|sed 's,[^-]*-[^-]*-,,') broadcom-sta-dkms wireless-toolsInstalling the above packages should cause the wl kernel module to be built.
3. Reboot
The above is my summary of the instructions here: https://wiki.debian.org/wl
P.S. If a wired internet connection is not an option, first get appropriate suffix in your Devuan installation by running uname -r|sed 's,[^-]*-[^-]*-,,'. Then boot into your linux distro that has working wifi, go to https://www.debian.org/distrib/packages#search_packages and "Search package directories" for broadcom-sta-dkms, wireless-tools, and linux-headers-suffix. You should be able to download the packages after a few clicks (choosing Debian stable/Stretch and architecture of your Devuan installation). Save packages to a flashdrive then, back in Devuan, install the three packages with sudo dpkg --install *.deb
Just one note of warning about using Tor at work:
I'm also behind a draconian firewall when I'm at work, and used Tor for a long time to get around it. One day I was contacted by the IT team because their records showed my computer was connecting to an IP address that was part of a "botnet". My tower was taken away for investigation (to make sure it was not infected with viruses/malware), and I was given a new tower. They never found anything (not surprising). It was embarrassing and inconvenient.
Moral of the story is if your IT department has a strict firewall, then it is probably the kind of IT department that also keeps tabs on the IP addresses you are connecting to. If the first Tor node you connect to is on one of their blacklists for some reason, you may get in trouble/inconvenience/scrutiny.
When on AC power, here is dmesg and lspci output when I plug in the card:
$ dmesg
---snip---
[ 38.816383] pci 0000:04:00.0: [1912:0015] type 00 class 0x0c0330
[ 38.816469] pci 0000:04:00.0: reg 0x10: [mem 0x00000000-0x00001fff 64bit]
[ 38.816931] pci 0000:04:00.0: PME# supported from D0 D3hot D3cold
[ 38.828158] pci 0000:04:00.0: BAR 0: assigned [mem 0xe0000000-0xe0001fff 64bit]
[ 38.828207] pci 0000:04:00.0: enabling device (0000 -> 0002)
[ 38.828557] xhci_hcd 0000:04:00.0: Resetting
[ 39.872583] xhci_hcd 0000:04:00.0: xHCI Host Controller
[ 39.872612] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 9
[ 39.877934] xhci_hcd 0000:04:00.0: hcc params 0x014051cf hci version 0x100 quirks 0x00000090
[ 39.878520] usb usb9: New USB device found, idVendor=1d6b, idProduct=0002
[ 39.878526] usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 39.878531] usb usb9: Product: xHCI Host Controller
[ 39.878535] usb usb9: Manufacturer: Linux 4.16.2-gnu xhci-hcd
[ 39.878539] usb usb9: SerialNumber: 0000:04:00.0
[ 39.878986] hub 9-0:1.0: USB hub found
[ 39.879013] hub 9-0:1.0: 2 ports detected
[ 39.879378] xhci_hcd 0000:04:00.0: xHCI Host Controller
[ 39.879389] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 10
[ 39.881478] usb usb10: We don't know the algorithms for LPM for this host, disabling LPM.
[ 39.881540] usb usb10: New USB device found, idVendor=1d6b, idProduct=0003
[ 39.881545] usb usb10: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 39.881550] usb usb10: Product: xHCI Host Controller
[ 39.881554] usb usb10: Manufacturer: Linux 4.16.2-gnu xhci-hcd
[ 39.881558] usb usb10: SerialNumber: 0000:04:00.0
[ 39.881832] hub 10-0:1.0: USB hub found
[ 39.881844] hub 10-0:1.0: 2 ports detected
[ 39.959935] [UFW BLOCK] IN=wlan0 OUT= MAC= SRC=fe80:0000:0000:0000:7f31:6966:e82c:1811 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=371341 PROTO=UDP SPT=8612 DPT=8612 LEN=24
[ 39.959968] [UFW BLOCK] IN=wlan0 OUT= MAC= SRC=fe80:0000:0000:0000:7f31:6966:e82c:1811 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=636760 PROTO=UDP SPT=8612 DPT=8610 LEN=24
[ 39.970442] [UFW BLOCK] IN=wlan0 OUT= MAC= SRC=fe80:0000:0000:0000:7f31:6966:e82c:1811 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=371341 PROTO=UDP SPT=8612 DPT=8612 LEN=24
[ 39.970523] [UFW BLOCK] IN=wlan0 OUT= MAC= SRC=fe80:0000:0000:0000:7f31:6966:e82c:1811 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=636760 PROTO=UDP SPT=8612 DPT=8610 LEN=24 $ lspci
---snip---
04:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02)When on battery power, here is dmesg and lspci output when I plug in the card:
$ dmesg
---snip---
[ 30.008572] pci 0000:04:00.0: [1912:0015] type 00 class 0x0c0330
[ 30.008658] pci 0000:04:00.0: reg 0x10: [mem 0x00000000-0x00001fff 64bit]
[ 30.008948] pci 0000:04:00.0: PME# supported from D0 D3hot D3cold
[ 30.020338] pci 0000:04:00.0: BAR 0: assigned [mem 0xe0800000-0xe0801fff 64bit]
[ 30.020437] pci 0000:04:00.0: enabling device (0000 -> 0002)
[ 30.021279] xhci_hcd 0000:04:00.0: Resetting
[ 31.040665] xhci_hcd 0000:04:00.0: xHCI Host Controller
[ 31.040694] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 9
[ 31.046064] xhci_hcd 0000:04:00.0: hcc params 0x014051cf hci version 0x100 quirks 0x00000090
[ 31.046745] usb usb9: New USB device found, idVendor=1d6b, idProduct=0002
[ 31.046751] usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 31.046755] usb usb9: Product: xHCI Host Controller
[ 31.046760] usb usb9: Manufacturer: Linux 4.16.2-gnu xhci-hcd
[ 31.046764] usb usb9: SerialNumber: 0000:04:00.0
[ 31.047217] hub 9-0:1.0: USB hub found
[ 31.047293] hub 9-0:1.0: 2 ports detected
[ 31.047723] xhci_hcd 0000:04:00.0: xHCI Host Controller
[ 31.047735] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 10
[ 31.049579] usb usb10: We don't know the algorithms for LPM for this host, disabling LPM.
[ 31.049641] usb usb10: New USB device found, idVendor=1d6b, idProduct=0003
[ 31.049647] usb usb10: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 31.049651] usb usb10: Product: xHCI Host Controller
[ 31.049655] usb usb10: Manufacturer: Linux 4.16.2-gnu xhci-hcd
[ 31.049659] usb usb10: SerialNumber: 0000:04:00.0
[ 31.049932] hub 10-0:1.0: USB hub found
[ 31.049993] hub 10-0:1.0: 2 ports detected
[ 31.120412] [UFW BLOCK] IN=wlan0 OUT= MAC= SRC=fe80:0000:0000:0000:7f31:6966:e82c:1811 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=470731 PROTO=UDP SPT=8612 DPT=8612 LEN=24
[ 31.120498] [UFW BLOCK] IN=wlan0 OUT= MAC= SRC=fe80:0000:0000:0000:7f31:6966:e82c:1811 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=854431 PROTO=UDP SPT=8612 DPT=8610 LEN=24
[ 31.131125] [UFW BLOCK] IN=wlan0 OUT= MAC= SRC=fe80:0000:0000:0000:7f31:6966:e82c:1811 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=470731 PROTO=UDP SPT=8612 DPT=8612 LEN=24
[ 31.131270] [UFW BLOCK] IN=wlan0 OUT= MAC= SRC=fe80:0000:0000:0000:7f31:6966:e82c:1811 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=854431 PROTO=UDP SPT=8612 DPT=8610 LEN=24 $ lspci
---snip---
04:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02)To my surprise, the outputs seem identical even though the card is functional in the first scenario, nonfunctional in the second scenario.
Does the above prove that inability to use the card while on battery power is a power/hardware limitation rather than a setting/software issue?
My T400 ThinkPad did not come with any USB 3.0 ports, so I added one of these cards:
https://www.amazon.com/StarTech-com-Exp … B00535CMEE
The wrinkle is that the card only works if laptop is on AC power. If laptop is running on battery power and I want to use the card, I need to plug the laptop in, eject the card, and reinsert the card.
I don't mind the above too much. However, because my laptop's battery lasts many hours, sometimes I don't have the AC adapter with me--and can't use the card.
Is the card's inability to function when laptop is on battery power a) due to some kernel/software setting or b) due to laptop's physical inability to provide enough power to the card when running on battery? If it is a software setting trying to "help" me by being frugal with battery power, I'd like to change the setting so that I can use the card when on battery power.
P.S. I'm on ASCII with MATE 1.16.2. I do not use a power manager. Any power settings on this machine are default low-level settings (e.g., kernel settings).
Another thought: Many MATE components use dbus for interprocess communication, so mate-panel almost certainly uses it as well. dbus logs to /var/log/syslog. Does anything interesting show up in the syslog when the panel becomes unresponsive?
Oh, pity. I was hoping it would be an easy fix.
MATE immediately restarts the panel when it is killed, so running killall mate-panel has the effect of a panel respawn. Maybe you can use that in a pinch while looking for a proper fix.
If you provide more information on how your system is configured, we can compare and hopefully single out the culprit.
rolfie, I'm also on Devuan ASCII with Mate 1.16 and Lightdm, manually installed. My system started out as MiyoLinux.
Are you using a background image for your panel? Check by right-clicking on panel -> Properties -> Background. When I was using a background image, my panel was unstable and sometimes icons would disappear and/or panel would lock up on me. Choosing "None (use system theme)" for panel background made all my panel issues go away.
Lightdm is probably innocent here.
Thank you, yeti and fsmithred. Good to know this is just how it is. I thought something in my /etc/apt/apt.conf.d/ or /etc/apt/preferences.d/ was broken.
Then my guess then is that it is either this way by design (for some reason unknown to me) or else it's a minor bug that's only cosmetic.
At any rate, I booted an old Debian 8 partition, downloaded ffmpeg, installed it, and checked the installed version. There are no url escape codes in the version that apt reports being installed. (I guess this is not surprising since apt gets version number from package's /DEBIAN/control file and not from the name of the .deb file.) No harm, no foul.
bruno@thinkpad8:~/Desktop$ apt-get download ffmpeg
Get:1 http://ftp.us.debian.org/debian/ jessie-backports/main ffmpeg amd64 7:3.2.10-1~deb9u1~bpo8+1 [1,535 kB]
Fetched 1,535 kB in 0s (1,537 kB/s)
bruno@thinkpad8:~/Desktop$ ls
ffmpeg_7%3a3.2.10-1~deb9u1~bpo8+1_amd64.deb # note the '%3a'
bruno@thinkpad8:~/Desktop$ sudo gdebi ./ffmpeg_7%3a3.2.10-1~deb9u1~bpo8+1_amd64.deb
# installation proceeds normally
bruno@thinkpad8:~/Desktop$ apt list --installed ffmpeg
Listing... Done
ffmpeg/jessie-backports,now 7:3.2.10-1~deb9u1~bpo8+1 amd64 [installed] # note the ':'Sorry for the noise, but when I first noticed this it was completely unexpected.
When I download packages that contain a colon in the version number (e.g., ffmpeg 7:3.2.10-1~deb9u1 or xserver-common 2:1.19.2-1+deb9u2), the downloaded package name contains %3a where I was expecting :.
bruno@thinkpad:~/Desktop$ apt download ffmpeg xserver-common
Get:1 http://gnuser.ddns.net/devuan/merged ascii/main amd64 ffmpeg amd64 7:3.2.10-1~deb9u1 [1,530 kB]
Get:2 http://gnuser.ddns.net/devuan/merged ascii/main amd64 xserver-common all 2:1.19.2-1+deb9u2 [2,059 kB]
Fetched 3,589 kB in 4s (784 kB/s)
bruno@thinkpad:~/Desktop$ ls
ffmpeg_7%3a3.2.10-1~deb9u1_amd64.deb
xserver-common_2%3a1.19.2-1+deb9u2_all.debUsing apt-get download instead of apt download makes no difference.
Is this expected behavior, an upstream bug, or symptom of some misconfiguration on my system? (Internet searches have come up dry.)
Is there a way to set up sudo on a per-application basis ...
ie: so that sudo will work with a select list of apps, like Wine and LinSSID.
Yes. If that's really all you want, putting a line like this at the end of /etc/sudoers (preferably by running # EDITOR=nano visudo) will do the trick:
groucho ALL=(root) NOPASSWD: /usr/bin/wine-stable,/usr/bin/winecfg-stable,/usr/bin/linssidHowever, being able to use sudo to run any command you want as any user:group you want is much more convenient. For that, put this at the end of sudoers:
groucho ALL=(ALL:ALL) NOPASSWD: ALLIf you prefer to enter your password each time, use PASSWD instead of NOPASSWD.
P.S. If you are truly in the sudo group, the %sudo... line shown in chris2be8's response should allow you to run any command with sudo provided you enter your password. The problem you are having is either because the %sudo... line is missing from sudoers (unlikely) or, more likely, you are not actually part of the sudo group. Type id at the command line to see the groups you are part of. If you are not part of the sudo group, add yourself to it with this command: # usermod -a -G sudo groucho
That's what I thought.
Thank you, ralph.ronnquist. I'm embarrassed that S0?eudev is in /etc/rcS.d/ (instead of in /etc/rc2.d/) but I didn't know to look there. A careful look at /etc/inittab would have clued me in to the fact that the /etc/rcS.d/ directory exists and its scripts run before those in /etc/rc?.d/.
You really took it to the next level with the information about the pre-pivot start up. In my mind all that is simply "initramfs stage"--the fine details of which I never considered or even heard of before. Thank you very much for such an insightful answer.
Even though eudev is a service (sudo service eudev status produces output and /etc/init.d/eudev exists), I cannot find a corresponding link in /etc/rc2.d (i.e., none of the links have eudev, udev, or udevd in the name).
What starts the eudev service and how?
A solution: In /etc/init.d/eudev, add this as the last line of the start) section (in my file, this line ends up being line 218):
ls /run/udev/tmp-rules* && { sleep 5; /lib/udev/udev-finish; } &
That part of /etc/init.d/eudev now looks like this:
# wait for the udevd childs to finish
log_action_begin_msg "Waiting for /dev to be fully populated"
if udevadm settle; then
log_action_end_msg 0
else
log_action_end_msg 0 'timeout'
fi
ls /run/udev/tmp-rules* && { sleep 5; /lib/udev/udev-finish; } &
;;
stop)I think the issue is that when eudev runs, the filesystem is not yet writable and therefore /lib/udev/write_net_rules writes to temporary files in /run/udev/ (see the choose_rules_file and writeable functions in /lib/udev/rule_generator.functions).
It is the job of /lib/udev/udev-finish to copy temporary rules in /run/udev/ (which don't survive reboot because they exist in RAM) to the root filesystem once filesystem is writable, but nothing seems to ever run this script (I inserted a line in udev-finish that creates a dummy file, but the dummy file never shows up under any circumstances).
So I think I found a bug: Nothing ever triggers /lib/udev/udev-finish, therefore temporary rules in RAM never get transferred to the filesystem, therefore /run/udev/tmp-rules--70-persistent-net.rules gets generated anew at every boot but /etc/udev/rules.d/70-persistent-net.rules never sees the light of day.
I discovered something: After every boot, /run/udev/tmp-rules--70-persistent-net.rules exists (populated with naming rules for eth0 and wlan0 based on their MAC addresses), even though /etc/udev/rules.d/70-persistent-net.rules never gets created. So the naming rules are generated anew on each boot, but exist only in RAM.
Maybe the timing of things at boot is such that eudev is trying to commit the naming rules to filesystem before the filesystem can be written to?
Afaict the idea is, that any subsequent addition event for the same net device adapter will process 70-persistent-net.rules first, and that will set NAME for the adapter, and thereby disarm 75-persistent-net-generator.rules.
This seems sensible, but the fact is that my 70-persistent-net.rules is absent, so it cannot be responsible for setting NAME for the adapter or for disarming 75-persistent-net-generator.rules. Something is disarming the generator.rules, the question is what that something is.
@w3 obrigado pelo link. Me cadastrei no git.devuan.org e pedi acesso ao wiki devuanbr. Também fiz o upload da minha chave de SSH pública. Ficarei de olho no wiki e contribuirei quando ver oportunidades, do mesmo jeito que contibuo neste fórum (devagar e sempre).
Que tipo de conteúdo e onde?
Ultimamente ando bastante ocupado com trabalho e família (tenho três filinhos com menos de 5 anos), mas posso ajudar dependendo do que se trata.
Thank you very much for that, fsmithred. The 70-persistent-net.rules on my refractasnapshot "parent" partition was definitely not a leftover, either, since that partition was a fresh install.
This is a complete mystery to me at this point.
fsmithred: On your ASCII partition that has the file, would you please backup the file, delete it from /etc/udev/rules.d/, reboot, then check if the file is regenerated? I'm guessing it won't be autogenerated (i.e., the file was there because it was autogenerated at some point in the past).
I'm glad I'm not the only one scratching head over this. I don't care about 70-persistent-net.rules per se--after all, everything works and all machines have the old interface names. But I do want to figure out why the file mysteriously stopped being autogenerated.
Ralph: /lib/udev/rules.d/75-persistent-net-generator.rules exists on all my machines, full of nice-looking code. Neither now nor in the past did any of these machines set the net.ifnames kernel boot parameter.
Thank you, fsmithred. Question #1 is completely answered. (I have a deep dislike for the new interface names, by the way. Yuck!)
The question remains as to why this file used to be automatically generated on these machines, but not anymore. I did not change any eudev settings. Did using refractasnapshot on the "parent" of the two affected machines have something to do with it? (I can imagine that unless the refracta scripts intervened somehow, transferring a typical autogenerated /etc/udev/rules.d/70-persistent-net.rules from parent to child computer would mess up the interface names--e.g., child computer's wireless card would be named wlan1 instead of the expected wlan0).
Today I noticed that two of my Devuan ASCII machines are missing /etc/udev/rules.d/70-persistent-net.rules altogether, while a third machine has the file but it is blank. All machines are working fine including internet access (and network interface names are the easy-to-remember old-fashioned ones). eudev is running on all the machines:
bruno@inspiron:~$ sudo service eudev status
[ ok ] udevd is running.This situation made me realize some gaps in my knowledge:
1. What is the function of this file normally?
2. Why is the file absent/empty? It used to be generated automatically, but not anymore. Is something broken on these machines?