Re: [arch-general] manually configure network
On 07/12/2017 10:29 PM, mick howe via arch-general wrote: On 13 July 2017 at 01:17, Mrrob wrote: On 13/07/17 07:09, mick howe via arch-general wrote: I've just changed ISP and I can't get the changed configuration to stick. I'm using 'static IP address - manual assignment' from Network configuration wiki page. I need to change my address from 192.168.1.0/24 to 192.168.20.1/24. using iproute2 tools as per wiki I can get everything working UNTIL I reboot, at which time some of the settings show the old values and others the new. I've been manually configuring these settings without problems since I started using linux in 1994. I assume that (as well as changing ISPs) you have changed your router and it has a different internal range to the old one. Correct, and the ISP failed to include modem password in the box. If you have an IP address automatically after booting then something is bringing up the network automatically. Assuming your Arch install is newer than 2013 then I would expect you've configured netctl to manage the interface. I had to reinstal when I moved in April 2013, would have used the simplest manual method Look in /etc/netctl [mick@cave ~]$ ls -aR /etc/netctl/etc/netctl: . .. examples hooks interfaces /etc/netctl/examples: . ethernet-static tunnel wireless-wpa ..macvlan-dhcp tuntap wireless-wpa-config bonding macvlan-static vlan-dhcp wireless-wpa-configsection bridgemobile_ppp vlan-staticwireless-wpa-static ethernet-custom openvswitch wireless-open ethernet-dhcp pppoe wireless-wep /etc/netctl/hooks: . .. /etc/netctl/interfaces: . .. and $ systemctl list-unit-files --state=enabled [mick@cave ~]$ systemctl list-unit-files --state=enabled UNIT FILE STATE org.cups.cupsd.path enabled autovt@.service enabled dbus-org.freedesktop.network1.service enabled dbus-org.freedesktop.resolve1.service enabled display-manager.service enabled getty@.serviceenabled httpd.service enabled lxdm.service enabled nmbd.service enabled openntpd.service enabled org.cups.cupsd.serviceenabled postgresql.serviceenabled smbd.service enabled systemd-networkd.service enabled systemd-resolved.service enabled org.cups.cupsd.socket enabled systemd-networkd.socket enabled remote-fs.target enabled 18 unit files listed. lines 1-21 is blahbluhblahnetwork1.service the guilty party or is it systemd-networkd.service? what am I looking for in these? This is the wiki page for the network manager you are using: systemd-networkd https://wiki.archlinux.org/index.php/Systemd-networkd --Rich
Re: [arch-general] manually configure network
On 07/12/2017 09:58 PM, mick howe via arch-general wrote: On 13 July 2017 at 01:17, Mrrob wrote: On 13/07/17 07:09, mick howe via arch-general wrote: I've just changed ISP and I can't get the changed configuration to stick. I'm using 'static IP address - manual assignment' from Network configuration wiki page. I need to change my address from 192.168.1.0/24 to 192.168.20.1/24. using iproute2 tools as per wiki I can get everything working UNTIL I reboot, at which time some of the settings show the old values and others the new. I've been manually configuring these settings without problems since I started using linux in 1994. I assume that (as well as changing ISPs) you have changed your router and it has a different internal range to the old one. Correct If you have an IP address automatically after booting then something is bringing up the network automatically. Assuming your Arch install is newer than 2013 then I would expect you've configured netctl to manage the interface. About april 2013 , can't remember details of what I did then but I would have used what was most like the the original method. Look in /etc/netctl [mick@cave ~]$ ls -aR /etc/netctl /etc/netctl: . .. examples hooks interfaces /etc/netctl/examples: .ethernet-static tunnel wireless-wpa .. macvlan-dhcptuntapwireless-wpa-config bonding macvlan-static vlan-dhcp wireless-wpa-configsection bridge mobile_ppp vlan-staticwireless-wpa-static ethernet-custom openvswitch wireless-open ethernet-dhcppppoewireless-wep /etc/netctl/hooks: . .. /etc/netctl/interfaces: . .. and $ systemctl list-unit-files --state=enabled --- mrrob --- You are probably using dhcpcd. This is what is installed when initially setting up the OS. Depending on exactly what settings are being reverted to default it may be normal behavior. What you need to do is find out exactly which network manager you are using and exactly what settings are not sticking across a reboot. The fix is probably not difficult but need more info to be able to make intelligent suggestions. I had a problem with dhcpcd reverting my DNS servers to the ISP defaults on every restart. --Rich
Re: [arch-general] systemd-boot ignores loader.conf
timeout 0 <-- in loader.conf 1st line default arch <-- in loader.conf 2nd line On 11/14/2016 12:58 PM, David Thurstenson via arch-general wrote: On Mon, Nov 14, 2016 at 12:55 PM, Tung Anh Vu via arch-general wrote: Exactly. I'm successfully booting, so the /boot/loader/entries/arch.conf is present and appears to be correct. My problem is, that I'm trying to make the boot menu to *not* appear, but without any success. Try setting "timeout 0" explicitly. I've got it working for a couple of machines this way, but really, it shouldn't be necessary.
Re: [arch-general] FireFox 44 turning the bookmark toolbar+ extensions area + current tab into light gray (like selected) [gist image]
On 01/30/2016 07:57 PM, Javier Vasquez wrote: On Sat, Jan 30, 2016 at 7:12 PM, Damjan Georgievski wrote: Just updated Arch, and got FF 44, but there's a new color behavior on the bookmark toolbar, the extensions area, and current tab. It looks like if everything was somehow selected, light grayed. This is new, but I don't know if it's the new 44+ expected behavior, or something that got broken, and perhaps there's a way to work it around. The gist linked image provides a snapshot of the new weird behavior: https://gist.github.com/je-vv/7a00601e9217cd9d3447 On Sat, Jan 30, 2016 at 7:12 PM, Damjan Georgievski wrote: you don't seem to be using the default look-and-feel of Firefox so it's hard to say what you expect to be right and how your expectation doesn't meet reality. -- damjan Hmm, well, I don't have anything specific set for FF look-and-feel. I'm using "GnomishDark" gtk+3 and gtk+2 themes though. By removing them (just default themes), I see a bit less contrast, but the same effect (light grayed). I uploaded a 2nd image on the same gist (shows below the 1st one): https://gist.github.com/je-vv/7a00601e9217cd9d3447 However, I just noticed I also have set in my gtk-3 settings: gtk-application-prefer-dark-theme = true And that together with the theme put in evidence the new grayed color. When unset, everything looks gray, icnlcuded the rest of the tabs, but still the bookmarks toolbar and the extensions area and the current tab look lighter, just that there's no big contrast given everything is gray (it also looks like lighter grayed). I uploaded a 3rd image for reference on the same gist, the one at the bottom: https://gist.github.com/je-vv/7a00601e9217cd9d3447 Looks like FF 44 actually made a change in here, making look lighter what's not other tabs and the main menu (hidden by default), which has the effect of a high contrast on dark gtk themes. I'm still no sure if this something that missed testing, or it's actually intentional. Looks like no one tested on dark themes, :-) Suggestions? Thanks, I am running FF-44 on the current Cinnamon desktop with the current Beta build of the NASA Night Launch theme which is a very dark theme with no odd issues.
Re: [arch-general] Cinnamon main menu bug?
On 12/28/2015 06:04 PM, Francis Gerund wrote: Hello. I am running Arch 64-bit, with the Cinnamon desktop environment. When I install an application program, it does not show up in the Cinnamon main menu until I restart Cinnamon. Then, there it is. Is this a known bug, or is it a "feature"? And is there a way to fix it so that added programs show up in the menu without restarting Cinnamon? Restart Cinnamon to load the new desktop file. This is not a bug but expected behavior.
Re: [arch-general] Problems using AUR since upgrade of pacman db version
On 01/01/2015 10:27 AM, Troy Engel wrote: On Thu, Jan 1, 2015 at 10:12 AM, Geoff wrote: Not intending to contradict, but rebuilding cower worked for me. I used a clean tarball and did makepackage --skipinteg (see the discussion under cower in the AUR) Same here on multiple systems. The pacman upgrade replaced libalpm.so from .8 to .9, you'll probably need to run 'pacman-db-upgrade', then rebuild/reinstall cower (another thread also mentioned package-query, which backs yaourt). If you're using pacaur there's an update for that as well which adds the prevent-as-root check to align with the new pacman 4.2 restriction. hth, -te The procedure described here, https://aur.archlinux.org/packages/package-query/ worked for package -query and pkgbrowser.