Re: [gentoo-user] Re: Problem with openrc-0.18.4 and ifplugd

[Mick]

On Tuesday 22 Dec 2015 14:20:26 Kai Krakow wrote:
> Am Tue, 22 Dec 2015 14:04:12 +
> 
> schrieb Mick :

> > There is no means of enabling or disabling the ifplugd service that I
> > have found, because there is no /etc/init.d/ifplugd script.  Once
> > installed ifplugd always starts at boot and daemonizes, configuring
> > or tearing down connections as a link is detected or lost.
> 
> As far as I understood, you now start ifplugd using the associated
> net.* init script. Openrc will detect that ifplugd is installed and
> then wait until a cable is plugged, plus starting an instance listening
> on the device.

No, this is not how ifplugd worked, for as long as I can remember.  I never 
started the interface, or had to start ifplugd by an init.d script or 
manually.


> Its clear how it used to work but I think the semantics changed. Since
> I do no longer use openrc I cannot confirm how the rest of the services
> react to and activated net.* init script if ifplugd is active through
> the plugin. I suppose dependent scripts should only be triggered after
> the cable is plugged in.
> 
> This is also why there is no config file: Its configured dynamically
> through the plugin and the interface specific init script.

I can confirm that the config file is only used by the /etc/init.d/ifplugd 
script - which however does not exist on Gentoo.

I created a config file, specified the enp11s0 there, started 
/usr/sbin/ifplugd manually and it still tried to bring up the default eth0 
interface.

Starting ifplugd manually with '-i enp11s0' works as intended.  It brings up 
the NIC and configures the interface:

 ifplugd(enp11s0)[4275]: ifplugd 0.28 initializing.
 ifplugd(enp11s0)[4275]: Using interface enp11s0/00:26:B9:20:B4:9C with driver 
 (version: 3.137)
 ifplugd(enp11s0)[4275]: Using detection mode: SIOCETHTOOL
 ifplugd(enp11s0)[4275]: Initialization complete, link beat not detected.
 kernel: IPv6: ADDRCONF(NETDEV_UP): enp11s0: link is not ready
 kernel: tg3 :0b:00.0 enp11s0: Link is up at 100 Mbps, full duplex
 kernel: tg3 :0b:00.0 enp11s0: Flow control is on for TX and on for RX
 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp11s0: link becomes ready
 ifplugd(enp11s0)[4275]: Link beat detected.
 ifplugd(enp11s0)[4275]: Executing '/etc/ifplugd/ifplugd.action enp11s0 up'.


> > I started this thread because recently I have to start my wired
> > interface manually, after which point ipfplugd also starts,
> > daemonizes and manages the connection.  This is not how it used to
> > work - I never had to start the wired interface myself.
> 
> This is how it works now: ifplugd is started through the interface
> script.

I hear what you say.  However, this makes me ask - what changed to cause this?  
Things changed since dev-libs/libgudev-230 and sys-fs/udev-225 were installed.  
<=sys-fs/udev-216 and friends used to bring up ifplugd(enp11s0) without any 
intervention from me or from /etc/init.d/ scripts.  So I have to guess that 
something changed in udev to cause this change in behaviour.

Thank you for helping me walk through this.  I'm going to raise a bug report 
and see what the devs think.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] [Sort of solved] Recommended pseudo-hardware for QEMU guest machine?

[wabenbau]

waltd...@waltdnes.org wrote:

> On Tue, Dec 22, 2015 at 05:43:17AM +0100, waben...@gmail.com wrote
> 
> > Have you installed x11-drivers/xf86-video-modesetting on the guest?
> 
>   Cannot be done on my machines.  On 2 physical machines, and on the
> Gentoo guest, I get...

You don't have to install it on the physical machines but only on the
guests.
 
> > emerge -pv xf86-video-modesetting
> > 
> > These are the packages that would be merged, in order:
> > 
> > Calculating dependencies... done!
> > [ebuild  N ] x11-drivers/xf86-video-modesetting-0.9.0::gentoo
> > 298 KiB [blocks B  ] x11-drivers/xf86-video-modesetting
> > ("x11-drivers/xf86-video-modesetting" is blocking
> > x11-base/xorg-server-1.17.4)
> > 
> > Total: 1 package (1 new), Size of downloads: 298 KiB
> > Conflict: 1 block (1 unsatisfied)
> > 
> >  * Error: The above package list contains packages which cannot be
> >  * installed at the same time on the same system.
> 
>   On the guest, I unmerged xorg-server and tried emerging
> xf86-video-modesetting.  The result was that it would've pulled in
> xorg-server, which would again have blocked xf86-video-modesetting.
> Wierd.

That's indeed strange. As I said, I have no experiences with gentoo
as guest OS.

Maybe it will help to recompile xorg-server without the xorg USE flag
on the guest machine. When you can connect via ssh then you can revert
it easily when it fails.

And use emerge --backtrack=999 :-)
 
> > Have you compiled the guest kernel with CONFIG_DRM_CIRRUS_QEMU?
> > 
> > If yes, then I guess that you don't need xf86-video-cirrus at all.
> > 
> > > With "-vga
> > > std" X doesn't start up at all.
> > 
> > You probably need to compile the guest kernel with CONFIG_DRM_BOCHS
> > for "-vga std".
> >  
> > >   Any suggestions for improvement?
> > 
> > There is also a kernel option for a KMS enabled DRM driver for the 
> > VMware SVGA virtual hardware (CONFIG_DRM_VMWGFX). I think that the 
> > performance of this driver is better than the performance of the
> > cirrus driver.
> 
>   As I mentioned earlier vmware, cirrus, and bochs all ticked off in
> "make menuconfig".  Now that I have something working, I think I'll

These options are depending on CONFIG_HAS_IOMEM, CONFIG_DRM and 
CONFIG_PCI. You must activate all of these options too.

> make a copy of the 10-gig guest disk image before any further
> tweaking that might render it inoperative again.

Backups are always a good idea.
 
> >   I think that you also need x11-drivers/xf86-video-vmware installed
> > on the guest if you want to use "-vga vmware".
> 
>   I've tried that earlier, when things weren't working.  Maybe it'll
> work this time.

Good luck.

--
Regards
wabe

