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

[waltdnes]

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...

> 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.

> 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 make
a copy of the 10-gig guest disk image before any further tweaking that
might render it inoperative again.

>   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.

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

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

[wabenbau]

 wrote:

> 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.

I think that you also need x11-drivers/xf86-video-vmware installed
on the guest if you want to use "-vga vmware".

--
Regards
wabe

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

[wabenbau]

waltd...@waltdnes.org wrote:

> On Mon, Dec 21, 2015 at 06:26:18PM +0100, waben...@gmail.com wrote
> 
>   My Google search turned up
> https://forums.gentoo.org/viewtopic-p-7456850.html which suggested
> VIDEO_CARDS="cirrus modesetting vesa", emerging world, and setting and
> running CIRRUS in the guest.  I did that.  With "-vga cirrus" I get a
> framebuffer X display in the Gentoo guest, which looks half-decent.
> xrandr reports...
> 
> Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
> VGA-0 connected 1024x768+0+0 (normal left inverted right x axis y
> axis) 0mm x 0mm 1024x768  60.00*+
>1280x1024 60.02  
>1280x960  60.00  
>1280x800  59.8159.91  
>1280x768  59.8759.99  
>800x600   60.3256.25  
>848x480   60.00  
>640x480   59.94
> 
> 
>   There is no documentation for "video_cards_modesetting" or
> "modesetting" flags.  I filed bug report...
> 
> https://bugs.gentoo.org/show_bug.cgi?id=569082
> 
> ...asking for it to be documented.  "emerge -pv xorg-drivers" doesn't
> show it, and there's nothing in /usr/portage/profiles/*.desc
>   File-attached is the X log.  It complains about not finding the
> cirrus driver.  But when I emerged xf86-video-cirrus, the log
> complained that the cirrus driver couldn't be loaded because it
> conflicted with a "kernel module" (actually built in). 

Have you installed x11-drivers/xf86-video-modesetting on the guest?

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.

--
Regards
wabe

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

[waltdnes]

On Mon, Dec 21, 2015 at 06:26:18PM +0100, waben...@gmail.com wrote

  My Google search turned up
https://forums.gentoo.org/viewtopic-p-7456850.html which suggested
VIDEO_CARDS="cirrus modesetting vesa", emerging world, and setting and
running CIRRUS in the guest.  I did that.  With "-vga cirrus" I get a
framebuffer X display in the Gentoo guest, which looks half-decent.
xrandr reports...

Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA-0 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 
0mm
   1024x768  60.00*+
   1280x1024 60.02  
   1280x960  60.00  
   1280x800  59.8159.91  
   1280x768  59.8759.99  
   800x600   60.3256.25  
   848x480   60.00  
   640x480   59.94


  There is no documentation for "video_cards_modesetting" or
"modesetting" flags.  I filed bug report...

https://bugs.gentoo.org/show_bug.cgi?id=569082

...asking for it to be documented.  "emerge -pv xorg-drivers" doesn't
show it, and there's nothing in /usr/portage/profiles/*.desc

  File-attached is the X log.  It complains about not finding the cirrus
driver.  But when I emerged xf86-video-cirrus, the log complained that
the cirrus driver couldn't be loaded because it conflicted with a
"kernel module" (actually built in).  With "-vga std" X doesn't start up
at all.

  Any suggestions for improvement?

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


log.txt.gz
Description: Binary data

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

[Kai Krakow]

Am Tue, 22 Dec 2015 00:50:24 +
schrieb Mick :

> > You could try running the service in debug mode (--debug), and look
> > at the line starting ifplugd. Check if the parameters look correct,
> > then try to fire the same command from command line and check the
> > console output for errors.  
> 
> ifplugd does not have a debug mode, but starting it by hand I see
> this:
> 
> Dec 22 00:38:08 dell_xps ifplugd(eth0)[4982]: ifplugd 0.28
> initializing. Dec 22 00:38:08 dell_xps ifplugd(eth0)[4982]: Using
> interface eth0 Dec 22 00:38:08 dell_xps ifplugd(eth0)[4982]: Failed
> to detect plug status of eth0
> Dec 22 00:38:08 dell_xps ifplugd(eth0)[4982]: Exiting.
> 
> Ha!  It now assumes that I have an eth0 interface, which I don't.
> Hmm ...  I wonder where it reads this from.

man ifplugd ;-)

-- 
Regards,
Kai

Replies to list-only preferred.


signature.asc
Description: PGP signature

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

[Kai Krakow]

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.

-- 
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 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.

-- 
Regards,
Mick


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

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

[Mick]

