Linux to Linux boots stop ethernet from connecting

[redandwhitestripes]

Hi fellow Puppy peeps,

I'm running Fossa Puppy on a frugal install alongside Windows 10 and Linux Mint on a 64 bit desktop PC. I also often boot Batocera Linux or a puppy variant from USB. Safe boot is disabled on my machine and legacy boot is enabled.

TLDR: Any live Linux booting into another Linux without poweroff makes my Ethernet unusable. Can anyone offer a script or other solution that may work? Anyone else had the same issue?

I recently posted on the Fossa thread about Fossa not connecting to my ethernet. It took me a while to realise the problem was not Fossa but a well-known bug that stops Linux connecting by ethernet after a reboot from Windows on a dual boot machine. The issue seems to be something to do with Windows claiming control of a MAC address and not releasing it on a reboot. The solutions on offer varied but the most popular was to disable all 'wake on LAN' and other power management options for the ethernet controller inside Windows. This seems to be working for me.

However, I still have the same problem with the ethernet refusing to connect in any version Linux after rebooting from a live run of any Linux. Even Linux Mint to Batocera or puppy live booting into puppy frugal, for example. Is this likely to be a similar issue with a MAC address problem? If so, is there any simple script that could fix it?

Any help, yet again, very appreciated.

[bigpup]

Do you have a specific boot loader that gives you a list of what OS to choose to boot?

I boot multiple Puppy versions installed on a hard drive.
I have a boot loader with entries to boot each one.
If I am running a specific Puppy version.
Choose reboot.
This Puppy version does a complete normal shutdown.
Triggers a boot up.
The computer boots up to the boot loader menu.
I choose a different Puppy to boot.

I am using wired Ethernet connection.
Never have a problem having Ethernet auto connect using the stored setup in each Puppy version.

I think your problem is you are not completely releasing OS control without doing a full shutdown.
These other Linux OS's may not be completely shutting down all operations, to do a reboot.

[rcrsn51]

Please identify the driver for your ethernet card, like r8169.

[Jafadmin]

A test you can try to help us analyze the problem: Boot to a LiveCD and connect to the network and test that it works. Then tell the LiveCD session to disable networking via the network tool. Then reboot.

Tell us if it still messes up.

[redandwhitestripes]

Do you have a specific boot loader that gives you a list of what OS to choose to boot?

I boot multiple Puppy versions installed on a hard drive.
I have a boot loader with entries to boot each one.
If I am running a specific Puppy version.
Choose reboot.
This Puppy version does a complete normal shutdown.
Triggers a boot up.
The computer boots up to the boot loader menu.
I choose a different Puppy to boot.

I am using wired Ethernet connection.
Never have a problem having Ethernet auto connect using the stored setup in each Puppy version.

I think your problem is you are not completely releasing OS control without doing a full shutdown.
These other Linux OS's may not be completely shutting down all operations, to do a reboot.

Hi Bigpup, rcrsn51 and Jafadmin. My device (according to Windows 10 which I'm using now as I'm working) is Realtek PCIe GBE Family Controller #5. I'm using Grub2 bootloader but as mentioned I also sometimes boot Puppy from Clarity's multiple USB boot tool and Batocera from a separate USB. They all seem to have the same effect. I'm surprised nobody else is having the same issue. I will try disabling the network and rebooting, then report back.

[bigpup]

Anytime you use Windows 10.
Shutdown with a normal full shutdown.
Do not shutdown in hibernate.
Hibernate does not fully release control of the computer from Windows 10.

[redandwhitestripes]

So I couldn't simply disconnect from the network as right-clicking on the network icon doesn't work for me (I've had this problem with Puppy before on other system so I'm sure this is just bad luck). Therefore I opened ICW and Frisbee, without actually changing or selecting anything, causing Puppy to disconnect.

I then did a soft reboot, after which Puppy shows a connected icon but actually there is no working connection, no page will load. A hard reboot or a reboot after running windows fixes this.

[Clarity]

Hi @redandwhitestripes. A guess. You need a firmware update for that problem.