Re: [gentoo-user] (Not Solved for me) anyone tried amdgpu (kernel module)

[Alexander Kapshuk]

On Tue, Dec 22, 2015 at 9:39 PM, Mick  wrote:

> On Sunday 20 Dec 2015 20:29:28 Alexander Kapshuk wrote:
> > On Sun, Dec 20, 2015 at 9:04 PM, Mick  wrote:
>
> > > This is not working for me on a Kaveri system.
> > >
> > > The wiki page suggests these firmware blobs:
> > >
> > > radeon/kaveri_ce.bin radeon/kaveri_me.bin radeon/kaveri_mec2.bin
> > > radeon/kaveri_mec.bin radeon/kaveri_pfp.bin radeon/kaveri_rlc.bin
> > > radeon/kaveri_sdma1.bin radeon/kaveri_sdma.bin radeon/kaveri_uvd.bin
> > > radeon/kaveri_vce.bin
> > >
> > > Unfortunately, radeon/kaveri_sdma1.bin does not seen to be available
> when
> > > I use sys-kernel/linux-firmware:
> > >
> > > find /lib/firmware/radeon/ -iname KAVERI*sdma*
> > > /lib/firmware/radeon/kaveri_sdma.bin
> > > /lib/firmware/radeon/KAVERI_sdma.bin
> > >
> > >
> > > I installed sys-firmware/amdgpu-ucode, but KAVERI is not found there
> > > either:
> > >
> > > find /lib/firmware/amdgpu/ -iname *sdma*
> > > /lib/firmware/amdgpu/carrizo_sdma.bin
> > > /lib/firmware/amdgpu/carrizo_sdma1.bin
> > > /lib/firmware/amdgpu/fiji_sdma.bin
> > > /lib/firmware/amdgpu/fiji_sdma1.bin
> > > /lib/firmware/amdgpu/tonga_sdma.bin
> > > /lib/firmware/amdgpu/tonga_sdma1.bin
> > > /lib/firmware/amdgpu/topaz_sdma.bin
> > > /lib/firmware/amdgpu/topaz_sdma1.bin
> > >
> > >
> > > Building the recommended blobs fails like so:
> > >
> > > # make && make modules_install && make firmware_install
> > >
> > >   CHK include/config/kernel.release
> > >   CHK include/generated/uapi/linux/version.h
> > >   CHK include/generated/utsrelease.h
> > >   CHK include/generated/bounds.h
> > >   CHK include/generated/asm-offsets.h
> > >   CALLscripts/checksyscalls.sh
> > >   CHK include/generated/compile.h
> > >
> > > kernel/Makefile:135: *** No X.509 certificates found ***
> > > make[1]: *** No rule to make target
> > > '/lib/firmware//radeon/kaveri_sdma1.bin',
> > > needed by 'firmware/radeon/kaveri_sdma1.bin.gen.o'.  Stop.
> > > Makefile:947: recipe for target 'firmware' failed
> > > make: *** [firmware] Error 2
>
> > That's interesting. 'kaveri_sdma1.bin' is found in the
> > 'sys-firmware/amdgpu-ucode' package. See below.
> > % pwd
> > radeon_ucode/kaveri
>
> I don't seem to have such a directory, or the files therein.  Where am I
> supposed to look?
>
> This is what emerge -uaDv sys-firmware/amdgpu-ucode installed on my PC:
>
> >>> Installing (1 of 1) sys-firmware/amdgpu-ucode-20150803::gentoo
>  * checking 44 files for package collisions
> >>> Merging sys-firmware/amdgpu-ucode-20150803 to /
> --- /lib/
> --- /lib/firmware/
> --- /lib/firmware/amdgpu/
> >>> /lib/firmware/amdgpu/carrizo_ce.bin
> >>> /lib/firmware/amdgpu/carrizo_me.bin
> >>> /lib/firmware/amdgpu/carrizo_mec.bin
> >>> /lib/firmware/amdgpu/carrizo_mec2.bin
> >>> /lib/firmware/amdgpu/carrizo_pfp.bin
> >>> /lib/firmware/amdgpu/carrizo_rlc.bin
> >>> /lib/firmware/amdgpu/carrizo_sdma.bin
> >>> /lib/firmware/amdgpu/carrizo_sdma1.bin
> >>> /lib/firmware/amdgpu/carrizo_uvd.bin
> >>> /lib/firmware/amdgpu/carrizo_vce.bin
> >>> /lib/firmware/amdgpu/fiji_ce.bin
> >>> /lib/firmware/amdgpu/fiji_mc.bin
> >>> /lib/firmware/amdgpu/fiji_me.bin
> >>> /lib/firmware/amdgpu/fiji_mec.bin
> >>> /lib/firmware/amdgpu/fiji_mec2.bin
> >>> /lib/firmware/amdgpu/fiji_pfp.bin
> >>> /lib/firmware/amdgpu/fiji_rlc.bin
> >>> /lib/firmware/amdgpu/fiji_sdma.bin
> >>> /lib/firmware/amdgpu/fiji_sdma1.bin
> >>> /lib/firmware/amdgpu/fiji_smc.bin
> >>> /lib/firmware/amdgpu/fiji_uvd.bin
> >>> /lib/firmware/amdgpu/fiji_vce.bin
> >>> /lib/firmware/amdgpu/tonga_ce.bin
> >>> /lib/firmware/amdgpu/tonga_mc.bin
> >>> /lib/firmware/amdgpu/tonga_me.bin
> >>> /lib/firmware/amdgpu/tonga_mec.bin
> >>> /lib/firmware/amdgpu/tonga_mec2.bin
> >>> /lib/firmware/amdgpu/tonga_pfp.bin
> >>> /lib/firmware/amdgpu/tonga_rlc.bin
> >>> /lib/firmware/amdgpu/tonga_sdma.bin
> >>> /lib/firmware/amdgpu/tonga_sdma1.bin
> >>> /lib/firmware/amdgpu/tonga_smc.bin
> >>> /lib/firmware/amdgpu/tonga_uvd.bin
> >>> /lib/firmware/amdgpu/tonga_vce.bin
> >>> /lib/firmware/amdgpu/topaz_ce.bin
> >>> /lib/firmware/amdgpu/topaz_mc.bin
> >>> /lib/firmware/amdgpu/topaz_me.bin
> >>> /lib/firmware/amdgpu/topaz_mec.bin
> >>> /lib/firmware/amdgpu/topaz_mec2.bin
> >>> /lib/firmware/amdgpu/topaz_pfp.bin
> >>> /lib/firmware/amdgpu/topaz_rlc.bin
> >>> /lib/firmware/amdgpu/topaz_sdma.bin
> >>> /lib/firmware/amdgpu/topaz_sdma1.bin
> >>> /lib/firmware/amdgpu/topaz_smc.bin
>
> No /kaveri/ in there.
>
>
> > Perhaps the path to the binary blobs specified in your kernel config file
> > is wrong? You want to double check that.
>
>
> This is what I have:
>
> grep /firmware .config
> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"
>
> Looking at it again the amdgpu wiki page does not list amdgpu firmwares for
> the KAVERI APU.  However, I am confused as to why I can't find
> radeon/kaveri_sdma1 in my installed firmwares (either from linux-firmware,
> or
> from amdgpu-ucode.
>
> --
> 

Re: perl ssl was:Re: [gentoo-user] dovecot imap-login

[Mick]

On Tuesday 22 Dec 2015 15:48:22 jens wefer wrote:
> Am Sun, 20 Dec 2015 23:18:00 +
> 
> schrieb Mick :

> > It may be a postfix bug, or it may be that gentoo's openssl ciphers
> > are more up to date and won't degrade the connection to SSLv3.  Can
> > you check what you get on the transaction with the server using
> > openssl_client?  Google for the correct commands to negotiate sending
> > messages using telnet so that you know what to type on the console.
> 
> Thanks for the tip.
> I test ssl smtp/imap with openssl s_client who reports error.20 unable
> to get local issuer certificate, so I create a new self signed
> certificate. first test with sendEmail and imapsync runs.
> I do not understand is why the client software works under other
> operating systems.
> 
> thx, bye, jens.

This could be because other distros OpenSSL configuration is not as strict/up 
to date as gentoo's.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] (Not Solved for me) anyone tried amdgpu (kernel module)

[Mick]

On Tuesday 22 Dec 2015 23:02:12 you wrote:
> On Tuesday 22 Dec 2015 21:30:48 Alexander Kapshuk wrote:

> > 'legacy' seems to be disabled by default. See below.
> > # emerge -ap sys-firmware/amdgpu-ucode
> > 
> > These are the packages that would be merged, in order:
> > 
> > Calculating dependencies  ... done!
> > [ebuild  N~] sys-firmware/amdgpu-ucode-20150803  USE="-legacy"
> 
> Aha!  Good catch!
> 
> [-  ] legacy
> sys-firmware/amdgpu-ucode: Install firmware for older chipsets which
> are optionally supported by AMDGPU
> [-  ] 20150803 [gentoo]
> 
> 
> Can I have both amdgpu and linux-firmware?
> 
> The latter has some wireless firmware I think I need to retain.

OK, I can have both emerged with the legacy USE flag, because of radeon 
firmware file collisions.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] [Sort of solved] Recommended pseudo-hardware for QEMU guest machine?