On Monday 21 Dec 2015 23:49:02 Kai Krakow wrote:
> Am Mon, 21 Dec 2015 23:20:24 +
> 
> schrieb Mick :
> > On Monday 21 Dec 2015 22:38:21 Alan McKinnon wrote:
> > > On 22/12/2015 00:37, Mick wrote:
> > > > Am I alone in experiencing this?  Any ideas for fixing it?
> > > > Should I post a bug and if so where?  I'm thinking that asking
> > > > Lennart to fix ifplugd so that it works with openrc would be
> > > > taking it a step too far.  :p
> > > 
> > > read the news items for the last 3 months or so.
> > > 
> > > openrc changes, networking and service dependencies have changed
> > > somewhat, all well documented in the news items
> > 
> > Thank you Alan, I believe I've read the news item you refer to, but I
> > am not sure I understand how or why it applies to two laptops.  The
> > news item refers to localmount and netmount which if they cannot be
> > mounted will cause problems.  I don't use netmount on these laptops:
> > 
> > # rc-update -s -v | grep mount
> > 
> >localmount | boot
> >
> >  mount-ro |shutdown
> >  netmount |
> > 
> > localmount works and I see no failures in mounting my filesystems.
> > What fails repeatably is ifplugd, which no longer starts wired or
> > wireless devices.
> 
> You could try running the service in debug mode (--debug), and look at
> the line starting ifplugd. Check if the parameters look correct, then
> try to fire the same command from command line and check the console
> output for errors.

ifplugd does not have a debug mode, but starting it by hand I see this:

Dec 22 00:38:08 dell_xps ifplugd(eth0)[4982]: ifplugd 0.28 initializing.
Dec 22 00:38:08 dell_xps ifplugd(eth0)[4982]: Using interface eth0
Dec 22 00:38:08 dell_xps ifplugd(eth0)[4982]: Failed to detect plug status of 
eth0
Dec 22 00:38:08 dell_xps ifplugd(eth0)[4982]: Exiting.

Ha!  It now assumes that I have an eth0 interface, which I don't.  Hmm ...  I 
wonder where it reads this from.

If I start the NIC manually I get:

Dec 22 00:33:52 dell_xps kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp11s0: link 
becomes ready
Dec 22 00:35:31 dell_xps kernel: IPv6: ADDRCONF(NETDEV_UP): enp11s0: link is 
not ready
Dec 22 00:35:30 dell_xps ifplugd(enp11s0)[4293]: ifplugd 0.28 initializing.
Dec 22 00:35:30 dell_xps ifplugd(enp11s0)[4293]: Using interface 
enp11s0/00:26:B9:20:B4:9C with driver  (version: 3.137)
Dec 22 00:35:30 dell_xps ifplugd(enp11s0)[4293]: Using detection mode: 
SIOCETHTOOL


> By the way: Is ifplugd still needed? I thought it has been replacable
> by openrcs improved hotplug/coldplug support a long time ago? I
> remember my main purpose of using ifplugd back the days I still used it
> was to decouple the network init latency from the rest of the boot
> process and thus speed it up - in addition to the benefit of not
> starting some services at all when no network was plugged in.

Yes, ifplugd is needed here.  Otherwise removal/insertion of the ethernet 
cable does not bring up/down the enp11s0 interface.


> Part of the problem may be that udev handles device renaming and
> bootstrapping now. Maybe ifplugd should be called from udev and no
> longer be a service? In the end, ifplugd is tied to the device name -
> and thus must be part of the device service it is going to manage. And
> I don't think this is how it works in openrc nowadays. Thus it needs
> to move deeper down the layer - which is udev.

Thank you for pointing me in this direction.  If ifplud now thinks that eth0 
is the default interface, where might it be deducing this from?  I installed 
sys-fs/udev-225 and dev-libs/libgudev-230 at the same time I updated openrc 
and this is when the problems started.

I never had an ifplugd.conf in use, perhaps I ought to set up one now?


> Alternatively, NetworkManager is probably also a good replacement then -
> tho I totally understand why you wouldn't want to install it. At least
> you wouldn't have to ask Lennart then for fixing ifplugd in openrc
> if problems arise. ;-)
> 
> As a side note: systemd-networkd handles and fits the same purpose as
> ifplugd very well - should you consider to migrate to systemd. *scnr*
> 
> It's also not by Lennart, which elevates your problems with asking
> Lennart to fix something. :-)

Thank you for this suggestion, but for reasons covered exhaustively and 
exhaustingly in a few past mega-threads I'd rather stay with openrc.

-- 
Regards,
Mick


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

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

[Neil Bothwick]

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.


-- 
Neil Bothwick

Pound for pound, the amoeba is the most vicious animal on the earth.


pgprzWTEjKBdl.pgp
Description: OpenPGP digital signature

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

[Mick]

On Monday 21 Dec 2015 23:35:21 Neil Bothwick wrote:
> On Mon, 21 Dec 2015 23:20:24 +, Mick wrote:
> > localmount works and I see no failures in mounting my filesystems.
> > What fails repeatably is ifplugd, which no longer starts wired or
> > wireless devices.
> 
> 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
.
-- 
Regards,
Mick


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

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

[Kai Krakow]

