- Arch-general - lists.archlinux.org

[arch-general] IRC down?
by arnaud gaboury 12 Dec '12

12 Dec '12

I can't post to #archlinux because I am banned. It seems weird to me, or am I really banned for whatever reason?

3 2

[arch-general] [signoff] linux-3.6.10-1
by Tobias Powalowski 12 Dec '12

12 Dec '12

Hi guys, please signoff 3.6.10 series for both arches. package is not in testing, please grab it from here: http://dev.archlinux.org/~tpowa/linux/ This will move to [core] directly, because 3.7 is in [testing]. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-general] samba4
by Juan Diego Tascón 12 Dec '12

12 Dec '12

Good day, Does someone has a working PKGBUILD for the new samba4 besides the samba4 from aur? if someone has it I would like to help with the tests. Cheers

1 0

Re: [arch-general] NFS close-to-open
by Bryan Schumaker 12 Dec '12

12 Dec '12

On 12/12/2012 05:35 AM, Paul Gideon Dann wrote: > On Tuesday 11 Dec 2012 12:08:46 you wrote: >> After more poking-about: filp_close() in the VFS calls nfs_file_flush(), >> which writes the file back to the server. The struct file we're given is >> freed up shortly after calling flush, so this looks like the last chance we >> get to write changes (and I don't think we should change that). > Hmm, so is this maybe an implementation limitation? I would expect "nocto" to > prevent that flushing, since that seems to be the main purpose of "nocto". > But maybe it would have been too much work to buffer the flushes, and so every > file gets flushed on close anyway? > > Paul Something like that, yeah. "nocto" just applies to the attribute cache, and does not change the flushing behavior. - Bryan

1 0

[arch-general] Diskless Booting Wiki Help
by Paul Gideon Dann 11 Dec '12

11 Dec '12

Hi guys, I'm not sure who's actually in charge of oversight on the Wiki, but I'd appreciate a little input from anyone, really. I've recently been trying to ensure the accuracy of the wiki with regards to diskless booting. I run a cluster at work, and I've spent quite some time looking into getting this system functioning correctly, and I wanted to make sure the documentation was there for others to use. However, another (presumably well-intentioned) contributor has rewritten the original article, and seems very keen to cut back everything he doesn't agree with. To be honest, I'm a bit sick of trying to convince him that all information is helpful, and that not everyone that reads the article will have his usecase. In particular, he's keen to remove all references to NFSv3 (although Arch doesn't currently support booting NFSv4 without his hack), and needing a separate /var for each node (which I've explained is necessary in many, if not most, situations). I'd appreciate someone taking a look at the talk page and article history. (I'm Giddie on the wiki.) If it's decided I'm wrong, I'm fine with that. I'm just keen for the wiki to be as helpful as possible, and I don't think that's the case right now. https://wiki.archlinux.org/index.php/Network_Installation_Guide Help appreciated, Paul

2 1

[arch-general] NFS close-to-open
by Paul Gideon Dann 11 Dec '12

11 Dec '12

I've been learning about the close-to-open policy of NFS, which causes each file to be flushed to the server as it's closed, to ensure consistency across clients. This is a big performance hit when trying to upgrade the system, because of the numerous writes to small files. I know about the "async" export option, obviously, but there is also a "nocto" client mount option, which is supposed to disable the close-to-open mechanism for that client. As far as I can tell, this is supposed to stop the client from flushing the file when it closes it (as well as not bothering to check cache consistency when it opens). However, this seems to have no effect: the client is still flushing the file to the server on close, causing massive wait-io. Does anyone have any idea why "nocto" doesn't have the effect I was hoping it would? The "async" option works as expected, but it's more important to me that the client cache is correct, and it just bugs me. Thanks for any insight, Paul

2 6

[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