[waltdnes]

On Tue, Dec 22, 2015 at 08:59:47PM +0100, waben...@gmail.com wrote
> waltd...@waltdnes.org wrote:
> 
> These options are depending on CONFIG_HAS_IOMEM, CONFIG_DRM and 
> CONFIG_PCI. You must activate all of these options too.

  All set in the guest kernel.

> > >   I think that you also need x11-drivers/xf86-video-vmware installed
> > > on the guest if you want to use "-vga vmware".
> > 
> >   I've tried that earlier, when things weren't working.  Maybe it'll
> > work this time.
> 
> Good luck.

  "-vga vmware" started off OK in the text console today, but two major
problems...

1) No mouse or text cursor once I fired up X.  A Google search indicates
that no-cursor-in-graphics-mode is a common problem with Vmware across
all platforms.  The QEMU "-show-cursor" option did not help.  Otherwise X
looked OK, and xrandr listed some ridiculously high resolutions, higher
than my 1920x1080 monitor.

2) The mouse still worked, despite being invisible.  I was able to
blindly execute the mouse-click sequence to bring up the menu that
included logoff.  Once I returned to the text console, it was all red.
Again, the keyboard still worked, and I was able to blindly shut down
the guest.

  For now I'll stick with "-vga cirrus" or "-vga std".  Looking at the
Xorg logs, I noticed that in "-vga std" X was looking for the "fbdev"
module, not finding it, and giving up.  I emerged xf86-video-fbdev and X
now works in "-vga std", although xrandr reports only 1024x768 is
available.  I intend to use it in linux mostly for distcc, so limited X
Window size options aren't a problem.

  I didn't get much linux computing done today.  I picked up a cheap
external USB floppy drive at Canada Computers and transferred Galactic
Civilizations v2.5 for OS/2 from my ancient relic 450 mhz Pentium 3 (128
megs of RAM) to my QEMU machine.  The P3 has a built-in floppy drive; my
other computers don't.  The next challenge is to get OS/2 Warp 4 running
in QEMU as per http://sites.mpc.com.br/ric/qemu/

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] (Not Solved for me) anyone tried amdgpu (kernel module)

[Mick]

On Tuesday 22 Dec 2015 23:07:24 Mick wrote:
> On Tuesday 22 Dec 2015 23:02:12 you wrote:
> > On Tuesday 22 Dec 2015 21:30:48 Alexander Kapshuk wrote:
> > > 'legacy' seems to be disabled by default. See below.
> > > # emerge -ap sys-firmware/amdgpu-ucode
> > > 
> > > These are the packages that would be merged, in order:
> > > 
> > > Calculating dependencies  ... done!
> > > [ebuild  N~] sys-firmware/amdgpu-ucode-20150803  USE="-legacy"
> > 
> > Aha!  Good catch!
> > 
> > [-  ] legacy
> > 
> > sys-firmware/amdgpu-ucode: Install firmware for older chipsets which
> > are optionally supported by AMDGPU
> > 
> > [-  ] 20150803 [gentoo]
> > 
> > Can I have both amdgpu and linux-firmware?
> > 
> > The latter has some wireless firmware I think I need to retain.
> 
> OK, I can have both emerged with the legacy USE flag, because of radeon
> firmware file collisions.