Am Mon, 21 Dec 2015 23:41:08 +
schrieb Mick :

>  *   Skipping module netplugd due to missing program: /sbin/netplugd

Could it be that sys-apps/netplug is what you want to use now instead
of ifplugd?

Did you try it? I think I remember that ifplugd simply did no longer
reliably work with younger baselayout and openrc (at least before I
abandoned it in favor of another service manager).

-- 
Regards,
Kai

Replies to list-only preferred.


signature.asc
Description: PGP signature

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

[Kai Krakow]

Am Mon, 21 Dec 2015 23:20:24 +
schrieb Mick :

> On Monday 21 Dec 2015 22:38:21 Alan McKinnon wrote:
> > On 22/12/2015 00:37, Mick wrote:
> 
> > > Am I alone in experiencing this?  Any ideas for fixing it?
> > > Should I post a bug and if so where?  I'm thinking that asking
> > > Lennart to fix ifplugd so that it works with openrc would be
> > > taking it a step too far.  :p
> > 
> > read the news items for the last 3 months or so.
> > 
> > openrc changes, networking and service dependencies have changed
> > somewhat, all well documented in the news items
> 
> Thank you Alan, I believe I've read the news item you refer to, but I
> am not sure I understand how or why it applies to two laptops.  The
> news item refers to localmount and netmount which if they cannot be
> mounted will cause problems.  I don't use netmount on these laptops:
> 
> # rc-update -s -v | grep mount
>localmount | boot  
>  mount-ro |shutdown   
>  netmount |
> 
> 
> localmount works and I see no failures in mounting my filesystems.
> What fails repeatably is ifplugd, which no longer starts wired or
> wireless devices.
> 

You could try running the service in debug mode (--debug), and look at
the line starting ifplugd. Check if the parameters look correct, then
try to fire the same command from command line and check the console
output for errors.

By the way: Is ifplugd still needed? I thought it has been replacable
by openrcs improved hotplug/coldplug support a long time ago? I
remember my main purpose of using ifplugd back the days I still used it
was to decouple the network init latency from the rest of the boot
process and thus speed it up - in addition to the benefit of not
starting some services at all when no network was plugged in.

Part of the problem may be that udev handles device renaming and
bootstrapping now. Maybe ifplugd should be called from udev and no
longer be a service? In the end, ifplugd is tied to the device name -
and thus must be part of the device service it is going to manage. And
I don't think this is how it works in openrc nowadays. Thus it needs
to move deeper down the layer - which is udev.

Alternatively, NetworkManager is probably also a good replacement then -
tho I totally understand why you wouldn't want to install it. At least
you wouldn't have to ask Lennart then for fixing ifplugd in openrc
if problems arise. ;-)

As a side note: systemd-networkd handles and fits the same purpose as
ifplugd very well - should you consider to migrate to systemd. *scnr*

It's also not by Lennart, which elevates your problems with asking
Lennart to fix something. :-)

-- 
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 Monday 21 Dec 2015 23:20:24 Mick wrote:
> On Monday 21 Dec 2015 22:38:21 Alan McKinnon wrote:
> > On 22/12/2015 00:37, Mick wrote:
> > > Am I alone in experiencing this?  Any ideas for fixing it?  Should I
> > > post a bug and if so where?  I'm thinking that asking Lennart to fix
> > > ifplugd so that it works with openrc would be taking it a step too
> > > far.  :p
> > 
> > read the news items for the last 3 months or so.
> > 
> > openrc changes, networking and service dependencies have changed
> > somewhat, all well documented in the news items
> 
> Thank you Alan, I believe I've read the news item you refer to, but I am
> not sure I understand how or why it applies to two laptops.  The news item
> refers to localmount and netmount which if they cannot be mounted will
> cause problems.  I don't use netmount on these laptops:
> 
> # rc-update -s -v | grep mount
>localmount | boot
>  mount-ro |shutdown
>  netmount |
> 
> 
> localmount works and I see no failures in mounting my filesystems.  What
> fails repeatably is ifplugd, which no longer starts wired or wireless
> devices.

I got rc.log going.  Attached, in case you can spot something amiss.  Please 
note wlan0 NIC was switched off at the time.

-- 
Regards,
Mick


rc boot logging started at Mon Dec 21 23:21:54 2015

 * Loading module i2c-dev ...
 [ ok ]
 * Autoloaded 1 module(s)
 * Checking local filesystems  ...
root: clean, 258811/673296 files, 1815499/2688871 blocks
boot: clean, 64/12048 files, 42672/48160 blocks
home: clean, 55366/1281120 files, 3053874/5120710 blocks
 [ ok ]
 * Remounting root filesystem read/write ...
 [ ok ]
 * Remounting filesystems ...
 [ ok ]
 * Updating /etc/mtab ...
 * Creating mtab symbolic link
 [ ok ]
 * runscript is deprecated; please use openrc-run instead.
 * Use of the opts variable is deprecated and will be
 * removed in the future.
 * Please use extra_commands, extra_started_commands or extra_stopped_commands.
 * Invalidating stale software suspend images ...
 [ ok ]
 * Activating swap devices ...
 [ ok ]
 * Mounting local filesystems ...
 [ ok ]
 * Configuring kernel parameters ...
