Re: What connection exist between CMOS battery and the network interface?

William Torrez Corea composed on 2024-10-13 23:47 (UTC-0600): > My computer lost configuration; have problems with the network, peripheral > and date/hour stopped working. The battery powers the clock when the PSU cannot. When there's not enough power for the clock, there isn't enough power to pr

What connection exist between CMOS battery and the network interface?

My computer lost configuration; have problems with the network, peripheral and date/hour stopped working. -- With kindest regards, William. *Larry Wall invented a messy programming language -- and changed the face of the Web*

Re: Sometimes different network interface name?

David Wright writes: > If you look at how the package iwd keeps the kernel's choice of name, > you'll see it installs: [...] Interesting. I can't say I'm convinced by the systemd.link manpage that this is the correct configuration but let's assume the iwd peeps know what they're doing. I set th

Re: Sometimes different network interface name?

On Fri 02 Sep 2022 at 13:44:24 (+0300), Anssi Saari wrote: > > I have an LTE module in my Debian router for failover in case my fiber > goes down. It has this occasional issue that mostly its interface is > wwan0 but sometimes it's wwx0a697e2d934f. > > When that happens I have something like this

Re: Sometimes different network interface name?

Tixy writes: > The number in the name looks like a MAC address and its value is in the > 'locally administered' range, i.e. not something baked into the device > by the manufacturer. It's an LTE device so it doesn't have a MAC address even though it presents an ethernet-like interface. Or I gues

Re: Sometimes different network interface name?

On Fri, 2022-09-02 at 13:44 +0300, Anssi Saari wrote: > I have an LTE module in my Debian router for failover in case my fiber > goes down. It has this occasional issue that mostly its interface is > wwan0 but sometimes it's wwx0a697e2d934f. > > When that happens I have something like this in my s

Re: Sometimes different network interface name?

On Fri 02 Sep 2022 at 13:44:24 +0300, Anssi Saari wrote: > > I have an LTE module in my Debian router for failover in case my fiber > goes down. It has this occasional issue that mostly its interface is > wwan0 but sometimes it's wwx0a697e2d934f. > > When that happens I have something like this

Sometimes different network interface name?

I have an LTE module in my Debian router for failover in case my fiber goes down. It has this occasional issue that mostly its interface is wwan0 but sometimes it's wwx0a697e2d934f. When that happens I have something like this in my syslog: Sep 1 08:34:40 animus kernel: [8.150781] qmi_ww

Re: Predictable Network Interface Names

Erwan David writes: > I also got a name change with an upgrade (I do not remember wether it > was kernel, systemd or udev). > > SInce interfaces where combined in a bond, imagine the mess... I think I noticed something like that too as I've updated my desktop HW and booted from some different me

Re: Predictable Network Interface Names

couple years ago for some forgotten reason. I think it was when the names first started changing on us, and I was trying to take control of the situation. I remember it working and then not working. Can't remember now why I gave up on it. Thankfully things have ironed out some since so it h

Re: Predictable Network Interface Names

On Thu, Mar 31, 2022 at 08:04:13AM -0400, Michael Stone wrote: > On Thu, Mar 31, 2022 at 07:10:33AM +0200, to...@tuxteam.de wrote: > > Somewhat self-referential. I'm not the one getting worked up here ;-) > > And I'm not the one accusing people of lying. I hope my clarification --uh-- clears thin

Re: Predictable Network Interface Names

On Thu, Mar 31, 2022 at 12:39:37PM +0100, Brian wrote: > On Thu 31 Mar 2022 at 07:28:47 +0200, to...@tuxteam.de wrote: > > [...]] > > > Since then, I learnt that I like to relax call my interfaces > > "eth0" and "wlan0". > > > > Can we still be friends? > > Of course! After all, we are both pla

Re: Predictable Network Interface Names

On Thu, Mar 31, 2022 at 07:10:33AM +0200, to...@tuxteam.de wrote: Somewhat self-referential. I'm not the one getting worked up here ;-) And I'm not the one accusing people of lying.

Re: Predictable Network Interface Names

On 2022-03-31 at 01:28, to...@tuxteam.de wrote: > This is one weakness I see with freedesktop often. They try to > fight complexity with ever more complexity, with the end result > of a more user-unfriendly (because less understandable) system. Very well expressed. I've added that to the "complet

Re: Predictable Network Interface Names

