@prehistoric:
Thanks for the book recommendation. I'll check it out.
In order to follow your instructions I had to delete not just 70-persistent-net.rules, but also 80-oldpersistent-net.rules. To avoid problems from doing this from a running system, I booted into tahrpup64 6.0.6 and deleted the files in the inactive Fatdog 710 save folder "/etc/udev/rules.d". When I rebooted, the wired network was reconfigured as eth0. I didn't have to tell it to use DHCP, it just came up working.
It is safe to do so from running Fatdog. You just need to reboot afterwards.
Even without deleting those stuff, you should already get DHCP. The fact that you don't, is curious.
I have an inkling of what happens, but I will need to do further checks.
Btw I'm not sure where you get that "80-oldpersistent-net.rules" from.
I'm still not clear on what the damn Network Wizard is telling me. What difference does it make if an interface is "associated" or "activated" if it is impossible to send network traffic across it?
"Assosciated" is for Wifi only. It means the wifi adapter has connected to the wifi router.
"Activated" is for Network Setup only - it means that the network configuration chosen has been activated.
There are many other reasons why the network fails to connect.
---
"Associated" but no IP address (DHCP fails) => no connection.
"Activated" with static IP address but wrong IP range => no connection
IP good but router bad ==> can only ping to router, but not to Internet, etc.
How can I tell if the system does or does not have a kernel module for the interface device?
No network interface will show up.
Suppose everything in Fatdog is correct, but the device on the other end of the line is having trouble with DHCP. How do you isolate the problem? These are not hypothetical concerns, I've been there.
The usual tools. Ping, etc. How do you detect if your network cable has a kink which sometimes connect and sometimes not (assuming you don't have network cable tracer)?
To avoid ticking off any number of people who do not spend all their free time solving puzzles please consider at least a button that resets everything to do with networking. It should not even require a reboot.
Yes, that's a good idea. Suggestion is being considered.
@Sage:
Wondering how general this fix is for other distros? I occasionally find a phantom network show up. I think it can happen if I install on e.g. a machine with a wifi connection and then transfer the HD to a machine with a wired NIC. Can dynamically delete one of the alleged connections but it's never persistent.
It is general in its idea, but not necessarily in the details. See:
https://www.freedesktop.org/wiki/Softwa ... faceNames/
Different version of udev/systemd requires different names for disabling certain stuff.
In eudev it is 80-net-name-slot.rules. Or you can use net.ifnames=0 on boot parameter.
But only when compiled in a certain way.
Deleting 70-persistent-net.rules is another way, when compiled with rule generator.
I'm confusing you, aren't I?
@disciple:
I followed the instructions to install to a usb stick and use fix-usb.sh*
That's the quick install method, yes.
I used the remaining space on the drive to create a VFAT partition.
This is so we still use the remaining space.
But it turns out "Windows... won't recognize more than one partition on a USB drive unless it has a certain bit set declaring it a USB-HDD".
In fact, this is a good way to hide data from Windows
I'm a bit lost on why this install method works the way it does though. Why not just have one filesystem on the USB stick? Is it a necessary consequence of trying to just use an iso image?
This is because the "image" is an triple-hybrid ISO image.
1. It's an ISO, and will boot when burned to a CD/DVD.
2. It's a harddisk image, with MBR. The MBR has 2 partitions:
a) 1st partition representing the ISO itself. Used for booting on BIOS systems
b) 2nd partition represents the efiboot.img, containing UEFI boot files.
*Incidentally, the first time around the stick wasn't bootable, so, wondering if there was a step missing from the instructions, I erased it, used Gparted to create a new partition and make that bootable, then started again. This seemed to work.
Really? If you dd-it straight away, it should work.
Anyway, if you want to create a USB that can share data with Windows, there are a few ways you can do that:
a) Create one big FAT32 partition covering the whole drive.
b) Create first FAT32 partition which you can use to share data with Windows, and create a 2nd partition where you install Fatdog.
@LateAdopter: thanks for the additional information.
@_gg:
I think it's some bug as fdisk doesn't see it properly as original:
That's definitely a bug. It could be that your're running out of space when creating the remaster?
Also, I see that your remaster is 547M in size. If you use UEFI, this **WILL NOT WORK** due to a silly bug:
http://www.murga-linux.com/puppy/viewtopic.php?t=109891.
1) when wired cable is replugged, IP is sometimes reset and DHCP doesn't automatically bring it back. using `dhcpcd eth0` helps.
Did you use network-setup to do this, or did you depend on auto-DHCP (that is, no configuration at all?)
2) when laptop is resumed from power suspend, it got the IP of last successful WIFI connection sticky and if you wake up in different wireless network it doesn't change IP until you manually reset it with `ifconfig wlan0 inet 0.0.0.0`.
I never suspend. Suspend doesn't work on my laptop, so I can't test this. Which wifi manager do you use, WPA GUI or network setup?
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]