* Applying /etc/sysctl.conf ...
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
 [ ok ]
 * Creating user login records ...
 [ ok ]
 * Wiping /tmp directory ...
 [ ok ]
 * runscript is deprecated; please use openrc-run instead.
 * Restoring Mixer Levels ...
 [ ok ]
 * Mounting misc binary format filesystem ...
 [ ok ]
 * Loading custom binary format handlers ...
 [ ok ]
 * Setting terminal encoding [UTF-8] ...
 [ ok ]
 * Setting console font [default8x16] ...
 [ ok ]
 * Setting hostname to dell_xps ...
 [ ok ]
 * Setting keyboard mode [UTF-8] ...
 [ ok ]
 * Loading key mappings [uk] ...
 [ ok ]
 * Bringing up network interface lo ...
 [ ok ]
 * runscript is deprecated; please use openrc-run instead.
 * Updating microcode ...
 [ ok ]
 * runscript is deprecated; please use openrc-run instead.
 * Bringing up interface lo
 *   Skipping module adsl due to missing program: /usr/sbin/adsl-start /usr/sbin/pppoe-start
 *   Skipping module br2684ctl due to missing program: br2684ctl
 *   Skipping module bridge due to missing program: brctl
 *   Skipping module clip due to missing program: /usr/sbin/atmsigd
 *   Skipping module netplugd due to missing program: /sbin/netplugd
 *   Skipping module ipppd due to missing program: /usr/sbin/ipppd
 *   Skipping module firewalld due to missing program: firewall-cmd
 *   Skipping module dhclient due to missing program: /sbin/dhclient
 *   Skipping module pump due to missing program: /sbin/pump
 *   Loaded modules: apipa arping bonding tuntap ccwgroup ethtool macvlan macchanger macnet ifplugd wpa_supplicant ssidnet iproute2 pppd system vlan dhcpcd ip6rd ip6to4
 *   ifplugd only works on interfaces with a valid MAC address
 *   127.0.0.1/8 ...
 [ ok ]
 *   Adding routes
 * 127.0.0.0/8 via 127.0.0.1 ...
 [ ok ]
 * Activating additional swap space ...
 [ ok ]
 * Setting up tmpfiles.d entries ...
 [ ok ]
 * Initializing random number generator ...
 [ ok ]

rc boot logging stopped at Mon Dec 21 23:21:58 2015


rc default logging started at Mon Dec 21 23:21:58 2015

 * runscript is deprecated; please use openrc-run instead.
 * Checking your configfile (/etc/syslog-ng/syslog-ng.conf) ...
 [ ok ]
 * Starting syslog-ng ...
 * start-stop-daemon: fopen `/run/syslog-ng.pid': No such file or directory
 * Detaching to start `/usr/sbin/syslog-ng' ...
 [ ok ]
 * runscript is deprecated; please use openrc-run instead.
Arno's Iptables Firewall Script v2.0.1e
---
Platform: Linux 4.1.12-gentoo x86_64
WARNING: External interface ppp0 does NOT exist (yet?)
Checking/probing Iptables modules:
[snip ...]

Dec 21 23:22:04 All firewall rules applied.
 * runscript is deprecated; please use openrc-run instead.
 * Starting chronyd ...
 * start-stop-daem

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

[Neil Bothwick]

On Mon, 21 Dec 2015 23:20:24 +, Mick wrote:

> localmount works and I see no failures in mounting my filesystems.
> What fails repeatably is ifplugd, which no longer starts wired or
> wireless devices.

Are you trying to run ifplugd from its init script? It's not meant to be
used like that with openrc.


-- 
Neil Bothwick

I distinctly remember forgetting that.


pgpcygyspmfHk.pgp
Description: OpenPGP digital signature

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

[Mick]

On Monday 21 Dec 2015 22:38:21 Alan McKinnon wrote:
> On 22/12/2015 00:37, Mick wrote:

> > Am I alone in experiencing this?  Any ideas for fixing it?  Should I post
> > a bug and if so where?  I'm thinking that asking Lennart to fix ifplugd
> > so that it works with openrc would be taking it a step too far.  :p
> 
> read the news items for the last 3 months or so.
> 
> openrc changes, networking and service dependencies have changed
> somewhat, all well documented in the news items

Thank you Alan, I believe I've read the news item you refer to, but I am not 
sure I understand how or why it applies to two laptops.  The news item refers 
to localmount and netmount which if they cannot be mounted will cause 
problems.  I don't use netmount on these laptops:

# rc-update -s -v | grep mount
   localmount | boot  
 mount-ro |shutdown   
 netmount |


localmount works and I see no failures in mounting my filesystems.  What fails 
repeatably is ifplugd, which no longer starts wired or wireless devices.

-- 
Regards,
Mick


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

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

[Kai Krakow]

Am Mon, 21 Dec 2015 16:59:39 -0600
schrieb »Q« :

> On Mon, 21 Dec 2015 21:40:30 +
> Neil Bothwick  wrote:
> 
> > On Mon, 21 Dec 2015 16:25:34 -0500, waltd...@waltdnes.org wrote:
> > 
> > > > From what I read/understand openrc is in the process of removal
> > > > from @system, for all profiles?
> > > 
> > >   In Lennart's dreams... and many peoples' nightmares.  
> > 
> > It's got nothing to do with Lennart. There is a choice of init
> > managers, openrc or systemd - so portage should, and apparently
> > will, handle this with a virtual. Currently, openrc is forced on
> > those using systemd, even though they have no use for it - that is
> > just as wrong as forcing systemd on openrc users.
> 
> AFAICT, the day is pretty close.
> 
> 
> and  indicate openrc
> is still in @system as a stopgap, to keep providing functions.sh
> because of bugs 373219 (FIXED already) and
> , which only has 4
> ebuilds left to fix.

Fixed here by install masking /etc/init.d and symlinking functions.sh
to the new location. ;-)

Disclaimer: Do not apply on openrc systems.

-- 
Regards,
Kai

Replies to list-only preferred.

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

[»Q«]

On Mon, 21 Dec 2015 21:40:30 +
Neil Bothwick  wrote:

> On Mon, 21 Dec 2015 16:25:34 -0500, waltd...@waltdnes.org wrote:
> 
> > > From what I read/understand openrc is in the process of removal
> > > from @system, for all profiles?
> > 
> >   In Lennart's dreams... and many peoples' nightmares.  
> 
> It's got nothing to do with Lennart. There is a choice of init
> managers, openrc or systemd - so portage should, and apparently will,
> handle this with a virtual. Currently, openrc is forced on those
> using systemd, even though they have no use for it - that is just as
> wrong as forcing systemd on openrc users.

AFAICT, the day is pretty close.


and  indicate openrc is
still in @system as a stopgap, to keep providing functions.sh because
of bugs 373219 (FIXED already) and
, which only has 4
ebuilds left to fix.

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

[Kai Krakow]

Am Mon, 21 Dec 2015 22:37:38 +
schrieb Mick :

> On Monday 21 Dec 2015 21:43:00 Kai Krakow wrote:
> > Am Mon, 21 Dec 2015 16:25:34 -0500
> > 
> > schrieb waltd...@waltdnes.org:
> > > On Mon, Dec 21, 2015 at 02:06:25PM +, James wrote
> > > 
> > > > From what I read/understand openrc is in the process of removal
> > > > from @system, for all profiles?
> > > > 
> > >   In Lennart's dreams... and many peoples' nightmares.
> > 
> > Haters gonna hate...
> > 
> > If I look at the virtual/service-manager ebuild, openrc probably in
> > the process of being removed from the system set and replaced by
> > this virtual. In that way you can more easily replace openrc with a
> > service manager of your choice.
> > 
> > The upgrade path will be straight forward: It doesn't affect your
> > openrc installation at all because through the service-manager deps
> > openrc is still pulled into the system set - simply by the fact
> > that it is installed.
> 
> Nevertheless, virtual options to make it easier to use alternatives
> to the current stable version of openrc are not my problem at this
> stage.  I can't get ifplugd to work, unless I start up net.
> first and I am getting no /var/log/rc.log to see what's gone
> sideways.  Regardless of these problems I am getting warnings on the
> console during boot time as posted initially.

Apparently I cannot help here because I removed openrc from my system
months ago (even install masking /etc/init.d) but I still maintain
systems which run openrc (and, *cough* baselayout-1, you didn't read
that, did you?). Upgrade paths there almost always involved following
"eselect news read new", the hardest ones involved network and device
management services. It's kind of a challenge to do this on a headless,
remote system without needing to physically access the machine. [1]

> Am I alone in experiencing this?  Any ideas for fixing it?  Should I
> post a bug and if so where?  I'm thinking that asking Lennart to fix
> ifplugd so that it works with openrc would be taking it a step too
> far.  :p

Hehe... Hey, this is surprisingly amusing. May I quote that? :-D
Thanks for the smirk.


[1]: Ah well, I cheated a bit: It's virtualized so I had another
channel of console access. ;-)

-- 
Regards,
Kai

Replies to list-only preferred.


signature.asc
Description: PGP signature

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

[Alan McKinnon]

