lose networking after running MX Linux

[Rene Lamontagne]

This morning I installed MX Linux 18.2 on a 16GB USB stick as discussed
yesterday, Then from this I installed this pristine copy to a 120GB SSD.
Everything works fine as it did on the USB stick except I seem to have
the problem when I shut down Linux and boot back into Windows 10 I loose
my network connectivity.
I have tried all kinds of fixes but nothing I do helps, The trouble
shooter message says I have an Ethernet cable not plugged but that is
not the case.
Checking on the internet on the other PC seems to point to closed Ports
or some such, I tried a brand new modem/router with no change, Even
reloaded a week old Macrium reflect backup, still no change.
If I boot back into Linux networking works fine.
On a hunch as I was in Linux using the internet I killed the system with
the power switch, no proper shutdown, I did a cold boot into windows 10
and Yes I was again properly connected.
Tried this 3 times with the same results , So something in MX linux
seems to leave the PC with a no internet condition on a proper shutdown.
I next went back to my Live USB stick and find it does not have this
problem, it leaves the network available to Windows.
I am not too versed in networking so am a bit of a loss but this does
make me think that what I read about closed ports may have validity.
Anyone better at this networking stuff might be able to feed me a few
crumbs to get me headed in the right direction.

Many thanks in advance.

Rene

[Dan C]

Post by Rene Lamontagne
This morning I installed MX Linux 18.2 on a 16GB USB stick as discussed
yesterday, Then from this I installed this pristine copy to a 120GB SSD.
Everything works fine as it did on the USB stick except I seem to have
the problem when I shut down Linux and boot back into Windows 10 I loose
my network connectivity.
I have tried all kinds of fixes but nothing I do helps, The trouble
shooter message says I have an Ethernet cable not plugged but that is
not the case.
Checking on the internet on the other PC seems to point to closed Ports
or some such, I tried a brand new modem/router with no change, Even
reloaded a week old Macrium reflect backup, still no change.
If I boot back into Linux networking works fine.
On a hunch as I was in Linux using the internet I killed the system with
the power switch, no proper shutdown, I did a cold boot into windows 10
and Yes I was again properly connected.
Tried this 3 times with the same results , So something in MX linux
seems to leave the PC with a no internet condition on a proper shutdown.
I next went back to my Live USB stick and find it does not have this
problem, it leaves the network available to Windows.
I am not too versed in networking so am a bit of a loss but this does
make me think that what I read about closed ports may have validity.
Anyone better at this networking stuff might be able to feed me a few
crumbs to get me headed in the right direction.
Many thanks in advance.
Rene

Format your hard drive and stick with Windoze.

Hope this helps!

[Mike Easter]

Post by Rene Lamontagne
This morning I installed MX Linux 18.2 on a 16GB USB stick as discussed
yesterday, Then from this I installed this pristine copy to a 120GB SSD.
Everything works fine as it did on the USB stick except I seem to have
the problem when I shut down Linux and boot back into Windows 10 I loose
my network connectivity.
I have tried all kinds of fixes but nothing I do helps, The trouble
shooter message says I have an Ethernet cable not plugged but that is
not the case.
Checking on the internet on the other PC seems to point to closed Ports
or some such, I tried a brand new modem/router with no change, Even
reloaded a week old Macrium reflect backup, still no change.
If I boot back into Linux networking works fine.
On a hunch as I was in Linux using the internet I killed the system with
the power switch, no proper shutdown, I did a cold boot into windows 10
and Yes I was again properly connected.
Tried this 3 times with the same results , So something in MX linux
seems to leave the PC with a no internet condition on a proper shutdown.
I next went back to my Live USB stick and find it does not have this
problem, it leaves the network available to Windows.
I am not too versed in networking so am a bit of a loss but this does
make me think that what I read about closed ports may have validity.
Anyone better at this networking stuff might be able to feed me a few
crumbs to get me headed in the right direction.

If I understand this correctly, the problem is the MX install's restart
to boot into Win leaves Win w/o ethernet connectivity, but MX live
restart to boot into Win does not cause that problem and cold boot Win
does not have the problem.

I have seen live distros which do things wrong in the shutdown, such as
not shutting power down properly, but I can't think of seeing this
network connectivity problem associated with restart.

[Rene Lamontagne]

Post by Mike Easter

Post by Rene Lamontagne
This morning I installed MX Linux 18.2 on a 16GB USB stick as
discussed yesterday, Then from this I installed this pristine copy to
a 120GB SSD.
Everything works fine as it did on the USB stick except I seem to have
the problem when I shut down Linux and boot back into Windows 10 I
loose my network connectivity.
I have tried all kinds of fixes but nothing I do helps, The trouble
shooter message says I have an Ethernet cable not plugged but that is
not the case.
Checking on the internet on the other PC seems to point to closed
Ports or some such, I tried a brand new modem/router with no change,
Even reloaded a week old Macrium reflect backup, still no change.
If I boot back into Linux networking works fine.
On a hunch as I was in Linux using the internet I killed the system
with the power switch, no proper shutdown, I did a cold boot into
windows 10 and Yes I was again properly connected.
Tried this 3 times with the same results , So something in MX linux
seems to leave the PC with a no internet condition on a proper shutdown.
I next went back to my Live USB stick and find it does not have this
problem, it leaves the network available to Windows.
I am not too versed in networking so am a bit of a loss but this does
make me think that what I read about closed ports may have validity.
Anyone better at this networking stuff might be able to feed me a few
crumbs to get me headed in the right direction.

If I understand this correctly, the problem is the MX install's restart
to boot into Win leaves Win w/o ethernet connectivity, but MX live
restart to boot into Win does not cause that problem and cold boot Win
does not have the problem.
I have seen live distros which do things wrong in the shutdown, such as
not shutting power down properly, but I can't think of seeing this
network connectivity problem associated with restart.

It seems that it is the MX shutdown that causes the problem, If I don't
shut it down but just kill the power all is fine, when I restart it in
windows all is OK, Bot if I do a proper MX shutdown or restart when
Windows comes up I get the not connected condition

The 16GB live MX USB stick works fine and does not exhibit this problem.

Rene

[Mike Easter]

Post by Rene Lamontagne
It seems that it is the MX shutdown that causes the problem, If I don't
shut it down but just kill the power all is fine, when I restart it in
windows all is OK, Bot if I do a proper MX shutdown or restart when
Windows comes up I get the not connected condition

I wonder if it makes a difference if you shut down the ethernet in MX
before you do the restart.

In MX you can shut down the ethernet graphically or by command. The
graphic icon on the taskbar in the live looks like a monitor screen and
is located between the clipit and sound/volume icons. It has a disconnect.

[Rene Lamontagne]

Post by Mike Easter

Post by Rene Lamontagne
It seems that it is the MX shutdown that causes the problem, If I
don't shut it down but just kill the power all is fine, when I restart
it in windows all is OK, Bot if I do a proper MX shutdown or restart
when Windows comes up I get the not connected condition

I wonder if it makes a difference if you shut down the ethernet in MX
before you do the restart.
In MX you can shut down the ethernet graphically or by command.  The
graphic icon on the taskbar in the live looks like a monitor screen and
is located between the clipit and sound/volume icons.  It has a disconnect.