I think I have some success!  :-)  It booted without any discernible problems, 
although I came across this complain in dmesg:

[0.544769] [drm] radeon: 1024M of VRAM memory ready
[0.544772] [drm] radeon: 1024M of GTT memory ready.
[0.544781] [drm] Loading kaveri Microcode
[0.544788] [drm] Internal thermal controller without fan control
[0.546112] [drm] radeon: dpm initialized
[0.546126] radeon :00:01.0: Direct firmware load for 
radeon/BONAIRE_uvd.bin failed with error -2
[0.546131] radeon :00:01.0: radeon_uvd: Can't load firmware 
"radeon/BONAIRE_uvd.bin"
[0.546141] radeon :00:01.0: Direct firmware load for 
radeon/BONAIRE_vce.bin failed with error -2
[0.546146] radeon :00:01.0: radeon_vce: Can't load firmware 
"radeon/BONAIRE_vce.bin"
[0.546152] [drm] GART: num cpu pages 262144, num gpu pages 262144
[0.559563] [drm] PCIE GART of 1024M enabled (table at 0x0004).
[0.559896] radeon :00:01.0: WB enabled
[0.559923] radeon :00:01.0: fence driver on ring 0 use gpu addr 
0x4c00 and cpu addr 0x88041dc03c00
[0.559931] radeon :00:01.0: fence driver on ring 1 use gpu addr 
0x4c04 and cpu addr 0x88041dc03c04
[0.559937] radeon :00:01.0: fence driver on ring 2 use gpu addr 
0x4c08 and cpu addr 0x88041dc03c08
[0.559944] radeon :00:01.0: fence driver on ring 3 use gpu addr 
0x4c0c and cpu addr 0x88041dc03c0c
[0.559950] radeon :00:01.0: fence driver on ring 4 use gpu addr 
0x4c10 and cpu addr 0x88041dc03c10
[0.559957] radeon :00:01.0: VCE init error (-22).
[0.559961] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[0.559965] [drm] Driver supports precise vblank timestamp query.
[0.559997] radeon :00:01.0: radeon: using MSI.
[0.560020] [drm] radeon: irq initialized.


Why is it asking for radeon/BONAIRE_*.bin?  :-/

The wiki page suggests I use the kaveri list of firmwares.  Should I use 
bonaire instead?  Or should I add the bonaire list to my existing kaveri 
firmwares in the kernel?
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

[gentoo-user] IPTABLES

[siefke_lis...@web.de]

Hello,

i try to run iptables, block bad ips and close the system. 

I want run firewall which block all INPUT, only ALLOW services i defined.
Ipset want to use to block spam ips, make it sure awesome as ever set rules 
manuell.

Im not so sure is okay, i has try and read but at end often i kick me out
from rootserver. So better ask what say profis of Gentoo. 

The Firewall Script > http://pastebin.com/b3305i41


Thank you for help & Nice Day

Silvio Siefke


pgpny1UxlIRK_.pgp
Description: PGP signature

Re: [gentoo-user] (Not Solved for me) anyone tried amdgpu (kernel module)

[Mick]