I have similar on 2 old PCs I have which REQUIRE a power-off before reboots.

But firmware is no longer available from manufacturers for them in my case. To get the latest, you could buy the updates from 1-2 websites who specialize is selling old firmware updates from major manufacturers. I dont remember which off-hand.

I am not aware of software that overcomes firmware problems.

[rockedge]

What might be happening is the ethernet card is not being named correctly for Puppy Linux at the boot up. Can you test out adding the line net.ifnames=0 to the kernel command line? That will insure that the ethernet device is named eth0. Something like in this example:

Code: Select all

title Bionic64-v8 (sda4/Bionic64-v8)
find --set-root uuid () acc8a5ba-3340-43e8-9d4c-b09ef6b299d1
  kernel /Bionic64-v8/vmlinuz  pdrv=acc8a5ba-3340-43e8-9d4c-b09ef6b299d1  psubdir=/Bionic64-v8 pmedia=atahd pfix=fsck net.ifnames=0
  initrd /Bionic64-v8/initrd.gz 

[mikewalsh]

What might be happening is the ethernet card is not being named correctly for Puppy Linux at the boot up. Can you test out adding the line net.ifnames=0 to the kernel command line? That will insure that the ethernet device is named eth0. Something like in this example:

Code: Select all

title Bionic64-v8 (sda4/Bionic64-v8)
find --set-root uuid () acc8a5ba-3340-43e8-9d4c-b09ef6b299d1
  kernel /Bionic64-v8/vmlinuz  pdrv=acc8a5ba-3340-43e8-9d4c-b09ef6b299d1  psubdir=/Bionic64-v8 pmedia=atahd pfix=fsck net.ifnames=0
  initrd /Bionic64-v8/initrd.gz 

Yep, that's entirely possible.

AFAIK, this whole business of

Code: Select all

net.ifnames

...came in with Ubuntu 18.04 (Bionic). I've never had this issue with 64-bit Bionic - one of my current "daily drivers" - but I DID have the problem back on the old Compaq tower when I played around with Bionicpup32 for a few months.

It's not necessarily the cause here, but it's easily fixed as rockedge shows above.

I do have something similar going on, though.

-----------------------------------

I run four 64-bitzers:-

• Xenialpup64

• Bionicpup64

• Fossapup64, and

• jrb's 'lite' spin on BK's Quirky64 'April' 7.0.1

....and two 32-bitzers:-

• Xenialpup 7.5

• Slacko 5.7.1 (by Sailor Enceladus)

Re-booting between the 64-bitzers is straight-forward, and ethernet re-connects every time. Re-booting from Slacko 5.7.1 to any of the 64-bit Pups, no problem. Re-booting from Xenial32 into Xenial64, Bionic64 or Fossa64, fine. But re-booting from Xenial32 into Quirky 64, ethernet connects, but.....there's "NO connection" (if you know what I mean.)

It's only this particular re-boot that ever gives problems. DHCP assigns one of those weird IPs that isn't actually a proper IP, ie, "192.168.xxx.xxx", so naturally, it's not REALLY 'connected'.

I get round the issue by a 60-second 'power-cycle' if I do this particular re-boot. This completely clears RAM because it drains the power-caps, thus no residual current 'holding' data in RAM. But it IS weird why ONLY this particular operation generates the issue, because booting into anything else from Xenial32 doesn't cause it!

So; the OP isn't the only one who has issues like this. I half wonder if my boot entries cause this, since they're a somewhat modified variant on the 'standard' boot-entry. They DO work, though.....so there can't be too much wrong.

(menu.lst is as follows:-)

Code: Select all

# menu.lst produced by grub4dosconfig-v1.9.3
color white/blue black/cyan white/black cyan/black
splashimage=/splash.xpm
timeout 20
default 0

# Frugal installed Puppy