I gave it a try Mike, no luck.
I also disabled the firewall in Windows 10, that also did nothing.
I did find a way to make it work by using a completely nasty way to shut
down an OS, By hitting the reset button while in MX Linux the system
will reboot into Windows (the default) with the network intact and running.
I am greatly surprised that Linux does not complain bitterly on this
kind of treatment, but until I find the real problem this will do.

Rene

[Paul]

Post by Rene Lamontagne

Post by Mike Easter

Post by Rene Lamontagne
It seems that it is the MX shutdown that causes the problem, If I
don't shut it down but just kill the power all is fine, when I
restart it in windows all is OK, Bot if I do a proper MX shutdown or
restart when Windows comes up I get the not connected condition

I wonder if it makes a difference if you shut down the ethernet in MX
before you do the restart.
In MX you can shut down the ethernet graphically or by command. The
graphic icon on the taskbar in the live looks like a monitor screen
and is located between the clipit and sound/volume icons. It has a
disconnect.

I gave it a try Mike, no luck.
I also disabled the firewall in Windows 10, that also did nothing.
I did find a way to make it work by using a completely nasty way to shut
down an OS, By hitting the reset button while in MX Linux the system
will reboot into Windows (the default) with the network intact and running.
I am greatly surprised that Linux does not complain bitterly on this
kind of treatment, but until I find the real problem this will do.
Rene

Open a Command Prompt in Windows when you're denied connectivity,
and check with ipconfig.

ipconfig

The equlvalent command in Linux is '

ifconfig

In there, you can verify whether DHCP worked to acquire an IP address.
The idea here, is to see if the "network unplugged" hint occurs
despite ipconfig giving working info. Or whether ipconfig is similar
dead.

If your ipconfig shows a working IP address, you can try pinging
the address from some other machine. This is to prove the PHY on the
NIC really is working, and it can't possibly be "unplugged".

The NIC consists of two parts. The PHY handles negotiation with the
router box, setting the transfer rate. The PHY connects to the MAC
(media access controller) via a nibble-wide bus. The two parts
are sometimes separate chips. Or, an Intel Southbridge can have the
whole thing inside. The PHY also has the fun task of driving the
low impedance load offered by the Ethernet isolation transformer.
And in the case of GbE, gets to make that whizzy 5-level waveform.

I can't think of a reason for this kind of disablement to occur.
It could somehow be tied to UEFI. It's possible to do all sorts of
stuff to UEFI, from an OS, and so developers must temper their
enthusiasm.

NICs sometimes have something called "critical data". All I know
is the name, and not how that functions.

Since power cycling seems to recover it, it could be that
the motherboard lacks a proper "reset" implementation. The
reset signal is supposed to go to the PHY. If reset stays stuck,
the two LEDs on the Ethernet connector stay in a stuck state. You
can tell by whether the Ethernet LEDs change state, that the
"PHY is moving", and it does not need to be programmed to do anything.
Thus, seeing the PHY make a change (LED state), tells you RESET
has been released.

But RESET is also good for clearing PHY state. If it were to be
in some weird state at shutdown, the RESET would clear that.

Ethernet has stuff like "HeartBeat", which presumably provides
a way to determine a peer is connected to the wire on the other
end. How is that state passed to the OS ? Dunno. But that is
potentially part of operation as well.

Normally, there wouldn't be a reason to "leave it in a mess",
as nothing needs to be done to the NIC at shutdown. If an OS
were to mess with the PHY and do something whizzy, the motherboard
RESET signal should clear that. I don't see (other than UEFI),
how state can be saved from one run to the next.

It's true that the NIC lives a "secret life" after shutdown.
You can program WOL (Wake On LAN). The MAC core can be powered
and remain running. It can signal via PME, that the magic pattern
to wake the system has been received. I would think though, that
the RESET at system start, would likely pave over any WOL state
at startup. The driver should really be programming the NIC,
the PHY autonegotiates again with the router, and all should
be well.

And you have hibernate and Fast Boot disabled on the Windows side,
which is why you're able to boot back and forth to other OSes.
This means Windows does a full boot, and does not thaw a hibernated
kernel. The difference, is the hibernated kernel does a kind of
"warm start" on the driver, but that really shouldn't be much
different from a "cold start" and a full boot.

*******

Go into MX.Linux and see if it has WOL or the equivalent of
"allow this device to wake the computer". See if this setting
can be disabled, which will prevent MX.Linux from programming
the NIC for WOL at shutdown.

Paul

