[gentoo-user] cryptsetup wont use aes-xts:plain64
hello list, i try to crypt a partition with cryptsetup. Yes, in Kernel i had all need things i think. CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=m CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=m CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_USER=m # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_PCRYPT=m CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_MCRYPTD=m CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_ABLK_HELPER=m CONFIG_CRYPTO_GLUE_HELPER_X86=m CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_SEQIV=m CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CTR=m CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=m CONFIG_CRYPTO_CMAC=m CONFIG_CRYPTO_HMAC=m CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_VMAC=m CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRC32C_INTEL=m CONFIG_CRYPTO_CRC32=m CONFIG_CRYPTO_CRC32_PCLMUL=m CONFIG_CRYPTO_CRCT10DIF=y CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m CONFIG_CRYPTO_GHASH=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_RMD128=m CONFIG_CRYPTO_RMD160=m CONFIG_CRYPTO_RMD256=m CONFIG_CRYPTO_RMD320=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA1_SSSE3=m CONFIG_CRYPTO_SHA256_SSSE3=m CONFIG_CRYPTO_SHA512_SSSE3=m CONFIG_CRYPTO_SHA1_MB=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_BLOWFISH_COMMON=m CONFIG_CRYPTO_BLOWFISH_X86_64=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAMELLIA_X86_64=m CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m CONFIG_CRYPTO_CAST_COMMON=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST5_AVX_X86_64=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_CAST6_AVX_X86_64=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_DES3_EDE_X86_64=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m CONFIG_CRYPTO_SERPENT_AVX_X86_64=m CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_ZLIB=m CONFIG_CRYPTO_LZO=m CONFIG_CRYPTO_LZ4=m CONFIG_CRYPTO_LZ4HC=m CONFIG_CRYPTO_ANSI_CPRNG=m CONFIG_CRYPTO_DRBG_MENU=m CONFIG_CRYPTO_DRBG_HMAC=y # CONFIG_CRYPTO_DRBG_HASH is not set # CONFIG_CRYPTO_DRBG_CTR is not set CONFIG_CRYPTO_DRBG=m CONFIG_CRYPTO_USER_API=m CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_SKCIPHER=m CONFIG_CRYPTO_HASH_INFO=y # CONFIG_CRYPTO_HW is not set but when i try to use cryptsetup i get this: # cryptsetup -c aes-xts:plain64 -y -s 256 luksFormat /dev/mapper/VolGroup01-media2 WARNING! This will overwrite data on /dev/mapper/VolGroup01-media2 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: device-mapper: reload ioctl on failed: Invalid argument Failed to setup dm-crypt key mapping for device /dev/mapper/VolGroup01-media2. Check that kernel supports aes-xts:plain64 cipher (check syslog for more info). Any ideas? i built cryptsetup with this useflags: nls openssl python udev urandom cryptsetup --help shows me i am able to use the options Default compiled-in device cipher parameters: loop-AES: aes, Key 256 bits plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160 LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha1, RNG: /dev/random any help / ideas or knowledge welcome. best regards marko --
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
Am 18.04.2015 um 12:27 schrieb Marko Weber | 8000: i try to crypt a partition with cryptsetup. Yes, in Kernel i had all need things i think. No, you haven't. You need to make those changes: CONFIG_CRYPTO_XTS=m CONFIG_CRYPTO_XTS=y CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_AES_X86_64=y CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_AES_NI_INTEL=y (only if you have an Intel CPU) You have to compile the modules which are necessary for the encryption method you're using directly into the kernel, not as a module, because the kernel needs them directly at boot time. but when i try to use cryptsetup i get this: # cryptsetup -c aes-xts:plain64 -y -s 256 luksFormat /dev/mapper/VolGroup01-media2 The correct command is: # cryptsetup -s 256 -y -c aes-xts-plain64 luksFormat /dev/mapper/VolGroup01-media2 Maybe you should consider those parameters: -s 512 (for a longer key) -h sha512 (otherwise sha1 will get used for the password hash) --use-random (manpage says: Using /dev/urandom can lead to weak keys.)
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
On 04/18/2015 02:07 PM, Heiko Baums wrote: You have to compile the modules which are necessary for the encryption method you're using directly into the kernel, not as a module, because the kernel needs them directly at boot time. No. Could you please explain why you think so? Even if your root partition is encrypted, your ramdisk could load the modules. After loading the modules you can see that they are available by cat /proc/crypto. The modules can be loaded _after_ bootup as well. Cheers Ralf
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
Am 18.04.2015 um 12:27 schrieb Marko Weber | 8000: i try to crypt a partition with cryptsetup. Yes, in Kernel i had all need things i think. Depending on the password hash you're using (parameter -h) you need to make the appropriate changes here, too: CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA1_SSSE3=m CONFIG_CRYPTO_SHA1_SSSE3=y CONFIG_CRYPTO_SHA256_SSSE3=m CONFIG_CRYPTO_SHA256_SSSE3=y CONFIG_CRYPTO_SHA512_SSSE3=m CONFIG_CRYPTO_SHA512_SSSE3=y CONFIG_CRYPTO_SHA1_MB=m CONFIG_CRYPTO_SHA1_MB=y CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_SHA512=y
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
Hi, @Marko tl;dr: it's going a bit offtopic. Marko, try to hardcompile those modules into your kernel. This should be the simplest fix of your problem. On 04/18/2015 02:44 PM, Heiko Baums wrote: Am 18.04.2015 um 14:12 schrieb Ralf: No. Could you please explain why you think so? Even if your root partition is encrypted, your ramdisk could load the modules. Are you sure about that? Are you sure that the necessary modules are definitely put into the initrd and that the kernel will be able to load them soon enough at boot time? I double checked it and now I am sure: For reasons of comfortability I inspected a standard Arch-Linux installation. It supports rootfs encryption and xts is loaded in the initrd as module. So it is possible to treat it as a module. Besides that: Why should your kernel config allow you to compile it as module if it isn't useable as module? Compiling those modules into the kernel is definitely more secure (in terms of being sure that they are always available) and doesn't do any harm, because they need to be loaded anyway. Yes for a homebrew kernel, i can second that. Btw., several dm-crypt/LUKS documentation (all that I've read) say that those modules have to be compiled into the kernel directly. After loading the modules you can see that they are available by cat /proc/crypto. You won't be able to run this command when the kernel tries to unlock the LUKS container at boot time. No, but it is accessible when creating your LUKS volume, and that's Marko problem at the moment. The modules can be loaded _after_ bootup as well. If you want to unlock the LUKS container at boot time (particularly if your root partition is encrypted), loading the modules after bootup is too late. Loading those modules during the early bootup phase in your initrd is actually not too late. Ah, and for completeness sake: Grub2 is able to speak LUKS. So your kernel and initrd maybe inside an encrypted volume. So I wouldn't risk it. Neither do I. Cheers Ralf
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
Hi Marko, could you please paste the latest few lines of dmesg after trying to create your volume? And please paste the output of lsmod. All your crypto-kernel-stuff are modules. Perhaps they're not loaded. Check if corresponding modules are loaded. Cheers Ralf On 04/18/2015 12:27 PM, Marko Weber | 8000 wrote: hello list, i try to crypt a partition with cryptsetup. Yes, in Kernel i had all need things i think. CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=m CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=m CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_USER=m # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_PCRYPT=m CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_MCRYPTD=m CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_ABLK_HELPER=m CONFIG_CRYPTO_GLUE_HELPER_X86=m CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_SEQIV=m CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CTR=m CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=m CONFIG_CRYPTO_CMAC=m CONFIG_CRYPTO_HMAC=m CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_VMAC=m CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRC32C_INTEL=m CONFIG_CRYPTO_CRC32=m CONFIG_CRYPTO_CRC32_PCLMUL=m CONFIG_CRYPTO_CRCT10DIF=y CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m CONFIG_CRYPTO_GHASH=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_RMD128=m CONFIG_CRYPTO_RMD160=m CONFIG_CRYPTO_RMD256=m CONFIG_CRYPTO_RMD320=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA1_SSSE3=m CONFIG_CRYPTO_SHA256_SSSE3=m CONFIG_CRYPTO_SHA512_SSSE3=m CONFIG_CRYPTO_SHA1_MB=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_BLOWFISH_COMMON=m CONFIG_CRYPTO_BLOWFISH_X86_64=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAMELLIA_X86_64=m CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m CONFIG_CRYPTO_CAST_COMMON=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST5_AVX_X86_64=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_CAST6_AVX_X86_64=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_DES3_EDE_X86_64=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m CONFIG_CRYPTO_SERPENT_AVX_X86_64=m CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_ZLIB=m CONFIG_CRYPTO_LZO=m CONFIG_CRYPTO_LZ4=m CONFIG_CRYPTO_LZ4HC=m CONFIG_CRYPTO_ANSI_CPRNG=m CONFIG_CRYPTO_DRBG_MENU=m CONFIG_CRYPTO_DRBG_HMAC=y # CONFIG_CRYPTO_DRBG_HASH is not set # CONFIG_CRYPTO_DRBG_CTR is not set CONFIG_CRYPTO_DRBG=m CONFIG_CRYPTO_USER_API=m CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_SKCIPHER=m CONFIG_CRYPTO_HASH_INFO=y # CONFIG_CRYPTO_HW is not set but when i try to use cryptsetup i get this: # cryptsetup -c aes-xts:plain64 -y -s 256 luksFormat /dev/mapper/VolGroup01-media2 WARNING! This will overwrite data on /dev/mapper/VolGroup01-media2 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: device-mapper: reload ioctl on failed: Invalid argument Failed to setup dm-crypt key mapping for device /dev/mapper/VolGroup01-media2. Check that kernel supports aes-xts:plain64 cipher (check syslog for more info). Any ideas? i built cryptsetup with this useflags: nls openssl python udev urandom cryptsetup --help shows me i am able to use the options Default compiled-in device cipher parameters: loop-AES: aes, Key 256 bits plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160 LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha1, RNG: /dev/random any help / ideas or knowledge welcome. best regards marko
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
Am 18.04.2015 um 14:12 schrieb Ralf: No. Could you please explain why you think so? Even if your root partition is encrypted, your ramdisk could load the modules. Are you sure about that? Are you sure that the necessary modules are definitely put into the initrd and that the kernel will be able to load them soon enough at boot time? Compiling those modules into the kernel is definitely more secure (in terms of being sure that they are always available) and doesn't do any harm, because they need to be loaded anyway. Btw., several dm-crypt/LUKS documentation (all that I've read) say that those modules have to be compiled into the kernel directly. After loading the modules you can see that they are available by cat /proc/crypto. You won't be able to run this command when the kernel tries to unlock the LUKS container at boot time. The modules can be loaded _after_ bootup as well. If you want to unlock the LUKS container at boot time (particularly if your root partition is encrypted), loading the modules after bootup is too late. So I wouldn't risk it.
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
Am 18.04.2015 um 12:27 schrieb Marko Weber | 8000: i try to crypt a partition with cryptsetup. Yes, in Kernel i had all need things i think. Sorry, but I forgot some more kernel modules you need: CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=y You didn't mention them, so I don't know if you have them already built into your kernel.
[gentoo-user] Strange new behavior from the mount command
I have two similar but not identical ~amd64 machines, and *one* of the two machines is doing something new and strange when I type mount with no arguments. The bad machine prints the list of mounted filesystems as it should, but then proceeds to read the partition table on every disk in the machine and writes a fresh version of /run/blkid/blkid.tab . This has the very annoying side effect of spinning up any sleeping disks, including the floppy disk (but not the dvd player, thankfully). I re-installed util-linux, which installs the mount utility, but no difference. (The two machines both have util-linux-2.26.1-r1). This new behavior began on April 14, FWIW, and the only package I installed on that machine that day was gentoo-sources-3.14.38, which is why I blamed the new kernel for the new behavior but I discovered since then that it happens with all the old kernels too. I'm stumped. Any ideas?
Re: [gentoo-user] Strange new behavior from the mount command
On Sat, 18 Apr 2015 11:48:12 walt wrote: I have two similar but not identical ~amd64 machines, and *one* of the two machines is doing something new and strange when I type mount with no arguments. The bad machine prints the list of mounted filesystems as it should, but then proceeds to read the partition table on every disk in the machine and writes a fresh version of /run/blkid/blkid.tab . This has the very annoying side effect of spinning up any sleeping disks, including the floppy disk (but not the dvd player, thankfully). I re-installed util-linux, which installs the mount utility, but no difference. (The two machines both have util-linux-2.26.1-r1). This new behavior began on April 14, FWIW, and the only package I installed on that machine that day was gentoo-sources-3.14.38, which is why I blamed the new kernel for the new behavior but I discovered since then that it happens with all the old kernels too. I'm stumped. Any ideas? Are you sure they are both running the same mount command? What does 'type mount' or 'which mount' show for each machine? Is the 'bad' machine perhaps using the '-l' option, which looks like it may need to read information from partitions on the fly: -l, --show-labels Add the labels in the mount output. mount must have permission to read the disk device (e.g. be suid root) for this to work. One can set such a label for ext2, ext3 or ext4 using the e2label(8) utility, or for XFS using xfs_admin(8), or for reiserfs using reiserfstune(8). On the other hand, using '-l' on my machine didn't appear to try anything, and didn't rewrite /run/blkid/blkid.tab but that may be because I don't use labels. -- Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/ Asking for technical help in newsgroups? Read this first: http://catb.org/~esr/faqs/smart-questions.html#intro
[gentoo-user] sound stuttering, breaking up, fading in and out
I have an issue with sound during music and sometimes video playback. Usually it fades out (gets quieter) and then fades back in a couple of seconds later. This happens randomly maybe a couple of times in an hour or two, but can sometimes go several hours without issue. It has happened with quodlibet and mocp (audio - mostly ogg, some mp3) and with vlc (video - mostly mp4/m4v). I don't use other music/video software enough to notice it there. During heavy load (like emerging packages), the sound will sometimes stutter or even stop and then restart a few seconds later. The computer is a few years old, but this has not happened in the past. I found somewhere the suggestion to add the following options to /etc/modprobe.d/sound.conf options snd-hda-intel vid=8086 pid=8ca0 snoop=0 The fading out/in *seems to be* less frequent since doing that. But that is my subjective feeling, not based on data. Any ideas on what might be wrong and how it can be fixed? ** System ** Window Manager = PekWM kernel = Linux sys76 3.18.11-gentoo #1 SMP PREEMPT Thu Apr 9 13:56:02 EDT 2015 x86_64 Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz GenuineIntel GNU/Linux ** Hardware Info ** lspci reports: Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller Modules, from lsmod | grep snd: snd_hda_codec_idt 39744 1 snd_hda_codec_generic39746 1 snd_hda_codec_idt snd_hda_intel 17007 2 snd_hda_controller 13712 1 snd_hda_intel snd_hda_codec 68033 4 snd_hda_codec_idt,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller snd_hwdep 5373 1 snd_hda_codec snd_pcm63521 3 snd_hda_codec,snd_hda_intel,snd_hda_controller snd_timer 15422 1 snd_pcm snd49995 11 snd_hwdep,snd_timer,snd_hda_codec_idt,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel ** Software ** [I] media-sound/pulseaudio Installed versions: 5.0-r7(03:35:44 PM 04/08/2015)(X alsa alsa-plugin asyncns bluetooth caps dbus gdbm glib gtk ipv6 orc qt4 ssl tcpd udev webrtc-aec -doc -equalizer -gnome -jack -libsamplerate -lirc -neon -oss -realtime -system-wide -systemd -test -xen -zeroconf ABI_MIPS=-n32 -n64 -o32 ABI_PPC=-32 -64 ABI_S390=-32 -64 ABI_X86=64 -32 -x32) [I] media-plugins/gst-plugins-pulse Installed versions: 0.10.31-r1(0.10)^t(12:55:06 PM 04/11/2015)(ABI_MIPS=-n32 -n64 -o32 ABI_PPC=-32 -64 ABI_S390=-32 -64 ABI_X86=64 -32 -x32) 1.4.5(1.0)^t(04:27:00 PM 04/05/2015)(ABI_MIPS=-n32 -n64 -o32 ABI_PPC=-32 -64 ABI_S390=-32 -64 ABI_X86=64 -32 -x32) [I] media-sound/moc Installed versions: 2.5.0(05:50:51 PM 04/12/2015)(aac alsa cache ffmpeg flac mad magic unicode vorbis -curl -debug -jack -libsamplerate -modplug -musepack -oss -sid -sndfile -speex -timidity -tremor -wavpack) (I removed Quodlibet recently for unrelated reasons.) Thanks for any and all help and advice. -- Chris Spackman GNU Terry Pratchett
Re: [gentoo-user] sound stuttering, breaking up, fading in and out
On 2015/04/18 at 08:11pm, Fernando Rodriguez wrote: On Saturday, April 18, 2015 6:46:37 PM Chris Spackman wrote: I have an issue with sound during music and sometimes video playback. The Arch wiki has a lot of tips for configure pulseaudio: https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Setting_the_default_fragment_number_and_buffer_size_in_PulseAudio Thanks for the information. The arch page suggested setting enable-lfe-remixing = yes in /etc/pulse/daemon.conf for analog surround - which I have. Trying that now. Music is doing much better during a big emerge (so far). Next I will set the realtime use flag; hadn't seen that before. I'll try these for a few days and see how it goes. Thanks. -- Chris Spackman GNU Terry Pratchett
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
On Saturday, April 18, 2015 9:35:27 PM Fernando Rodriguez wrote: On Saturday, April 18, 2015 12:27:15 PM Marko Weber | 8000 wrote: hello list, i try to crypt a partition with cryptsetup. Yes, in Kernel i had all need things i think. CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=m CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=m CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_USER=m # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_PCRYPT=m CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_MCRYPTD=m CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_ABLK_HELPER=m CONFIG_CRYPTO_GLUE_HELPER_X86=m CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_SEQIV=m CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CTR=m CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=m CONFIG_CRYPTO_CMAC=m CONFIG_CRYPTO_HMAC=m CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_VMAC=m CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRC32C_INTEL=m CONFIG_CRYPTO_CRC32=m CONFIG_CRYPTO_CRC32_PCLMUL=m CONFIG_CRYPTO_CRCT10DIF=y CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m CONFIG_CRYPTO_GHASH=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_RMD128=m CONFIG_CRYPTO_RMD160=m CONFIG_CRYPTO_RMD256=m CONFIG_CRYPTO_RMD320=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA1_SSSE3=m CONFIG_CRYPTO_SHA256_SSSE3=m CONFIG_CRYPTO_SHA512_SSSE3=m CONFIG_CRYPTO_SHA1_MB=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_BLOWFISH_COMMON=m CONFIG_CRYPTO_BLOWFISH_X86_64=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAMELLIA_X86_64=m CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m CONFIG_CRYPTO_CAST_COMMON=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST5_AVX_X86_64=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_CAST6_AVX_X86_64=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_DES3_EDE_X86_64=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m CONFIG_CRYPTO_SERPENT_AVX_X86_64=m CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_ZLIB=m CONFIG_CRYPTO_LZO=m CONFIG_CRYPTO_LZ4=m CONFIG_CRYPTO_LZ4HC=m CONFIG_CRYPTO_ANSI_CPRNG=m CONFIG_CRYPTO_DRBG_MENU=m CONFIG_CRYPTO_DRBG_HMAC=y # CONFIG_CRYPTO_DRBG_HASH is not set # CONFIG_CRYPTO_DRBG_CTR is not set CONFIG_CRYPTO_DRBG=m CONFIG_CRYPTO_USER_API=m CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_SKCIPHER=m CONFIG_CRYPTO_HASH_INFO=y # CONFIG_CRYPTO_HW is not set but when i try to use cryptsetup i get this: # cryptsetup -c aes-xts:plain64 -y -s 256 luksFormat /dev/mapper/VolGroup01-media2 WARNING! This will overwrite data on /dev/mapper/VolGroup01-media2 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: device-mapper: reload ioctl on failed: Invalid argument Failed to setup dm-crypt key mapping for device /dev/mapper/VolGroup01-media2. Check that kernel supports aes-xts:plain64 cipher (check syslog for more info). Any ideas? i built cryptsetup with this useflags: nls openssl python udev urandom cryptsetup --help shows me i am able to use the options Default compiled-in device cipher parameters: loop-AES: aes, Key 256 bits plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160 LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha1, RNG: /dev/random any help / ideas or knowledge welcome. best regards marko That message is incorrectly shown if something's wrong with the way you specified the cipher and key size. It threw me off for a while too. This is what I ended up using: cryptsetup -i 3 -c twofish-xts-essiv:sha256 -s 512 -h sha512 luksFormat file.img I don't remember where I was getting it wrong, I think I was using -s 256 but xts uses half the key for every other block so the key needs to be twice the size. I found a site with a table that list what you can use with which
[gentoo-user] Re: Strange new behavior from the mount command
On 04/18/2015 02:31 PM, Paul Colquhoun wrote: On Sat, 18 Apr 2015 11:48:12 walt wrote: I have two similar but not identical ~amd64 machines, and *one* of the two machines is doing something new and strange when I type mount with no arguments. The bad machine prints the list of mounted filesystems as it should, but then proceeds to read the partition table on every disk in the machine and writes a fresh version of /run/blkid/blkid.tab . This has the very annoying side effect of spinning up any sleeping disks, including the floppy disk (but not the dvd player, thankfully). I re-installed util-linux, which installs the mount utility, but no difference. (The two machines both have util-linux-2.26.1-r1). This new behavior began on April 14, FWIW, and the only package I installed on that machine that day was gentoo-sources-3.14.38, which is why I blamed the new kernel for the new behavior but I discovered since then that it happens with all the old kernels too. I'm stumped. Any ideas? Are you sure they are both running the same mount command? What does 'type mount' or 'which mount' show for each machine? Is the 'bad' machine perhaps using the '-l' option, which looks like it may need to read information from partitions on the fly: -l, --show-labels Add the labels in the mount output. mount must have permission to read the disk device (e.g. be suid root) for this to work. One can set such a label for ext2, ext3 or ext4 using the e2label(8) utility, or for XFS using xfs_admin(8), or for reiserfs using reiserfstune(8). On the other hand, using '-l' on my machine didn't appear to try anything, and didn't rewrite /run/blkid/blkid.tab but that may be because I don't use labels. Good questions, thanks. I know both machines are actually running /bin/mount and not using any arguments (like -l) because strace shows me that info in its first line of output: execve(/bin/mount, [mount], [/* 61 vars */]) = 0 That number 61 on the 'bad' machine is 48, though, and I don't know where that odd-looking string of characters is generated or what it means. To me it looks like a comment in a file of 'c' code. Still stumped :(
[gentoo-user] dev-lang/perl:0 - problem
I've not updated to two months and now I'm getting dependency problem with dev-lang/perl (dev-lang/perl-5.20.2:0/5.20::gentoo, ebuild scheduled for merge) pulled in by =dev-lang/perl-5.20.2* required by (virtual/perl-File-Spec-3.480.100-r1:0/0::gentoo, ebuild scheduled for merge) ^ ^^^ (and 38 more with the same problem) (dev-lang/perl-5.18.2-r2:0/5.18::gentoo, installed) pulled in by dev-lang/perl:0/5.18=[-build(-)] required by (dev-perl/Crypt-PasswdMD5-1.400.0:0/0::gentoo, installed) (and 94 more with the same problem) How to solve it? I don't want to mess with perl and ended up with emerge not working. -- Joseph
[gentoo-user] Re: dev-lang/perl:0 - problem
On 04/18/2015 04:38 PM, Joseph wrote: I've not updated to two months and now I'm getting dependency problem with dev-lang/perl (dev-lang/perl-5.20.2:0/5.20::gentoo, ebuild scheduled for merge) pulled in by =dev-lang/perl-5.20.2* required by (virtual/perl-File-Spec-3.480.100-r1:0/0::gentoo, ebuild scheduled for merge) ^ ^^^ (and 38 more with the same problem) (dev-lang/perl-5.18.2-r2:0/5.18::gentoo, installed) pulled in by dev-lang/perl:0/5.18=[-build(-)] required by (dev-perl/Crypt-PasswdMD5-1.400.0:0/0::gentoo, installed) (and 94 more with the same problem) Did you try perl-cleaner? (emerge app-admin/perl-cleaner)
Re: [gentoo-user] Re: Strange new behavior from the mount command
On Saturday, April 18, 2015 3:59:15 PM walt wrote: execve(/bin/mount, [mount], [/* 61 vars */]) = 0 That number 61 on the 'bad' machine is 48, though, and I don't know where that odd-looking string of characters is generated or what it means. To me it looks like a comment in a file of 'c' code. Still stumped :( That would be the number of environment variables passed to execve. strace is just trying not to be too noisy. Are there any differences in the options used in fstab between both machines, Especially the auto or noauto options or if one of them is using labels. The mount(8) man page may have more hints. -- Fernando Rodriguez
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
On Saturday, April 18, 2015 12:27:15 PM Marko Weber | 8000 wrote: hello list, i try to crypt a partition with cryptsetup. Yes, in Kernel i had all need things i think. CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=m CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=m CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_USER=m # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_PCRYPT=m CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_MCRYPTD=m CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_ABLK_HELPER=m CONFIG_CRYPTO_GLUE_HELPER_X86=m CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_SEQIV=m CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CTR=m CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=m CONFIG_CRYPTO_CMAC=m CONFIG_CRYPTO_HMAC=m CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_VMAC=m CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRC32C_INTEL=m CONFIG_CRYPTO_CRC32=m CONFIG_CRYPTO_CRC32_PCLMUL=m CONFIG_CRYPTO_CRCT10DIF=y CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m CONFIG_CRYPTO_GHASH=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_RMD128=m CONFIG_CRYPTO_RMD160=m CONFIG_CRYPTO_RMD256=m CONFIG_CRYPTO_RMD320=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA1_SSSE3=m CONFIG_CRYPTO_SHA256_SSSE3=m CONFIG_CRYPTO_SHA512_SSSE3=m CONFIG_CRYPTO_SHA1_MB=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_BLOWFISH_COMMON=m CONFIG_CRYPTO_BLOWFISH_X86_64=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAMELLIA_X86_64=m CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m CONFIG_CRYPTO_CAST_COMMON=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST5_AVX_X86_64=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_CAST6_AVX_X86_64=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_DES3_EDE_X86_64=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m CONFIG_CRYPTO_SERPENT_AVX_X86_64=m CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_ZLIB=m CONFIG_CRYPTO_LZO=m CONFIG_CRYPTO_LZ4=m CONFIG_CRYPTO_LZ4HC=m CONFIG_CRYPTO_ANSI_CPRNG=m CONFIG_CRYPTO_DRBG_MENU=m CONFIG_CRYPTO_DRBG_HMAC=y # CONFIG_CRYPTO_DRBG_HASH is not set # CONFIG_CRYPTO_DRBG_CTR is not set CONFIG_CRYPTO_DRBG=m CONFIG_CRYPTO_USER_API=m CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_SKCIPHER=m CONFIG_CRYPTO_HASH_INFO=y # CONFIG_CRYPTO_HW is not set but when i try to use cryptsetup i get this: # cryptsetup -c aes-xts:plain64 -y -s 256 luksFormat /dev/mapper/VolGroup01-media2 WARNING! This will overwrite data on /dev/mapper/VolGroup01-media2 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: device-mapper: reload ioctl on failed: Invalid argument Failed to setup dm-crypt key mapping for device /dev/mapper/VolGroup01-media2. Check that kernel supports aes-xts:plain64 cipher (check syslog for more info). Any ideas? i built cryptsetup with this useflags: nls openssl python udev urandom cryptsetup --help shows me i am able to use the options Default compiled-in device cipher parameters: loop-AES: aes, Key 256 bits plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160 LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha1, RNG: /dev/random any help / ideas or knowledge welcome. best regards marko That message is incorrectly shown if something's wrong with the way you specified the cipher and key size. It threw me off for a while too. This is what I ended up using: cryptsetup -i 3 -c twofish-xts-essiv:sha256 -s 512 -h sha512 luksFormat file.img I don't remember where I was getting it wrong, I think I was using -s 256 but xts uses half the key for every other block so the key needs to be twice the size. I found a site with a table that list what you can use with which options but unfortunately I can't find it now. So try using -s 512 (since cryptsetup is telling you that you can use a 256 bit key). -- Fernando Rodriguez
Re: [gentoo-user] List of Epic FAIL
On Friday 17 Apr 2015 23:33:40 Andreas K. Huettel wrote: Am Freitag, 17. April 2015, 06:18:47 schrieb Alan Grimes: #8,#16; INTERNAL COMPILER ERROR!! (recently RMA'd some RAM, new ram had a 1-bit intermittent failure in 32GB, jacked voltage and hoped was good...) Well, seems it isn't. These are the two memory-intensive packages in the list. As Alan says, if you are using bad RAM you're playing a rather deterministic game. When, not if, the hole in your memory is met by a running process the output will go sideways. If you don't want to return the memory back and get a new module, then you could try the badmem or badram patches. I would recommend you get new memory, but either of these patches may bring a quicker result and at least confirm that the faulty memory caused the emerge failures. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
