- Arch-general - lists.archlinux.org

[arch-general] On /etc/conf.d deprecation
by Dimitrios Apostolou 11 Dec '12

11 Dec '12

Hello list, from a reply I got to a bug report (FS#32817, reply is private) I found out that configuration files in /etc/conf.d are deprecated and that the supported way is to replicate and customize service files. Imagine that in /usr unit file the daemon is being called as "binary -d". So I create the /etc unit file that supersedes it and calls it as "blah -d -n1". Then the package gets updated and the /usr unit file changes to "binary -d --lock=/whatever/path". As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called "binary -d --lock=/whatever/path $BLAH_ARGS" there would have been no such problem. /etc/conf.d is a weaker but more elegant mechanism. I'm not saying it should replace unit files, but it should work *with* unit files, as the Arch way even if not in Freedesktop's - Fedora's recommendations. Of course anyone will still be free to copy and customize the unit file. So I'm curious to know why this mechanism was deprecated? Is it speed we gain by not including the EnvironmentFile directive in the systemd unit file? Is there some other reason I might be missing? Thanks in advance, Dimitris

9 15

[arch-general] booting from encrypted partition - reevaluate partition table (gpt, kpartx, cryptdevice, grub2)
by Marek Otahal 11 Dec '12

11 Dec '12

Hi fellow archers, I have the following problem: On a physical (gpt) partition I have an encrypted LUKS partition which contains GPT partition table with desired final partitions (/,/home, etc..) I decided to skip LVM as gpt fulfils my needs (many primary partitions, easy resize), but using kernel boot parameters (grub2): linux /vmlinuz-linux root=/dev/mapper/crypto3 cryptdevice=/dev/sdb6:crypto:allow-discards resume=/dev/mapper/crypto1 ro quiet I do not get expected result (and how partitions really look like): # lsblk -f NAME FSTYPE LABEL MOUNTPOINT sda ├─sda1 ntfs data ├─sda2 btrfs backup ├─sda9 ext4 / └─sda10 └─cryptswap1 (dm-0) swap [SWAP] sdb ├─sdb1 ext4 boot /boot ├─sdb2 vfat EFI /boot/efi ├─sdb3 ├─sdb4 ntfs win8 ├─sdb5 crypto_LUKS └─sdb6 crypto_LUKS └─crypto (dm-1) ├─crypto1 (dm-2) swap swap ├─crypto2 (dm-3) btrfs var ├─crypto3 (dm-4) btrfs arch └─crypto4 (dm-5) btrfs home This is what I really get (and what I get when cryptsetup luksOpen /dev/sdb6 crypto ): # lsblk -f NAME FSTYPE LABEL MOUNTPOINT sda ├─sda1 ntfs data ├─sda2 btrfs backup ├─sda9 ext4 / └─sda10 └─cryptswap1 (dm-0) swap [SWAP] sdb ├─sdb1 ext4 boot /boot ├─sdb2 vfat EFI /boot/efi ├─sdb3 ├─sdb4 ntfs win8 ├─sdb5 crypto_LUKS └─sdb6 crypto_LUKS └─crypto (dm-1) I would need the system to reevaluate/recheck the newly opened partition if it contains other partitions! I found a related thread: http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5896 Now a workaround: 1/ install kpartx and add it to BINARIES="kpartx" in /etc/mkinitcpio.conf 2/ hack /lib/initcpio/hooks/encrypt and put line kpartx -a /dev/mapper/crypto right behind every "cryptsetup .. luksOpen ..." line there. 3/ similarly, I should place "kpartx -d /dev/mapper/crypto" before "cryptsetup .. luksClose ..." is called during shutdown. I did not find these routine in hooks/encrypt, where does it happen? I'd like to know if there is any supported solution for this, or any advice from you. Thank you for help! Have a nice day, Mark -- Marek Otahal :o)

1 0

[arch-general] Secure Boot Support
by kristof 11 Dec '12

11 Dec '12

Now that Matthew Garrett's shim is fully featured and publicly available, will Arch be implementing support for secure boot in the near future? For those who haven't seen the news yet: http://mjg59.dreamwidth.org/17542.html and http://mjg59.dreamwidth.org/20303.html give a pretty in-depth description of how to implement this distro-generic solution to secure boot. More technical details on the shim are available here: http://mjg59.dreamwidth.org/19448.html Finally, I found this OpenSUSE dev post pretty helpful in understanding how the MOKs work but it's not a necessary article to read: https://www.suse.com/blogs/uefi-secure-boot-details/ The only work necessary on the packager's part is using Peter Jones' signing tool to sign GRUB2, kernel modules, and the Arch Linux distributed kernel binaries with an Arch Linux "key" that the users would place into the shim's trusted key database. This isn't any more cumbersome than the current package signing procedures, and I think it would go a long way to be one of the first distributions to support secure-boot without having to fiddle with the UEFI. A final note: the shim currently only supports x86_64 machines and it's unknown if Garrett will ever work on a 32-bit binary. That, on top of the fact that Garrett won't be working on an ARM solution because of licensing issues, means that secure boot would simply be an Arch64 specific feature. I'd really like to hear the community's thoughts on this.

7 12

[arch-general] Fwd: [arch-dev-public] Secure Boot Support
by Keshav P R 11 Dec '12

11 Dec '12

On Tue, Dec 11, 2012 at 3:15 PM, Thomas Bächler <thomas(a)archlinux.org>wrote: > Am 10.12.2012 17:21, schrieb kristof: > >> Could you refer to any documentation about this? Why would the boot > >> loader need to call back into shim? > > > > I'm going off of my correspondence with Matthew Garrett in the comments > > section of a post he wrote concerning the shim. His reply to me when I > > asked what distros who don't use rEFInd or GRUB in their installation > > media (like ours) is as follows(from: > > http://mjg59.dreamwidth.org/20303.html?view=813903&posted=1#cmt813903) > > Just as I thought: Calling back into shim is necessary/useful if you > want your second-stage bootloader to verify kernel signatures. If you > don't do that, you can probably use just about any UEFI bootloader. > > Boot Managers (not bootloaders) like rEFInd and Gummiboot require the kernel to be signed with one of the keys present in the UEFI firmware database, since its finally the firmware that is going to launch the kernel EFISTUB as a normal .efi file, and the firmware won't launch unless the key with which the kernel is signed, is present in the firmware database (not the shim's MOK database, which is independent of firmware key database). Please correct me if I am wrong, but I am not sure even shim's keys might work for EFISTUB. One can create their own keys and enroll that key into the database. More info at http://rodsbooks.com/efi-bootloaders/secureboot.html and http://rodsbooks.com/refind/secureboot.html . > This would be an infinitely nicer solution, if it were not for the fact > > that there aren't any bootloaders available which can insure a > > completely trusted chain of execution. I can manually specify in the > > UEFI to load bootloader X signed with Arch's key but bootloader X, > > unless hardcoded to do so, can't make sure that kernel X and module X > > are signed by the very same key. This leads to arbitrary code execution > > and we all know why this is a bad idea. > > Future bootloaders will probably solve this problem by providing proper > verification of kernel and initramfs. For the moment, all that I would > really _want_ to achieve is to make Arch boot flawlessly on Secure Boot > machines without relying on Secure Boot's "Setup Mode" (meaning disabled > verification, which would in turn make Windows 8 angry). Matthew's shim > seems to make this possible. > > I have a secure-boot capable system ( https://wiki.archlinux.org/index.php/HCL/Firmwares/UEFI#Lenovo_Thinkpad_Edg…) but have secure-boot disabled for now. I am also dual-booting Windows 8 x64 Pro, and the only message the upgrade assistant showed was that secure boot was disabled in the system when installing. Windows 8 boots perfectly fine with secure boot disabled in UEFI mode. I even have CSM (BIOS compatibilty layer) disabled in the firmware setup. So I suggest asking people to disable or change secure-boot mode to setup mode in their system before installing Arch, instead of using Microsoft signed shim binary etc. Adding further to this, I would prefer if the user generates, signs the uefi apps and the kernels he/she wants to use him/herself, and also manage the keys by themself, instead of creating a central Arch specific secure-boot key or any key from a dev. Regards. Keshav > > >

1 0

[arch-general] systemd and core dumps
by Olivier Langlois 11 Dec '12

11 Dec '12

Apparently core dumps (if enabled) are stored in the systemd journal. ~ $ cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e systemd-coredumpctl looks nice to use but I am not totally sure yet that collecting core dumps in the journal is something that I want systematically. I am looking for a way to override this. I haven't found any mention of that option in systemd documentation. Does anyone here would have an idea where I could search? Olivier

3 2

[arch-general] python+pango
by Fons Adriaensen 10 Dec '12

10 Dec '12

Hello all, Is there a python3 module for pango (as there is one for cairo) ? pacman -Ss pango gives me: extra/libtiger 0.3.4-3 A rendering library for Kate streams using Pango and Cairo extra/pango 1.32.3-1 [installed: 1.30.1-1] A library for layout and rendering of text extra/pango-perl 1.223-2 Perl bindings for Pango extra/pangomm 2.28.4-1 [installed] C++ bindings for pango extra/pangomm-docs 2.28.4-1 Developer documentation for pangomm extra/pangox-compat 0.0.2-1 X Window System font support for Pango extra/sdl_pango 0.1.2-4 Pango SDL binding community/haskell-pango 0.12.4-1 Binding to the pango library for Gtk2Hs. community/ruby-pango 1.1.5-1 Ruby bindings for pango so it looks like the answer is no... Yet there are examples on the web, e.g.: http://cairographics.org/pycairo_pango/ ?? -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

2 1

[arch-general] Concerning Secure Boot Support
by kristof 10 Dec '12

10 Dec '12

For those of you who care (and you may not number very many): As it stands, Gummiboot doesn't support calling back to Matthew Garrett's shim and until this happens it won't work in secure boot mode. I'm not aware of Pierre Schmitz's reasoning for using Gummiboot as opposed to rEFInd, but if the official archiso is to boot on secure bootable machines, it'll have to either use rEFInd or Fedora 18's RC's GRUB2 (the current install media of Fedora 18 uses the latter). These are essentially the only two options until syslinux gets a stable EFI release and does the same sort of hardcoded shim support. Notice I said Fedora's, and not upstream's. Upstream GRUB2 doesn't support kernel verification against the MOK database yet so Fedora 18 is shipping a patched version. Assuming we weren't going to wait for GRUB2 to support secure boot, we could ship Fedora's bootloader instead or apply similar patchwork, but this goes against Arch philosophy and it might be easier to simply wait for upstream support. Regardless of what Arch does the decision will have to come from someone with much more authority on Arch's direction; either Pierre because he's the one rolling out the monthly iso or another developer because using non-vanilla software, even something as critical as a bootloader, isn't very Arch-like. Someone correct me if I'm wrong. Not only that, but setting up a system of signing kernels, modules (out-of-tree modules are a beast that haven't been worked out yet beyond self-signing), and GRUB2 as well as rEFInd (for those who choose to use a boot manager beyond their UEFI's) with openssl generated x509 certificates using either Fedora's pesign (what MJG recommends) or Ubuntu's sbsign (a similar too that I've used and can guarantee will work) is a bit of work on its own. Lastly, the shim itself needs to be pulled into [extra] and it should come with some script like "shim-install" which would simply rename the grub-efi binary as grubx64.efi and would place the shim in /boot/efi/EFI/BOOT/x86_64/, renaming it bootx64.efi. Not so difficult at all, but it's another thing to do. That's only the technical implementation, however. Documentation would be tricky considering every manufacturer designs their UEFI implementation a little bit differently; on my system, I was stumped until I realized that regardless of the shim being signed by Microsoft's key I had to actually specify in the interface that I wanted to trust that particular .efi file. One point of the shim is so that launching Linux on a new machine isn't anymore daunting than changing the boot device order (I wouldn't worry so much about this with Arch users, however) but if the user still has to muck about in firmware that is different for everybody, one of many purposes has been swiftly defeated. Anyway, that's pretty much everything that's keeping secure boot from coming to Arch Linux for now. Well, that, and the fact that no developer actually owns a UEFI machine with secure-boot support. We'll see what happens in the future, I suppose. Thoughts and comments are requested.

3 2

[arch-general] crypttab support for non-root devices with systemd
by Karol Babioch 09 Dec '12

09 Dec '12

Hi, I've installed Arch on a system with a two "disk" setup, where the first disk is a SSD, which I'm booting from. The second disk is an encrypted software RAID with LVM on top. Now obviously I want the second "disk" to be unlocked and mounted automatically on boot. This was no problem in the past. Now with systemd it seems to be harder. At least I get asked for the password on boot. This will unlock the device, however afterwards I have to activate the LVM and mount it manually. Is this already supported out of the box? The wiki mentions something about scripts, which may be changed, but I would like to have something more solid than self made scripts, which may break with every update in the future. Best regards, Karol Babioch

2 6

[arch-general] Switching between Internet connections
by Sudaraka Wijesinghe 09 Dec '12

09 Dec '12

Hello, My laptop is connected to a LAN with Internet connection and it gets the IP stuff (address, routing, dns) via dhcp using the default systemd scripts on boot. I also have a 3G modem (USB) which I have created the ppp scripts to connect based on the Wiki article https://wiki.archlinux.org/index.php/3G_and_GPRS_modems_with_pppd Both connections work fine, except after switching to modem from LAN some applications (pidgin, xchat, ect. which were running) still uses the DNS nameserver from previous connection (LAN) meaning they still trying to send DNS queries to LAN router (which is not reachable at that time). This gets fixed after that application is closed and reopened. Is this behavior normal or a bug? Thanks. P.S. To disconnect/connect from LAN I either use: > # systemctl stop dhcpcd@wlan0 > # systemctl start dhcpcd@wlan0 or > # dhcpcd -k wlan0 > # dhcpcd wlan0 To disconnect/connect I use poff/pon commands and the scripts are setup exactly as described on the Wiki. -- Sudaraka Wijesinghe.

5 4

[arch-general] Executing a command of a chroot outside of the chroot
by Δημήτρης Ζέρβας 08 Dec '12

08 Dec '12

I have a chroot environment on /data/workbench/mnt and I want to execute a binary which is inside the chroot environment (for example /data/workbench/mnt/bin/bash). I added the chroot library path to $LD_LIBRARY_PATH and I just did /data/workbench/mnt/bin/bash. I get a very strange error: No such file or directory. I am ABSOLUTELY sure that the file exists. When I chroot /data/workbench/mnt /bin/bash everything runs smoothly without errors. What's going on? BTW: I'm on armv7l -- (\_ /) copy the bunny to your profile (0.o ) to help him achieve world domination. (> <) come join the dark side. /_|_\ (we have cookies.)

4 8