[Dan Purgert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Paul
[...]
Open a Command Prompt in Windows when you're denied connectivity,
and check with ipconfig.
ipconfig
The equlvalent command in Linux is '
ifconfig

Just a note -- while "ifconfig" still works in many cases, it is being
phased out / replaced by the "ip" command (part of the "iproute2"
package), so you may get warnings these days.

The 'ip' options to get the address info are one of:

- "ip a" (short for 'ip address', shows all interfaces). OR
- "ip a l <name>" (short for 'ip address link <name>', limits to the
named interface)

HTH

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAly1tAUACgkQjhHd8xJ5
ooGjlQf+OxrnhjJXJwrfOQpzZO75AGz/AabLUqZewUHXFY8UoUmmcHOzac5igBSL
OJKUEj+j9RB6Y7EZIRdc/iyh18IMuijymIXyQezKlVPDrRZXKJXdPpXIAhWYHoRw
RTpGpwfjIHWdtJtgDP4P8/kGIpKhGzNIzlSkT3oxxljhLkqwrJSjvtNIzOpeUF42
9Es8cXF0PZFCER27oCxdbypGsFDGZCU3cme0RB5Ewhl1OPPxZuMTWfTsXewIW6Io
ukXGfBMuL9JV1LLu7ikXgXYVD8wMYp5xjXFdT1wB9/IR9Ji3+Uxg+Glyv2QLzqWI
Sopvw50gu3PK71K/UxtCJevOmF3lwA==
=g2LN
-----END PGP SIGNATURE-----

[Rene Lamontagne]

Post by Paul

Post by Rene Lamontagne

Post by Mike Easter

Post by Rene Lamontagne
It seems that it is the MX shutdown that causes the problem, If I
don't shut it down but just kill the power all is fine, when I
restart it in windows all is OK, Bot if I do a proper MX shutdown or
restart when Windows comes up I get the not connected condition

I wonder if it makes a difference if you shut down the ethernet in MX
before you do the restart.
In MX you can shut down the ethernet graphically or by command.  The
graphic icon on the taskbar in the live looks like a monitor screen
and is located between the clipit and sound/volume icons.  It has a
disconnect.

I gave it a try Mike, no luck.
I also disabled the firewall in Windows 10, that also did nothing.
I did find a way to make it work by using a completely nasty way to
shut down an OS, By hitting the reset button while in MX Linux the
system will reboot into Windows (the default) with the network intact
and running.
I am greatly surprised that Linux does not complain bitterly on this
kind of treatment, but until I find the real problem this will do.
Rene

Open a Command Prompt in Windows when you're denied connectivity,
and check with ipconfig.
   ipconfig
The equlvalent command in Linux is '
   ifconfig
In there, you can verify whether DHCP worked to acquire an IP address.
The idea here, is to see if the "network unplugged" hint occurs
despite ipconfig giving working info. Or whether ipconfig is similar
dead.
If your ipconfig shows a working IP address, you can try pinging
the address from some other machine. This is to prove the PHY on the
NIC really is working, and it can't possibly be "unplugged".
The NIC consists of two parts. The PHY handles negotiation with the
router box, setting the transfer rate. The PHY connects to the MAC
(media access controller) via a nibble-wide bus. The two parts
are sometimes separate chips. Or, an Intel Southbridge can have the
whole thing inside. The PHY also has the fun task of driving the
low impedance load offered by the Ethernet isolation transformer.
And in the case of GbE, gets to make that whizzy 5-level waveform.
I can't think of a reason for this kind of disablement to occur.
It could somehow be tied to UEFI. It's possible to do all sorts of
stuff to UEFI, from an OS, and so developers must temper their
enthusiasm.
NICs sometimes have something called "critical data". All I know
is the name, and not how that functions.
Since power cycling seems to recover it, it could be that
the motherboard lacks a proper "reset" implementation. The
reset signal is supposed to go to the PHY. If reset stays stuck,
the two LEDs on the Ethernet connector stay in a stuck state. You
can tell by whether the Ethernet LEDs change state, that the
"PHY is moving", and it does not need to be programmed to do anything.
Thus, seeing the PHY make a change (LED state), tells you RESET
has been released.
But RESET is also good for clearing PHY state. If it were to be
in some weird state at shutdown, the RESET would clear that.
Ethernet has stuff like "HeartBeat", which presumably provides
a way to determine a peer is connected to the wire on the other
end. How is that state passed to the OS ? Dunno. But that is
potentially part of operation as well.
Normally, there wouldn't be a reason to "leave it in a mess",
as nothing needs to be done to the NIC at shutdown. If an OS
were to mess with the PHY and do something whizzy, the motherboard
RESET signal should clear that. I don't see (other than UEFI),
how state can be saved from one run to the next.
It's true that the NIC lives a "secret life" after shutdown.
You can program WOL (Wake On LAN). The MAC core can be powered
and remain running. It can signal via PME, that the magic pattern
to wake the system has been received. I would think though, that
the RESET at system start, would likely pave over any WOL state
at startup. The driver should really be programming the NIC,
the PHY autonegotiates again with the router, and all should
be well.
And you have hibernate and Fast Boot disabled on the Windows side,
which is why you're able to boot back and forth to other OSes.
This means Windows does a full boot, and does not thaw a hibernated
kernel. The difference, is the hibernated kernel does a kind of
"warm start" on the driver, but that really shouldn't be much
different from a "cold start" and a full boot.
*******
Go into MX.Linux and see if it has WOL or the equivalent of
"allow this device to wake the computer". See if this setting
can be disabled, which will prevent MX.Linux from programming
the NIC for WOL at shutdown.
   Paul

Thanks Paul, I have now printed out your reply and will slowly start
going through it and trying the various suggestions, will report later.

Rene

[Diesel]

Rene Lamontagne <***@shaw.ca> news:q94pvv$tpl$***@dont-email.me
Tue, 16 Apr 2019 14:48:30 GMT in alt.os.linux, wrote:

[snip]

Post by Rene Lamontagne
Thanks Paul, I have now printed out your reply and will slowly
start going through it and trying the various suggestions, will
report later.

Argh..Listen...

either cold boot the machine always when switching OSes or restarting
the machine, OR REPLACE THE NIC CARD. It's most likely not a
compatability issue with your mainboard and the NIC card. A warm boot
is a warm boot, regardless of OS, as is a cold boot. One forces a real
reset, the other skips steps along the way.

I really don't know why some people (not you, the other poster) need to
add so much geeky, and boring for many detail for a relatively simple
troubleshooting task. Basics 101 fucking hell. Seems some people
skipped those classes.

If your NIC is getting pissy about warm vs cold reboots, just change it
out. You can get them so damn cheap now, it's not even funny.

[Rene Lamontagne]

Post by Diesel
[snip]

Post by Rene Lamontagne
Thanks Paul, I have now printed out your reply and will slowly
start going through it and trying the various suggestions, will
report later.

Argh..Listen...
either cold boot the machine always when switching OSes or restarting
the machine, OR REPLACE THE NIC CARD. It's most likely not a
compatability issue with your mainboard and the NIC card. A warm boot
is a warm boot, regardless of OS, as is a cold boot. One forces a real
reset, the other skips steps along the way.
I really don't know why some people (not you, the other poster) need to
add so much geeky, and boring for many detail for a relatively simple
troubleshooting task. Basics 101 fucking hell. Seems some people
skipped those classes.
If your NIC is getting pissy about warm vs cold reboots, just change it
out. You can get them so damn cheap now, it's not even funny.

1: I always cold boot when switching OS's.

2: the Nic is built on the MB not removable.

3: The problem has been solved by Mike Easter, It was a bug in MX Linux
switching to systemd cure it.

Rene

[Rene Lamontagne]

Post by Paul

Post by Rene Lamontagne

Post by Mike Easter

Post by Rene Lamontagne
It seems that it is the MX shutdown that causes the problem, If I
don't shut it down but just kill the power all is fine, when I
restart it in windows all is OK, Bot if I do a proper MX shutdown or
restart when Windows comes up I get the not connected condition

I wonder if it makes a difference if you shut down the ethernet in MX
before you do the restart.
In MX you can shut down the ethernet graphically or by command.  The
graphic icon on the taskbar in the live looks like a monitor screen
and is located between the clipit and sound/volume icons.  It has a
disconnect.

I gave it a try Mike, no luck.
I also disabled the firewall in Windows 10, that also did nothing.
I did find a way to make it work by using a completely nasty way to
shut down an OS, By hitting the reset button while in MX Linux the
system will reboot into Windows (the default) with the network intact
and running.
I am greatly surprised that Linux does not complain bitterly on this
kind of treatment, but until I find the real problem this will do.
Rene

Open a Command Prompt in Windows when you're denied connectivity,
and check with ipconfig.
   ipconfig
The equlvalent command in Linux is '
   ifconfig
In there, you can verify whether DHCP worked to acquire an IP address.
The idea here, is to see if the "network unplugged" hint occurs
despite ipconfig giving working info. Or whether ipconfig is similar
dead.

ipconfig shows "media disconnected"

Post by Paul
If your ipconfig shows a working IP address, you can try pinging
the address from some other machine. This is to prove the PHY on the
NIC really is working, and it can't possibly be "unplugged".
The NIC consists of two parts. The PHY handles negotiation with the
router box, setting the transfer rate. The PHY connects to the MAC
(media access controller) via a nibble-wide bus. The two parts
are sometimes separate chips. Or, an Intel Southbridge can have the
whole thing inside. The PHY also has the fun task of driving the
low impedance load offered by the Ethernet isolation transformer.
And in the case of GbE, gets to make that whizzy 5-level waveform.
I can't think of a reason for this kind of disablement to occur.
It could somehow be tied to UEFI. It's possible to do all sorts of
stuff to UEFI, from an OS, and so developers must temper their
enthusiasm.

No UEFI

Post by Paul
NICs sometimes have something called "critical data". All I know
is the name, and not how that functions.
Since power cycling seems to recover it, it could be that
the motherboard lacks a proper "reset" implementation. The
reset signal is supposed to go to the PHY. If reset stays stuck,
the two LEDs on the Ethernet connector stay in a stuck state. You
can tell by whether the Ethernet LEDs change state, that the
"PHY is moving", and it does not need to be programmed to do anything.
Thus, seeing the PHY make a change (LED state), tells you RESET
has been released.

both NIC leds off, no blinking

Post by Paul
But RESET is also good for clearing PHY state. If it were to be
in some weird state at shutdown, the RESET would clear that.
Ethernet has stuff like "HeartBeat", which presumably provides
a way to determine a peer is connected to the wire on the other
end. How is that state passed to the OS ? Dunno. But that is
potentially part of operation as well.
Normally, there wouldn't be a reason to "leave it in a mess",
as nothing needs to be done to the NIC at shutdown. If an OS
were to mess with the PHY and do something whizzy, the motherboard
RESET signal should clear that. I don't see (other than UEFI),
how state can be saved from one run to the next.
It's true that the NIC lives a "secret life" after shutdown.
You can program WOL (Wake On LAN). The MAC core can be powered
and remain running. It can signal via PME, that the magic pattern
to wake the system has been received. I would think though, that
the RESET at system start, would likely pave over any WOL state
at startup. The driver should really be programming the NIC,
the PHY autonegotiates again with the router, and all should
be well.

Both reset and power off by power button do the same

Post by Paul
And you have hibernate and Fast Boot disabled on the Windows side,
which is why you're able to boot back and forth to other OSes.
This means Windows does a full boot, and does not thaw a hibernated
kernel. The difference, is the hibernated kernel does a kind of
"warm start" on the driver, but that really shouldn't be much
different from a "cold start" and a full boot.

Both hibernate and fast boot are disabled

Post by Paul
*******
Go into MX.Linux and see if it has WOL or the equivalent of
"allow this device to wake the computer". See if this setting
can be disabled, which will prevent MX.Linux from programming
the NIC for WOL at shutdown.

In network settings, edit wired connection1 I have the wake on lan with
8 option checkboxes as follows

default
ignore
PHY
broadcast
unicast
multicast
ARP
magic

the default one was checked so I unchecked it and left them all blank,
no joy.
Then I checked ignore, still no help.

Should one of the other ones be checked? I didn't try them as I don't
know what they do.
So that is where i am at the moment.
Thanks for the time you have put in and hope the above answers may give
you some ideas.

Post by Paul
   Paul

Rene

[Paul]

Post by Rene Lamontagne
both NIC leds off, no blinking

So it's like some power has been removed from it.

Or, a separate reset signal is being sent to that
PHY-MAC thing, and preventing it from starting.

And yet initialization of the computer is not
clearing that state.

If you Google the machine name, has this pattern shown
up before ? Like, on other OSes ?

And it isn't a BIOS state change, because you can
recover from it, without changing a BIOS setting.

Paul

[Mike Easter]

Post by Paul
Or, a separate reset signal is being sent to that
PHY-MAC thing, and preventing it from starting.
And yet initialization of the computer is not
clearing that state.
If you Google the machine name, has this pattern shown
up before ? Like, on other OSes ?

For whatever it is worth, one of the things about MX is that it ships w/
systemd but has it disabled by default, so it uses sysvinit.

It is also possible to enable systemd in MX when the boot shows the grub
screen by using advanced options.

So, another experimental configuration that might resolve whether or not
some kind of init (de-init) is going wrong would be to boot MX w/
systemd working and see if the same NIC problem develops during the
restart.

[Rene Lamontagne]

Post by Paul

Post by Rene Lamontagne
both NIC leds off, no blinking

So it's like some power has been removed from it.
Or, a separate reset signal is being sent to that
PHY-MAC thing, and preventing it from starting.
And yet initialization of the computer is not
clearing that state.
If you Google the machine name, has this pattern shown
up before ? Like, on other OSes ?
And it isn't a BIOS state change, because you can
recover from it, without changing a BIOS setting.
   Paul

Its my own build so can't google for much info specs are

Asus Sabertooth X58 MB
6 GB 3 lane memory
i7 950 CPU
EVO 212 CPU cooler
ATI XD 5850 cu GPU
Corsair MX750i PS
Coolermaster 690 II case with X external hot swap bay

Hardware works Fine in both Linux and Windows.

Mike came up with a new approach using systemd I will try that next.

Rene

[Mike Easter]

Post by Rene Lamontagne
Mike came up with a new approach using systemd I will try that next.

For some reason, in my ignorance, I'm optimistic.

[Rene Lamontagne]

Post by Mike Easter

Post by Rene Lamontagne
Mike came up with a new approach using systemd I will try that next.

For some reason, in my ignorance, I'm optimistic.

HURRAY!!! you sure nailed that one Mike, Works like a charm.
I don't know anything about systemd except the few snippets I read on
the NGs but it works so I'll take it. now I don't know whats haywire in
the init thingy but I'll let you and Paul figure that out.
Now I will have to hunt up the program that lets you configure grub so
it always boots to systemd.
Many thanks to you and Paul for your great efforts, much appreciated.

Rene

[Mike Easter]

Post by Rene Lamontagne

Post by Mike Easter

Post by Rene Lamontagne
Mike came up with a new approach using systemd I will try that next.

For some reason, in my ignorance, I'm optimistic.

HURRAY!!! you sure nailed that one Mike, Works like a charm.

Good.

Post by Rene Lamontagne
I don't know anything about systemd except the few snippets I read on
the NGs but it works so I'll take it. now I don't know whats haywire in
the init thingy but I'll let you and Paul figure that out.
Now I will have to hunt up the program that lets you configure grub so
it always boots to systemd.
Many thanks to you and Paul for your great efforts, much appreciated.

Now I believe this problem is a mistake in how MX has managed its
initialization process that shows up in the restart.

I'm sure they would like to hear about this, particularly
'anticapitalista' who plays a big part in the dev of both MX and antiX.

I think that it is difficult to make a report that developers like to
read, but if you reported it into the MX forum, it would likely be
reproduced by someone who can communicate with the developers.
Presumably it is reproducible, else it won't get any attention.

The forum has pretty active participation https://forum.mxlinux.org/

I don't know where this would belong, general or hardware or software
configuration.

[Rene Lamontagne]

Post by Mike Easter

Post by Rene Lamontagne

Post by Mike Easter

Post by Rene Lamontagne
Mike came up with a new approach using systemd I will try that next.

For some reason, in my ignorance, I'm optimistic.

HURRAY!!! you sure nailed that one Mike, Works like a charm.

Good.

Post by Rene Lamontagne
I don't know anything about systemd except the few snippets I read on
the NGs but it works so I'll take it. now I don't know whats haywire
in the init thingy but I'll let you and Paul figure that out.
Now I will have to hunt up the program that lets you configure grub so
it always boots to systemd.
Many thanks to you and Paul for your great efforts, much appreciated.

Now I believe this problem is a mistake in how MX has managed its
initialization process that shows up in the restart.
I'm sure they would like to hear about this, particularly
'anticapitalista' who plays a big part in the dev of both MX and antiX.
I think that it is difficult to make a report that developers like to
read, but if you reported it into the MX forum, it would likely be
reproduced by someone who can communicate with the developers.
Presumably it is reproducible, else it won't get any attention.
The forum has pretty active participation

/

Post by Mike Easter
I don't know where this would belong, general or hardware or software
configuration.

I will try and get it on their forums and see if I get a response.
I found the grub edit software called Grub customizer and installed it,
Now it boots with systemd automatically with no intervention, So that's A1.
Any drawbacks or gotchyas using systemd? I remember some time back there
was a long thread about it but I sorta glanced over it, at the time I
was not too interested.

Rene

[Carlos E. R.]

Post by Rene Lamontagne
I will try and get it on their forums and see if I get a response.
I found the grub edit software called Grub customizer and installed it,
Now it boots with systemd automatically with no intervention, So that's A1.
Any drawbacks or gotchyas using systemd? I remember some time back there
was a long thread about it but I sorta glanced over it, at the time I
was not too interested.

If it is a distribution that is playing with the switch from init.d to
systemd, there may be issues. Or, like you have experienced, the reverse.

What you see against it is mostly /political/.

[Mike Easter]

Post by Carlos E. R.
If it is a distribution that is playing with the switch from init.d to
systemd, there may be issues. Or, like you have experienced, the reverse.
What you see against it is mostly /political/.

The MX wiki has a page in which they have positive and negative things
to say about systemd. I think the dominant sysvinit influences are
anticapitalista, Bitjam, and some other MX dev/s. It is interesting
that it is rigged to be able to run w/ or w/o systemd operating.

https://mxlinux.org/wiki/system/systemd/

There is a much more extensive systemd MX wiki page that I found helpful
here https://mxlinux.org/wiki/system/systemd-overview/

[Yossarian]

Post by Rene Lamontagne
I don't know anything about systemd except the few snippets I read on
the NGs but it works so I'll take it.

Read this
http://www.ocsmag.com/2016/10/19/systemd-progress-through-complexity/
From my experience systemd is not much understand by users so if you have
problem related to systemd there is no one to help you.

[William Unruh]

Post by Yossarian

Post by Rene Lamontagne
I don't know anything about systemd except the few snippets I read on
the NGs but it works so I'll take it.

Read this
http://www.ocsmag.com/2016/10/19/systemd-progress-through-complexity/
From my experience systemd is not much understand by users so if you have
problem related to systemd there is no one to help you.

Actually the same was true of sysVinit. I am told by some who do know
systemd that it is not hard to also add stuff to systemd.
One problem is that much of systemd has be rewritten in C. With the
scripts in sysVinit, one could, after learning bash scripting, fairly
easily hack the scripts. That is much harder if one has to hack C
or C++ source code.

Post by Yossarian
TJ

[Rene Lamontagne]

Post by William Unruh

Post by Yossarian

Post by Rene Lamontagne
I don't know anything about systemd except the few snippets I read on
the NGs but it works so I'll take it.

Read this
http://www.ocsmag.com/2016/10/19/systemd-progress-through-complexity/
From my experience systemd is not much understand by users so if you have
problem related to systemd there is no one to help you.

Actually the same was true of sysVinit. I am told by some who do know
systemd that it is not hard to also add stuff to systemd.
One problem is that much of systemd has be rewritten in C. With the
scripts in sysVinit, one could, after learning bash scripting, fairly
easily hack the scripts. That is much harder if one has to hack C
or C++ source code.

Post by Yossarian
TJ

No, I don't have any problems with systemd yet.

Rene

[Diesel]

Post by Rene Lamontagne

Post by Mike Easter

Post by Rene Lamontagne
Mike came up with a new approach using systemd I will try that next.

For some reason, in my ignorance, I'm optimistic.

HURRAY!!! you sure nailed that one Mike, Works like a charm.
I don't know anything about systemd except the few snippets I read
on the NGs but it works so I'll take it. now I don't know whats
haywire in the init thingy but I'll let you and Paul figure that
out. Now I will have to hunt up the program that lets you
configure grub so it always boots to systemd.
Many thanks to you and Paul for your great efforts, much
appreciated.

It's the warm/cold boot process. You're bandaiding the real problem and
possibly introducing more issues for yourself by opting to run systemd
to clear it. Ah well, it's your system, do whatever you want with it.
It looks great from my house. :)

