Re: [gentoo-user] abi_x86_32 FLAG
Am 21.04.2015 um 00:22 schrieb Joseph: I'm trying to update one of my amd64 (I use XFCE) and there are lot of package that require use flag: abi_x86_32 Which package is forcing new: abi_x86_32 flag? sys-boot/grub-0.97-r14 x11-drivers/nvidia-drivers Replace sys-boot/grub-0.97-r14 by sys-boot/grub-static-0.97-r12. Don't forget to write the new bootloader into your MBR afterwards by running: # grub grub root (hdX,X) grub setup (hdX) And regarding x11-drivers/nvidia-drivers see those bug reports: https://bugs.gentoo.org/show_bug.cgi?id=545582 https://bugs.gentoo.org/show_bug.cgi?id=485724
Re: [gentoo-user] abi_x86_32 FLAG
On Mon, Apr 20, 2015 at 6:47 PM, Heiko Baums li...@baums-on-web.de wrote: Am 21.04.2015 um 00:22 schrieb Joseph: I'm trying to update one of my amd64 (I use XFCE) and there are lot of package that require use flag: abi_x86_32 Which package is forcing new: abi_x86_32 flag? sys-boot/grub-0.97-r14 x11-drivers/nvidia-drivers Replace sys-boot/grub-0.97-r14 by sys-boot/grub-static-0.97-r12. Better yet, upgrade to grub:2 already.
[gentoo-user] masking asterisk 11
I'm still using asterisk 1.8 and trying to mask aserisk-11 so I put in /etc/portage/package.mask =net-misc/asterisk-11.15.0-r1 =net-misc/asterisk-11.17.1 but it is not working when I try: emerge -pva asterisk These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U #] net-misc/asterisk-11.17.1 [1.8.28.2] Why isn't it masking asterisk-11 -- Joseph
Re: [gentoo-user] apache and the -D parameter
On 21/04/15 04:15, Michael Orlitzky wrote: On 04/20/2015 09:54 AM, Bill Kenworthy wrote: ps aux: several entries of root 7549 0.0 0.0 145116 7916 ?Ss 05:05 0:00 /usr/sbin/apache2 -D DEFAULT_VHOST -D INFO -D SSL -D SSL_DEFAULT_VHOST -D WSGI -D LANGUAGE -D SSL -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -E /var/log/apache2/startuperror.log -k start Since these are showing the -D arguments being passed to the full path, /usr/sbin/apache2, maybe you can try running, # /usr/sbin/apache2 -M instead of just apache2 -M? Kind of a long shot, but I can't see anything else wrong. as expected, no difference :( strace doesnt show anything useful - its reading the config files including 70-mod_wsgi.conf but doesnt show anything else. BillK
Re: [gentoo-user] another old server: what about udev and CONFIG_DEVTMPFS ?
Am 2015-04-20 um 15:28 schrieb Alan McKinnon: ~ 90 min drive one way ;-) I've had a few of those myself :-) I always figured if I was in for a 4 hour minimum trip anyway, I really owe it to the customer to spend an extra 30 minutes to be 100% sure everything was done correctly. The customer in case tells me that he has no money and that I shouldn't invest too much time The initial trigger for all the current investigation is a dropped hdd from the raid arrays The guy opted out of being a real customer in late 2010 or so .. and now mdadm emails me. Don't ask how the backup reports look. S
[gentoo-user] abi_x86_32 FLAG
I'm trying to update one of my amd64 (I use XFCE) and there are lot of package that require use flag: abi_x86_32 equery d emul-linux (nothing found) for EMUL in $(eix -I --only-names emul-linux); do equery depends $EMUL; done * These packages depend on app-emulation/emul-linux-x86-baselibs: app-emulation/emul-linux-x86-gtklibs-20140508-r3 (~app-emulation/emul-linux-x86-baselibs-20140508) app-emulation/emul-linux-x86-xlibs-20140508 (!abi_x86_32 ? ~app-emulation/emul-linux-x86-baselibs-20140508) app-text/acroread-9.5.5-r2 (app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)]) (ldap ? app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)]) sys-boot/grub-0.97-r14 (amd64 ? app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)]) * These packages depend on app-emulation/emul-linux-x86-gtklibs: app-text/acroread-9.5.5-r2 (app-emulation/emul-linux-x86-gtklibs[-abi_x86_32(-)]) sys-devel/gcc-4.5.4 (multilib ? app-emulation/emul-linux-x86-gtklibs) sys-devel/gcc-4.8.3 (multilib ? app-emulation/emul-linux-x86-gtklibs) * These packages depend on app-emulation/emul-linux-x86-opengl: app-emulation/emul-linux-x86-gtklibs-20140508-r3 (~app-emulation/emul-linux-x86-opengl-20140508) app-emulation/emul-linux-x86-xlibs-20140508 (opengl ? app-emulation/emul-linux-x86-opengl) app-text/acroread-9.5.5-r2 (app-emulation/emul-linux-x86-opengl[-abi_x86_32(-)]) * These packages depend on app-emulation/emul-linux-x86-xlibs: app-emulation/emul-linux-x86-gtklibs-20140508-r3 (~app-emulation/emul-linux-x86-xlibs-20140508) app-emulation/emul-linux-x86-opengl-20140508 (!abi_x86_32 ? =app-emulation/emul-linux-x86-xlibs-20100611) app-text/acroread-9.5.5-r2 (app-emulation/emul-linux-x86-xlibs[-abi_x86_32(-)]) (nsplugin ? app-emulation/emul-linux-x86-xlibs[-abi_x86_32(-)]) sys-devel/gcc-4.5.4 (multilib ? app-emulation/emul-linux-x86-xlibs) sys-devel/gcc-4.8.3 (multilib ? app-emulation/emul-linux-x86-xlibs) x11-drivers/nvidia-drivers-340.65 (app-emulation/emul-linux-x86-xlibs) Which package is forcing new: abi_x86_32 flag? -- Joseph
[gentoo-user] Questions about cpu frequency utils scripting
It seems like many of the cpu speed/governor switcher utilities in
/usr/portage/sys-power don't work due to being too old. I cobbled
together a simple bash script (YES!) that sort of emulates the eselect
interface, and allows me to switch between
userspace/powersave/performance/ondemend/conservative governors. Root
permission is required, of course, to write to the /sys pseudo
filesystem. I want to add some basic error-checking and documentation
in the comments before releasing it in the wild.
The only thing I can't get working is setting specific speeds. I do
set the governor to userspace first. I can't think of any other
problem. Given that I can switch between performance and powersave and
ondemand/conservative, I'm not too worried about this, but I'd like to
know for completeness.
Another item I'm missing is wildcarding directories in bash. The
selected values are applied to the CPUs in a loop that goes like so...
for core in /sys/devices/system/cpu/cpu[0-9]/
do
echo ${governor[${choiceminus}]} ${core}cpufreq/scaling_governor
echo -n CPU ${core:27:1} set to
cat ${core}cpufreq/scaling_governor
done
That works fine for notebooks with say 8 cores. But what happens when
you hit 16 cores? I can't come up with one bash wildcard expression
that handles /sys/devices/system/cpu/cpu[0-9]/ and
/sys/devices/system/cpu/cpu[0-9][0-9]/ simultaneously. There's
probably an elegant solution right under my nose, but my Google-fu is
failing me right now. In a worst-case-scenario, I could have one loop
for /sys/devices/system/cpu/cpu[0-9]/. Then test for the existance of
/sys/devices/system/cpu/cpu10]/. If it exists, run a separate loop
for /sys/devices/system/cpu/cpu[0-9][0-9]/. Ugly, but it would work.
--
Walter Dnes waltd...@waltdnes.org
I don't run desktop environments; I run useful applications
Re: [gentoo-user] abi_x86_32 FLAG
Am 21.04.2015 um 01:27 schrieb Mike Gilbert: Better yet, upgrade to grub:2 already. Why? As long as grub legacy is working there's no need to upgrade. I'm still running grub legacy, too.
Re: [gentoo-user] abi_x86_32 FLAG
On 04/21/15 00:47, Heiko Baums wrote: Am 21.04.2015 um 00:22 schrieb Joseph: I'm trying to update one of my amd64 (I use XFCE) and there are lot of package that require use flag: abi_x86_32 Which package is forcing new: abi_x86_32 flag? sys-boot/grub-0.97-r14 x11-drivers/nvidia-drivers Replace sys-boot/grub-0.97-r14 by sys-boot/grub-static-0.97-r12. Don't forget to write the new bootloader into your MBR afterwards by running: # grub grub root (hdX,X) grub setup (hdX) And regarding x11-drivers/nvidia-drivers see those bug reports: https://bugs.gentoo.org/show_bug.cgi?id=545582 https://bugs.gentoo.org/show_bug.cgi?id=485724 I don't think grub is asking for it. According to: eselect news Starting on 2015-03-29, we are enabling true multilib support on amd64 and masking the old emul-linux-x86 package sets for removal So I might as well go with abi_x86_32 flag -- Joseph
Re: [gentoo-user] masking asterisk 11
Hi Joseph, I don't see any lower version of asterisk-11 in the tree, so if you don't have an overlay that specifically provides the version you are looking for, portage has no other choice than to select the masked one. And it infact DOES take your mask into account, note the # in the emerge output, it just can't figure out an alternative for you. Greetings --Flo
Re: [gentoo-user] stable java virtuals require unstable java packages
Am 21.04.2015 um 07:42 schrieb Alan McKinnon: It's either a bug in virtual/jdk-1.7 ebuild or more likely, stable request for icedtead-bin-7 is lagging behind. You are right, the stable request is still going on: https://bugs.gentoo.org/show_bug.cgi?id=546902 Obviously the virtual got stableized a bit too fast.
Re: [gentoo-user] abi_x86_32 FLAG
Joseph syscon...@gmail.com wrote: On 04/21/15 00:47, Heiko Baums wrote: Am 21.04.2015 um 00:22 schrieb Joseph: I'm trying to update one of my amd64 (I use XFCE) and there are lot of package that require use flag: abi_x86_32 Which package is forcing new: abi_x86_32 flag? sys-boot/grub-0.97-r14 x11-drivers/nvidia-drivers Replace sys-boot/grub-0.97-r14 by sys-boot/grub-static-0.97-r12. Don't forget to write the new bootloader into your MBR afterwards by running: # grub grub root (hdX,X) grub setup (hdX) And regarding x11-drivers/nvidia-drivers see those bug reports: https://bugs.gentoo.org/show_bug.cgi?id=545582 https://bugs.gentoo.org/show_bug.cgi?id=485724 I don't think grub is asking for it. According to: eselect news Starting on 2015-03-29, we are enabling true multilib support on amd64 and masking the old emul-linux-x86 package sets for removal So I might as well go with abi_x86_32 flag I was looking to my world update and I saw that none of my emul-linux packages will be removed and there are some packages which depend on them such as nvidia-drivers and the C compiler! So any reason to do anything, or just let portage sort things out as the packages remove their dependencies on emul-linux? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
[gentoo-user] stable java virtuals require unstable java packages
Is it normal for a stable virtual to require an unstable package? Running 'emerge -auND' generates the following output on my system: Calculating dependencies ... done! [ebuild NS ~] dev-java/icedtea-bin-7.2.5.3 [6.1.13.5] USE=X alsa cups nsplugin -cjk -doc -examples (-selinux) -source -webstart [ebuild NS] virtual/jdk-1.7.0 [1.6.0-r2] [ebuild NS] virtual/jre-1.7.0 [1.6.0-r1] [ebuild U ~] dev-java/icedtea-web-1.5.1-r1 [1.4.2] USE=icedtea7%* -tagsoup% The following keyword changes are necessary to proceed: (see package.accept_keywords in the portage(5) man page for more details) # required by virtual/jdk-1.7.0::gentoo # required by virtual/jre-1.7.0::gentoo # required by sys-libs/db-4.8.30-r2::gentoo[java] # required by dev-libs/redland-1.0.16::gentoo[berkdb] # required by app-office/libreoffice-4.4.1.2::gentoo # required by @selected # required by @world (argument) =dev-java/icedtea-bin-7.2.5.3 ~x86 # required by dev-java/icedtea-bin-7.2.5.3::gentoo[nsplugin] # required by virtual/jdk-1.7.0::gentoo # required by virtual/jre-1.7.0::gentoo # required by sys-libs/db-4.8.30-r2::gentoo[java] # required by dev-libs/redland-1.0.16::gentoo[berkdb] # required by app-office/libreoffice-4.4.1.2::gentoo # required by @selected # required by @world (argument) =dev-java/icedtea-web-1.5.1-r1 ~x86 /usr/portage/virtual/jre/jre-1.7.0.ebuild:12 =virtual/jdk-1.7.0* /usr/portage/virtual/jdk/jdk-1.7.0.ebuild:12,13 =dev-java/icedtea-bin-7* =dev-java/icedtea-7* Thanks.
Re: [gentoo-user] abi_x86_32 FLAG
On 04/20/2015 06:14 PM, Joseph wrote: I don't think grub is asking for it. Not grub specifically, but grub is probably built with ncurses support and ncurses needs it. Dan
Re: [gentoo-user] abi_x86_32 FLAG
On 04/20/2015 04:27 PM, Mike Gilbert wrote: Better yet, upgrade to grub:2 already. I only use grub2 on machines with EFI, and in my house that's only two... I can't stand how it tries to add things automatically. It actually got so annoying that I created a manual boot entry that is symlinked to the kernel I want to run. It was easier than trying to fight it all the time. Dan
Re: [gentoo-user] stable java virtuals require unstable java packages
On 21/04/2015 07:28, Alexander Kapshuk wrote: Is it normal for a stable virtual to require an unstable package? No, that is definitely not how virtuals should work. It's either a bug in virtual/jdk-1.7 ebuild or more likely, stable request for icedtead-bin-7 is lagging behind. I know the java team is badly understaffed, lots of mentions on -dev, so maybe log a stable request but against icedtea-bin-7 Running 'emerge -auND' generates the following output on my system: Calculating dependencies ... done! [ebuild NS ~] dev-java/icedtea-bin-7.2.5.3 [6.1.13.5] USE=X alsa cups nsplugin -cjk -doc -examples (-selinux) -source -webstart [ebuild NS] virtual/jdk-1.7.0 [1.6.0-r2] [ebuild NS] virtual/jre-1.7.0 [1.6.0-r1] [ebuild U ~] dev-java/icedtea-web-1.5.1-r1 [1.4.2] USE=icedtea7%* -tagsoup% The following keyword changes are necessary to proceed: (see package.accept_keywords in the portage(5) man page for more details) # required by virtual/jdk-1.7.0::gentoo # required by virtual/jre-1.7.0::gentoo # required by sys-libs/db-4.8.30-r2::gentoo[java] # required by dev-libs/redland-1.0.16::gentoo[berkdb] # required by app-office/libreoffice-4.4.1.2::gentoo # required by @selected # required by @world (argument) =dev-java/icedtea-bin-7.2.5.3 ~x86 # required by dev-java/icedtea-bin-7.2.5.3::gentoo[nsplugin] # required by virtual/jdk-1.7.0::gentoo # required by virtual/jre-1.7.0::gentoo # required by sys-libs/db-4.8.30-r2::gentoo[java] # required by dev-libs/redland-1.0.16::gentoo[berkdb] # required by app-office/libreoffice-4.4.1.2::gentoo # required by @selected # required by @world (argument) =dev-java/icedtea-web-1.5.1-r1 ~x86 /usr/portage/virtual/jre/jre-1.7.0.ebuild:12 =virtual/jdk-1.7.0* /usr/portage/virtual/jdk/jdk-1.7.0.ebuild:12,13 =dev-java/icedtea-bin-7* =dev-java/icedtea-7* Thanks. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] apache and the -D parameter
On 04/20/2015 09:54 AM, Bill Kenworthy wrote: ps aux: several entries of root 7549 0.0 0.0 145116 7916 ?Ss 05:05 0:00 /usr/sbin/apache2 -D DEFAULT_VHOST -D INFO -D SSL -D SSL_DEFAULT_VHOST -D WSGI -D LANGUAGE -D SSL -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -E /var/log/apache2/startuperror.log -k start Since these are showing the -D arguments being passed to the full path, /usr/sbin/apache2, maybe you can try running, # /usr/sbin/apache2 -M instead of just apache2 -M? Kind of a long shot, but I can't see anything else wrong.
Re: [gentoo-user] another old server: what about udev and CONFIG_DEVTMPFS ?
On 20/04/2015 14:51, Stefan G. Weichinger wrote: Another 5 yr server that needs some care. sys-fs/udev-151-r4 and a kernel without CONFIG_DEVTMPFS set. The old udev blocks openrc etc etc ... Aside from: install from scratch - what happens if I upgrade udev before booting a kernel with CONFIG_DEVTMPFS set? Problems? Yes, it won't work. And the ebuild will error out. I'd like to upgrade udev, then install openrc etc ... before I can drive there and reboot the box. You intend to drive there anyway and reboot it. Rebuilding udev openrc will probably take 15 minutes. It's such a little time, why are you trying to save 15 minutes in advance by taking an unknown and risky path? Just do everything on-site, it's safest -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] another old server: what about udev and CONFIG_DEVTMPFS ?
I could install openrc with USE=-netifrc now ... then it doesn't pull in netifrc which depends on udev etc etc Not a real solution as now I miss net.lo ... oh my. I scp'ed it over ;) just to make that one reboot work ...
Re: [gentoo-user] another old server: what about udev and CONFIG_DEVTMPFS ?
On 20.04.2015 14:56, Alan McKinnon wrote: Problems? Yes, it won't work. And the ebuild will error out. Ah, I see. I'd like to upgrade udev, then install openrc etc ... before I can drive there and reboot the box. You intend to drive there anyway and reboot it. Rebuilding udev openrc will probably take 15 minutes. It's such a little time, why are you trying to save 15 minutes in advance by taking an unknown and risky path? Just do everything on-site, it's safest ~ 90 min drive one way ;-) Thanks anyway, Stefan
Re: [gentoo-user] apache and the -D parameter
On Monday, April 20, 2015 06:56:49 PM Bill Kenworthy wrote: Hi, I am trying to set up mod_wsgi and apache in an LXC container. apache is ignoring all -D parameters on startup even though I can see them in the startup script debug and they are being passed to apache according to ps aux. apache -M does not show the modules in the loaded list. If I remove the IfDefine around the load command it works fine. I am thinking that its something about the container but what? BillK What's the full ifDefine line? What is your full APACHE2_OPTS line where you put the -D ? -- Joost
[gentoo-user] another old server: what about udev and CONFIG_DEVTMPFS ?
Another 5 yr server that needs some care. sys-fs/udev-151-r4 and a kernel without CONFIG_DEVTMPFS set. The old udev blocks openrc etc etc ... Aside from: install from scratch - what happens if I upgrade udev before booting a kernel with CONFIG_DEVTMPFS set? Problems? I'd like to upgrade udev, then install openrc etc ... before I can drive there and reboot the box. Stefan
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
hi Heiko, Am 2015-04-18 17:41, schrieb Heiko Baums: 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. i have them in config. with y marko
Re: [gentoo-user] another old server: what about udev and CONFIG_DEVTMPFS ?
On 20/04/2015 15:01, Stefan G. Weichinger wrote: On 20.04.2015 14:56, Alan McKinnon wrote: Problems? Yes, it won't work. And the ebuild will error out. Ah, I see. I'd like to upgrade udev, then install openrc etc ... before I can drive there and reboot the box. You intend to drive there anyway and reboot it. Rebuilding udev openrc will probably take 15 minutes. It's such a little time, why are you trying to save 15 minutes in advance by taking an unknown and risky path? Just do everything on-site, it's safest ~ 90 min drive one way ;-) I've had a few of those myself :-) I always figured if I was in for a 4 hour minimum trip anyway, I really owe it to the customer to spend an extra 30 minutes to be 100% sure everything was done correctly. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
hi fernando, Am 2015-04-19 03:35, schrieb Fernando Rodriguez: 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. # cryptsetup -c aes-xts:plain64 -y -s 512 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). 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
[gentoo-user] apache and the -D parameter
Hi, I am trying to set up mod_wsgi and apache in an LXC container. apache is ignoring all -D parameters on startup even though I can see them in the startup script debug and they are being passed to apache according to ps aux. apache -M does not show the modules in the loaded list. If I remove the IfDefine around the load command it works fine. I am thinking that its something about the container but what? BillK
Re: [gentoo-user] apache and the -D parameter
On 20/04/15 21:21, J. Roeleveld wrote: On Monday, April 20, 2015 06:56:49 PM Bill Kenworthy wrote: Hi, I am trying to set up mod_wsgi and apache in an LXC container. apache is ignoring all -D parameters on startup even though I can see them in the startup script debug and they are being passed to apache according to ps aux. apache -M does not show the modules in the loaded list. If I remove the IfDefine around the load command it works fine. I am thinking that its something about the container but what? BillK What's the full ifDefine line? What is your full APACHE2_OPTS line where you put the -D ? -- Joost standard gentoo VM on gentoo, with lxc-gentoo and stable apache and mod_wsgi inside - its a new install for playing with radicale and wsgi /etc/conf.d/apache2: APACHE2_OPTS=-D DEFAULT_VHOST -D INFO -D SSL -D SSL_DEFAULT_VHOST -D WSGI -D LANGUAGE -D SSL ps aux: several entries of root 7549 0.0 0.0 145116 7916 ?Ss 05:05 0:00 /usr/sbin/apache2 -D DEFAULT_VHOST -D INFO -D SSL -D SSL_DEFAULT_VHOST -D WSGI -D LANGUAGE -D SSL -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -E /var/log/apache2/startuperror.log -k start /etc/apache2/http.conf ** note I have to comment out the alias because the module isnt found unless I comment out the IfDefine IfDefine WSGI LoadModule wsgi_module modules/mod_wsgi.so /IfDefine WSGIScriptAlias / /var/www/localhost/htdocs/hello.wsgi Note that there are no modules from IfDefine here - these are all outside the blocks. If I comment the IfDefines out it loads the module and it all works fine. radicale radicale # apache2 -M Loaded Modules: core_module (static) mpm_prefork_module (static) http_module (static) so_module (static) actions_module (shared) alias_module (shared) auth_basic_module (shared) authn_alias_module (shared) authn_anon_module (shared) authn_dbd_module (shared) authn_dbm_module (shared) authn_default_module (shared) authn_file_module (shared) authz_dbm_module (shared) authz_default_module (shared) authz_groupfile_module (shared) authz_host_module (shared) authz_owner_module (shared) authz_user_module (shared) autoindex_module (shared) cgid_module (shared) dbd_module (shared) deflate_module (shared) dir_module (shared) env_module (shared) expires_module (shared) ext_filter_module (shared) filter_module (shared) headers_module (shared) ident_module (shared) imagemap_module (shared) include_module (shared) log_config_module (shared) logio_module (shared) mime_module (shared) mime_magic_module (shared) negotiation_module (shared) rewrite_module (shared) setenvif_module (shared) speling_module (shared) unique_id_module (shared) usertrack_module (shared) vhost_alias_module (shared) Syntax OK radicale radicale #
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
Am 2015-04-18 12:27, schrieb Marko Weber | 8000: 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_MCRYP# cryptsetup -c aes-xts:plain64 -y -s 512 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).TD=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 # Ok, now i have built into Kernel. ALso CONFIG_BLK_DEV_DM_BUILTIN=y CONFIG_BLK_DEV_DM=y i set. Here is output of /proc/crypto = # cat /proc/crypto name : ghash driver : ghash-generic module : kernel priority : 100 refcnt : 1 selftest : passed type : shash blocksize: 16 digestsize : 16 name : stdrng driver : drbg_nopr_hmac_sha256 module : kernel priority : 107
Re: [gentoo-user] another old server: what about udev and CONFIG_DEVTMPFS ?
On Mon, Apr 20, 2015 at 8:56 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 20/04/2015 14:51, Stefan G. Weichinger wrote: Another 5 yr server that needs some care. sys-fs/udev-151-r4 and a kernel without CONFIG_DEVTMPFS set. The old udev blocks openrc etc etc ... Aside from: install from scratch - what happens if I upgrade udev before booting a kernel with CONFIG_DEVTMPFS set? Problems? Yes, it won't work. And the ebuild will error out. Um... what? The ebuild will display a warning, but it does not die.
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
Am 20.04.2015 um 15:43 schrieb Marko Weber | 8000: # cryptsetup -c aes-xts:plain64 -y -s 512 luksFormat /dev/mapper/VolGroup01-media2 As I've already mentioned in my first answer, there is a typo in this command. Well, I actually didn't mention that it's a typo, but I gave you the correct command: # 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.) Or in other words: It's not -c aes-xts:plain64, but -c aes-xts-plain.
[gentoo-user] TomTom updates (wine?)
Hello, So TomTom only supports map updates to their devices via winblows. Sure I can do this but I'd like to do it from a gentoo system. So has anyone found a pathway that is sufficient for this (wine?) others ways to run the tomtom softare for map updates? Its a VIA 1605TM with lifetime free updates, if that matters. James
Re: [gentoo-user] cryptsetup wont use aes-xts:plain64
On Sat, 18 Apr 2015 12:27:15 +0200 Marko Weber | 8000 we...@zbfmail.de 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_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 I read the whole tread, but will reply here. I use this mode on some devices, and for me works fine (gentoo systems), I have it enabled in kernel, also I have cryptsetup with sys-fs/cryptsetup-1.6.5 (gcrypt nls python_single_target_python2_7 python_targets_python2_7 python_targets_python3_3 udev) You can probably ignore python*, 'gcrypt' is probably important USE flag. Also something which maybe unrelated to you but is important about CONFIG_CRYPTO_XTS is XTS: IEEE1619/D16 narrow block cipher use with aes-xts-plain, key size 256, 384 or 512 bits. This implementation currently can't handle a sectorsize which is not a multiple of 16 bytes.
Re: [gentoo-user] Re: Strange new behavior from the mount command
On Mon, Apr 20, 2015 at 3:21 PM, walt w41...@gmail.com wrote: On 04/19/2015 05:45 PM, Mike Gilbert wrote: On Sun, Apr 19, 2015 at 6:18 PM, walt w41...@gmail.com wrote: As a quick-and-dirty way of testing your idea I moved /etc/fstab out of the way. I was surprised to learn that mount doesn't care about fstab, and doesn't even bother to look for it (when invoked with no arguments). It reads information from /etc/mtab primarily, as well as /run/mount/utab. Also, if /etc/mtab is a symlink, it reads from /proc/self/mountinfo instead of /etc/mtab. It seems like there is probably some difference in the data it is reading from those files on your system. Maybe post them so we can all have a look? I really appreciate your help, thanks. Sorry there's so much to read through. I avoided the possible caching problem Francisco mentioned by booting the machine without an /etc/fstab, so it wound up with only / and swap partitions actually mounted. Here are the files that mount opened (running with no arguments) that it normally would not open: #cat /proc/cmdline BOOT_IMAGE=(hd0,gpt5)/boot/vmlinuz root=PARTUUID=345FD3C4-9E1C-49EB-859C-E3A3034325B3 rootwait init=/usr/lib64/systemd/systemd #cat /proc/self/mountinfo 12 0 8:21 / / rw,relatime shared:1 - ext4 /dev/root rw,data=ordered I think this may be related to having /dev/root appear in /proc/self/moutinfo. In this case, mount will look for your root filesystem in /proc/cmdline, and resolve it from there. Since your kernel command line has a PARTUUID tag, it probably needs to scan the partition tables to resolve that. This is mostly a SWAG; I didn't trace the code to this point.
Re: [gentoo-user] Re: Strange new behavior from the mount command
On Mon, Apr 20, 2015 at 4:01 PM, Mike Gilbert flop...@gentoo.org wrote: On Mon, Apr 20, 2015 at 3:21 PM, walt w41...@gmail.com wrote: On 04/19/2015 05:45 PM, Mike Gilbert wrote: On Sun, Apr 19, 2015 at 6:18 PM, walt w41...@gmail.com wrote: As a quick-and-dirty way of testing your idea I moved /etc/fstab out of the way. I was surprised to learn that mount doesn't care about fstab, and doesn't even bother to look for it (when invoked with no arguments). It reads information from /etc/mtab primarily, as well as /run/mount/utab. Also, if /etc/mtab is a symlink, it reads from /proc/self/mountinfo instead of /etc/mtab. It seems like there is probably some difference in the data it is reading from those files on your system. Maybe post them so we can all have a look? I really appreciate your help, thanks. Sorry there's so much to read through. I avoided the possible caching problem Francisco mentioned by booting the machine without an /etc/fstab, so it wound up with only / and swap partitions actually mounted. Here are the files that mount opened (running with no arguments) that it normally would not open: #cat /proc/cmdline BOOT_IMAGE=(hd0,gpt5)/boot/vmlinuz root=PARTUUID=345FD3C4-9E1C-49EB-859C-E3A3034325B3 rootwait init=/usr/lib64/systemd/systemd #cat /proc/self/mountinfo 12 0 8:21 / / rw,relatime shared:1 - ext4 /dev/root rw,data=ordered I think this may be related to having /dev/root appear in /proc/self/moutinfo. In this case, mount will look for your root filesystem in /proc/cmdline, and resolve it from there. Since your kernel command line has a PARTUUID tag, it probably needs to scan the partition tables to resolve that. This is mostly a SWAG; I didn't trace the code to this point. Also, there was a recent patch changed in gentoo-sources to prevent PARTUUID from appearing in /proc/self/mountinfo. This would explain why this is a new behavior for you. https://bugs.gentoo.org/show_bug.cgi?id=467266
[gentoo-user] Re: Strange new behavior from the mount command
On 04/19/2015 05:45 PM, Mike Gilbert wrote: On Sun, Apr 19, 2015 at 6:18 PM, walt w41...@gmail.com wrote: As a quick-and-dirty way of testing your idea I moved /etc/fstab out of the way. I was surprised to learn that mount doesn't care about fstab, and doesn't even bother to look for it (when invoked with no arguments). It reads information from /etc/mtab primarily, as well as /run/mount/utab. Also, if /etc/mtab is a symlink, it reads from /proc/self/mountinfo instead of /etc/mtab. It seems like there is probably some difference in the data it is reading from those files on your system. Maybe post them so we can all have a look? I really appreciate your help, thanks. Sorry there's so much to read through. I avoided the possible caching problem Francisco mentioned by booting the machine without an /etc/fstab, so it wound up with only / and swap partitions actually mounted. Here are the files that mount opened (running with no arguments) that it normally would not open: #cat /proc/cmdline BOOT_IMAGE=(hd0,gpt5)/boot/vmlinuz root=PARTUUID=345FD3C4-9E1C-49EB-859C-E3A3034325B3 rootwait init=/usr/lib64/systemd/systemd #cat /proc/partitions (only sdb5 and sdb6 are actually mounted atm) major minor #blocks name 80 120060864 sda 81 6144 sda1 85 15253654 sda5 86 27455053 sda6 87 25679871 sda7 88 25832488 sda8 89 25832488 sda9 1101048575 sr0 8 16 78150744 sdb 8 172313328 sdb1 8 18 2048 sdb2 8 21 20482843 sdb5 8 223092481 sdb6 8 23 26129691 sdb7 8 24 26129691 sdb8 20 4 fd0 8 32 488386584 sdc 8 33 1 sdc1 8 344192933 sdc2 8 35 7168 sdc3 8 37 484185112 sdc5 2540 157044736 dm-0 /etc/blkid.conf (but I don't have one) #cat /run/blkid/blkid.tab device DEVNO=0x0805 TIME=1429555704.829004 LABEL=amd64 UUID=e976fc30-c08f-6a5b-18c7-ef57278a08ad TYPE=ext4 PARTLABEL=Linux/Windows data PARTUUID=b098397c-68c3-4b56-bd15-6364c3c2108e/dev/sda5/device device DEVNO=0x0806 TIME=1429555704.829387 UUID=TMWa80-CXcZ-iQkR-SkQY-0xPe-p834-iNki91 TYPE=LVM2_member PARTLABEL=Linux LVM PARTUUID=68083bec-62f4-4979-8cd8-377d0cb62ac1/dev/sda6/device device DEVNO=0x0807 TIME=1429555704.829692 UUID=ehtwkq-Z4LH-Pdjn-5vp3-xRhM-12ho-OjlhZ9 TYPE=LVM2_member PARTLABEL=Linux LVM PARTUUID=b9b2a14b-b983-4cad-ac5f-cc1f5aad0a28/dev/sda7/device device DEVNO=0x0808 TIME=1429555704.829969 UUID=gyDXEl-y1Xd-Yll1-rtcf-I3ph-t22r-xk9r21 TYPE=LVM2_member PARTLABEL=Linux LVM PARTUUID=08c8a3a0-dabd-4921-980e-1b5bca87f258/dev/sda8/device device DEVNO=0x0809 TIME=1429555704.830247 UUID=JnKcRI-WGb4-SymA-3xi8-3YOU-8VaQ-YK4U75 TYPE=LVM2_member PARTLABEL=Linux LVM PARTUUID=fcc56ca1-a76c-44fb-a42c-76fe10d56120/dev/sda9/device device DEVNO=0x0811 TIME=1429555704.970765 LABEL=C UUID=3D15-CC2D TYPE=vfat PARTLABEL=Linux/Windows data PARTUUID=71dd1824-2a9a-4f17-afa1-32c9bfa5cab6/dev/sdb1/device device DEVNO=0x0815 TIME=1429555704.971519 LABEL=gentoo64unstable UUID=b2cce2df-05cd-0d3a-9fdd-30d4b4ceffce TYPE=ext4 PARTLABEL=Linux/Windows data PARTUUID=345fd3c4-9e1c-49eb-859c-e3a3034325b3/dev/sdb5/device device DEVNO=0x0816 TIME=1429555704.972341 LABEL=SWAP UUID=f09da9c9-968a-4a33-a01d-89ee41c5fa47 TYPE=swap PARTLABEL=Linux swap PARTUUID=bb618fd6-6be9-4bb4-b3aa-73a81c47edbd/dev/sdb6/device device DEVNO=0x0817 TIME=1429555704.972706 UUID=p8Dc0Z-eBoA-8F5q-ehxl-p0Ce-p2Z2-Q8ukuU TYPE=LVM2_member PARTLABEL=Linux LVM PARTUUID=b9f85a57-2bbc-48ff-baf7-2dbd5d10e573/dev/sdb7/device device DEVNO=0x0818 TIME=1429555704.972988 UUID=fJv0XT-3Ge2-Ipm4-y20s-wOv0-cClc-qcBO59 TYPE=LVM2_member PARTLABEL=Linux LVM PARTUUID=40a60278-daec-43a1-95e1-07308600467f/dev/sdb8/device device DEVNO=0x0822 TIME=1429555705.7818 LABEL=FAT32SAM UUID=B4F6-C857 TYPE=vfat PARTUUID=000c4056-02/dev/sdc2/device device DEVNO=0x0825 TIME=1429555705.18210 LABEL=SAMSUNG UUID=f8c60d37-f86a-4117-b71e-546de21cbd16 TYPE=ext4 PARTUUID=000c4056-05/dev/sdc5/device device DEVNO=0xfe00 TIME=1429555705.123208 PRI=45 LABEL=U UUID=482ec9a2-55cb-4f9d-8fff-ce73e29c1864 SEC_TYPE=ext2 TYPE=ext3/dev/mapper/vg0-u/device /proc/evms/volumes (but I don't have one) And (because /etc/mtab is a symlink to /proc/self/mounts): #cat /proc/self/mounts rootfs / rootfs rw 0 0 /dev/root / ext4 rw,relatime,data=ordered 0 0 devtmpfs /dev devtmpfs rw,relatime,size=1929384k,nr_inodes=482346,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0 tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup
