March 2014 - Arch-general - lists.archlinux.org

[arch-general] creating an archlinux usb key with persistence
by Don Raikes 13 Mar '14

13 Mar '14

Hi, Are there instructions for creating an archlinux usb key with persistence somewhere? I want to use my archlinux usb key as a diagnostic tool, and sometimes it is helpful to save files to it for later review. Any info would be appreciated. BTW: I am planning on using a 64gb usb key for this endeavor.

8 15

[arch-general] Zramswap for /tmp
by Mark Lee 13 Mar '14

13 Mar '14

Salutations, I wanted to float the idea of mounting /tmp on zram. We could still use the 50% ratio (or something less) but reduce the risk of running out of ram while using tmpfs. Regards, Mark

5 8

[arch-general] doubts about rolling release
by Ary Kleinerman 13 Mar '14

13 Mar '14

Hi, I'm a new Archer and I'm planning to install arch linux in a production server environment, but I have doubts because Arch is a rolling release. My question is: what does it happen when there are big changes? e.g. changes in the filesystem or when Arch has started using systemd. Regards, Ary -- *Ing. Ary Kleinerman* Building Networks S.A. Córdoba, Argentina +54 351 5544150

10 14

[arch-general] talkingarch problems formatting partitions
by Don Raikes 12 Mar '14

12 Mar '14

Hi, I downloaded the talkingarch-20140203-dual.iso yesterday and want to install it onto my desktop system. I booted into the talkingarchlinux system no problems, and used parted to create the partitions on my hard disk. When I go to format the partitions, as soon as I enter the command: # mkfs -t ext4 /dev/sda1 The entire system locks up. I have to do a hard reboot of the system to get anything working again. Any idea why this might be happening?

3 6

[arch-general] Incremental update for TeXLive 2013
by Rémy Oudompheng 12 Mar '14

12 Mar '14

Hello, I am going to push updated TeXLive packages to [extra]. The following bugs are expected to be fixed: https://bugs.archlinux.org/task/34932 https://bugs.archlinux.org/task/28560 https://bugs.archlinux.org/task/28514 Regards, Rémy.

5 4

[arch-general] "Partition" alignment with LVM on LUKS
by Mauro Santos 12 Mar '14

12 Mar '14

I've bought a new HD to replace one that is starting to show problems intermittently. I'm planning to keep a very similar setup to what I have currently, which uses LVM on LUKS. Old HD has 512B physical sectors so alignment there was not a problem. New HD however is an advanced format drive, that means a 4kB sector size and 512B logical sector size, that's where problems can start. The reason I'm asking for input on this is because I can't confirm with a good degree of certainty if things are all properly aligned, by doing and write and readback test (1). Either my google fu is not working or it's hard to find information on this. In [1] the question is similar but there is no answer. The guide on [2] shows some commands with explicit alignment options but the guide is not very recent. In [3] there is some general information and some benchmarks, but no concrete information about lvm on luks. In the wiki there is also mention to explicit alignment options but it's related to SSDs so not the case for me. The only one that seems to get close is [5], by looking at /sys/block/sdXN/queue/minimum_io_size it says 4096. Also for all other layers after that /sys/block/dm-[0-9]/queue/minimum_io_size (one belongs to luks and otherers to lvm) it also says 4096 so I _suppose_ automatic detection might leave things properly aligned. Here's the sequence of commands I have used: -used fdisk to create 2 partitions, used the suggested defaults for start of partition -used cryptsetup to format sda2, didn't use any alignment options -opened the encrypted volume and used pvcreate on it, again didn't use any alignment options -used vgcreate to create a new VG and added the PV I created before -used lvcreate to create several logical volumes, didn't use any alignment options -used mkfs.ext4 to format the logical volumes, also no alignment options used. I can't be 100% sure things are all aligned because of the following: (1) The machines I'm using now don't have AES-NI capable cpus, maximum encryption and decryption speeds are lower than the maximum raw speed of the hard disk (around 100MB/s). The machine where I have the disk connected now can encrypt at 64.5 MiB/s and decrypt at 68.0 MiB/s according to cryptsetup benchmark. Using 'dd if=/dev/zero of=testfile bs=10M count=100' I get 59.6 MB/s and with 'dd if=testfile of=/dev/null bs=10M' I get 59.2 MB/s. These values lead me to believe that everything is properly aligned. Unaligned reads usually don't incur in much of a performance penalty, while unaligned writes should make things slow to a crawl. I would like to get some input from anyone with knowledge or hands on experience on this before I commit to transplanting everything from the current HD to the new one, better get this right the first time than to have to redo it later again. Sorry for the long post and thanks in advance for any input. [1] https://bbs.archlinux.org/viewtopic.php?id=169841 [2] http://danynativel.com/blog/2013/02/10/archlinux-installation-guide-on-encr… [3] http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/ [4] https://wiki.archlinux.org/index.php/Lvm#Installing_Arch_Linux_on_LVM [5] http://serverfault.com/questions/356534/ssd-erase-block-size-lvm-pv-on-raw-… -- Mauro Santos