[Chris Elvidge]

Post by Rene Lamontagne

Post by Paul

Post by Rene Lamontagne
both NIC leds off, no blinking

So it's like some power has been removed from it.
Or, a separate reset signal is being sent to that
PHY-MAC thing, and preventing it from starting.
And yet initialization of the computer is not
clearing that state.
If you Google the machine name, has this pattern shown
up before ? Like, on other OSes ?
And it isn't a BIOS state change, because you can
recover from it, without changing a BIOS setting.
Paul

Its my own build so can't google for much info specs are
Asus Sabertooth X58 MB
6 GB 3 lane memory
i7 950 CPU
EVO 212 CPU cooler
ATI XD 5850 cu GPU
Corsair MX750i PS
Coolermaster 690 II case with X external hot swap bay
Hardware works Fine in both Linux and Windows.
Mike came up with a new approach using systemd I will try that next.
Rene

MX is one of the most popular distros around - it's probably worth a
full reinstall /from the iso/. That is where you installed onto the USB
stick, right?

If you're going with systemd, don't use MX. MX is shimmed to make it
look like a systemd distro to systemd utils. Try a systemd based distro
- there's lots of them. Mint MATE is a good start.

For non-systemd, you could try Antix (MX is based on Antix (to an
extent)). I like it. Or go full Devuan.

[Rene Lamontagne]

Post by Chris Elvidge

Post by Rene Lamontagne

Post by Paul

Post by Rene Lamontagne
both NIC leds off, no blinking

So it's like some power has been removed from it.
Or, a separate reset signal is being sent to that
PHY-MAC thing, and preventing it from starting.
And yet initialization of the computer is not
clearing that state.
If you Google the machine name, has this pattern shown
up before ? Like, on other OSes ?
And it isn't a BIOS state change, because you can
recover from it, without changing a BIOS setting.
    Paul

Its my own build so can't google for much info specs are
Asus Sabertooth X58 MB
6 GB 3 lane memory
i7 950 CPU
EVO 212 CPU cooler
ATI XD 5850 cu GPU
Corsair MX750i PS
Coolermaster 690 II case with X external hot swap bay
Hardware works Fine in both Linux and Windows.
Mike came up with a new approach using systemd I will try that next.
Rene

MX is one of the most popular distros around - it's probably worth a
full reinstall /from the iso/. That is where you installed onto the USB
stick, right?
If you're going with systemd, don't use MX. MX is shimmed to make it
look like a systemd distro to systemd utils. Try a systemd based distro
- there's lots of them. Mint MATE is a good start.
For non-systemd, you could try Antix (MX is based on Antix (to an
extent)). I like it. Or go full Devuan.

Not knowing much about systemd I'm willing to give it a go, Maybe I'll
learn a little more about Linux.
Too many distros to choose from, I'll give MX a good go, I like it's
style and setup.

Thanks, Rene

[Paul]

Post by Rene Lamontagne

Post by Paul

Post by Rene Lamontagne
both NIC leds off, no blinking

So it's like some power has been removed from it.
Or, a separate reset signal is being sent to that
PHY-MAC thing, and preventing it from starting.
And yet initialization of the computer is not
clearing that state.
If you Google the machine name, has this pattern shown
up before ? Like, on other OSes ?
And it isn't a BIOS state change, because you can
recover from it, without changing a BIOS setting.
Paul

Its my own build so can't google for much info specs are
Asus Sabertooth X58 MB
6 GB 3 lane memory
i7 950 CPU
EVO 212 CPU cooler
ATI XD 5850 cu GPU
Corsair MX750i PS
Coolermaster 690 II case with X external hot swap bay
Hardware works Fine in both Linux and Windows.
Mike came up with a new approach using systemd I will try that next.
Rene

I tested here on my X79.