On Wed, Mar 30, 2022 at 05:56:47PM -0500, Nicholas Geovanis wrote: Because some of us work in corporate data centers. And everything you claim that helps us here really does the opposite. Because it was introduced in large part to support mobile computing. Which does not and will never be valuabl

Re: Predictable Network Interface Names

On Thu 31 Mar 2022 at 07:28:47 +0200, to...@tuxteam.de wrote: [...]] > Since then, I learnt that I like to relax call my interfaces > "eth0" and "wlan0". > > Can we still be friends? Of course! After all, we are both playing in the same game. -- Brian.

Re: Predictable Network Interface Names

31.03.22, 13:01 +0200, Sven Hartge: Greg Wooledge wrote: unicorn:~$ cat /etc/systemd/network/10-lan0.link [Match] MACAddress=18:60:24:77:5c:ec [Link] Name=lan0 Careful with that one. If you use VLANs then you suddenly get multiple interface with the same MAC and strange things will happe

Re: Predictable Network Interface Names

Greg Wooledge wrote: > unicorn:~$ cat /etc/systemd/network/10-lan0.link > [Match] > MACAddress=18:60:24:77:5c:ec > [Link] > Name=lan0 Careful with that one. If you use VLANs then you suddenly get multiple interface with the same MAC and strange things will happen, because it matches for all of

Re: Predictable Network Interface Names

On Wed, Mar 30, 2022 at 10:38:10PM +0100, Brian wrote: > On Wed 30 Mar 2022 at 21:50:53 +0200, to...@tuxteam.de wrote: > > > On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote: > > > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote: > > > > > > > On Wed, Mar 30, 2022 at 05:35:12PM +02

Re: Predictable Network Interface Names

On Wed, Mar 30, 2022 at 05:55:11PM -0400, Michael Stone wrote: > On Wed, Mar 30, 2022 at 10:38:10PM +0100, Brian wrote: > > Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals > > the truth and peddles false information purposefully? > > Some people get excessively worked up over thin

Re: Predictable Network Interface Names

On Wednesday, 30 March 2022 18:31:36 EDT Michael Stone wrote: > On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote: > >It's like you haven't even read this thread. > > of course I have > > >Predictable interface names *do* sometimes change. And when that > >happens, it's a huge deal,

Re: Predictable Network Interface Names

> Some people get excessively worked up over things like interface names > and like to throw around strong words for dramatic effect. Just ignore > the noise. I've just come to accept that the actual interface name is going to be some bizarre name. So I look it up, and then promptly rename it

Re: Predictable Network Interface Names

On Wed, Mar 30, 2022, 5:32 PM Michael Stone wrote: > On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote: > >It's like you haven't even read this thread. > > of course I have > > >Predictable interface names *do* sometimes change. And when that happens, > >it's a huge deal, because all

Re: Predictable Network Interface Names

On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote: It's like you haven't even read this thread. of course I have Predictable interface names *do* sometimes change. And when that happens, it's a huge deal, because all of the configuration files are set up for the old name. Things

Re: Predictable Network Interface Names

On Wed, Mar 30, 2022 at 05:55:11PM -0400, Michael Stone wrote: > For most consumer sytems the interface name matters not one bit, because > it's auto-discovered on install, will never change, and there's little > likelihood that another interface will be added. It's like you haven't even read this

Re: Predictable Network Interface Names

On Wed, Mar 30, 2022 at 10:38:10PM +0100, Brian wrote: Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals the truth and peddles false information purposefully? Some people get excessively worked up over things like interface names and like to throw around strong words for dramati

Re: Predictable Network Interface Names

On Wed 30 Mar 2022 at 21:50:53 +0200, to...@tuxteam.de wrote: > On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote: > > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote: > > > > > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote: > > > > as I can read here [1] network names shoul

Re: Predictable Network Interface Names

On Wed, Mar 30, 2022 at 04:00:42PM -0500, Nicholas Geovanis wrote: > Does anyone here know how the BSD-derived "free" unices handle this > situation? I haven't used OpenBSD in several years, but the last time I used it, it went something like this: The OpenBSD kernel has drivers for lots of diffe

Re: Predictable Network Interface Names

On Wed, Mar 30, 2022, 2:15 PM Brian wrote: > On Wed 30 Mar 2022 at 14:39:33 -0400, Greg Wooledge wrote: > > > On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote: > > > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote: > > > > Yes. You've now seen direct evidence of the lie. I guess