On 22/12/2015 00:37, Mick wrote:
> On Monday 21 Dec 2015 21:43:00 Kai Krakow wrote:
>> Am Mon, 21 Dec 2015 16:25:34 -0500
>>
>> schrieb waltd...@waltdnes.org:
>>> On Mon, Dec 21, 2015 at 02:06:25PM +, James wrote
>>>
 From what I read/understand openrc is in the process of removal from
 @system, for all profiles?

>>>   In Lennart's dreams... and many peoples' nightmares.
>>
>> Haters gonna hate...
>>
>> If I look at the virtual/service-manager ebuild, openrc probably in
>> the process of being removed from the system set and replaced by this
>> virtual. In that way you can more easily replace openrc with a service
>> manager of your choice.
>>
>> The upgrade path will be straight forward: It doesn't affect your openrc
>> installation at all because through the service-manager deps openrc is
>> still pulled into the system set - simply by the fact that it is
>> installed.
> 
> Nevertheless, virtual options to make it easier to use alternatives to the 
> current stable version of openrc are not my problem at this stage.  I can't 
> get ifplugd to work, unless I start up net. first and I am getting no 
> /var/log/rc.log to see what's gone sideways.  Regardless of these problems I 
> am getting warnings on the console during boot time as posted initially.
> 
> Am I alone in experiencing this?  Any ideas for fixing it?  Should I post a 
> bug and if so where?  I'm thinking that asking Lennart to fix ifplugd so that 
> it works with openrc would be taking it a step too far.  :p
> 



read the news items for the last 3 months or so.

openrc changes, networking and service dependencies have changed
somewhat, all well documented in the news items

-- 
Alan McKinnon
alan.mckin...@gmail.com

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

[Mick]

On Monday 21 Dec 2015 21:43:00 Kai Krakow wrote:
> Am Mon, 21 Dec 2015 16:25:34 -0500
> 
> schrieb waltd...@waltdnes.org:
> > On Mon, Dec 21, 2015 at 02:06:25PM +, James wrote
> > 
> > > From what I read/understand openrc is in the process of removal from
> > > @system, for all profiles?
> > > 
> >   In Lennart's dreams... and many peoples' nightmares.
> 
> Haters gonna hate...
> 
> If I look at the virtual/service-manager ebuild, openrc probably in
> the process of being removed from the system set and replaced by this
> virtual. In that way you can more easily replace openrc with a service
> manager of your choice.
> 
> The upgrade path will be straight forward: It doesn't affect your openrc
> installation at all because through the service-manager deps openrc is
> still pulled into the system set - simply by the fact that it is
> installed.

Nevertheless, virtual options to make it easier to use alternatives to the 
current stable version of openrc are not my problem at this stage.  I can't 
get ifplugd to work, unless I start up net. first and I am getting no 
/var/log/rc.log to see what's gone sideways.  Regardless of these problems I 
am getting warnings on the console during boot time as posted initially.

Am I alone in experiencing this?  Any ideas for fixing it?  Should I post a 
bug and if so where?  I'm thinking that asking Lennart to fix ifplugd so that 
it works with openrc would be taking it a step too far.  :p

-- 
Regards,
Mick


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

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

[Kai Krakow]

Am Mon, 21 Dec 2015 16:25:34 -0500
schrieb waltd...@waltdnes.org:

> On Mon, Dec 21, 2015 at 02:06:25PM +, James wrote
> 
> > From what I read/understand openrc is in the process of removal from
> > @system, for all profiles?
> 
>   In Lennart's dreams... and many peoples' nightmares.

Haters gonna hate...

If I look at the virtual/service-manager ebuild, openrc probably in
the process of being removed from the system set and replaced by this
virtual. In that way you can more easily replace openrc with a service
manager of your choice.

The upgrade path will be straight forward: It doesn't affect your openrc
installation at all because through the service-manager deps openrc is
still pulled into the system set - simply by the fact that it is
installed.

-- 

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

[Neil Bothwick]

On Mon, 21 Dec 2015 16:25:34 -0500, waltd...@waltdnes.org wrote:

> > From what I read/understand openrc is in the process of removal from
> > @system, for all profiles?  
> 
>   In Lennart's dreams... and many peoples' nightmares.

It's got nothing to do with Lennart. There is a choice of init managers,
openrc or systemd - so portage should, and apparently will, handle this
with a virtual. Currently, openrc is forced on those using systemd, even
though they have no use for it - that is just as wrong as forcing systemd
on openrc users.


-- 
Neil Bothwick

Never underestimate the bandwidth of a station wagon full of tapes!


pgpx2GKchEzPw.pgp
Description: OpenPGP digital signature

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

[waltdnes]

On Mon, Dec 21, 2015 at 02:06:25PM +, James wrote

> From what I read/understand openrc is in the process of removal from
> @system, for all profiles?

  In Lennart's dreams... and many peoples' nightmares.

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

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

[Alan McKinnon]