If I set WOL to "Ignore" in MX.Linux, then reboot,
the green LED goes off. There is the reset pulse,
then the "beep" at the beginning of POST. As the
BIOS is printing the disk drive list on the screen,
the green LED comes back on.

So on mine, it isn't actually the reset pulse which
establishes hardware state. The UEFI BIOS seems to be
setting things up as it likes, several seconds after
RESET is gone.

And my system passes the test. Sysvinit-reboot-Win10 has
working networking. As does SystemD-reboot-Win10.

*******

RTL-8110SC and Windows 7, similar symptoms, year 2010.

https://social.technet.microsoft.com/Forums/windows/en-US/d1b7c40e-b4fa-4720-bb84-5d38def35c78/realtek-dual-gigabit-integrated-nic?forum=w7itprohardware

And the same chip on this board, has a "never twice the same"
behavior.

https://forums.opensuse.org/showthread.php/391202

There could be some quirk in the RealTek hardware
that the driver is not picking up properly.

Search terms: 8110sc windows 10 not

Paul

[Rene Lamontagne]

Post by Paul

Post by Rene Lamontagne

Post by Paul

Post by Rene Lamontagne
both NIC leds off, no blinking

So it's like some power has been removed from it.
Or, a separate reset signal is being sent to that
PHY-MAC thing, and preventing it from starting.
And yet initialization of the computer is not
clearing that state.
If you Google the machine name, has this pattern shown
up before ? Like, on other OSes ?
And it isn't a BIOS state change, because you can
recover from it, without changing a BIOS setting.
    Paul

Its my own build so can't google for much info specs are
Asus Sabertooth X58 MB
6 GB 3 lane memory
i7 950 CPU
EVO 212 CPU cooler
ATI XD 5850 cu GPU
Corsair MX750i PS
Coolermaster 690 II case with X external hot swap bay
Hardware works Fine in both Linux and Windows.
Mike came up with a new approach using systemd I will try that next.
Rene

I tested here on my X79.
If I set WOL to "Ignore" in MX.Linux, then reboot,
the green LED goes off. There is the reset pulse,
then the "beep" at the beginning of POST. As the
BIOS is printing the disk drive list on the screen,
the green LED comes back on.
So on mine, it isn't actually the reset pulse which
establishes hardware state. The UEFI BIOS seems to be
setting things up as it likes, several seconds after
RESET is gone.
And my system passes the test. Sysvinit-reboot-Win10 has
working networking. As does SystemD-reboot-Win10.
*******
RTL-8110SC and Windows 7, similar symptoms, year 2010.
https://social.technet.microsoft.com/Forums/windows/en-US/d1b7c40e-b4fa-4720-bb84-5d38def35c78/realtek-dual-gigabit-integrated-nic?forum=w7itprohardware
And the same chip on this board, has a "never twice the same"
behavior.
https://forums.opensuse.org/showthread.php/391202
There could be some quirk in the RealTek hardware
that the driver is not picking up properly.
Search terms:  8110sc windows 10 not
   Paul

Mine is an 8167, part of the same family, in device manager under the
realtech network adapter I see many settings that are changeable, are
these set by the driver or something else? any chance of something ever
changing one to a wrong value? Just a stab in the dark.

Rene

[Paul]

Post by Rene Lamontagne
Mine is an 8167, part of the same family, in device manager under the
realtech network adapter I see many settings that are changeable, are
these set by the driver or something else? any chance of something ever
changing one to a wrong value? Just a stab in the dark.
Rene

The properties in Device Manager are established by the
driver. Each generation of NDIS is supposed to have
a different feature set. And the drivers are supposed to
offer all sorts of features in an attempt to meet NDISx.

Whether the hardware actually obeys the settings is
another matter. I have one RealTek chip here, for
PCI bus, that generates 5 interrupts per packet, and
surely that is a mistake. There is so much CPU used
to run it, that it can't do full GbE unless a CPU
core can run at over 4GHz. That particular chip also
freezes Linux, so it's a product that stays out
of computers here. I would be embarrassed to try to
re-sell those on Ebay :-)

And there aren't as many good NICs as there used to be.
The last thing I bought was an ASIX USB3 to GbE based
adapter, which plugs into a USB3 port. I couldn't find
a decent adapter locally. The problem I see with the
Intel ones this year, as they appear to interact with
Management Engine, and some PCs seem to be mistaking
an Intel card as being part of Management Engine,
and this causes various warnings on the screen.

The NICs intended for Management Engine are "dual head",
and packets can go to two destinations on the PC. One
interface is for regular networking, while the second
interface is for a running ME instance. And at least one
Intel plugin card, seems to be using one of those, instead
of the "regular" ones Intel used to make.

The lack of NICs to buy suggests "oh, it's a race to the
bottom, and that's why the quality ones left the market".
Yet, the market is not filled with these mythical hard-to-beat
ElCheapo NICs. There isn't a lot available at retail.
Sure, we used to get 8139 cards for $10 a pop, but
those were only 100BT and hardly a reason to celebrate.
But I suppose those cards were a "cautionary tale" and
scared everyone away. The 8139 has limited buffering
(something like four static buffers) and doesn't
even have buffer rings (DMA scatter gather buffers
in a ring data structure). Yet, hardly anyone notices
their $10 card isn't a champ.

I still have an 8139 here, and do use it occasionally.
But I don't have enough PCI slots any more on computers,
to be using that. There isn't room.

Paul

[Rene]

Post by Paul

Post by Rene Lamontagne
Mine is an 8167, part of the same family, in device manager under the
realtech network adapter I see many settings that are changeable, are
these set by the driver or something else? any chance of something
ever changing one to a wrong value? Just a stab in the dark.
Rene

The properties in Device Manager are established by the
driver. Each generation of NDIS is supposed to have
a different feature set. And the drivers are supposed to
offer all sorts of features in an attempt to meet NDISx.
Whether the hardware actually obeys the settings is
another matter. I have one RealTek chip here, for
PCI bus, that generates 5 interrupts per packet, and
surely that is a mistake. There is so much CPU used
to run it, that it can't do full GbE unless a CPU
core can run at over 4GHz. That particular chip also
freezes Linux, so it's a product that stays out
of computers here. I would be embarrassed to try to
re-sell those on Ebay :-)
And there aren't as many good NICs as there used to be.
The last thing I bought was an ASIX USB3 to GbE based
adapter, which plugs into a USB3 port. I couldn't find
a decent adapter locally. The problem I see with the
Intel ones this year, as they appear to interact with
Management Engine, and some PCs seem to be mistaking
an Intel card as being part of Management Engine,
and this causes various warnings on the screen.
The NICs intended for Management Engine are "dual head",
and packets can go to two destinations on the PC. One
interface is for regular networking, while the second
interface is for a running ME instance. And at least one
Intel plugin card, seems to be using one of those, instead
of the "regular" ones Intel used to make.
The lack of NICs to buy suggests "oh, it's a race to the
bottom, and that's why the quality ones left the market".
Yet, the market is not filled with these mythical hard-to-beat
ElCheapo NICs. There isn't a lot available at retail.
Sure, we used to get 8139 cards for $10 a pop, but
those were only 100BT and hardly a reason to celebrate.
But I suppose those cards were a "cautionary tale" and
scared everyone away. The 8139 has limited buffering
(something like four static buffers) and doesn't
even have buffer rings (DMA scatter gather buffers
in a ring data structure). Yet, hardly anyone notices
their $10 card isn't a champ.
I still have an 8139 here, and do use it occasionally.
But I don't have enough PCI slots any more on computers,
to be using that. There isn't room.
   Paul