On Tuesday 22 Dec 2015 21:30:48 Alexander Kapshuk wrote:
> On Tue, Dec 22, 2015 at 9:39 PM, Mick  wrote:
> > On Sunday 20 Dec 2015 20:29:28 Alexander Kapshuk wrote:
> > > On Sun, Dec 20, 2015 at 9:04 PM, Mick  wrote:
> > > > This is not working for me on a Kaveri system.
> > > > 
> > > > The wiki page suggests these firmware blobs:
> > > > 
> > > > radeon/kaveri_ce.bin radeon/kaveri_me.bin radeon/kaveri_mec2.bin
> > > > radeon/kaveri_mec.bin radeon/kaveri_pfp.bin radeon/kaveri_rlc.bin
> > > > radeon/kaveri_sdma1.bin radeon/kaveri_sdma.bin radeon/kaveri_uvd.bin
> > > > radeon/kaveri_vce.bin
> > > > 
> > > > Unfortunately, radeon/kaveri_sdma1.bin does not seen to be available
> > 
> > when
> > 
> > > > I use sys-kernel/linux-firmware:
> > > > 
> > > > find /lib/firmware/radeon/ -iname KAVERI*sdma*
> > > > /lib/firmware/radeon/kaveri_sdma.bin
> > > > /lib/firmware/radeon/KAVERI_sdma.bin
> > > > 
> > > > 
> > > > I installed sys-firmware/amdgpu-ucode, but KAVERI is not found there
> > > > either:
> > > > 
> > > > find /lib/firmware/amdgpu/ -iname *sdma*
> > > > /lib/firmware/amdgpu/carrizo_sdma.bin
> > > > /lib/firmware/amdgpu/carrizo_sdma1.bin
> > > > /lib/firmware/amdgpu/fiji_sdma.bin
> > > > /lib/firmware/amdgpu/fiji_sdma1.bin
> > > > /lib/firmware/amdgpu/tonga_sdma.bin
> > > > /lib/firmware/amdgpu/tonga_sdma1.bin
> > > > /lib/firmware/amdgpu/topaz_sdma.bin
> > > > /lib/firmware/amdgpu/topaz_sdma1.bin
> > > > 
> > > > 
> > > > Building the recommended blobs fails like so:
> > > > 
> > > > # make && make modules_install && make firmware_install
> > > > 
> > > >   CHK include/config/kernel.release
> > > >   CHK include/generated/uapi/linux/version.h
> > > >   CHK include/generated/utsrelease.h
> > > >   CHK include/generated/bounds.h
> > > >   CHK include/generated/asm-offsets.h
> > > >   CALLscripts/checksyscalls.sh
> > > >   CHK include/generated/compile.h
> > > > 
> > > > kernel/Makefile:135: *** No X.509 certificates found ***
> > > > make[1]: *** No rule to make target
> > > > '/lib/firmware//radeon/kaveri_sdma1.bin',
> > > > needed by 'firmware/radeon/kaveri_sdma1.bin.gen.o'.  Stop.
> > > > Makefile:947: recipe for target 'firmware' failed
> > > > make: *** [firmware] Error 2
> > > 
> > > That's interesting. 'kaveri_sdma1.bin' is found in the
> > > 'sys-firmware/amdgpu-ucode' package. See below.
> > > % pwd
> > > radeon_ucode/kaveri
> > 
> > I don't seem to have such a directory, or the files therein.  Where am I
> > supposed to look?
> > 
> > This is what emerge -uaDv sys-firmware/amdgpu-ucode installed on my PC:
> > >>> Installing (1 of 1) sys-firmware/amdgpu-ucode-20150803::gentoo
> >  
> >  * checking 44 files for package collisions
> >  
> > >>> Merging sys-firmware/amdgpu-ucode-20150803 to /
> > 
> > --- /lib/
> > --- /lib/firmware/
> > --- /lib/firmware/amdgpu/
> > 
> > >>> /lib/firmware/amdgpu/carrizo_ce.bin
> > >>> /lib/firmware/amdgpu/carrizo_me.bin
> > >>> /lib/firmware/amdgpu/carrizo_mec.bin
> > >>> /lib/firmware/amdgpu/carrizo_mec2.bin
> > >>> /lib/firmware/amdgpu/carrizo_pfp.bin
> > >>> /lib/firmware/amdgpu/carrizo_rlc.bin
> > >>> /lib/firmware/amdgpu/carrizo_sdma.bin
> > >>> /lib/firmware/amdgpu/carrizo_sdma1.bin
> > >>> /lib/firmware/amdgpu/carrizo_uvd.bin
> > >>> /lib/firmware/amdgpu/carrizo_vce.bin
> > >>> /lib/firmware/amdgpu/fiji_ce.bin
> > >>> /lib/firmware/amdgpu/fiji_mc.bin
> > >>> /lib/firmware/amdgpu/fiji_me.bin
> > >>> /lib/firmware/amdgpu/fiji_mec.bin
> > >>> /lib/firmware/amdgpu/fiji_mec2.bin
> > >>> /lib/firmware/amdgpu/fiji_pfp.bin
> > >>> /lib/firmware/amdgpu/fiji_rlc.bin
> > >>> /lib/firmware/amdgpu/fiji_sdma.bin
> > >>> /lib/firmware/amdgpu/fiji_sdma1.bin
> > >>> /lib/firmware/amdgpu/fiji_smc.bin
> > >>> /lib/firmware/amdgpu/fiji_uvd.bin
> > >>> /lib/firmware/amdgpu/fiji_vce.bin
> > >>> /lib/firmware/amdgpu/tonga_ce.bin
> > >>> /lib/firmware/amdgpu/tonga_mc.bin
> > >>> /lib/firmware/amdgpu/tonga_me.bin
> > >>> /lib/firmware/amdgpu/tonga_mec.bin
> > >>> /lib/firmware/amdgpu/tonga_mec2.bin
> > >>> /lib/firmware/amdgpu/tonga_pfp.bin
> > >>> /lib/firmware/amdgpu/tonga_rlc.bin
> > >>> /lib/firmware/amdgpu/tonga_sdma.bin
> > >>> /lib/firmware/amdgpu/tonga_sdma1.bin
> > >>> /lib/firmware/amdgpu/tonga_smc.bin
> > >>> /lib/firmware/amdgpu/tonga_uvd.bin
> > >>> /lib/firmware/amdgpu/tonga_vce.bin
> > >>> /lib/firmware/amdgpu/topaz_ce.bin
> > >>> /lib/firmware/amdgpu/topaz_mc.bin
> > >>> /lib/firmware/amdgpu/topaz_me.bin
> > >>> /lib/firmware/amdgpu/topaz_mec.bin
> > >>> /lib/firmware/amdgpu/topaz_mec2.bin
> > >>> /lib/firmware/amdgpu/topaz_pfp.bin
> > >>> /lib/firmware/amdgpu/topaz_rlc.bin
> > >>> /lib/firmware/amdgpu/topaz_sdma.bin
> > >>> /lib/firmware/amdgpu/topaz_sdma1.bin
> > >>> /lib/firmware/amdgpu/topaz_smc.bin
> > 
> > No /kaveri/ in there.
> > 
> > > Perhaps the path to the binary blobs specified in your kernel config
> > > file is wrong? You want to double check that.
> > 
> > This is what 

Re: [gentoo-user] Re: Problem with openrc-0.18.4 and ifplugd

[Neil Bothwick]

On Tue, 22 Dec 2015 15:15:57 +, Mick wrote:

> > As far as I understood, you now start ifplugd using the associated
> > net.* init script. Openrc will detect that ifplugd is installed and
> > then wait until a cable is plugged, plus starting an instance
> > listening on the device.  
> 
> No, this is not how ifplugd worked, for as long as I can remember.  I
> never started the interface, or had to start ifplugd by an init.d
> script or manually.

It may not be how you used it, but that is how ifplugd (or netplug) is
supposed to be used with openrc. It detects whether ifplugd or netplug is
installed when the interface is started up and starts it up to monitor
the interface using the correct options. It's been that way fr a lot of
years and was documented, I think in the comments in the net.* scripts.

Your approach may have worked in the past but it was unsupported, now it
appears that it doesn't work.


-- 
Neil Bothwick

WYTYSYDG - What you thought you saw, you didn't get.


pgpqLHMOQkCzt.pgp
Description: OpenPGP digital signature

Re: perl ssl was:Re: [gentoo-user] dovecot imap-login

[jens wefer]

Am Sun, 20 Dec 2015 23:18:00 +
schrieb Mick :

