- Arch-general - lists.archlinux.org

[arch-general] iptutils 20150815.1b5d03a-2 and ipv4-only system
by Leonid Isaev 10 Sep '15

10 Sep '15

Hi, I noticed that ping in [testing]/iputils does not work on systems with disabled IPv6 stack. For example (as root): ---------- # ping archlinux.org ping: socket: Operation not permitted (raw socket required by specified options). # cat /proc/cmdline BOOT_IMAGE=../vmlinuz-linux ... ipv6.disable=1 ... # pacman -Qo ping /usr/bin/ping is owned by iputils 20150815.1b5d03a-2 # getcap /usr/bin/ping /usr/bin/ping = cap_net_raw+ep ---------- I tried playing with cmdline options, without any success. ping from [core]/iputils 20140519.fad11dc-1 does work. Is this a bug or a feature, and does anyone know how to make ping work again? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

4 7

Re: [arch-general] Remove ca-certificate-cacert dependencies
by Felix Yan 10 Sep '15

10 Sep '15

On 09/10/2015 03:53 PM, Niklaus Schiess wrote: > Hi, > > the ca-certificates package depends on ca-certificates-cacert, which in > my opinion should not be the case. What seems to be the proper way to > remove CAcert certificates from the trust store? Just remove the certs > with `trust anchor`, or pacman -Rdd ca-certificates-cacert? Both seem to > be temporary fixes. I suggest the CAcert certificates should be removed > or at least the ca-certificates package should not depend on them. The package "ca-certifcates" is a virtual package that provided by "ca-certificates-utils" too, so you can simply remove ca-certificates-cacert together with ca-certificates. -- Regards, Felix Yan

1 0

[arch-general] DHCP server package orphaned
by Mike Cloaked 10 Sep '15

10 Sep '15

Having seen that the dhcp server package has been orphaned yesterday, hopefully this will be picked up and maintained as it is a pretty important standard package for a server. -- mike c

2 2

[arch-general] Remove ca-certificate-cacert dependencies
by Niklaus Schiess 10 Sep '15

10 Sep '15

Hi, the ca-certificates package depends on ca-certificates-cacert, which in my opinion should not be the case. What seems to be the proper way to remove CAcert certificates from the trust store? Just remove the certs with `trust anchor`, or pacman -Rdd ca-certificates-cacert? Both seem to be temporary fixes. I suggest the CAcert certificates should be removed or at least the ca-certificates package should not depend on them. Regards, Niklaus -- PGP FP: CB84 8C68 ADDB 6C50 7DF1 4227 F2A6 056A A799 76DA

1 0

[arch-general] systemd-networkd 226 in virtual machines
by Damjan Georgievski 09 Sep '15

09 Sep '15

in 226, systemd-networkd now supports predictable interface names for virtio devices.[1] For people running Arch in KVM with virtio-net (as I do), that means the network interface name will change from eth0 to - in my case - ens5. That, for me also meant no ip address after reboot. Make sure to set [Match]Name=en* or some such before rebooting. [1] https://github.com/systemd/systemd/blob/23d08d1b2bfd7f4b3c0a9408c9ccd65c3fb… -- damjan

2 1

[arch-general] Any ETA on the Tex Live 2015 update?
by Mohammad_AlSaleh 07 Sep '15

07 Sep '15

Hello. Tex Live 2015 was released on June 11. The Arch packages were flagged out-of-date on June 13. I'm wondering if there is any reason for the hold-up. Other than the maintainers(s) being busy of course.

7 9

[arch-general] ca-certificates update
by mick 07 Sep '15

07 Sep '15

After re-installing in july I'm having problems with certificates and was pointed to https://www.archlinux.org/news/ca-certificates-update/ ca-certificates update 2014-12-11 - Jan Steffens The way local CA certificates are handled has changed. If you have added any locally trusted certificates: 1 Move /usr/local/share/ca-certificates/*.crt to /etc/ca-certificates/trust-source/anchors/ 2 Do the same with all manually-added /etc/ssl/certs/*.pem files and rename them to *.crt 3 Instead of update-ca-certificates, run trust extract-compat Also see man 8 update-ca-trust and trust --help. when I tried step 2: move /etc/ssl/certs/*.pem to /etc/ca-certificates/trust-source/anchors/ and rename them to *.crt I found 1 the mv command seems to have lost the ablity to rename files as they are moved. 2 moving or copying the *.pem file results in adirectory full of broken links. I think the solution might be to create symlinks to the real files, located at /etc/ca-certificates/extracted/cadir instead of linking to link to the files but before I try that I want to be sure I wont break anything. mick

1 0

[arch-general] systemd 215 breaks machinectl login
by arnaud gaboury 05 Sep '15

05 Sep '15

I just upgraded to systemd 215, and connaction to my container is broken. # machinectl login MyMachine Connected to machine MyMachine. Press ^] three times within 1s to exit session. Then it hangs here indefinitely. No login shell. -- google.com/+arnaudgabourygabx

1 0

[arch-general] Update problems
by edson duarte 02 Sep '15