Thanks for the info Paul, Guess I will leave well enough alone and
seeing it's fixed I better not break it again, It seems OK running systemd.

Rene

[Carlos E. R.]

...

Post by Rene

Post by Paul
    Paul

Thanks for the info Paul, Guess I will leave well enough alone and
seeing it's fixed I better not break it again, It seems OK running systemd.

The proper thing to do now would be to inform that distribution bug
tracking system of this problem, which is a bug actually.

Or, you can delve in and find what they do differently. There will be
an init.d script and there will be a service configuration file. Maybe
they feed different options to some driver. Although the driver itself
should autoload by the kernel. As this is something you are not familiar
with, it should be the distribution people who can investigate; or they
can try direct questions from you to look at this file or other log.

[Rene Lamontagne]

Post by Carlos E. R.
...

Post by Rene

Post by Paul
    Paul

Thanks for the info Paul, Guess I will leave well enough alone and
seeing it's fixed I better not break it again, It seems OK running systemd.

The proper thing to do now would be to inform that distribution bug
tracking system of this problem, which is a bug actually.
Or, you can delve in and find what they do differently.  There will be
an init.d script and there will be a service configuration file. Maybe
they feed different options to some driver. Although the driver itself
should autoload by the kernel. As this is something you are not familiar
with, it should be the distribution people who can investigate; or they
can try direct questions from you to look at this file or other log.

Yes, I am going to try to contact them or their forum today to see if I
can get a response.

Rene

[Rene Lamontagne]

Post by Carlos E. R.
...

Post by Rene

Post by Paul
    Paul

Thanks for the info Paul, Guess I will leave well enough alone and
seeing it's fixed I better not break it again, It seems OK running systemd.

The proper thing to do now would be to inform that distribution bug
tracking system of this problem, which is a bug actually.
Or, you can delve in and find what they do differently.  There will be
an init.d script and there will be a service configuration file. Maybe
they feed different options to some driver. Although the driver itself
should autoload by the kernel. As this is something you are not familiar
with, it should be the distribution people who can investigate; or they
can try direct questions from you to look at this file or other log.

OK, Paul, Mike and Carlos, I wrote up and sent a report to MX Linux
group which sent me to Bugzilla which seems OK, I have never used this
service before so hope it works.

Rene

[Carlos E. R.]

Post by Rene Lamontagne

Post by Mike Easter

Post by Rene Lamontagne
It seems that it is the MX shutdown that causes the problem, If I
don't shut it down but just kill the power all is fine, when I
restart it in windows all is OK, Bot if I do a proper MX shutdown or
restart when Windows comes up I get the not connected condition

I wonder if it makes a difference if you shut down the ethernet in MX
before you do the restart.
In MX you can shut down the ethernet graphically or by command.  The
graphic icon on the taskbar in the live looks like a monitor screen
and is located between the clipit and sound/volume icons.  It has a
disconnect.

I gave it a try Mike, no luck.
I also disabled the firewall in Windows 10, that also did nothing.
I did find a way to make it work by using a completely nasty way to shut
down an OS, By hitting the reset button while in MX Linux the system
will reboot into Windows (the default) with the network intact and running.
I am greatly surprised that Linux does not complain bitterly on this
kind of treatment, but until I find the real problem this will do.

Instead, you can request the system to poweroff instead of rebooting.

And check that it is a real power off, that the network card does not
remain powered for WOL, as Paul mentions.

[Rene Lamontagne]

Post by Carlos E. R.

Post by Rene Lamontagne

Post by Mike Easter

Post by Rene Lamontagne
It seems that it is the MX shutdown that causes the problem, If I
don't shut it down but just kill the power all is fine, when I
restart it in windows all is OK, Bot if I do a proper MX shutdown or
restart when Windows comes up I get the not connected condition

I wonder if it makes a difference if you shut down the ethernet in MX
before you do the restart.
In MX you can shut down the ethernet graphically or by command.  The
graphic icon on the taskbar in the live looks like a monitor screen
and is located between the clipit and sound/volume icons.  It has a
disconnect.

I gave it a try Mike, no luck.
I also disabled the firewall in Windows 10, that also did nothing.
I did find a way to make it work by using a completely nasty way to
shut down an OS, By hitting the reset button while in MX Linux the
system will reboot into Windows (the default) with the network intact
and running.
I am greatly surprised that Linux does not complain bitterly on this
kind of treatment, but until I find the real problem this will do.

Instead, you can request the system to poweroff instead of rebooting.
And check that it is a real power off, that the network card does not
remain powered for WOL, as Paul mentions.

OK, tried that with WOL not checked, no luck, same results.

Rene

[Jasen Betts]

Post by Rene Lamontagne
This morning I installed MX Linux 18.2 on a 16GB USB stick as discussed
yesterday, Then from this I installed this pristine copy to a 120GB SSD.
Everything works fine as it did on the USB stick except I seem to have
the problem when I shut down Linux and boot back into Windows 10 I loose
my network connectivity.
I have tried all kinds of fixes but nothing I do helps, The trouble
shooter message says I have an Ethernet cable not plugged but that is
not the case.
Checking on the internet on the other PC seems to point to closed Ports
or some such, I tried a brand new modem/router with no change, Even
reloaded a week old Macrium reflect backup, still no change.
If I boot back into Linux networking works fine.
On a hunch as I was in Linux using the internet I killed the system with
the power switch, no proper shutdown, I did a cold boot into windows 10
and Yes I was again properly connected.
Tried this 3 times with the same results , So something in MX linux
seems to leave the PC with a no internet condition on a proper shutdown.
I next went back to my Live USB stick and find it does not have this
problem, it leaves the network available to Windows.
I am not too versed in networking so am a bit of a loss but this does
make me think that what I read about closed ports may have validity.
Anyone better at this networking stuff might be able to feed me a few
crumbs to get me headed in the right direction.

what happens if you kill the non-working windows system using the
power switch? does it come back working?

[Rene Lamontagne]

Post by Jasen Betts

Post by Rene Lamontagne
This morning I installed MX Linux 18.2 on a 16GB USB stick as discussed
yesterday, Then from this I installed this pristine copy to a 120GB SSD.
Everything works fine as it did on the USB stick except I seem to have
the problem when I shut down Linux and boot back into Windows 10 I loose
my network connectivity.
I have tried all kinds of fixes but nothing I do helps, The trouble
shooter message says I have an Ethernet cable not plugged but that is
not the case.
Checking on the internet on the other PC seems to point to closed Ports
or some such, I tried a brand new modem/router with no change, Even
reloaded a week old Macrium reflect backup, still no change.
If I boot back into Linux networking works fine.
On a hunch as I was in Linux using the internet I killed the system with
the power switch, no proper shutdown, I did a cold boot into windows 10
and Yes I was again properly connected.
Tried this 3 times with the same results , So something in MX linux
seems to leave the PC with a no internet condition on a proper shutdown.
I next went back to my Live USB stick and find it does not have this
problem, it leaves the network available to Windows.
I am not too versed in networking so am a bit of a loss but this does
make me think that what I read about closed ports may have validity.
Anyone better at this networking stuff might be able to feed me a few
crumbs to get me headed in the right direction.

what happens if you kill the non-working windows system using the
power switch? does it come back working?