On 21/12/2015 19:21, Peter Humphrey wrote:
> On Monday 21 December 2015 14:06:25 James wrote:
> 
>> H. I would think most folks running openrc are also not using udev
>> but are using eudev [1]? From what I read/understand openrc is in the
>> process of removal from @system, for all profiles?
> 
> I don't know about that, but I'm certainly using udev with openrc.
> 
> While I'm here, is there any practical difference between world and @world, 
> or between system and @system?
> 


There are no differences in practice, it's a semantic thing.

Portage used "emerge world" from the very beginning (lifted from FreeBSD
ports) and it's still supported today even though technically and
semantically "emerge @world" is more correct - world is at heart a set.

It's mentioned in one of portage's man pages, IIRC in emerge (1) but
right now I don't have the inclination to look. That is left as an
exercise for the interested reader.



-- 
Alan McKinnon
alan.mckin...@gmail.com

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

[Alan McKinnon]

On 21/12/2015 16:06, James wrote:
> Mick  gmail.com> writes:
> 
> 
> 
> 
 In addition /var/log/rc.log is empty - no messages are captured,
 Finally, there are a lot of messages like this in the console at boot
 time:
> 
 * start-stop-daemon: fopen 'var/run/dbus.pid' : No such file or 
 directory Detaching to start '/usr/bin/dbus-daemon ...'
 * runscript is deprecated; please use openrc-run instead.
 How do I put this right?
> 
> H. I would think most folks running openrc are also not using udev
> but are using eudev [1]? From what I read/understand openrc is in the
> process of removal from @system, for all profiles?


I would wager the opposite. eudev was a temporary hack - udev with stuff
removed.

I use openrc everywhere with udev, and have never run eudev at all



-- 
Alan McKinnon
alan.mckin...@gmail.com

[gentoo-user] Maybe bug? (glibc related?)

[Elias Diem]

Hi

I just got the following while running Vim's testsuite.


*** buffer overflow detected ***: vim terminated; report to 

Makefile:151: recipe for target 'af.ck' failed
make[2]: *** [af.ck] Killed


The compiler gave me the following warning.


gcc -c -I. -Iproto -DHAVE_CONFIG_H  -O1 -o objects/if_cscope.o 
if_cscope.c
In file included from /usr/include/string.h:639:0,
 from os_unix.h:542,
 from vim.h:282,
 from eval.c:14:
In function ‘strcpy’,
inlined from ‘add_nr_var’ at eval.c:24396:5,
inlined from ‘call_user_func’ at eval.c:24061:5:
/usr/include/bits/string3.h:110:3: warning: call to __builtin___strcpy_chk will 
always overflow destination buffer
   return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
   ^
In function ‘strcpy’,
inlined from ‘call_user_func’ at eval.c:24067:5:
/usr/include/bits/string3.h:110:3: warning: call to __builtin___strcpy_chk will 
always overflow destination buffer
   return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
   ^
In function ‘strcpy’,
inlined from ‘add_nr_var’ at eval.c:24396:5,
inlined from ‘call_user_func’ at eval.c:24082:5:
/usr/include/bits/string3.h:110:3: warning: call to __builtin___strcpy_chk will 
always overflow destination buffer
   return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
   ^
In function ‘strcpy’,
inlined from ‘add_nr_var’ at eval.c:24396:5,
inlined from ‘call_user_func’ at eval.c:24084:5:
/usr/include/bits/string3.h:110:3: warning: call to __builtin___strcpy_chk will 
always overflow destination buffer
   return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
   ^


This seems to only happen with -O1. I don't get this 
behaviour with -O2.

Do you need more info?

Should I file a bug?

-- 
Greetings
Elias

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

[wabenbau]

waltd...@waltdnes.org wrote:

> On Sun, Dec 20, 2015 at 04:47:35AM +0100, waben...@gmail.com wrote
> > waltd...@waltdnes.org wrote:
> > 
> > >   I'm now at the configuring-the-kernel stage of the Gentoo guest
> > > install.  I had originally expected to pull in the .config from
> > > the host machine, make a few tweaks, and get going.  However, it
> > > appears that multiple video and sound and network cards are
> > > supported, none of which match those on the host.  Which ones do
> > > people recommend selecting?
> > > 
> > 
> > That's what I'm using to start qemu:
> > 
> > qemu-system-x86_64 -machine accel=kvm -cpu host -m 4096 -enable-kvm
> > -name vm-01 -net nic,model=virtio -net user,hostfwd=tcp::2022-:22
> > -localtime -hda /path/to/image.qcow2 -display gtk -vga vmware
> 
>   I can't get X to work on the guest.  Text console is OK, but no X.
> I ticked support for cirrus, bochs, qxl, and vmware emulation in the
> guest kernel.  I wonder if I missed something.  I also emerged the
> corresponding X drivers.  vmware was a pain because I had to rebuild
> mesa and other stuff to emerge the vmware video driver.
> 
>   File-attached are Xorg logs for failed attempts with vga=
> cirrus/std/vmware.  QEMU refused to start when I specified -vga qxl.
> The vmware log looks like it started X properly, but it immediately
> dumped me out, and gave an all-red QEMU window.  I ssh'd in from the
> host to set up the next card.  I know that the all-red window was a
> text console.  To reboot, I blindly typed "su -", followed by root
> password, followed by "halt -p", and the QEMU session halted.
> 
>   I use the following script to boot up Gentoo on the guest.  I cycled
> through all 4 cards...
> 
> #!/bin/bash
> qemu-system-i386 -enable-kvm \
>-cpu host -display gtk -vga cirrus \
>-drive file=gentoo32.img,format=raw \
>-drive file=linuxswap.img,format=raw \
>-net nic,model=virtio \
>-rtc base=localtime,clock=host \
>-net user,hostname=gentoovm,hostfwd=tcp::2022-:22 \
>-m 3G -monitor stdio -name "Gentoo VM" \
>-parallel none \
>${@
> 

I never used gentoo as guest OS, only xubuntu and OpenSuse. So I can't
give you tips for your gentoo guest installation.

Have you also tried it without the -monitor option?

Here some infos about my host and guest OS.

Host: gentoo, kernel 4.1.7-hardened-r1, qemu-2.5.0, 
x11-base/xorg-server-1.17.4, x11-drivers/xf86-video-ati-7.6.1

Guest: xubuntu 14.04.3 LTS, kernel 3.13.0-74-generic, vmware VGA emulation

If screen resolution and performance isn't that important for you then
you could also try to connect via vnc or spice.

Attached is my guest xorg.log.

--
Regards
wabe

Xorg.0.log.bz2
Description: application/bzip

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

[Peter Humphrey]

On Monday 21 December 2015 14:06:25 James wrote:

> H. I would think most folks running openrc are also not using udev
> but are using eudev [1]? From what I read/understand openrc is in the
> process of removal from @system, for all profiles?

I don't know about that, but I'm certainly using udev with openrc.

While I'm here, is there any practical difference between world and @world, 
or between system and @system?

-- 
Rgds
Peter

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

[James]

Mick  gmail.com> writes:




> > > In addition /var/log/rc.log is empty - no messages are captured,
> > > Finally, there are a lot of messages like this in the console at boot
> > > time:

> > > * start-stop-daemon: fopen 'var/run/dbus.pid' : No such file or 
> > > directory Detaching to start '/usr/bin/dbus-daemon ...'
> > > * runscript is deprecated; please use openrc-run instead.
> > > How do I put this right?

H. I would think most folks running openrc are also not using udev
but are using eudev [1]? From what I read/understand openrc is in the
process of removal from @system, for all profiles?



> > I think your error is related to my thread below.
> > Just get rid of line form fstab:
> > none /proc proc defaults 0 0
> > and any other not related ones.
> Thank you Thelma, but I do not have /proc or /tmpfs on my stab.  Just a  
> few  disk partitions.


Another thread alluded to a news post. I cannot find that old news post?

I use a simple partition scheme with /boot  /  and /usr/local on separate
partitions. So the consensus is remove both of these from the fstab?::

shm /dev/shm tmpfs   nodev,nosuid,noexec  0 0

none/procprocdefaults 0 0


Historically speaking, fstab, mtab init* and cgroups were all very well
defined and mostly logical to figure out and follow. Where do I read up on
the mtab functionality, particularly in light of these dynamic changes and
as inter-related issue between where openrc, mount, fstab and mtab will end
up, functionally, in the future gentoo scheme?  


James

[1] https://wiki.gentoo.org/wiki/Eudev

[gentoo-user] git-2.eclass or git broken?

[Stanislav Nikolov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It looks like the git-2.eclass on line 554 says "EGIT_UPDATE_CMD="git pull -f 
-u ${EGIT_OPTIONS}" which, git refuses to accept with the error message "error: 
unknown switch `u'". The git pull manual page clearly says that it should work, 
but it obviously doesn't. What is going on?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWeARYAAoJEBYxB87Vey/RKgIH/3H6bf57LcqyQt/IcVS4ueHv
w18RpIlFwPHIlAWRVsjweJspAF6M1BtcNP9ynNA0L1lS8YFDc4//qzrCk6uUpAs4
nwS6BJW1RZ5Wciu5kYSvHNiW0ljfG6vbfLOMm9YYCsdowr7RUBQHNw99Nik8L1M2
BPH1eZoXY3jwCLwV5y03oVXQIYLtGEcBw3dphWaTcCHl/JiBNOyh+p/HuRjbQt+y
yojgJnP1unpZbUE8mFTefPR45mLBgR4QpOnWUZJQgLORa99+otePQY37ekMGrKb7
R2WFb3aulRmKUvyqURwFGagd+T4snmYtzbuVbniBzR+njhkXb0+ioQs9djEfysw=
=k4wZ
-END PGP SIGNATURE-