Bionic64 Pup Killed XP's Ethernet
Bionic64 Pup Killed XP's Ethernet
I decided to install Bionic on my work PC.
This PC's job is mostly just to receive backups of files from the work computers, so I figured I could dual boot Bionic with XP, keeping XP if I ever need it (which I will due to specific software).
I used LICK to install Bionic, all went smoothly except Bionic didn't automatically connect to the eth0 connection upon boot, as puppy usually does. Did a SNS DHCP, connected no problems.
Rebooted Windows and it will not connect to the ethernet. It says the cable is unplugged. I double checked that, it isn't. Rebooted into Bionic, connects straight away.
Interesting notes:
The IP address in Bionic is different to what XP was. In my experience, the IP address stays the same for the same hardware despite the OS. Is that the same of other people?
Doing a backup to Bionic from another Puppy computer is much faster than in XP (probably irrelevant info, but shows that Puppy is awesome)
This PC's job is mostly just to receive backups of files from the work computers, so I figured I could dual boot Bionic with XP, keeping XP if I ever need it (which I will due to specific software).
I used LICK to install Bionic, all went smoothly except Bionic didn't automatically connect to the eth0 connection upon boot, as puppy usually does. Did a SNS DHCP, connected no problems.
Rebooted Windows and it will not connect to the ethernet. It says the cable is unplugged. I double checked that, it isn't. Rebooted into Bionic, connects straight away.
Interesting notes:
The IP address in Bionic is different to what XP was. In my experience, the IP address stays the same for the same hardware despite the OS. Is that the same of other people?
Doing a backup to Bionic from another Puppy computer is much faster than in XP (probably irrelevant info, but shows that Puppy is awesome)
Re: Bionic64 Pup Killed XP's Ethernet
Have you done a full power-down-cold-boot to let the hardware reset?p310don wrote:Rebooted Windows
try adding this line to the boot parameters net.ifnames=0
here is an example:
I am wondering if booting into Bionic64 is renaming the network adapter and that is effecting XP during it's start up.
here is an example:
Code: Select all
title Bionic64 (uuid/Bionic64)
find --set-root uuid () 13ec514b-7e2d-43e1-b18e-ed4daceba563
kernel /Bionic64/vmlinuz pdrv=13ec514b-7e2d-43e1-b18e-ed4daceba563 psubdir=/Bionic64 net.ifnames=0 pmedia=atahd pfix=fsck
initrd /Bionic64/initrd.gz
Look for the file lickgrub.cfg. I think LICK uses grub2, so you'd better get started learning grub2 syntax
As for the XP problem - I would have thought that a cold reboot would've fixed it.
As for the XP problem - I would have thought that a cold reboot would've fixed it.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
I have tried disabling the network in the BIOS and starting windows. It doesn't see the network. Then turned it off and on again re-enabled the network. Still it reports that the cable is unplugged.
Further things for me to try
Plug the ethernet cable into a different port on the modem.
Reboot the modem.
Find a spare PCI network card that I'm sure I have somewhere, and use that.
worst case - clone the XP hard drive, convert it to a VDI, and then use that whenever I need to run the windows software. Not sure if I can re-activate XP these days however
Further things for me to try
Plug the ethernet cable into a different port on the modem.
Reboot the modem.
Find a spare PCI network card that I'm sure I have somewhere, and use that.
worst case - clone the XP hard drive, convert it to a VDI, and then use that whenever I need to run the windows software. Not sure if I can re-activate XP these days however
LICK uses grub4dos actually. I am glad, GRUB2 is one of the reasons I left Ubuntu, too hard. I like simple stuff.Look for the file lickgrub.cfg. I think LICK uses grub2, so you'd better get started learning grub2 syntax Very Happy
As for the XP problem - I would have thought that a cold reboot would've fixed it.
I am at home now, so can't check it, but I think the file is lick.lst something like that. Editing it with rockedge's suggestion didn't work.
Rebooting the modem does not work - in fact it created a new issue. Upon reboot, it fails to connect automatically, so back through the DHCP process, and another different IP address gets assigned, which mucks up my back up script from my other Puppy PC.
Maybe fiddling isn't doing me any favours.
Of interest, perhaps a clue. The green light on the back of the modem that indicates that something is plugged into it is not on when I boot into XP, nor was it on when I booted in Puppy before DHCPing. It is on when I am connected in Puppy.
Maybe fiddling isn't doing me any favours.
Of interest, perhaps a clue. The green light on the back of the modem that indicates that something is plugged into it is not on when I boot into XP, nor was it on when I booted in Puppy before DHCPing. It is on when I am connected in Puppy.
HMMMM - maybe the modem light is more of a clue.
If I disconnect from the network in Bionic, the light goes out, even though the cable is still plugged in. This tells me (I'm guessing) that the eth0 port is actually being turned off by Bionic, rather than just not used.
I have used this PC with Puppy in the past, 4.31 actually, and never had an issue. So my new question is does Bionic interact with the NIC differently to older pups? ie, does it physically disable the port when not in use?
If I disconnect from the network in Bionic, the light goes out, even though the cable is still plugged in. This tells me (I'm guessing) that the eth0 port is actually being turned off by Bionic, rather than just not used.
I have used this PC with Puppy in the past, 4.31 actually, and never had an issue. So my new question is does Bionic interact with the NIC differently to older pups? ie, does it physically disable the port when not in use?
SOLVED - kinda
Solved the problem, but I don't know why it happened.
I did some serious digging and found the CD of 4.30 that I had, booted using that. Clicked on connect, it used the OLD Puppy connect procedure of checking for a live network connection first (modem light was on now) and then get Auto DHCP, which gave me the IP address that windows used originally.
Checked to make sure it worked. Seamonkey version 2 (I think) still loads google, albeit very basic version of.
Then rebooted the machine, the modem light stayed on, which is exciting. Booted XP, and it connects to the 'net no problems.
Conclusion - the title is correct, Bionic64 is killing the ethernet, when it shuts down.
Solved the problem, but I don't know why it happened.
I did some serious digging and found the CD of 4.30 that I had, booted using that. Clicked on connect, it used the OLD Puppy connect procedure of checking for a live network connection first (modem light was on now) and then get Auto DHCP, which gave me the IP address that windows used originally.
Checked to make sure it worked. Seamonkey version 2 (I think) still loads google, albeit very basic version of.
Then rebooted the machine, the modem light stayed on, which is exciting. Booted XP, and it connects to the 'net no problems.
Conclusion - the title is correct, Bionic64 is killing the ethernet, when it shuts down.
I can't help but to fiddle. Booted into Fatdog 8.0 today to test. It connects automatically to the ethernet, and turns off the port on shut down, just like Bionic. This makes me think it might be kernel related..?
Interestingly, after booting Fatdog, I booted 4.3 to reset the network, and it couldn't see the adaptor at all. I booted into Slacko 5.7 which did see it, then shut down, restarted in XP and it worked properly again.
Booting into Fatdog or Bionic doesn't have a problem in themselves, only when I want to start one of the older OSes.
Interestingly, after booting Fatdog, I booted 4.3 to reset the network, and it couldn't see the adaptor at all. I booted into Slacko 5.7 which did see it, then shut down, restarted in XP and it worked properly again.
Booting into Fatdog or Bionic doesn't have a problem in themselves, only when I want to start one of the older OSes.
Yes, I have that identical issue, except for wifi hardware, when I run Slitaz (not sure if Tazpup has same effect on my machine. Very painful since I enjoy playing with Slitaz.p310don wrote:Conclusion - the title is correct, Bionic64 is killing the ethernet, when it shuts down.
Sometimes an
rfkill unblock all
command frees similar things up for me (but not for my Slitaz issue sadly)
I usually resort to similar workaround - booting an old Puppy, Win 7, XP, or something, but there are cases where that won't work for me either (maybe after Slitaz actually) - then I enter the BIOS and reset BIOS to its 'default setting' which always makes wifi card available for me again.
I also have no idea how my wifi hardware can be getting so absolutely turned-off that even rfkill won't bring it back to life (but maybe BIOS reset clears corrupted device registers or something, but I don't know).
wiak
WeeDogLinux forum: https://weedoglinux.rockedge.org/viewforum.php?f=4
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
p310don - output of lspci and lsmod? (assuming the network card is a "card" and not USB dongles etc).
That will help to identify the offending network card/driver and see are common thread about this problem.
That will help to identify the offending network card/driver and see are common thread about this problem.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
jamesbond asked
lspci:
lsmod
It is the onboard network adaptor for P5PL2 Asus motherboard.output of lspci and lsmod
lspci:
Code: Select all
00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port (rev 02)
00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 01)
00:1c.3 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 4 (rev 01)
00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 01)
00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 01)
00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 01)
00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 01)
00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 IDE interface: Intel Corporation NM10/ICH7 Family SATA Controller [IDE mode] (rev 01)
00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 01)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
04:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1)
04:00.1 Audio device: NVIDIA Corporation GF119 HDMI Audio Controller (rev a1)
Code: Select all
Module Size Used by
iptable_filter 16384 0
ip_tables 24576 1 iptable_filter
cfg80211 270336 0
rfkill 20480 1 cfg80211
nouveau 1699840 5
snd_hda_codec_analog 16384 1
snd_hda_codec_hdmi 45056 1
snd_hda_codec_generic 65536 1 snd_hda_codec_analog
mxm_wmi 16384 1 nouveau
wmi 20480 2 mxm_wmi,nouveau
i2c_algo_bit 16384 1 nouveau
ttm 81920 1 nouveau
drm_kms_helper 131072 1 nouveau
syscopyarea 16384 1 drm_kms_helper
sysfillrect 16384 1 drm_kms_helper
sysimgblt 16384 1 drm_kms_helper
fb_sys_fops 16384 1 drm_kms_helper
pcspkr 16384 0
snd_hda_intel 28672 0
snd_hda_codec 90112 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_analog
snd_hda_core 49152 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_analog,snd_hda_codec
drm 331776 8 drm_kms_helper,ttm,nouveau
snd_pcm_oss 45056 0
snd_mixer_oss 24576 1 snd_pcm_oss
r8169 73728 0
snd_pcm 77824 5 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_hda_core
input_leds 16384 0
realtek 20480 1
snd_seq_dummy 16384 0
i2c_i801 28672 0
libphy 40960 2 r8169,realtek
snd_seq_oss 36864 0
snd_seq_midi 16384 0
snd_seq_midi_event 16384 2 snd_seq_midi,snd_seq_oss
snd_rawmidi 24576 1 snd_seq_midi
lpc_ich 24576 0
snd_seq 45056 6 snd_seq_midi,snd_seq_oss,snd_seq_midi_event,snd_seq_dummy
snd_seq_device 16384 4 snd_seq,snd_seq_midi,snd_seq_oss,snd_rawmidi
snd_timer 28672 2 snd_seq,snd_pcm
snd 65536 13 snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_seq_oss,snd_hda_intel,snd_hda_codec_analog,snd_hda_codec,snd_timer,snd_pcm_oss,snd_pcm,snd_rawmidi,snd_mixer_oss
soundcore 16384 1 snd
floppy 69632 0
parport_pc 32768 0
parport 40960 1 parport_pc
asus_atk0110 20480 0
hwmon 16384 2 asus_atk0110,nouveau
pcc_cpufreq 16384 0
Hmmm, from your lspci your NIC is this: RTL8111/8168/8411
And a few lookups shows that the most common problem with this NIC is wake-on-lan (it's either ON when it shouldn't be, or vice versa). This is my guess: when the newer kernels shutdown, the wake-on-lan feature is also turned off; and Windows XP probably expects that the WOL feature is on (=the card is already turned ON when Windows starts) so it doesn't bother to turn it on.
Arch Wiki has something to say about it: https://wiki.archlinux.org/index.php/Ne ... OL_problem, although your problem seems to be the opposite. Anyway, go to that option in Windows and toggle it, and see if it makes a difference.
If your BIOS has a Wake-On-Lan settings, you may want to toggle that settings (or simply turn it on first). On the second thought, perhaps it's safer to change the BIOS settings first if it exist before changing the Windows driver configuration.
And a few lookups shows that the most common problem with this NIC is wake-on-lan (it's either ON when it shouldn't be, or vice versa). This is my guess: when the newer kernels shutdown, the wake-on-lan feature is also turned off; and Windows XP probably expects that the WOL feature is on (=the card is already turned ON when Windows starts) so it doesn't bother to turn it on.
Arch Wiki has something to say about it: https://wiki.archlinux.org/index.php/Ne ... OL_problem, although your problem seems to be the opposite. Anyway, go to that option in Windows and toggle it, and see if it makes a difference.
If your BIOS has a Wake-On-Lan settings, you may want to toggle that settings (or simply turn it on first). On the second thought, perhaps it's safer to change the BIOS settings first if it exist before changing the Windows driver configuration.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
-
- Posts: 18
- Joined: Sun 12 Nov 2017, 23:42
You misunderstand what Wake on Lan is.
WOL is there so that a machine can be powered up and the OS loaded.
It can then be put to SLEEP so that minimal activity takes place.
If there is then some activity on the network, the machine will wake up to process it.
It does not matter what Os is running, It is a hardware function.
This feature was designed so that a machine could be remotely activated over the network for support purposes.
WOL is there so that a machine can be powered up and the OS loaded.
It can then be put to SLEEP so that minimal activity takes place.
If there is then some activity on the network, the machine will wake up to process it.
It does not matter what Os is running, It is a hardware function.
This feature was designed so that a machine could be remotely activated over the network for support purposes.
"Just think of it as leaving early to avoid the rush" - T Pratchett