title Bionicpup64 8.0 (sda2/Bionicpup64)
  find --set-root uuid () 0ee0f8be-07f3-4e5b-b3c3-2554fae39a3e
  kernel /Bionicpup64/vmlinuz  pdrv=0ee0f8be-07f3-4e5b-b3c3-2554fae39a3e  psubdir=/Bionicpup64 pmedia=atahd pfix=fsckp
  initrd /Bionicpup64/initrd.gz

title Fossapup 64 9.5 (sda2/Fossapup64)
  find --set-root uuid () 0ee0f8be-07f3-4e5b-b3c3-2554fae39a3e
  kernel /Fossapup64/vmlinuz  pdrv=0ee0f8be-07f3-4e5b-b3c3-2554fae39a3e  psubdir=/Fossapup64 pmedia=atahd pfix=fsckp
  initrd /Fossapup64/initrd.gz  
  
title Quirky April 64 'lite' (sda2/Quirky7_64_lite)
  find --set-root uuid () 0ee0f8be-07f3-4e5b-b3c3-2554fae39a3e
  kernel /Quirky7_64_lite/vmlinuz  pdrv=0ee0f8be-07f3-4e5b-b3c3-2554fae39a3e  psubdir=/Quirky7_64_lite pmedia=atahd pfix=fsckp
  initrd /Quirky7_64_lite/initrd.gz

title Xenialpup 64 7.5 (sda2/Xenialpup64)
  find --set-root uuid () 0ee0f8be-07f3-4e5b-b3c3-2554fae39a3e
  kernel /Xenialpup64/vmlinuz  pdrv=0ee0f8be-07f3-4e5b-b3c3-2554fae39a3e  psubdir=/Xenialpup64 pmedia=atahd pfix=fsckp
  initrd /Xenialpup64/initrd.gz

title Slacko 5.7.1 (sda2/Slacko_571)
  find --set-root uuid () 0ee0f8be-07f3-4e5b-b3c3-2554fae39a3e
  kernel /Slacko_571/vmlinuz  pdrv=0ee0f8be-07f3-4e5b-b3c3-2554fae39a3e  psubdir=/Slacko_571 pmedia=atahd pfix=fsckp
  initrd /Slacko_571/initrd.gz

title Xenialpup (sda2/Xenial32)
  find --set-root uuid () 0ee0f8be-07f3-4e5b-b3c3-2554fae39a3e
  kernel /Xenial32/vmlinuz  pdrv=0ee0f8be-07f3-4e5b-b3c3-2554fae39a3e  psubdir=/Xenial32 pmedia=atahd pfix=fsckp
  initrd /Xenial32/initrd.gz
  
# Windows
# this entry searches Windows on the HDD and boot it up
title Windows\nBoot up Windows if installed
  errorcheck off
  find --set-root --ignore-floppies --ignore-cd  /bootmgr
  chainloader /bootmgr
  find --set-root --ignore-floppies --ignore-cd  /ntldr
  chainloader /ntldr
  find --set-root --ignore-floppies --ignore-cd   /io.sys
  chainloader /io.sys
  errorcheck on

# Advanced Menu
title Advanced menu
  configfile /menu-advanced.lst
  commandline

BK used the "Quirky" series as an experimental test-bed, and I really don't know quite what jrb did when he re-built/re-mastered this one....

{*shrug...*)

I've found MY "fix", so I'm sorted.

Mike.

[redandwhitestripes]

Thanks for the responses from everyone. I'm starting to think I'll just have to live with it since there seems to be no way around it. AFAICT the the drive is still assigned the name eth0 at each boot. That said, one long-shot solution I'm looking in to is assigning a different, cloned MAC address to the ethernet for each Linux boot, if I can work out how to do it.

[williams2]

assigning a different, cloned MAC address

You can install and use macchanger, using the Puppy Package Manager ppm,
or from, for example, https://pkgs.org/download/macchanger

You would set the network down, run macchanger, then set the network up.

For example, for network interface wlan0:

rfkill block wlan
macchanger -A wlan0
rfkill unblock wlan

This would set the mac address to a valid vendor name with a random mac address.

Read the man page, for example, http://manpages.ubuntu.com/manpages/xen ... ger.1.html

Or you can use the ip command.