Tried that, Nope still not working.

Rene

[guest]

Post by Rene Lamontagne

Post by Rene Lamontagne
This morning I installed MX Linux 18.2 on a 16GB USB stick as
discussed yesterday, Then from this I installed this pristine copy to
a 120GB SSD.
Everything works fine as it did on the USB stick except I seem to have
the problem when I shut down Linux and boot back into Windows 10 I
loose my network connectivity.
I have tried all kinds of fixes but nothing I do helps, The trouble
shooter message says I have an Ethernet cable not plugged but that is
not the case.
Checking on the internet on the other PC seems to point to closed
Ports or some such, I tried a brand new modem/router with no change,
Even reloaded a week old Macrium reflect backup, still no change.
If I boot back into Linux networking works fine.
On a hunch as I was in Linux using the internet I killed the system
with the power switch, no proper shutdown, I did a cold boot into
windows 10 and Yes I was again properly connected.
Tried this 3 times with the same results , So something in MX linux
seems to leave the PC with a no internet condition on a proper shutdown.
I next went back to my Live USB stick and find it does not have this
problem, it leaves the network available to Windows.
I am not too versed in networking so am a bit of a loss but this does
make me think that what I read about closed ports may have validity.
Anyone better at this networking stuff might be able to feed me a few
crumbs to get me headed in the right direction.

what happens if you kill the non-working windows system using the power
switch? does it come back working?

Tried that, Nope still not working.
Rene

maybe it is a time to try a different distro?

i use pclinuxos for many years now, had on few comps with diffrent
configuration/video cards, never had problems and I hardly ever look
under the hood.

If you contact this website:

https://www.osdisc.com/index.html?affiliate=distrowatch

they will gladly make you usb stick with persistence

good luck

[Rene Lamontagne]

Post by guest

Post by Rene Lamontagne

Post by Rene Lamontagne
This morning I installed MX Linux 18.2 on a 16GB USB stick as
discussed yesterday, Then from this I installed this pristine copy to
a 120GB SSD.
Everything works fine as it did on the USB stick except I seem to have
the problem when I shut down Linux and boot back into Windows 10 I
loose my network connectivity.
I have tried all kinds of fixes but nothing I do helps, The trouble
shooter message says I have an Ethernet cable not plugged but that is
not the case.
Checking on the internet on the other PC seems to point to closed
Ports or some such, I tried a brand new modem/router with no change,
Even reloaded a week old Macrium reflect backup, still no change.
If I boot back into Linux networking works fine.
On a hunch as I was in Linux using the internet I killed the system
with the power switch, no proper shutdown, I did a cold boot into
windows 10 and Yes I was again properly connected.
Tried this 3 times with the same results , So something in MX linux
seems to leave the PC with a no internet condition on a proper shutdown.
I next went back to my Live USB stick and find it does not have this
problem, it leaves the network available to Windows.
I am not too versed in networking so am a bit of a loss but this does
make me think that what I read about closed ports may have validity.
Anyone better at this networking stuff might be able to feed me a few
crumbs to get me headed in the right direction.

what happens if you kill the non-working windows system using the power
switch? does it come back working?

Tried that, Nope still not working.
Rene

maybe it is a time to try a different distro?
i use pclinuxos for many years now, had on few comps with diffrent
configuration/video cards, never had problems and I hardly ever look
under the hood.
https://www.osdisc.com/index.html?affiliate=distrowatch
they will gladly make you usb stick with persistence
good luck
Thanks Quest, I,m sure your distro is great also and I appreciate the

offer, But Mike Easter just solved my only problem and I have MX Linux
installed on a 120 GB SSD and it works great and I like it so will stick
with it.

Rene

[Gordon]

Post by Rene Lamontagne

Post by guest
Thanks Quest, I,m sure your distro is great also and I appreciate the

offer, But Mike Easter just solved my only problem and I have MX Linux
installed on a 120 GB SSD and it works great and I like it so will stick
with it.

Okay, that is great ,but would you mind sharing what the cure was? Thanks.

MX Linux has gained traction and will be at the top od distrowatch pretty
soon, and for good reason. It works as an OS should. This does not mean that
other distros do not, but rather that another of Ms Peguin's offspring has
come to the table to offer more choice for us.

[Rene Lamontagne]

Post by Gordon

Post by Rene Lamontagne

Post by guest
Thanks Quest, I,m sure your distro is great also and I appreciate the

offer, But Mike Easter just solved my only problem and I have MX Linux
installed on a 120 GB SSD and it works great and I like it so will stick
with it.

Okay, that is great ,but would you mind sharing what the cure was? Thanks.
MX Linux has gained traction and will be at the top od distrowatch pretty
soon, and for good reason. It works as an OS should. This does not mean that
other distros do not, but rather that another of Ms Peguin's offspring has
come to the table to offer more choice for us.

For sure I would like to share, It indeed was not very clear in all the
back and forth posts.

Mike Easter was the author of the fix, so credit goes to him.
His suggestion was to wait for the Grub screen then choose the advanced
option, then from there choose the option that boots with "systemd'
and let MX boot with that option, I followed that advice and the problem
is solved.

I have also sent a bug report to MX Linux on Bugzilla,

that is the only glitch I have encountered so far, everything works
great, Network, Sound, Video, Printer, scanner etc, so its a keeper.
Yes, I also have Mint Cinnamon 19.1 and Xenialpup 7.5 which work very
well and are in my keepers set.

[Mike Easter]

Post by Rene Lamontagne
His suggestion was to wait for the Grub screen then choose the advanced
option, then from there choose the option that boots with "systemd'
and let MX boot with that option, I followed that advice and the problem
is solved.

But, we don't know *why* yet :-)

But, it gives us a chance to think/wonder about what goes on during the
initialization of the NIC in a distro based on Debian stable when it
uses sysvinit vs systemd that would cause the restart sequence to be
'different' in some way. To have a different result.

How does MX adapt its sysvinit choice from the vanilla stable Deb?

[Rene Lamontagne]

Post by Mike Easter

Post by Rene Lamontagne
His suggestion was to wait for the Grub screen then choose the
advanced option, then from there choose the option that boots with
"systemd'
and let MX boot with that option, I followed that advice and the
problem is solved.

But, we don't know *why* yet :-)
But, it gives us a chance to think/wonder about what goes on during the
initialization of the NIC in a distro based on Debian stable when it
uses sysvinit vs systemd that would cause the restart sequence to be
'different' in some way.  To have a different result.
How does MX adapt its sysvinit choice from the vanilla stable Deb?

Solving the problem is far beyond my payscale, MX Linux group are more
likely to do it, Or guys like You or Paul might be able to figure it
out. :-)

Rene

[guest]

Post by Gordon

Post by Rene Lamontagne

Post by guest
Thanks Quest, I,m sure your distro is great also and I appreciate the

offer, But Mike Easter just solved my only problem and I have MX Linux
installed on a 120 GB SSD and it works great and I like it so will
stick with it.

Okay, that is great ,but would you mind sharing what the cure was? Thanks.
MX Linux has gained traction and will be at the top od distrowatch
pretty soon, and for good reason. It works as an OS should. This does
not mean that other distros do not, but rather that another of Ms
Peguin's offspring has come to the table to offer more choice for us.

distro at the top of that least means many people were looking at the
link(!) to the description of such distro

not that it was downloaded, installed or that it works good

just another "statistics"