1 1

[arch-general] A bug about Bumblebee
by Liuyang 12 Mar '14

12 Mar '14

�� optirun firefox [ 1353.034599] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA GPU at PCI:1:0:0. Please [ 1353.034658] [ERROR]Aborting because fallback start is disabled. .................................................................................................................................................................... Kernel:3.10.33-1-lts Driver:nvidia-lts 334.21 ..................................................................................................................................................................... �� cat /etc/bumblebee/bumblebee.conf # Configuration file for Bumblebee. Values should **not** be put between quotes ## Server options. Any change made in this section will need a server restart # to take effect. [bumblebeed] # The secondary Xorg server DISPLAY number VirtualDisplay=:8 # Should the unused Xorg server be kept running? Set this to true if waiting # for X to be ready is too long and don't need power management at all. KeepUnusedXServer=false # The name of the Bumbleblee server group name (GID name) ServerGroup=bumblebee # Card power state at exit. Set to false if the card shoud be ON when Bumblebee # server exits. TurnCardOffAtExit=false # The default behavior of '-f' option on optirun. If set to "true", '-f' will # be ignored. NoEcoModeOverride=false # The Driver used by Bumblebee server. If this value is not set (or empty), # auto-detection is performed. The available drivers are nvidia and nouveau # (See also the driver-specific sections below) Driver=nvidia # Directory with a dummy config file to pass as a -configdir to secondary X XorgConfDir=/etc/bumblebee/xorg.conf.d [optirun] Bridge=auto VGLTransport=proxy PrimusLibraryPath=/usr/lib/primus:/usr/lib32/primus AllowFallbackToIGC=false ## Section with nvidia driver specific options, only parsed if Driver=nvidia [driver-nvidia] # Module name to load, defaults to Driver if empty or unset KernelDriver=nvidia PMMethod=bbswitch # colon-separated path to the nvidia libraries LibraryPath=/usr/lib/nvidia:/usr/lib32/nvidia # comma-separated path of the directory containing nvidia_drv.so and the # default Xorg modules path XorgModulePath=/usr/lib/nvidia/xorg,/usr/lib/xorg/modules XorgConfFile=/etc/bumblebee/xorg.conf.nvidia ## Section with nouveau driver specific options, only parsed if Driver=nouveau [driver-nouveau] KernelDriver=nouveau PMMethod=auto XorgConfFile=/etc/bumblebee/xorg.conf.nouveau .................................................................................................................................................................. �� cat /etc/bumblebee/xorg.conf.nvidia Section "ServerLayout" Identifier "Layout0" Option "AutoAddDevices" "false" Option "AutoAddGPU" "false" EndSection Section "Device" Identifier "DiscreteNvidia" Driver "nvidia" VendorName "NVIDIA Corporation" BusID "PCI:01:00:0" Option "ProbeAllGpus" "false" Option "NoLogo" "true" Option "UseEDID" "false" Option "UseDisplayDevice" "none" EndSection ....................................................................................................................................................................................................................................... And with kernel 3.15 and nvidia driver 334.21 I got the same message. Asking you for help.

2 1

Re: [arch-general] [arch-dev-public] Cyclic dependencies between systemd and util-linux
by Leonid Isaev 12 Mar '14

