Re: hotpluggable member of a bridge
Le quintidi 15 nivôse, an CCXXV, Stefan Monnier a écrit : > Is there something better? Like a predefined way to just say that when > `usb0` appears, it should be added to `br0` (and ideally, this would > also `ifup` the `br0` interface if it's not up yet). Not with /etc/network/interfaces and ifupdown, but udev can do all that. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: hotpluggable member of a bridge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jan 05, 2017 at 10:07:59AM +0100, Nicolas George wrote: > Le quintidi 15 nivôse, an CCXXV, Stefan Monnier a écrit : > > Is there something better? Like a predefined way to just say that when > > `usb0` appears, it should be added to `br0` (and ideally, this would > > also `ifup` the `br0` interface if it's not up yet). > > Not with /etc/network/interfaces and ifupdown, but udev can do all that. I always thought this is a division of labor between udev (generating a "hotplug event", like "eth0 link went just up" and ifupdown, declaring what has to happen (cf. the "allow-hotplug" directive). But I must admit I never looked to deeply into that to be authoritative. The docs [1] seem to suggest that, though. Of course, udev would be involved for other network management systems too, like NM: ideally, udev just dispatches and normalizes kernel events and delegates to specialized subsystems. In a pinch you can just sneak a complete shell script in an udev rule (and I'm guilty of having done such a thing [2]), but doing this as "system architecture" might lead to madness :-) [1] https://www.debian.org/doc/manuals/debian-reference/ch05.en.html [2] Once, for a customer: inserting the right storage medium (with the right UUID) triggered a system backup. regards - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlhuEdwACgkQBcgs9XrR2kZtowCfb0Glm/fJD9ByArT9nkGMmh4L 7NkAn2L0r4w7NeYa4E7PgK1BguWM7oZK =VqAG -END PGP SIGNATURE-
Re: Potential problem with aptitude search?
On Thursday 05 January 2017 03:28:23 Sven Hartge wrote: > Carl Fink wrote: > > Thoughts? I'll submit a bug report if warranted but I thought I'd get the > > community's opinion first. > > aptitude search the package name and only the package name by default. > > If you want to search inside the description, you have to search like > this: > > aptitude search "~dsip" > > See here: https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html And then there is apropos https://debian-administration.org/article/614/Commands_you_might_have_missed_apropos If apt and aptitude were identical there would be no point in having both. Lisi
Re: hotpluggable member of a bridge
>> Is there something better? Like a predefined way to just say that when >> `usb0` appears, it should be added to `br0` (and ideally, this would >> also `ifup` the `br0` interface if it's not up yet). > Not with /etc/network/interfaces and ifupdown, but udev can do all that. Interesting. Any hint how? Stefan
Re: hotpluggable member of a bridge
Le sextidi 16 nivôse, an CCXXV, Stefan Monnier a écrit : > Interesting. Any hint how? It would be too long to explain here, but this page seems to cover the basics of what you need: http://packetpushers.net/udev/ Regards, -- Nicolas George signature.asc Description: Digital signature
Re: hotpluggable member of a bridge
Am 05.01.2017 um 10:29 schrieb to...@tuxteam.de:
> and delegates to specialized subsystems. In a pinch you can just sneak
> a complete shell script in an udev rule (and I'm guilty of having done
> such a thing [2]), but doing this as "system architecture" might lead to
> madness :-)
> [2] Once, for a customer: inserting the right storage medium (with
>the right UUID) triggered a system backup.
Please don't do that. udev is a not a service manager and starting (long
running) tasks from a udev rule is bad.
See also the udev man page:
Starting daemons or other long-running processes is not appropriate
for udev; the forked processes, detached or not, will be
unconditionally killed after the event handling has finished.
If you want to trigger the start of a service via udev, tag the device
with "systemd" and use SYSTEMD_WANTS [1] via a custom udev rule, like
,TAG+="systemd",ENV{SYSTEMD_WANTS}="foo.service"
Regards,
Michael
[1]
https://www.freedesktop.org/software/systemd/man/systemd.device.html#SYSTEMD_WANTS=
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Re: hotpluggable member of a bridge
Hi. On Wed, 04 Jan 2017 22:34:16 -0500 Stefan Monnier wrote: > I have a bridge interface `br0` which usually contains jut `eth0` but > occasionally also needs to contain `usb0`, which is an ethernet-dongle > kind of thing. > > How do I setup /etc/network/interfaces for that? > > Currently, I just setup everything "manually": `br0` is setup `static`, > and `usb0` is setup as `manual` with post-up scripts that add it to > the bridge. > > Is there something better? Like a predefined way to just say that when > `usb0` appears, it should be added to `br0` (and ideally, this would > also `ifup` the `br0` interface if it's not up yet). Conventional Linux bridge cannot do that. All those interfaces(5) stanzas are merely a wrapper to 'brctl addbr' and 'brctl addif', which are invoked by ifupdown. But, it all changes if you replace conventional bridge with openvswitch, which *can* add new interfaces (ports as they call it) to its own bridges dynamically *and* it can be configured via interfaces(5). A sample configuration would be: allow-ovs br0 iface br0 inet4 static address … netmask … ovs_type OVSBridge allow-br0 eth0 iface eth0 inet6 auto ovs_type OVSPort ovs_bridge br0 allow-hotplug usb0 iface usb0 inet6 auto ovs_type OVSPort ovs_bridge br0 Reco
Re: hotpluggable member of a bridge
> > > A sample configuration would be: > > allow-ovs br0 > iface br0 inet4 static > address … > netmask … > ovs_type OVSBridge > > allow-br0 eth0 > iface eth0 inet6 auto > ovs_type OVSPort > ovs_bridge br0 > > allow-hotplug usb0 > iface usb0 inet6 auto > ovs_type OVSPort > ovs_bridge br0 > > Reco > > Pardon my ignorance, can you explain why you set an IPv4 address on your bridge and an IPv6 address on your bridge interfaces? I've never seen this before and would like to know what this accomplishes. Perhaps its a typo as I thought IPv4 was just set with "inet" and IPv6 was set with "inet6". Thanks, Joshua Schaeffer
Re: hotpluggable member of a bridge
Hi. On Thu, 5 Jan 2017 09:19:35 -0700 Joshua Schaeffer wrote: > > > > > > A sample configuration would be: > > > > allow-ovs br0 > > iface br0 inet4 static > > address … > > netmask … > > ovs_type OVSBridge > > > > allow-br0 eth0 > > iface eth0 inet6 auto > > ovs_type OVSPort > > ovs_bridge br0 > > > > allow-hotplug usb0 > > iface usb0 inet6 auto > > ovs_type OVSPort > > ovs_bridge br0 > > > > Reco > > > > > Pardon my ignorance, can you explain why you set an IPv4 address on your > bridge and an IPv6 address on your bridge interfaces? I've never seen this > before and would like to know what this accomplishes. Perhaps its a typo as > I thought IPv4 was just set with "inet" and IPv6 was set with "inet6". It's simple, although isn't obvious from this abridged example. I need a single IPv4 for both interfaces, so I set it on a bridge. I don't need distinct IPv4 on ports, so I don't set it there. Bridged interfaces retain their MACs, so they would get different IPv6 ULAs, which are provided by radvd from the different host. And I don't need these IPv6 either. So, I can do: allow-br0 eth0 iface eth0 inet manual ovs_type OVSPort ovs_bridge br0 And get myself all kinds of unneeded trouble, or I can do: allow-br0 eth0 iface eth0 inet6 auto autoconf 0 accept_ra 0 ovs_type OVSPort ovs_bridge br0 Barring this IPv4/IPv6 difference, there should be no noticeable outcome between 'inet manual' and 'inet6 auto'. Reco
Re: [OT] get all devices from a vendor from pci.ids
Op Wed, 04 Jan 2017 17:27:55 +0100 schreef Floris :
(Not really a Debian question, but I know there are smart people on this
list.)
I want to search the pci.ids file (from the pciutils package) for all
Compaq devices.
Pci ID's 0e11: , 1032: and 10da: matches Compaq.
Unfortunately, only at a beginning of a list the id of the vendor is
printed in column 1. The id of the devices are printed in column 2, with
an empty first column.
(part of pci.ids)
...
0e11 Compaq Computer Corporation
0001 PCI to EISA Bridge
0002 PCI to ISA Bridge
0046 Smart Array 64xx
0e11 4091 Smart Array 6i
0e11 409a Smart Array 641
0e11 409b Smart Array 642
0e11 409c Smart Array 6400
0e11 409d Smart Array 6400 EM
0049 NC7132 Gigabit Upgrade Module
004a NC6136 Gigabit Server Adapter
...
c000 Remote Insight Lights-Out Edition
f130 NetFlex-3/P ThunderLAN 1.0
f150 NetFlex-3/P ThunderLAN 2.3
0e55 HaSoTec GmbH
...
Is there an awk, grep and or sed solution?
Floris
an other solution would be something like:
# cat pci.ids | {magic-command} 0e11:004a
NC6136 Gigabit Server Adapter
what is the magic command?
Floris
Re: hotpluggable member of a bridge
Interesting, thanks for the explanation. On Thu, Jan 5, 2017 at 9:32 AM, Reco wrote: > Hi. > > On Thu, 5 Jan 2017 09:19:35 -0700 > Joshua Schaeffer wrote: > > > > > > > > > > A sample configuration would be: > > > > > > allow-ovs br0 > > > iface br0 inet4 static > > > address … > > > netmask … > > > ovs_type OVSBridge > > > > > > allow-br0 eth0 > > > iface eth0 inet6 auto > > > ovs_type OVSPort > > > ovs_bridge br0 > > > > > > allow-hotplug usb0 > > > iface usb0 inet6 auto > > > ovs_type OVSPort > > > ovs_bridge br0 > > > > > > Reco > > > > > > > > Pardon my ignorance, can you explain why you set an IPv4 address on your > > bridge and an IPv6 address on your bridge interfaces? I've never seen > this > > before and would like to know what this accomplishes. Perhaps its a typo > as > > I thought IPv4 was just set with "inet" and IPv6 was set with "inet6". > > It's simple, although isn't obvious from this abridged example. > I need a single IPv4 for both interfaces, so I set it on a bridge. > I don't need distinct IPv4 on ports, so I don't set it there. > > Bridged interfaces retain their MACs, so they would get different IPv6 > ULAs, which are provided by radvd from the different host. > And I don't need these IPv6 either. > > So, I can do: > > allow-br0 eth0 > iface eth0 inet manual > ovs_type OVSPort > ovs_bridge br0 > > And get myself all kinds of unneeded trouble, or I can do: > > allow-br0 eth0 > iface eth0 inet6 auto > autoconf 0 > accept_ra 0 > ovs_type OVSPort > ovs_bridge br0 > > Barring this IPv4/IPv6 difference, there should be no noticeable > outcome between 'inet manual' and 'inet6 auto'. > > Reco > >
Re: [OT] get all devices from a vendor from pci.ids
Hello,
On Thu, Jan 5, 2017 at 6:00 PM, Floris wrote:
> Op Wed, 04 Jan 2017 17:27:55 +0100 schreef Floris :
>
>
>> (Not really a Debian question, but I know there are smart people on this
>> list.)
>>
>> I want to search the pci.ids file (from the pciutils package) for all
>> Compaq devices.
>> Pci ID's 0e11: , 1032: and 10da: matches Compaq.
>> Unfortunately, only at a beginning of a list the id of the vendor is printed
>> in column 1. The id of the devices are printed in column 2, with an empty
>> first column.
>>
>> (part of pci.ids)
>> ...
>> 0e11 Compaq Computer Corporation
>> 0001 PCI to EISA Bridge
>> 0002 PCI to ISA Bridge
>> 0046 Smart Array 64xx
>> 0e11 4091 Smart Array 6i
>> 0e11 409a Smart Array 641
>> 0e11 409b Smart Array 642
>> 0e11 409c Smart Array 6400
>> 0e11 409d Smart Array 6400 EM
>> 0049 NC7132 Gigabit Upgrade Module
>> 004a NC6136 Gigabit Server Adapter
>> ...
>> c000 Remote Insight Lights-Out Edition
>> f130 NetFlex-3/P ThunderLAN 1.0
>> f150 NetFlex-3/P ThunderLAN 2.3
>> 0e55 HaSoTec GmbH
>> ...
>>
>> Is there an awk, grep and or sed solution?
>>
>> Floris
>>
>
> an other solution would be something like:
>
> # cat pci.ids | {magic-command} 0e11:004a
> NC6136 Gigabit Server Adapter
>
> what is the magic command?
Using perl:
perl -ne 'print if (/^0e11/.../^\S/) and (/^\s/) or (/^0e11/);'
/usr/share/misc/pci.ids
Re: hotpluggable member of a bridge
>> Interesting. Any hint how? > It would be too long to explain here, but this page seems to cover the > basics of what you need: > http://packetpushers.net/udev/ I don't see any mechanism in there that will bring up an interface or add it to a bridge, nor bring up the bridge. As I said, I already have something working using `manual`. It looks like: allow-hotplug usb0 iface usb0 inet manual post-up brctl addif br0 $IFACE; ifconfig $IFACE up pre-down ifconfig $IFACE down; brctl delif br0 $IFACE and I think I can fairly easily spice it up to bring `br0` up on demand (tho creating `br0` eagerly is fine as well. The "ondemand" part is mostly about the need to re-start the DHCP client when `usb0` gets added to `br0`). But what I'm looking for is a way to do that without writing it as a script (IOW a more declarative way to do it). Stefan
PROGRESS [Re: New to iptables]
On 1/4/2017 10:54 AM, Richard Owlett wrote: [snipping my original ;] One doesn't understand things without understood background. This thread triggered some understanding of things I'd been told in past. I'm using http://www.netfilter.org/documentation/ as a reading guide. A shorewall or netfilter page pointed me to ufw (I'll use gufw for now). Browsing the the feature list of privoxy suggests it may be of interest. I won't be using a VM, but will install very minimal Debian with a browser on a flash drive and use it for banking.
Re: [OT] get all devices from a vendor from pci.ids
Le sextidi 16 nivôse, an CCXXV, Floris a écrit : > Thanks! But I prefer a solution with "essential" Debian software/ packages ~ $ dpkg -S =perl perl-base: /usr/bin/perl ~ $ dpkg -s perl-base | head -n 2 Package: perl-base Essential: yes signature.asc Description: Digital signature
Re: [OT] get all devices from a vendor from pci.ids
Op Thu, 05 Jan 2017 18:13:41 +0100 schreef Javier Barroso
:
Hello,
On Thu, Jan 5, 2017 at 6:00 PM, Floris wrote:
Op Wed, 04 Jan 2017 17:27:55 +0100 schreef Floris :
(Not really a Debian question, but I know there are smart people on
this
list.)
I want to search the pci.ids file (from the pciutils package) for all
Compaq devices.
Pci ID's 0e11: , 1032: and 10da: matches Compaq.
Unfortunately, only at a beginning of a list the id of the vendor is
printed
in column 1. The id of the devices are printed in column 2, with an
empty
first column.
(part of pci.ids)
...
0e11 Compaq Computer Corporation
0001 PCI to EISA Bridge
0002 PCI to ISA Bridge
0046 Smart Array 64xx
0e11 4091 Smart Array 6i
0e11 409a Smart Array 641
0e11 409b Smart Array 642
0e11 409c Smart Array 6400
0e11 409d Smart Array 6400 EM
0049 NC7132 Gigabit Upgrade Module
004a NC6136 Gigabit Server Adapter
...
c000 Remote Insight Lights-Out Edition
f130 NetFlex-3/P ThunderLAN 1.0
f150 NetFlex-3/P ThunderLAN 2.3
0e55 HaSoTec GmbH
...
Is there an awk, grep and or sed solution?
Floris
an other solution would be something like:
# cat pci.ids | {magic-command} 0e11:004a
NC6136 Gigabit Server Adapter
what is the magic command?
Using perl:
perl -ne 'print if (/^0e11/.../^\S/) and (/^\s/) or (/^0e11/);'
/usr/share/misc/pci.ids
Thanks! But I prefer a solution with "essential" Debian software/ packages
Floris
Re: [OT] get all devices from a vendor from pci.ids
Op Thu, 05 Jan 2017 21:07:10 +0100 schreef Nicolas George : Le sextidi 16 nivôse, an CCXXV, Floris a écrit : Thanks! But I prefer a solution with "essential" Debian software/ packages ~ $ dpkg -S =perl perl-base: /usr/bin/perl ~ $ dpkg -s perl-base | head -n 2 Package: perl-base Essential: yes Sorry, I only looked at the perl package dpkg -s perl Package: perl Status: install ok installed Priority: standard Section: perl So every Debian user has the perl command? Floris
Re: PROGRESS [Re: New to iptables]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jan 05, 2017 at 01:25:10PM -0600, Richard Owlett wrote: > On 1/4/2017 10:54 AM, Richard Owlett wrote: > [snipping my original ;] > One doesn't understand things without understood background. > This thread triggered some understanding of things I'd been told in > past. That's great to hear (should I say "read"). It's what we all are here for, right? All the best for your plans :) Cheers - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlhur7sACgkQBcgs9XrR2kZ1BwCfcPunHMD0HzpbcEjVcAL1aT1x ioIAniN1sZL2dhCQIbF52Q0Y7T9Sy9hA =sxgp -END PGP SIGNATURE-
Monitor switched off after resume from hibernation
I'm on debian stretch, and my computer is a MacBookPro 12,1. I've recently noticed an issue that affect my system when it hibernates. When the screen is already switched off and then the system hibernates, it won't resume correctly later on. Specifically, the monitor will be switched off again at the end of the resume process. E.g. I give the following command in order to switch off the monitor: $ sleep 1 && xset dpms force off then I close the lid so that my system hibernates. Then I resume the system. The monitors turns on, as I see the boot loader screen and some boot messages. But then, when the resume is complete, the screen is switched off again, and there is no way to turn it on. The only solution is press the power button to turn off the entire computer. I get the same issue even when, instead of using the xset command, I wait several minutes so that the screen is switched off automatically by KDE's power management, and then I hibernate the system. By contrast, I have no issue if I hibernate when the screen is still on. The resume works perfectly well. Besides, suspend (to RAM) has no issue either, both when the screen is on and when it is off. I've already reported a bug to the mainteiners of debian kernel. But in the meanwhile, as a workaround I'm thinking of using a systemd script that forces the monitor on just before the system starts hibernating. I've tried with "xset dpms force on", however it won't in fact turn on the monitor. Is there a way to do this? Thanks & Regards, Davide
Re: hotpluggable member of a bridge
Le 05/01/2017 à 17:32, Reco a écrit : Joshua Schaeffer wrote: A sample configuration would be: allow-ovs br0 iface br0 inet4 static address … netmask … ovs_type OVSBridge allow-br0 eth0 iface eth0 inet6 auto ovs_type OVSPort ovs_bridge br0 allow-hotplug usb0 iface usb0 inet6 auto ovs_type OVSPort ovs_bridge br0 Pardon my ignorance, can you explain why you set an IPv4 address on your bridge and an IPv6 address on your bridge interfaces? I wondered the same. It's simple, although isn't obvious from this abridged example. No it's not. I need a single IPv4 for both interfaces, so I set it on a bridge. I don't need distinct IPv4 on ports, so I don't set it there. This has nothing to do with IPv6 config. Bridged interfaces retain their MACs, so they would get different IPv6 ULAs, which are provided by radvd from the different host. Not if they are bridged before they are brought UP or accept_ra/autoconf is disabled. And get myself all kinds of unneeded trouble, or I can do: allow-br0 eth0 iface eth0 inet6 auto autoconf 0 accept_ra 0 ovs_type OVSPort ovs_bridge br0 Ok, THIS, provides the missing info from your previous post : disable autoconf and accept_ra. But according to man interfaces(5), the inet6 "auto" method ignores the "autoconf" option. This option is specific to the "static" method.
Re: hotpluggable member of a bridge
Le 05/01/2017 à 22:17, Pascal Hambourg a écrit : But according to man interfaces(5), the inet6 "auto" method ignores the "autoconf" option. This option is specific to the "static" method. And "dhcp".
Re: hotpluggable member of a bridge
Hi. On Thu, 5 Jan 2017 22:17:23 +0100 Pascal Hambourg wrote: > > Bridged interfaces retain their MACs, so they would get different IPv6 > > ULAs, which are provided by radvd from the different host. > > Not if they are bridged before they are brought UP I'm not that familiar with openvswitch to make claims about the order in which an interface brought up and bridged. If you have such knowledge then feel free to share it with the list please. > or accept_ra/autoconf is disabled. Disabling it is the whole point. > > And get myself all kinds of unneeded trouble, or I can do: > > > > allow-br0 eth0 > > iface eth0 inet6 auto > > autoconf 0 > > accept_ra 0 > > ovs_type OVSPort > > ovs_bridge br0 > > Ok, THIS, provides the missing info from your previous post : disable > autoconf and accept_ra. > > But according to man interfaces(5), the inet6 "auto" method ignores the > "autoconf" option. This option is specific to the "static" method. Indeed. Thanks for the correction. Reco
Re: Monitor switched off after resume from hibernation
Ummm, why turn the monitor off first? I use suspend rather than hibernate, on a macbook 4,1 and just close the lid. I get a password screen as soon as I open up. Keith Bainbridge 0447667468 keithrbaugro...@gmail.com Sent from my APad On 6 Jan 2017 08:04, "solitone" wrote: > I'm on debian stretch, and my computer is a MacBookPro 12,1. I've recently > noticed an issue that affect my system when it hibernates. > > When the screen is already switched off and then the system hibernates, it > won't resume correctly later on. Specifically, the monitor will be > switched off > again at the end of the resume process. > > E.g. I give the following command in order to switch off the monitor: > > $ sleep 1 && xset dpms force off > > then I close the lid so that my system hibernates. Then I resume the > system. > The monitors turns on, as I see the boot loader screen and some boot > messages. > But then, when the resume is complete, the screen is switched off again, > and > there is no way to turn it on. The only solution is press the power button > to > turn off the entire computer. > > I get the same issue even when, instead of using the xset command, I wait > several minutes so that the screen is switched off automatically by KDE's > power management, and then I hibernate the system. > > By contrast, I have no issue if I hibernate when the screen is still on. > The > resume works perfectly well. Besides, suspend (to RAM) has no issue either, > both when the screen is on and when it is off. > > I've already reported a bug to the mainteiners of debian kernel. But in the > meanwhile, as a workaround I'm thinking of using a systemd script that > forces > the monitor on just before the system starts hibernating. I've tried with > "xset dpms force on", however it won't in fact turn on the monitor. Is > there a > way to do this? > > Thanks & Regards, > Davide > >
Re: hotpluggable member of a bridge
> But, it all changes if you replace conventional bridge with > openvswitch, which *can* add new interfaces (ports as they call it) to > its own bridges dynamically *and* it can be configured via interfaces(5). Interesting. Would it work if the IP address of the bridge is acquired dynamically via DHCP? E.g. at boot, the bridge contains only eth0, but it can't get an IP address because there's no DHCP server on that network (or maybe eth0 is not even connected to anything yet). Later, someone connects an ethernet dongle that appears as usb0 and that one should be added to br0 and since it is connected to a network that has a DHCP server, I'd want the br0 to acquire an IP at that moment. Stefan
Re: hotpluggable member of a bridge
Michael Biebl wrote:
>> [2] Once, for a customer: inserting the right storage medium (with
>>the right UUID) triggered a system backup.
> Please don't do that. udev is a not a service manager and starting (long
> running) tasks from a udev rule is bad.
I wish someone would clue in Dell into that.
> See also the udev man page:
> Starting daemons or other long-running processes is not appropriate
> for udev; the forked processes, detached or not, will be
> unconditionally killed after the event handling has finished.
Dell includes a udev-rule in its ISM-Packages for iDRAC like this:
,
| # Dell USBNIC Device
| SUBSYSTEM=="usb", ATTR{idVendor}=="413c", ATTR{idProduct}=="a102",
ATTR{manufacturer}=="Dell(TM)", ACTION=="add", RUN+="/etc/init.d/dcismeng start
&"
`
The idea is to start the iSM-Daemon once the idrac-usb-network device is
detected. But because of the problem you mention this fails horribly and
causes a 30 second delay during boot if used with systemd.
Urgh.
Grüße,
Sven.
--
Sigmentation fault. Core dumped.
Re: Monitor switched off after resume from hibernation
On Fri 06 Jan 2017 at 11:11:45 (+1100), Keith Bainbridge wrote: > Ummm, why turn the monitor off first? Perhaps because Davide doesn't want to wait 30 mins¹ before closing the lid and finding out if the problem still recurs. > I use suspend rather than hibernate, on a macbook 4,1 and just close the > lid. I get a password screen as soon as I open up. So would that be using more power both when the lid is closed, and also when the lid is left open for prolonged periods? ¹ I used to specify 10/20/30 minutes for stand-by/suspend/off when I ran real CRT monitors. > On 6 Jan 2017 08:04, "solitone" wrote: > > > I'm on debian stretch, and my computer is a MacBookPro 12,1. I've recently > > noticed an issue that affect my system when it hibernates. > > > > When the screen is already switched off and then the system hibernates, it > > won't resume correctly later on. Specifically, the monitor will be > > switched off > > again at the end of the resume process. > > > > E.g. I give the following command in order to switch off the monitor: > > > > $ sleep 1 && xset dpms force off > > > > then I close the lid so that my system hibernates. Then I resume the > > system. > > The monitors turns on, as I see the boot loader screen and some boot > > messages. > > But then, when the resume is complete, the screen is switched off again, > > and > > there is no way to turn it on. The only solution is press the power button > > to > > turn off the entire computer. > > > > I get the same issue even when, instead of using the xset command, I wait > > several minutes so that the screen is switched off automatically by KDE's > > power management, and then I hibernate the system. > > > > By contrast, I have no issue if I hibernate when the screen is still on. > > The > > resume works perfectly well. Besides, suspend (to RAM) has no issue either, > > both when the screen is on and when it is off. > > > > I've already reported a bug to the mainteiners of debian kernel. But in the > > meanwhile, as a workaround I'm thinking of using a systemd script that > > forces > > the monitor on just before the system starts hibernating. I've tried with > > "xset dpms force on", however it won't in fact turn on the monitor. Is > > there a > > way to do this? Do you perhaps need xset -display dpms force on in the systemd script? Cheers, David.
Re: Congratulations Tha ynis , y You...r Roof is Covered - FREE!Tj9W
Sent from my MetroPCS 4G LTE Android device - Reply message - From: "Nicolas George" To: "Stefan Monnier" Cc: Subject: Congratulations Thaynis , Your Roof is Covered - FREE!Tj9W Date: Thu, Jan 5, 2017 10:31 AM asdf @#%@#%$#^%#$^#$
Re: Monitor switched off after resume from hibernation
Please see below Keith Bainbridge 0447667468 keithrbaugro...@gmail.com Sent from my APad On 6 Jan 2017 12:58, "David Wright" wrote: On Fri 06 Jan 2017 at 11:11:45 (+1100), Keith Bainbridge wrote: > Ummm, why turn the monitor off first? Perhaps because Davide doesn't want to wait 30 mins¹ before closing the lid and finding out if the problem still recurs. Not my case. The book simply suspends when the lid is closed.
Re: Monitor switched off after resume from hibernation
On Friday, January 6, 2017 11:11:45 AM CET Keith Bainbridge wrote: > Ummm, why turn the monitor off first? I use KDE's power management tool to e.g. dim the screen after 5 minutes, switch the screen off after 10 mins, suspend to RAM after 20 mins, and hibernate to disk when I close the lid. If I leave the computer inactive for more than 10 minutes and then I close the lid, the system will hibernate. When I resume it, the monitor will be switched off at the end of the resume process. > I use suspend rather than hibernate, on a macbook 4,1 and just close the > lid. Yes, but I'd rather take advantage of all the energy saving options that are available. Booting up is so quick on a MacBookPro 12,1 that you may well use hibernate rather than suspend, and resume the system in few seconds.
Re: Monitor switched off after resume from hibernation
I'm no expert, but I wonder if the book is resuming from hibernate in the state it was at hibernate. If so, the system thinks the screen is off. On the issue of power saving, my battery lasts about 15 minutes when working. In suspend it sits there for several days. I don't know how much more power you are saving with hibernate. Keith Bainbridge 0447667468 keithrbaugro...@gmail.com Sent from my APad On 6 Jan 2017 16:55, "solitone" wrote: > On Friday, January 6, 2017 11:11:45 AM CET Keith Bainbridge wrote: > > Ummm, why turn the monitor off first? > > I use KDE's power management tool to e.g. dim the screen after 5 minutes, > switch the screen off after 10 mins, suspend to RAM after 20 mins, and > hibernate to disk when I close the lid. > > If I leave the computer inactive for more than 10 minutes and then I close > the > lid, the system will hibernate. When I resume it, the monitor will be > switched > off at the end of the resume process. > > > I use suspend rather than hibernate, on a macbook 4,1 and just close the > > lid. > > Yes, but I'd rather take advantage of all the energy saving options that > are > available. Booting up is so quick on a MacBookPro 12,1 that you may well > use > hibernate rather than suspend, and resume the system in few seconds. > >