02 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 hi! pacman reports that the repositories are up to date for a couple of weeks now with no errors or warnings and this had never happened, i've tried looking in the forums and the news on the website but found nothin g. anyone knows why this is happening? thanks! - -- edson duarte https://emailselfdefense.fsf.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV5vmTAAoJEEuaWOJw2A3L0HIP/3hK2qGN8mvismCbOBiIf+9k 7il7ROwjRkd1NadoHXawMkgDu6ywLYVCiSy5K5nR6+Jz4opAE9xoWKdyJ5b6sWNp tEwKu73JWlEV7Wrnl7aEZcj6U/QW6yRdQic+9eQABBL3HEilScgloYsvS1ZrhON5 1spLWWEbQi6XwNgKqoRFkewybUFMfJXd+zWNdlVSKuBi1Repr+JsRnfStzHuLBKQ MptNCC+ybJTmJ/KFvw7dDjObb1tDXNjEzLpdNok1RFLcrMeYCrmBM3soOsn6EGuf vFyRXZuMKxI+y4DdlFCeIkBhw/XPd7c48bkkw/tj1RpYl9OCKAbpVK79J3p7r25k jTZLbsqE+D2R8aT4i9Ji3f/Se6tWvUuwhxKaxhY4RshpMdPo311Eiz+8OO8aMz3+ iwxfxHDzcgUhrAtGU6LWlEnUjgoDa1oBa+uvXpEgBcmJsKay5ueM06WDAxXu31Vg 89RY3+pD7hbjNidiKdZFfF4IvNTsokFFHGaCh/ui51ceRcXjfCePJLBftc21R/2a ak2PKsBsJYxIgLL4z3l6heulmqiOmpOnDzUgrfna05q+0jDfhS1Fis3suyV31dzZ 5oi5+tWl+Nkp80h/XbRUGHYjkMt/gJ14Kr/Bu0WYx01urd16SpbvUEyMq28utdyP ZKhyX2tOnApKKo/giWze =rBdK -----END PGP SIGNATURE-----

2 2

[arch-general] Strange mdadm fail to activate root raid1 array - resulting in loss of libraries and pacman data?
by David C. Rankin 01 Sep '15

01 Sep '15

All, I saw TB's patch posts to the kernel-raid mailing list. I believe I experienced the same systemd-mdadm error which resulted in ~440 libraries being left as 0-byte files and pacman losing all reference to what files where owned by what packages. In my case dmesg showed the system never made any attempt to activate sda7 as part of the root array (md1) on boot. Following a --fail, --remove and --add to re-add sda7 worked as advertised. However, on next reboot, grub was found and launched the kernel, only to have the system crash due to /usr/lib/libkmod.so "file too short" (0-byte). Attempting to re-install the kernel to attempt to address the issue resulted in: [2015-08-31 15:58] [ALPM-SCRIPTLET] ==> WARNING: No modules were added to the image. This is probably not what you want. [2015-08-31 15:58] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img [2015-08-31 15:58] [ALPM-SCRIPTLET] ==> WARNING: errors were encountered during the build. The image may not be complete. [2015-08-31 15:58] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback' [2015-08-31 15:58] [ALPM-SCRIPTLET] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect [2015-08-31 15:58] [ALPM-SCRIPTLET] ==> Starting build: 4.1.6-1-ARCH [2015-08-31 15:58] [ALPM-SCRIPTLET] -> Running build hook: [base] [2015-08-31 15:58] [ALPM-SCRIPTLET] -> Running build hook: [udev] [2015-08-31 15:58] [ALPM-SCRIPTLET] -> Running build hook: [modconf] [2015-08-31 15:58] [ALPM-SCRIPTLET] -> Running build hook: [block] [2015-08-31 15:58] [ALPM-SCRIPTLET] ==> ERROR: module not found: `eata' [2015-08-31 15:58] [ALPM-SCRIPTLET] ==> ERROR: module not found: `a100u2w' [2015-08-31 15:58] [ALPM-SCRIPTLET] ==> ERROR: module not found: `3w_sas' [2015-08-31 15:58] [ALPM-SCRIPTLET] ==> ERROR: module not found: `bnx2fc' <snip> lots of modules not found Booting the install media, chrooting and investigating revealed some 440 libraries in /usr/lib that were 0-byte. pacman had also lost its package-file database. E.g. # pacman -Ql unixodbc # (showed no files) all of this occurred with mdadm 3.3.2-2, which is still the current package. TB's original post at the kernel raid list regarding the patch is: [PATCH 0/2] mdadm: Fix udev rule interaction with systemd, http://www.spinics.net/lists/raid/msg49678.html The explanation of the losses on my system posted to the list are: Re-add of raid1 drive resulted in strange loss of data on Archlinux? http://www.spinics.net/lists/raid/msg49704.html Are these the symptoms (or related symptoms) that the TB's patch is intended to address? This has only occurred once since the current mdadm was installed back on 2015-05-26. What is the recommended work-around until a fix is in place? (validate all arrays with /proc/mdstat) But then how to handle a degraded boot? I did --fail, --remove --add, and ended up with a mess. Is there some other suggested way to handle this? -- David C. Rankin, J.D.,P.E.

1 0