> On Saturday 19 Dec 2015 10:31:09 jens wefer wrote:
> > Am Mon, 14 Dec 2015 08:50:29 +0100
> > 
> > schrieb jens wefer :
> > > Am Sat, 12 Dec 2015 23:09:20 +0100
> > > 
> > > schrieb jens wefer :
> > > > Am Sat, 12 Dec 2015 17:53:04 +
> > > > 
> > > > schrieb Stroller :
> > > > > > On Sat, 12 December 2015, at 3:08 a.m., jens wefer
> > > > > >  wrote:
> > > > > > 
> > > > > > I set up a mail server, postfix/dovecot, ssl required.
> > > > > > test with mail-client, all ok
> > > > > > when I try to copy mails with imapsync (gentoo) comes
> > > > > > timeout, and imapsync will login again.
> > > > > > with each new login, a new process imap-login is generated.
> > > > > 
> > > > > Sorry if this is a dumb question, but how do you know it's
> > > > > timing out?
> > > > > 
> > > > > Could it just be slow, as it has to compile loads of messages
> > > > > in its first run?
> > > > > 
> > > > > Looks like dovecot has a 30 minute timeout. [1]
> > > > > 
> > > > > An old message on the Dovecot mailing list [2] suggests to set
> > > > > "verbose_proctitle = yes" in config to see why each process is
> > > > > open.
> > > > > 
> > > > > It also suggests using high-performance mode, rather that the
> > > > > default.
> > > > > 
> > > > > Stroller.
> > > > 
> > > > timeout comes from imapsync (default timeout 120 sec).
> > > > after 10 minutes then running 5 Dovecot processes which want
> > > > 100% CPU time. mail logfile:
> > > > imap-login: Login: user =  blablub, TLS ession, ..
> > > 
> > > I think that's a problem with perl.
> > > When I send an email with sendEmail comes SSLv3 Aler handshake
> > > failure. if I use a newer sendEmail version (1.56.5) comes
> > > Segnentation fault. when I start sendEmail on CentOS is
> > > everything ok.
> > 
> > I send emails with email-client and sendEmail (win/centos).
> > mail.log
> > [...]: initializing the server-side TLS engine
> > [...]: connect from brumw.lxsbbshome.tld[192.168.0.15]
> > [...]: setting up TLS connection from
> > brumw.lxsbbshome.tld[192.168.0.15] [...]:
> > brumw.lxsbbshome.tld[192.168.0.15]: TLS cipher list
> > "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH" [...]:
> > SSL_accept:before/accept initialization [...]: SSL_accept:SSLv3
> > read client hello A [...]: SSL_accept:SSLv3 write server hello A
> > [...]: SSL_accept:SSLv3 write certificate A [...]: SSL_accept:SSLv3
> > write server done A [...]: SSL_accept:SSLv3 flush data
> > [...]: SSL_accept:SSLv3 read client certificate A
> > [...]: SSL_accept:SSLv3 read client key exchange A
> > [...]: SSL_accept:SSLv3 read certificate verify A
> > [...]: SSL_accept:SSLv3 read finished A
> > [...]: brumw.lxsbbshome.tld[192.168.0.15]: Issuing session ticket,
> > key expiration: 1450478594 [...]: SSL_accept:SSLv3 write session
> > ticket A [...]: SSL_accept:SSLv3 write change cipher spec A
> > [...]: SSL_accept:SSLv3 write finished A
> > [...]: SSL_accept:SSLv3 flush data
> > [...]: Anonymous TLS connection established from
> > brumw.lxsbbshome.tld[192.168.0.15]: TLSv1.2 with cipher
> > AES128-GCM-SHA256 (128/128 bits) [...]: AFC46282149:
> > client=brumw.lxsbbshome.tld[192.168.0.15]
> > 
> > when I send email with sendEmail from gentoo-client it comes
> > handshake error mail.log
> > [...]: initializing the server-side TLS engine
> > [...]: connect from robin.lxsbbshome.tld[192.168.0.17]
> > [...]: setting up TLS connection from
> > robin.lxsbbshome.tld[192.168.0.17] [...]:
> > robin.lxsbbshome.tld[192.168.0.17]: TLS cipher list
> > "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH" [...]:
> > SSL_accept:before/accept initialization [...]: SSL3 alert
> > write:fatal:handshake failure [...]: SSL_accept:error in error
> > [...]: SSL_accept:error in error [...]: SSL_accept error from
> > robin.lxsbbshome.tld[192.168.0.17]: -1 [...]: warning: TLS library
> > problem: error:1408A10B:SSL routines:ssl3_get_client_hello:wrong
> > version number:s3_srvr.c:960: [...]: lost connection after STARTTLS
> > from robin.lxsbbshome.tld[192.168.0.17] [...]: disconnect from
> > robin.lxsbbshome.tld[192.168.0.17] ehlo=1 starttls=0/1 commands=1/2
> > 
> > sendEmail.log
> > [...]: DEBUG => Connecting to rosalie.lxsbbshome.tld:25
> > [...]: DEBUG => My IP address is: 192.168.0.17
> > [...]: DEBUG => evalSMTPresponse() - Checking for SMTP success or
> > error status in the message: 220 rosalie.lxsbbshome.tld ESMTP
> > Postfix [...]: DEBUG => evalSMTPresponse() - Found SMTP success
> > code: 220 [...]: SUCCESS => Received:   220
> > rosalie.lxsbbshome.tld ESMTP Postfix [...]: INFO => Sending:
> > EHLO robin.lxsbbshome.tld [...]: DEBUG =>
> > evalSMTPresponse() - Checking for SMTP success or error status in
> > the message: 250-rosalie.lxsbbshome.tld, 250-PIPELINING, 250-SIZE
> > 1024, 250-VRFY, 250-ETRN, 250-STARTTLS, 250-AUTH PLAIN,
> > 

[gentoo-user] Re: Problem with openrc-0.18.4 and ifplugd

[Kai Krakow]

Am Tue, 22 Dec 2015 14:04:12 +
schrieb Mick :