12 Mar '14

On Wed, 12 Mar 2014 17:21:20 +0100 Tobias Powalowski <tobias.powalowski(a)googlemail.com> wrote: > Am 12.03.2014 06:32, schrieb Gerardo Exequiel Pozzi: > > On 02/24/2014 03:56 PM, Thomas Bächler wrote: > >> Right now, we have a problem with cyclic dependencies in core: systemd > >> requires libblkid and libuuid (systemd-udevd) and util-linux requires > >> libudev (findmnt, and soon uuidd [1]). > >> > >> I don't like this situation and currently it is revoled by adding > >> systemd as optdepend to util-linux. This has the side effect that in a > >> chroot with only certain packages installed, one has to explicitly > >> install systemd to get findmnt working. Since I've run into this > >> situation and cyclic deps are bad, I propose the following: > >> > >> Split both util-linux and systemd into libutil-linux/util-linux and > >> libsystemd/systemd. Then we could have both util-linux and systemd > >> depend on both libsystemd and libutil-linux. > >> > >> [1] http://www.spinics.net/lists/util-linux-ng/msg08699.html > >> > > We also have another set when installing {base} group: > > > > warning: util-linux will be installed before its coreutils dependency > > warning: util-linux will be installed before its pam dependency > > warning: shadow will be installed before its pam dependency > > > > > New depends introduce error during base installation, > libutil-linux needs coreutils first else no install is found. Sorry for cross-list posting... Actually, this is an old error which I saw on all new installs for quite some time. For example: ----- [2014-02-14 19:46] [PACMAN] installed shadow (4.1.5.1-7) [2014-02-14 19:46] [ALPM-SCRIPTLET] /tmp/alpm_p51CHp/.INSTALL: line 6: install: command not found [2014-02-14 19:46] [PACMAN] installed util-linux (2.24.1-1) ----- Cheers, L. -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

1 0

Re: [arch-general] [arch-dev-public] Upgrading Apache to 2.4
by Anatol Pomozov 11 Mar '14

11 Mar '14

Hi + php maintainer On Thu, Mar 6, 2014 at 3:05 PM, Rene Pasing <rene(a)pasing.net> wrote: > Hi Anatol, > > On 03/06/2014 10:48 PM, Anatol Pomozov wrote: >> Apache 2.4 has been moved from [testing] to [extra] and now available >> for everyone. Please update your setup, follow the migration >> instructions https://httpd.apache.org/docs/trunk/upgrading.html and >> report any problems. Thanks everyone. > > I get the following error: > > Mar 06 23:59:34 VAIO-ARCH apachectl[697]: [Thu Mar 06 23:59:34.072638 > 2014] [:crit] [pid 699:tid 139754760394624] Apache is running a threaded > MPM, but your PHP Module is not compiled to be threadsafe. You need to > recompile PHP. > Mar 06 23:59:34 VAIO-ARCH apachectl[697]: AH00013: Pre-configuration failed > Mar 06 23:59:34 VAIO-ARCH systemd[1]: httpd.service: control process > exited, code=exited status=1 > Mar 06 23:59:34 VAIO-ARCH systemd[1]: Failed to start Apache Web Server. > Mar 06 23:59:34 VAIO-ARCH systemd[1]: Unit httpd.service entered failed > state. > > I will switch to php-fpm soon, but nevertheless... Just wanted you to be > aware... ;-) Sounds like a bug to me. Mind filing one at bugs.archlinux.org? Pierre, I found some information in Google+ related to apache24 package in aur: "The only thing was that I had to recompile PHP to be thread-safe. It was '--enable-zts' parameter, I think...". The flag sounds like a solution for this bug.

7 9

[arch-general] Security vulnerability (CVE-2014-0004) in udisks/udisks2
by Manuel Reimer 11 Mar '14

11 Mar '14

Hello, I already flagged the packages out of date, but maybe other people are interested, too, that there is a known security hole in udisks/udisks2, which has been fixed upstream with new releases: http://lists.freedesktop.org/archives/devkit-devel/2014-March/001568.html Greetings, Manuel

3 6