Re: Predictable Network Interface Names

On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote: > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote: > > > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote: > > > as I can read here [1] network names should be stable. > > > (Stable interface names even when hardware is added or

Re: Predictable Network Interface Names

Greg Wooledge wrote: > On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote: > > That's good advice, but are MAC addresses memorable? > > Doesn't matter. You can choose a memorable name. The MAC address is > simply the data point you place in the config file, so the system knows > this is the

Re: Predictable Network Interface Names

Le 30/03/2022 à 21:15, Brian a écrit : = which goes into some detail. Thanks. Very informative. As the second link says: The resulting reality is that your PCI based names are only stable if you change no hardware in the s

Re: Predictable Network Interface Names

On Wed 30 Mar 2022 at 14:39:33 -0400, Greg Wooledge wrote: > On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote: > > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote: > > > Yes. You've now seen direct evidence of the lie. I guess I won't need > > > to post links to the wiki articles

Re: Predictable Network Interface Names

Le 30/03/2022 à 20:39, Greg Wooledge a écrit : Doesn't matter. You can choose a memorable name. The MAC address is simply the data point you place in the config file, so the system knows this is the interface you're talking about. unicorn:~$ cat /etc/systemd/network/10-lan0.link [Match] MACAd

Re: Predictable Network Interface Names

On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote: > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote: > > Yes. You've now seen direct evidence of the lie. I guess I won't need > > to post links to the wiki articles that say the same thing you've already > > observed. > > I would be

Re: Predictable Network Interface Names

On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote: > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote: > > as I can read here [1] network names should be stable. > > (Stable interface names even when hardware is added or removed) > > > [1] > > https://www.freedesktop.org/wiki/Softwa

Re: Predictable Network Interface Names

On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote: > as I can read here [1] network names should be stable. > (Stable interface names even when hardware is added or removed) > [1] > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Sorry, but you've been lie

Predictable Network Interface Names

Hello, as I can read here [1] network names should be stable. (Stable interface names even when hardware is added or removed) First of all I have multiple PCIe NIC in a server. What I see now is: When I add or remove a PCIe card (USB card) the name is changed from enp5s3 to enp6s3 and back

Re: Installer can't find network interface on Intel NUC BOXNUC8i3BEH1

> On Feb 13, 2019, at 6:51 PM, Rick Thomas wrote: > > > >> On Feb 13, 2019, at 5:47 PM, Ben Hutchings wrote: >> >> On Wed, 2019-02-13 at 16:17 -0500, Laurent Dumont wrote: >>> I'm not sure if it's the exact same case but I had the same issue with a >>> more recent motherboard. Debian faile

Re: Installer can't find network interface on Intel NUC BOXNUC8i3BEH1

> On Feb 13, 2019, at 5:47 PM, Ben Hutchings wrote: > > On Wed, 2019-02-13 at 16:17 -0500, Laurent Dumont wrote: >> I'm not sure if it's the exact same case but I had the same issue with a >> more recent motherboard. Debian failed to detect the network card with the >> E1000 drivers. >> >> I

Re: Installer can't find network interface on Intel NUC BOXNUC8i3BEH1

On Wed, 2019-02-13 at 16:17 -0500, Laurent Dumont wrote: > I'm not sure if it's the exact same case but I had the same issue with a > more recent motherboard. Debian failed to detect the network card with the > E1000 drivers. > > I tried an iso with the non free repo without success. > > A base U

Re: Installer can't find network interface on Intel NUC BOXNUC8i3BEH1

stuff. When it gets to > trying to identify the network interface, it fails at that task and drops > into a screen with a long list of network drivers for me to choose from. > > I didn’t know what driver to load (the Newegg description says it uses an > Intel networking chip, but

Installer can't find network interface on Intel NUC BOXNUC8i3BEH1

made a bootable USB stick the usual way with dd to copy the iso to the stick. It boots fine and loads some preliminary stuff. When it gets to trying to identify the network interface, it fails at that task and drops into a screen with a long list of network drivers for me to choose from. I

Re: Predictable Network Interface Names

mportant here. > With Predictable Network Interface Names enabled, it should be possible, to > do this automated. It is now, once they fixed it. > I got this 'ens' part, no problem. But where do the numbers come from? Long story short, VMWare NICs were horribly broken in regards to P

Predictable Network Interface Names

Hi ML members, I have a bunch of machines, all virtual, where I have to swap the NIC type. Three or four NIC's per host, e1000 to vmxnet3 for those who may care about. With Predictable Network Interface Names enabled, it should be possible, to do this automated. Not being lazy, I'v

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

t/tree/debian/udev.postinst#n49 > > The /etc/systemd/network/99-default.link file overrides the the package > provided one from /lib/systemd/network/99-default.link > > So, in order to enable the new naming scheme, remove > /etc/systemd/network/99-default.link then rebuild the i

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

build the initramfs. On the next boot you should have the new network interface names. Regards, Michael -- 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: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

Sure, this is the content: cat /tmp/foo/lib/systemd/network/99-default.link # This machine is most likely a virtualized guest, where the old persistent # network interface mechanism (75-persistent-net-generator.rules) did not work. # This file disables /lib/systemd/network/99-default.link to

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

Am 27.07.2017 um 19:50 schrieb Patrick Flaig: > Oh my fault, 99-default.link is available, I checked the wrong folder. > The file is containing some text, saying that the machine is most likely a > virtualized guest. Can you paste the contents verbatim. -- Why is it that all of the instruments

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

Oh my fault, 99-default.link is available, I checked the wrong folder. The file is containing some text, saying that the machine is most likely a virtualized guest. > Am 27.07.2017 um 19:28 schrieb Michael Biebl : > > Am 27.07.2017 um 18:55 schrieb debian-li...@patschie.de: > >>> Am 27.07.2017

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

Am 27.07.2017 um 18:55 schrieb debian-li...@patschie.de: >> Am 27.07.2017 um 18:25 schrieb Michael Biebl : >> lsinitramfs /boot/initrd.img-$(uname -r) | grep 99-default.link >> lib/systemd/network/99-default.link > Missing Odd. Do you have that file on the host system? Can you check with debsums

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

> Am 27.07.2017 um 18:25 schrieb Michael Biebl : > > Am 27.07.2017 um 18:04 schrieb debian-li...@patschie.de: >> Hi Michael, >> >> I forgot to mention that I also recreated the initramfs: >> after several tries just to update it, I deleted the initramfs and recreated >> it completely. >> But s

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

> Am 27.07.2017 um 18:25 schrieb Michael Biebl : > > Am 27.07.2017 um 18:04 schrieb debian-li...@patschie.de: >> Hi Michael, >> >> I forgot to mention that I also recreated the initramfs: >> after several tries just to update it, I deleted the initramfs and recreated >> it completely. >> But s

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

Thanks, confirmed, the initrd doesn’t contain any udev rule files in /etc/udev/rules.d > Am 27.07.2017 um 18:11 schrieb Greg Wooledge : > > On Thu, Jul 27, 2017 at 06:04:49PM +0200, debian-li...@patschie.de wrote: >> Is there a way to manually check the contents of the initramfs, just to make

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

Am 27.07.2017 um 18:04 schrieb debian-li...@patschie.de: > Hi Michael, > > I forgot to mention that I also recreated the initramfs: > after several tries just to update it, I deleted the initramfs and recreated > it completely. > But still the same effect. > > Is there a way to manually check t

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

On Thu, Jul 27, 2017 at 06:04:49PM +0200, debian-li...@patschie.de wrote: > Is there a way to manually check the contents of the initramfs, just to make > sure that the 70-persistent-net.rules isn’t there? mkdir /tmp/foo && cd /tmp/foo && unmkinitramfs /boot/initrd.whatever (The old way of just

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

-net.rules isn’t there? Patrick > Am 27.07.2017 um 17:57 schrieb Michael Biebl : > > Hi Patrick > > Am 27.07.2017 um 17:15 schrieb debian-li...@patschie.de: >> Hi, >> >> I’m running into some troubles to enable the predictable network interface >>

Re: Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

Hi Patrick Am 27.07.2017 um 17:15 schrieb debian-li...@patschie.de: > Hi, > > I’m running into some troubles to enable the predictable network interface > names for a system upgraded from Jessie. > > What I figured out so far: > Setting net.ifnames=1 on the kernel command

Jessie to Stretch Upgrade: Enable Predictable Network Interface Names

Hi, I’m running into some troubles to enable the predictable network interface names for a system upgraded from Jessie. What I figured out so far: Setting net.ifnames=1 on the kernel command line doesn’t help and seems no longer to be supported parameter (at least "sysctl - a" doesn

Re: Predictable Network Interface Names prevents WiFi connections.

Hi Miguel, Did you ever get an answer about this? I can't get Network Manager (from KDE) to connect if the predictable network interface names are enabled. Cheers, Marcos

Re: how to compute predictable network interface names?

Hi Christian, On 02/24/17 12:43, Christian Seiler wrote: > > udev will then rename the device once it encounters it. > > In newer udev versions, it will use some (but not all) settings from > systemd.link files. The other settings are interpreted by > systemd.networkd. (And if you don't use that

Re: how to compute predictable network interface names?

ere and not rename the interface at all. NamePolicy=kernel will most likely never trigger on any system you have (it has never triggered on any system I have), it's for the case where the kernel driver says "yeah, the name I chose is already a name that's going to be persistent".

Re: how to compute predictable network interface names?

On 02/24/2017 10:10 AM, Harald Dunkel wrote: > > Now I got confused: Who is responsible for renaming the NIC names? > Is this a systemd feature, is this the job of udev, or are the NICs > renamed by the kernel very early at boot time? Shouldn't I get the > same predictable name for eth0, no matter

Re: how to compute predictable network interface names?

On 02/23/2017 04:25 PM, Christian Seiler wrote: > > There's a policy which are going to be preferred. man 5 systemd.link > tells you what the options are and /lib/systemd/network/99-default.link > tells you what the default setting is (the first successful one is > used). Of course I stumbled ove

Re: how to compute predictable network interface names?

ss. If you want to continue doing something like that, use the kernel boot parameter net.ifnames=0 and create your own udev rule. For example: /etc/udev/rules.d/76-netnames.rules: # Create custom network interface names based on MAC address. SUBSYSTEM=="net", ACTION==&qu

Re: how to compute predictable network interface names?

On 02/23/2017 04:16 PM, Harald Dunkel wrote: > On 02/16/2017 12:47 PM, Christian Seiler wrote: >> >> On a system with predictable names running? Or on a system >> pre-upgrade? >> > > Its more "pre-installation". I boot a USB stick and run > my own installer (using debootstrap or creating a clone).

Re: how to compute predictable network interface names?

On 02/16/2017 12:47 PM, Christian Seiler wrote: > > On a system with predictable names running? Or on a system > pre-upgrade? > Its more "pre-installation". I boot a USB stick and run my own installer (using debootstrap or creating a clone). The NIC name is needed to setup /etc/network/interface

Re: how to compute predictable network interface names?

On Thu, Feb 16, 2017 at 12:47:25PM +0100, Christian Seiler wrote: > On a system with predictable names running? Or on a system > pre-upgrade? > > Because if you have a system that's being upgraded at the > moment, the following command _might_ work _after_ you've > upgraded udev and _before_ you'v

Re: how to compute predictable network interface names?

with that MAC and name it something yourself. For example, you could create a file [1] /etc/systemd/network/10-uplink.link with the following contents: [Match] MACAddress=xx:yy:zz:gg:hh:ii [Link] Name=uplink This way the network interface with the specified MAC address is now called "up

how to compute predictable network interface names?

Hi folks, I understand that the predictable nic names can be turned off using net.ifnames=0 on the kernel command line, but I wonder if there is a shell script to actually predict the "enpYsZ" from the old style "ethX" initially assigned by the kernel? Something like % predict_n

Predictable Network Interface Names prevents WiFi connections.

Hello. I'm having a weird problem with my Debian testing installation. I use KDE Plasma 5 and NetworkManager in a up-to-date system. The problem is I can't connect to any wifi if Predictable Network Interface Names are in use. I can see all wireless networks in Network Manager, so I s

Re: Huawei E173 - no more network interface?

kjo...@poczta.onet.pl (Kamil Jońca) writes: > Sometimes[1] I had to use Huawei E173 gsm modem. > About a year ago, when I put this modem in USB port I got network > interface like wwan0 or usb0. > But now this not happen any more. > I got only ttyUSB? interfaces. It is considered

Huawei E173 - no more network interface?

Sometimes[1] I had to use Huawei E173 gsm modem. About a year ago, when I put this modem in USB port I got network interface like wwan0 or usb0. But now this not happen any more. I got only ttyUSB? interfaces. What should I check/do to have network interface? KJ -- http://wolnelektury.pl

Re: LSB Raise network interface taking too long

Am 27.03.2015 um 18:50 schrieb Paulo Roberto: > And you were right, removing the /etc/network/if-up.d/openntpd the problem > was gone. > > I assume that this file that comes in the openntpd package should not exist. > Am I correct? It's a but in the openntpd package, I'd say. In general, such ho

Re: LSB Raise network interface taking too long

, Michael Biebl wrote: > Am 27.03.2015 um 17:07 schrieb Paulo Roberto: > > Hello, > > > > During the boot, when it's time to bring the interfaces up, this process > > takes more than 5 minutes. > > The below message is displayed on the screen: > > >

Re: LSB Raise network interface taking too long

Am 27.03.2015 um 17:07 schrieb Paulo Roberto: > Hello, > > During the boot, when it's time to bring the interfaces up, this process > takes more than 5 minutes. > The below message is displayed on the screen: > > A start job is running for LSB: Raise network inter

LSB Raise network interface taking too long

Hello, During the boot, when it's time to bring the interfaces up, this process takes more than 5 minutes. The below message is displayed on the screen: A start job is running for LSB: Raise network interface [5:16] After the timeout the systems works normally. I'm using Lenny

Re: Upgrade wheezy->jessie: Network interface: eth0 (atl1c) shows excessive power consumption

> The estimated remaining time is 2 hours, 10 minutes > > > > Summary: 585.9 wakeups/second, 50.0 GPU ops/seconds, 0.0 VFS ops/sec and > > 22.6% CPU use > > > > Power est. Usage Events/sCategory Description > > > > 4

Re: Upgrade wheezy->jessie: Network interface: eth0 (atl1c) shows excessive power consumption

.0 GPU ops/seconds, 0.0 VFS ops/sec and > 22.6% CPU use > > Power est. Usage Events/sCategory Description > 4.91 W 0.0 pkts/s Device Network interface: > eth0 > (atl1c) … > Does anybody have an idea, how to debug thi

Upgrade wheezy->jessie: Network interface: eth0 (atl1c) shows excessive power consumption

Network interface: eth0 (atl1c) 2.41 W 73.3% Device Display backlight 998 mW568.0 rpm Device Laptop fan 693 mW 50.5 ms/s 169.7Processkwin -session 10e2d5d3650001348178311003743_1422711531_152502 245

Re: /etc/network/interface file auto reset.

On Sb, 20 sep 14, 14:02:43, Andrei POPESCU wrote: > > Further reading: ... > http://www.dtcc.edu/cs/rfc1855.html A kind soul pointed out to me off-list that this link is dead. Apologize for not checking, here is a link to the same document: https://www.ietf.org/rfc/rfc1855.txt Kind regards, And

Re: /etc/network/interface file auto reset.

On Saturday 20 September 2014 13:07:13 softwatt wrote: > On 09/20/2014 02:02 PM, Andrei POPESCU wrote: > > On Sb, 20 sep 14, 09:58:22, softwatt wrote: > >> > Why is quoting always needed? > > > > Other readers might be missing previous messages (network delays, > > deleted it, etc.), but want to ju

Re: [OT] /etc/network/interface file auto reset.

Hi. On Sat, 20 Sep 2014 23:51:55 +0500 Muhammad Yousuf Khan wrote: > I also apologies for my wrong posting style. actually i am not aware of > what top posting is. can any of you please tell me what top posting means > so that i can avoid this in future. You reply to the mail. You write your r

Re: /etc/network/interface file auto reset.

I also apologies for my wrong posting style. actually i am not aware of what top posting is. can any of you please tell me what top posting means so that i can avoid this in future. Thanks, MYK

Re: /etc/network/interface file auto reset.

Thanks Reco, Cindy and all for useful comments. i will try all suggestion next working day and will update you accordingly. Thanks, MYK On Sat, Sep 20, 2014 at 6:10 PM, Cindy-Sue Causey wrote: > On 9/19/14, Darac Marjal wrote: > > > > Put this into /etc/network/interfaces.d/br0 > > > >>all

Re: /etc/network/interface file auto reset.

On 9/19/14, Darac Marjal wrote: > > Put this into /etc/network/interfaces.d/br0 > >>allow-hotplug br0 >>iface br0 inet static >>address 10.xx.xx.18 >>netmask 255.xx.xx.xx >>network 10.xx.xx.0 >>gateway 10.xx.xx.3 >>broadcast 10.xx

Re: /etc/network/interface file auto reset.

On 09/20/2014 02:02 PM, Andrei POPESCU wrote: > On Sb, 20 sep 14, 09:58:22, softwatt wrote: >> > Why is quoting always needed? > > Other readers might be missing previous messages (network delays, > deleted it, etc.), but want to jump in now. Without any context they > would be unable or could

Re: [OT] /etc/network/interface file auto reset.

On Sat, Sep 20, 2014 at 10:49 AM, Reco wrote: > On Sat, 20 Sep 2014 07:20:00 +0100 > Lisi Reisz wrote: > > > On Friday 19 September 2014 15:57:38 Reco wrote: > > > On Fri, 19 Sep 2014 19:38:23 +0500 > > > > > > Muhammad Yousuf Khan wrote: > > > > thinks for your input. but i want to investigate

Re: /etc/network/interface file auto reset.

On Sb, 20 sep 14, 09:58:22, softwatt wrote: > Why is quoting always needed? Other readers might be missing previous messages (network delays, deleted it, etc.), but want to jump in now. Without any context they would be unable or could provide answers for a different question. > Mail clients k

Re: [OT] /etc/network/interface file auto reset.

On Sat, 20 Sep 2014 07:20:00 +0100 Lisi Reisz wrote: > On Friday 19 September 2014 15:57:38 Reco wrote: > > On Fri, 19 Sep 2014 19:38:23 +0500 > > > > Muhammad Yousuf Khan wrote: > > > thinks for your input. but i want to investigate which process is doing > > > this? > > > > Please do not top p

Re: /etc/network/interface file auto reset.

Hi. On Sat, 20 Sep 2014 07:30:50 +0200 mikael Flood wrote: > it might be due to some configuration management agent running on the > system which dictates a sane state of /etc/network/interfaces. > > might be puppet or cfengine. I don't have much experience with puppet, cfengine, chef or ansi

Re: /etc/network/interface file auto reset.

On Saturday 20 September 2014 07:58:22 softwatt wrote: > Why is quoting always needed? > Mail clients know which mail is a reply to which. Well, I find it very difficult to follow you, and at least one person has answered and said that he did not know the original question but... Which encourag

Re: /etc/network/interface file auto reset.

Why is quoting always needed? Mail clients know which mail is a reply to which. signature.asc Description: OpenPGP digital signature

Re: /etc/network/interface file auto reset.

On Friday 19 September 2014 15:57:38 Reco wrote: > On Fri, 19 Sep 2014 19:38:23 +0500 > > Muhammad Yousuf Khan wrote: > > thinks for your input. but i want to investigate which process is doing > > this? > > Please do not top post. Better top-posting than not quoting at all. Well, less awful any

Re: /etc/network/interface file auto reset.

On Friday 19 September 2014 07:56:14 softwatt wrote: > But that is not risk-free. What if the thing that's overwriting the file > on startup dislikes not being able to write to the file and crashes? > > By the way, my solution would fail if the overwriting is happening after > startup. softwatt, d

Re: /etc/network/interface file auto reset.

On Fri, 19 Sep 2014 19:38:23 +0500 Muhammad Yousuf Khan wrote: > thinks for your input. but i want to investigate which process is doing > this? Please do not top post. Come thinking of it, I believe there's a way of accomplish what you need. Try this: apt-get install auditd auditctl -w /etc/

Re: /etc/network/interface file auto reset.

On Fri, Sep 19, 2014 at 09:56:14AM +0300, softwatt wrote: > But that is not risk-free. What if the thing that's overwriting the file > on startup dislikes not being able to write to the file and crashes? At least a culprit is proven. > By the way, my solution would fail if the overwriting is happ

Re: /etc/network/interface file auto reset.

@softwatt Thanks for the info but there are many workaournd like these. what i wanted is to investigate the cause. @Reco thinks for your input. but i want to investigate which process is doing this? On Fri, Sep 19, 2014 at 12:39 PM, softwatt wrote: > Thanks for explaining. Debian guys teach me

Re: /etc/network/interface file auto reset.

For more information, see interfaces(5). ># The loopback network interface >auto lo >iface lo inet loopback ># The primary network interface >allow-hotplug eth1 >#iface eth1 inet dhcp >#iface eth1 inet static Put this into /etc/network/interfaces.d/

Re: /etc/network/interface file auto reset.

Thanks for explaining. Debian guys teach me something new every day. signature.asc Description: OpenPGP digital signature

  1   2   3   >