> On Tuesday 22 Dec 2015 01:12:10 Kai Krakow wrote:
> > Am Tue, 22 Dec 2015 00:54:35 +
> > 
> > schrieb Mick :
> > > On Tuesday 22 Dec 2015 00:48:13 Neil Bothwick wrote:
> > > > On Mon, 21 Dec 2015 23:55:06 +, Mick wrote:
> > > > > > Are you trying to run ifplugd from its init script? It's not
> > > > > > meant to be used like that with openrc.
> > > > > 
> > > > > I don't have any init scripts for ifplugd.  I wondered what
> > > > > starts it/stops it, and found /lib64/netifrc/net/ifplugd.sh
> > > > 
> > > > It should be started by the net.eth* scripts, so you need to
> > > > start the network interface first.
> > > 
> > > Thanks again Neil.  I don't think this is as you suggest.  I never
> > > had wired or wireless interfaces enabled to start at boot time,
> > > because ifplugd started them up as necessary.
> > > 
> > > From the README file:
> > >The network interface which is controlled by ifplugd should
> > > not be configured automatically by your distribution's network
> > > subsystem, since ifplugd will do this for you if needed.
> > 
> > But that doesn't apply here because the "net.* plugin" starts
> > ifplugd, and defers further initializations until ifplugd detects a
> > link.
> > 
> > This is what I meant when I talked about pushing ifplugd further
> > down the layer. I just didn't remember that this is now solved by a
> > plugin in net.* itself.
> > 
> > Don't enable ifplugd service. Openrc will do its magic.
> 
> There is no means of enabling or disabling the ifplugd service that I
> have found, because there is no /etc/init.d/ifplugd script.  Once
> installed ifplugd always starts at boot and daemonizes, configuring
> or tearing down connections as a link is detected or lost.

As far as I understood, you now start ifplugd using the associated
net.* init script. Openrc will detect that ifplugd is installed and
then wait until a cable is plugged, plus starting an instance listening
on the device.

> To make it clearer, this is how it used to work on two laptops:
> 
> I install ifplugd and remove from rc-update any net. that I
> have configured.  ifplugd will always start at boot as a daemon and
> will bring up and configure the wired NIC once a cable is detected.
> There is no start up script in /etc/init.d/ installed by default,
> although the man page mentions it, along
> with /etc/ifplugd/ifplugd.conf, which is also not installed.  This is
> the only file that installed on my systems:
> 
> # find /etc -iname *ifplug*
> /etc/ifplugd
> /etc/ifplugd/ifplugd.action

Its clear how it used to work but I think the semantics changed. Since
I do no longer use openrc I cannot confirm how the rest of the services
react to and activated net.* init script if ifplugd is active through
the plugin. I suppose dependent scripts should only be triggered after
the cable is plugged in.

This is also why there is no config file: Its configured dynamically
through the plugin and the interface specific init script.

> I started this thread because recently I have to start my wired
> interface manually, after which point ipfplugd also starts,
> daemonizes and manages the connection.  This is not how it used to
> work - I never had to start the wired interface myself.

This is how it works now: ifplugd is started through the interface
script.

You may need to start and stop network dependent service through
ifplugd.action instead of enabling them statically through openrc. But
again: I'm not sure about it. It may be worth a try.

> Furthermore, starting ifplugd on a terminal now shows that it is
> listening on eth0 instead of enp11s0, but hadn't tried this before
> things broke.  According to the man page eth0 is the default, but I
> can't recall manually specifying a different interface for ifplugd in
> the past.  It always brought up the wired interface, no matter what
> it was called.

This is due to its defaults mentioned in the man page: It defaults to
eth0. Gentoo no longer installs a config file.


-- 
Regards,
Kai

Replies to list-only preferred.


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Problem with openrc-0.18.4 and ifplugd

[Mick]

On Tuesday 22 Dec 2015 01:12:10 Kai Krakow wrote:
> Am Tue, 22 Dec 2015 00:54:35 +
> 
> schrieb Mick :
> > On Tuesday 22 Dec 2015 00:48:13 Neil Bothwick wrote:
> > > On Mon, 21 Dec 2015 23:55:06 +, Mick wrote:
> > > > > Are you trying to run ifplugd from its init script? It's not
> > > > > meant to be used like that with openrc.
> > > > 
> > > > I don't have any init scripts for ifplugd.  I wondered what starts
> > > > it/stops it, and found /lib64/netifrc/net/ifplugd.sh
> > > 
> > > It should be started by the net.eth* scripts, so you need to start
> > > the network interface first.
> > 
> > Thanks again Neil.  I don't think this is as you suggest.  I never
> > had wired or wireless interfaces enabled to start at boot time,
> > because ifplugd started them up as necessary.
> > 
> > From the README file:
> >The network interface which is controlled by ifplugd should not be
> >configured automatically by your distribution's network subsystem,
> >since ifplugd will do this for you if needed.
> 
> But that doesn't apply here because the "net.* plugin" starts ifplugd,
> and defers further initializations until ifplugd detects a link.
> 
> This is what I meant when I talked about pushing ifplugd further down
> the layer. I just didn't remember that this is now solved by a plugin
> in net.* itself.
> 
> Don't enable ifplugd service. Openrc will do its magic.

There is no means of enabling or disabling the ifplugd service that I have 
found, because there is no /etc/init.d/ifplugd script.  Once installed ifplugd 
always starts at boot and daemonizes, configuring or tearing down connections 
as a link is detected or lost.

To make it clearer, this is how it used to work on two laptops:

I install ifplugd and remove from rc-update any net. that I have 
configured.  ifplugd will always start at boot as a daemon and will bring up 
and configure the wired NIC once a cable is detected.  There is no start up 
script in /etc/init.d/ installed by default, although the man page mentions 
it, along with /etc/ifplugd/ifplugd.conf, which is also not installed.  This 
is the only file that installed on my systems:

# find /etc -iname *ifplug*
/etc/ifplugd
/etc/ifplugd/ifplugd.action


I started this thread because recently I have to start my wired interface 
manually, after which point ipfplugd also starts, daemonizes and manages the 
connection.  This is not how it used to work - I never had to start the wired 
interface myself.

Furthermore, starting ifplugd on a terminal now shows that it is listening on 
eth0 instead of enp11s0, but hadn't tried this before things broke.  According 
to the man page eth0 is the default, but I can't recall manually specifying a 
different interface for ifplugd in the past.  It always brought up the wired 
interface, no matter what it was called.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] (Not Solved for me) anyone tried amdgpu (kernel module)

[Mick]

On Sunday 20 Dec 2015 20:29:28 Alexander Kapshuk wrote:
> On Sun, Dec 20, 2015 at 9:04 PM, Mick  wrote:

> > This is not working for me on a Kaveri system.
> > 
> > The wiki page suggests these firmware blobs:
> > 
> > radeon/kaveri_ce.bin radeon/kaveri_me.bin radeon/kaveri_mec2.bin
> > radeon/kaveri_mec.bin radeon/kaveri_pfp.bin radeon/kaveri_rlc.bin
> > radeon/kaveri_sdma1.bin radeon/kaveri_sdma.bin radeon/kaveri_uvd.bin
> > radeon/kaveri_vce.bin
> > 
> > Unfortunately, radeon/kaveri_sdma1.bin does not seen to be available when
> > I use sys-kernel/linux-firmware:
> > 
> > find /lib/firmware/radeon/ -iname KAVERI*sdma*
> > /lib/firmware/radeon/kaveri_sdma.bin
> > /lib/firmware/radeon/KAVERI_sdma.bin
> > 
> > 
> > I installed sys-firmware/amdgpu-ucode, but KAVERI is not found there
> > either:
> > 
> > find /lib/firmware/amdgpu/ -iname *sdma*
> > /lib/firmware/amdgpu/carrizo_sdma.bin
> > /lib/firmware/amdgpu/carrizo_sdma1.bin
> > /lib/firmware/amdgpu/fiji_sdma.bin
> > /lib/firmware/amdgpu/fiji_sdma1.bin
> > /lib/firmware/amdgpu/tonga_sdma.bin
> > /lib/firmware/amdgpu/tonga_sdma1.bin
> > /lib/firmware/amdgpu/topaz_sdma.bin
> > /lib/firmware/amdgpu/topaz_sdma1.bin
> > 
> > 
> > Building the recommended blobs fails like so:
> > 
> > # make && make modules_install && make firmware_install
> > 
> >   CHK include/config/kernel.release
> >   CHK include/generated/uapi/linux/version.h
> >   CHK include/generated/utsrelease.h
> >   CHK include/generated/bounds.h
> >   CHK include/generated/asm-offsets.h
> >   CALLscripts/checksyscalls.sh
> >   CHK include/generated/compile.h
> > 
> > kernel/Makefile:135: *** No X.509 certificates found ***
> > make[1]: *** No rule to make target
> > '/lib/firmware//radeon/kaveri_sdma1.bin',
> > needed by 'firmware/radeon/kaveri_sdma1.bin.gen.o'.  Stop.
> > Makefile:947: recipe for target 'firmware' failed
> > make: *** [firmware] Error 2

> That's interesting. 'kaveri_sdma1.bin' is found in the
> 'sys-firmware/amdgpu-ucode' package. See below.
> % pwd
> radeon_ucode/kaveri

I don't seem to have such a directory, or the files therein.  Where am I 
supposed to look?

This is what emerge -uaDv sys-firmware/amdgpu-ucode installed on my PC:

>>> Installing (1 of 1) sys-firmware/amdgpu-ucode-20150803::gentoo
 * checking 44 files for package collisions
>>> Merging sys-firmware/amdgpu-ucode-20150803 to /
--- /lib/
--- /lib/firmware/
--- /lib/firmware/amdgpu/
>>> /lib/firmware/amdgpu/carrizo_ce.bin
>>> /lib/firmware/amdgpu/carrizo_me.bin
>>> /lib/firmware/amdgpu/carrizo_mec.bin
>>> /lib/firmware/amdgpu/carrizo_mec2.bin
>>> /lib/firmware/amdgpu/carrizo_pfp.bin
>>> /lib/firmware/amdgpu/carrizo_rlc.bin
>>> /lib/firmware/amdgpu/carrizo_sdma.bin
>>> /lib/firmware/amdgpu/carrizo_sdma1.bin
>>> /lib/firmware/amdgpu/carrizo_uvd.bin
>>> /lib/firmware/amdgpu/carrizo_vce.bin
>>> /lib/firmware/amdgpu/fiji_ce.bin
>>> /lib/firmware/amdgpu/fiji_mc.bin
>>> /lib/firmware/amdgpu/fiji_me.bin
>>> /lib/firmware/amdgpu/fiji_mec.bin
>>> /lib/firmware/amdgpu/fiji_mec2.bin
>>> /lib/firmware/amdgpu/fiji_pfp.bin
>>> /lib/firmware/amdgpu/fiji_rlc.bin
>>> /lib/firmware/amdgpu/fiji_sdma.bin
>>> /lib/firmware/amdgpu/fiji_sdma1.bin
>>> /lib/firmware/amdgpu/fiji_smc.bin
>>> /lib/firmware/amdgpu/fiji_uvd.bin
>>> /lib/firmware/amdgpu/fiji_vce.bin
>>> /lib/firmware/amdgpu/tonga_ce.bin
>>> /lib/firmware/amdgpu/tonga_mc.bin
>>> /lib/firmware/amdgpu/tonga_me.bin
>>> /lib/firmware/amdgpu/tonga_mec.bin
>>> /lib/firmware/amdgpu/tonga_mec2.bin
>>> /lib/firmware/amdgpu/tonga_pfp.bin
>>> /lib/firmware/amdgpu/tonga_rlc.bin
>>> /lib/firmware/amdgpu/tonga_sdma.bin
>>> /lib/firmware/amdgpu/tonga_sdma1.bin
>>> /lib/firmware/amdgpu/tonga_smc.bin
>>> /lib/firmware/amdgpu/tonga_uvd.bin
>>> /lib/firmware/amdgpu/tonga_vce.bin
>>> /lib/firmware/amdgpu/topaz_ce.bin
>>> /lib/firmware/amdgpu/topaz_mc.bin
>>> /lib/firmware/amdgpu/topaz_me.bin
>>> /lib/firmware/amdgpu/topaz_mec.bin
>>> /lib/firmware/amdgpu/topaz_mec2.bin
>>> /lib/firmware/amdgpu/topaz_pfp.bin
>>> /lib/firmware/amdgpu/topaz_rlc.bin
>>> /lib/firmware/amdgpu/topaz_sdma.bin
>>> /lib/firmware/amdgpu/topaz_sdma1.bin
>>> /lib/firmware/amdgpu/topaz_smc.bin

No /kaveri/ in there.


> Perhaps the path to the binary blobs specified in your kernel config file
> is wrong? You want to double check that.


This is what I have:

grep /firmware .config
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"

Looking at it again the amdgpu wiki page does not list amdgpu firmwares for 
the KAVERI APU.  However, I am confused as to why I can't find 
radeon/kaveri_sdma1 in my installed firmwares (either from linux-firmware, or 
from amdgpu-ucode.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.