Each time I boot up, I have to click on the Connection icon and then click through a number of other steps before I can use my browser, in spite of the fact that, when I went through it last time, I clicked "yes" when asked if I wanted the settings to be available when next I booted.
Is there some other way that I can force the settings to persist?
In case it should be relevant, I click in order each time: Connect; Connect to internet by network interface; eth0; Auto DHCP; Yes; and Exit.
Leslie
Connection settings don't persist (Solved?)
Re: Connection settings don't persist
Hi Leslieklesliek wrote:Each time I boot up, I have to click on the Connection icon and then click through a number of other steps before I can use my browser, in spite of the fact that, when I went through it last time, I clicked "yes" when asked if I wanted the settings to be available when next I booted.
Is there some other way that I can force the settings to persist?
In case it should be relevant, I click in order each time: Connect; Connect to internet by network interface; eth0; Auto DHCP; Yes; and Exit.
Leslie
Have you been saving the pup_save.3fs file when you shut down puppy?
[size=75][color=darkred]Toshiba M35X S-111 - Aspire 5100-3357 using puppy 2.12 - 2.13 - 2.14 - 4.3.1 -
Bootable CD and no hard drive[/color][/size]
Acer Aspire 1 netbook using thumbdrive or CD
Bootable CD and no hard drive[/color][/size]
Acer Aspire 1 netbook using thumbdrive or CD
I am not sure but I think the defaults can be overridden by adding code but I not sure how to do it. maybe someone will tell us how to do it. Sorry I can't help with any other info.
Last edited by kent41 on Wed 13 Dec 2006, 00:25, edited 1 time in total.
[size=75][color=darkred]Toshiba M35X S-111 - Aspire 5100-3357 using puppy 2.12 - 2.13 - 2.14 - 4.3.1 -
Bootable CD and no hard drive[/color][/size]
Acer Aspire 1 netbook using thumbdrive or CD
Bootable CD and no hard drive[/color][/size]
Acer Aspire 1 netbook using thumbdrive or CD
Kent41, I must be saving the pup_save.3fs file each time I shut down, though I'm not conscious of having done anything deliberate to do so. I have Puppy on a bootable compact flash drive and I assume that's sufficient to lead to automatic saving. Yesterday, for instance, I downloaded the Opera web browser and it's been there after reboots.
More generally, I have what I expect is a common problem, namely, finding the right search terms when trying to see if something's been dealt with before.
Since posting my original query, I've kept searching and found the topic on the forum, "Puppy doesn't save eth0 settings". I haven't had a chance to try it yet, but it seems as though I should have a file called /etc/eth0mode, which is created after I run the network wizard. It also seems that if I copy that file's contents to /etc/rc.d/rc.local, then my connection will be restarted whenever I boot up. I'll try that as soon as I can.
While I'm mentioning lack of persistency of settings, I also find that setting my time, date and time zone doesn't survive a reboot. If anyone can solve that problem for me, I'd be happy to hear the solution. If not, I'll keep working on it when I can next get in front of my computer running Puppy.
Thanks for the replies.
Leslie
LATER: To start at the end, the problem isn't solved yet.
I looked at my /etc/eth0mode file. At bootup, it has five lines:
echo "Trying to get IP address from DHCP server (60sec timeout) ..."
rm /etc/dhcpc/dhcpd-eth0.pid 2>/dev/null
rm /etc/dhcpc/dhcpd-eth0.cache 2>/dev/null
rm /etc/dhcpc/dhcpd-eth0.info 2>/dev/null
dhcpd eth0
Those lines don't change after I run the network wizard. Also, they survive a reboot, but they don't obviate the need to run the wizard afresh.
I copied the last four of them to /etc/rc.d/rc.local, saved and rebooted. They persist, but they don't obviate the need to run the wizard afresh either.
One other complication. Each time I booted up until recently, I could have sworn there was an explicit line on the screen that said that rc.local was being run. Now, that line doesn't appear any longer. I don't know why, but maybe rc.local isn'r being run for some reason and that's why copying the last four lines from eth0mode hasn't solved the problem.
I'm very confused.
STILL LATER: I edited my rc.local file by putting in the line:
echo "TEST"
I rebooted and waited to see if TEST appeared at any stage. It didn't. I go from some line about version update to a line that talks about starting x. I take it that means that I've inadvertently done something to stop rc.local (and who knows what else) from running on bootup.
How do I overcome that problem, which seems to me to be more serious than having to redo the connection wizard each time?
More generally, I have what I expect is a common problem, namely, finding the right search terms when trying to see if something's been dealt with before.
Since posting my original query, I've kept searching and found the topic on the forum, "Puppy doesn't save eth0 settings". I haven't had a chance to try it yet, but it seems as though I should have a file called /etc/eth0mode, which is created after I run the network wizard. It also seems that if I copy that file's contents to /etc/rc.d/rc.local, then my connection will be restarted whenever I boot up. I'll try that as soon as I can.
While I'm mentioning lack of persistency of settings, I also find that setting my time, date and time zone doesn't survive a reboot. If anyone can solve that problem for me, I'd be happy to hear the solution. If not, I'll keep working on it when I can next get in front of my computer running Puppy.
Thanks for the replies.
Leslie
LATER: To start at the end, the problem isn't solved yet.
I looked at my /etc/eth0mode file. At bootup, it has five lines:
echo "Trying to get IP address from DHCP server (60sec timeout) ..."
rm /etc/dhcpc/dhcpd-eth0.pid 2>/dev/null
rm /etc/dhcpc/dhcpd-eth0.cache 2>/dev/null
rm /etc/dhcpc/dhcpd-eth0.info 2>/dev/null
dhcpd eth0
Those lines don't change after I run the network wizard. Also, they survive a reboot, but they don't obviate the need to run the wizard afresh.
I copied the last four of them to /etc/rc.d/rc.local, saved and rebooted. They persist, but they don't obviate the need to run the wizard afresh either.
One other complication. Each time I booted up until recently, I could have sworn there was an explicit line on the screen that said that rc.local was being run. Now, that line doesn't appear any longer. I don't know why, but maybe rc.local isn'r being run for some reason and that's why copying the last four lines from eth0mode hasn't solved the problem.
I'm very confused.
STILL LATER: I edited my rc.local file by putting in the line:
echo "TEST"
I rebooted and waited to see if TEST appeared at any stage. It didn't. I go from some line about version update to a line that talks about starting x. I take it that means that I've inadvertently done something to stop rc.local (and who knows what else) from running on bootup.
How do I overcome that problem, which seems to me to be more serious than having to redo the connection wizard each time?
It seemed silly to keep extending the previous post, so I'm reporting something here that I hope may be helpful to PaulBx1.
I found (in the rc.d directory, I think) a readme about the startup process, which mentioned the relevant files and the order in which they run. There are six of them in rc.d: rc.sysinit, rc.modules, rc.update, rc.local0, rc.network and rc.local.
On another computer than the one which I'm trying to get going with Puppy, I booted up Puppy from the live cd. I then mounted a flash drive and copied to it five of the six startup files in rc.d. For the rc.local0 file, I copied instead to the flash drive the substitute one that Paul recently uploaded to the forum to resolve certain USB problems.
I then booted up the computer I want to use Puppy on. I moved the existing six files in rc.d to a new directory I called "old_files" and then copied to /etc/rc.d the six files on the flash drive. I then shutdown, rebooted and, when I did, my Internet access was immediately available. I've rebooted a couple of times now and it seems that Internet access remains immediately available.
If you're game to try the above, PaulBx1, you may find that your Internet access persists afterwards too.
I now suspect that my fooling around with one or more of those six files when trying to get my USB mouse working properly had unintended consequences that were cured by using pristine versions of those files. Anyway, so far so good.
Leslie
I found (in the rc.d directory, I think) a readme about the startup process, which mentioned the relevant files and the order in which they run. There are six of them in rc.d: rc.sysinit, rc.modules, rc.update, rc.local0, rc.network and rc.local.
On another computer than the one which I'm trying to get going with Puppy, I booted up Puppy from the live cd. I then mounted a flash drive and copied to it five of the six startup files in rc.d. For the rc.local0 file, I copied instead to the flash drive the substitute one that Paul recently uploaded to the forum to resolve certain USB problems.
I then booted up the computer I want to use Puppy on. I moved the existing six files in rc.d to a new directory I called "old_files" and then copied to /etc/rc.d the six files on the flash drive. I then shutdown, rebooted and, when I did, my Internet access was immediately available. I've rebooted a couple of times now and it seems that Internet access remains immediately available.
If you're game to try the above, PaulBx1, you may find that your Internet access persists afterwards too.
I now suspect that my fooling around with one or more of those six files when trying to get my USB mouse working properly had unintended consequences that were cured by using pristine versions of those files. Anyway, so far so good.
Leslie
What I found on my machine when I finally looked, is that it indeed was saving the file /etc/eth0mode. However it was not saved as an executable. By going to /etc and doing a "chmod 755 eth0mode" command, it now can be run and works. I am pretty sure it will come up right next time I try booting 212 (out in the garage - I am wrestling with ethernet cables too! 
)
)
It didn't make a difference because it really does not matter if it is executable or not, it is being executed as part of other script.
So, recapping...
- You've already checked that the driver is correctly loaded at boot time either because the boot scripts recognized it or because you loaded it with the network wizard and saved the driver.
- You configured your connection using the wizard and it created the eth0mode file.
- You checked the contents of eth0mode and you saw that the commands seem correct
- Even with all of the above your connection does not start at boot.
I will need help here, I'm in the dark. I've used the network wizard in 5 different computers that require different drivers including cable ethernet connections, wireless with native drivers, wireless with ndiswrapper.
It is important that when you report a problem you specify what version of puppy you are using. I remember that in an older version (I think it was 2.01 or 2.02 there was some code missing from the rc.network.
So, please work with me here so we can find a solution to the problem.
So, recapping...
- You've already checked that the driver is correctly loaded at boot time either because the boot scripts recognized it or because you loaded it with the network wizard and saved the driver.
- You configured your connection using the wizard and it created the eth0mode file.
- You checked the contents of eth0mode and you saw that the commands seem correct
- Even with all of the above your connection does not start at boot.
I will need help here, I'm in the dark. I've used the network wizard in 5 different computers that require different drivers including cable ethernet connections, wireless with native drivers, wireless with ndiswrapper.
It is important that when you report a problem you specify what version of puppy you are using. I remember that in an older version (I think it was 2.01 or 2.02 there was some code missing from the rc.network.
So, please work with me here so we can find a solution to the problem.
[url]http://rarsa.blogspot.com[/url] Covering my eclectic thoughts
[url]http://www.kwlug.org/blog/48[/url] Covering my Linux How-to
[url]http://www.kwlug.org/blog/48[/url] Covering my Linux How-to
Perhaps there is a connection between what I am seeing here with dhcpcd. The problem might be a low level thing like that.rarsa wrote:So, please work with me here so we can find a solution to the problem.
http://www.murga-linux.com/puppy/viewto ... 3671#83671
In addition, my main laptop has a wireless card that I have to run dhcpcd twice for it to work. I've tried all different manner of combinations and I really do HAVE to run it twice, no matter what.
Your wizard might be right on in concept and this might be a strange hardware bug.
wireless
See my topic earlier, I have the same problem and have tried on pup 1.0.7, pup pro2.1, and pup2.1.2, i cannot make nediswrapper persist and network save for next boot up wont work. I think it needs a fix for the next version 
OK Rarsa, I've got some juicy info for you to chew on, a real dog toy. 
My machine is a Thinkpad A21m (700MHz CPU) with a Netgear FA410 ethernet card. I am using Puppy 212 when I try this, but I cannot conclude 212 is the problem for this particular item because I only went to ethernet when 212 broke my wireless connection.
Here is the appropriate part of bootkernel.log, note the link beat is detected:
Here is the appropriate part of bootsysinit.log:
BTW it's not line 198 any more; should find a better way to identify the appropriate line if you are going to leave that in there.
So what happened in my case is that the link beat is detected in the one stage of the boot process, but in (I'm guessing) the later stage, rc.network, it did not detect it, even with 4 tests. BTW I copied those 4 tests one at a time to the command line after the boot, and they detected the link beat every time.
One suggestion, in the first of the 4 tests you might echo something like "Link beat not detected on 1st try, trying again..." and likewise for the other tests. Just a thought.
Oh, my eth0mode was there, it looked like this:
I have no idea why this is not working.
My machine is a Thinkpad A21m (700MHz CPU) with a Netgear FA410 ethernet card. I am using Puppy 212 when I try this, but I cannot conclude 212 is the problem for this particular item because I only went to ethernet when 212 broke my wireless connection.
Here is the appropriate part of bootkernel.log, note the link beat is detected:
Code: Select all
pcmcia: registering new device pcmcia1.0
eth0: NE2000 (DL10022 rev 30): io 0x300, irq 3, hw_addr 00:E0:98:89:71:AE
parport: PnPBIOS parport detected.
parport0: PC-style at 0x3bc, irq 7 [PCSPP,TRISTATE]
lp0: using parport0 (interrupt-driven).
lp0: console ready
eth0: found link beat
eth0: autonegotiation complete: 100baseT-FD selected
Code: Select all
The following interfaces have been found: eth0
Trying to connect
Testing if eth0 network is alive...
Ethernet cable not plugged in, or network dead.
...pausing for 3 seconds...
[1;31mNOTICE: IF THIS IS WRONG, EDIT /etc/rc.d/rc.network AND UNCOMMENT LINE 198[0;39m
So what happened in my case is that the link beat is detected in the one stage of the boot process, but in (I'm guessing) the later stage, rc.network, it did not detect it, even with 4 tests. BTW I copied those 4 tests one at a time to the command line after the boot, and they detected the link beat every time.
One suggestion, in the first of the 4 tests you might echo something like "Link beat not detected on 1st try, trying again..." and likewise for the other tests. Just a thought.
Oh, my eth0mode was there, it looked like this:
Code: Select all
echo "Trying to get IP address from DHCP server (60sec timeout)..."
rm /etc/dhcpc/dhcpcd-eth0.pid 2>/dev/null #if left over from last session, causes trouble.
rm /etc/dhcpc/dhcpcd-eth0.cache 2>/dev/null #ditto
rm /etc/dhcpc/dhcpcd-eth0.info 2>/dev/null #ditto
dhcpcd eth0
I was having the same issue with network settings not being saved, but seem to have fixed it. The process was rather random though.
First, I found this thread, thanks.
I had already used the wizard by both the "Connect" icon and Setup menu to configure a wired ethernet connection.
I had also loaded 4 driver modules in the process.
What I did was edit /etc/ethernetmodules so only the necessary module was included. That worked for 1 reboot.
Next I set a static IP, but that didn't work after a reboot.
I again ran the wizard and chose dhcp. Now it's working after a number of reboots.
Nothing has changed in any of the files mentioned in this thread.
Like I said, kind of random.
I'm using a fresh hd install of 2.12 and a pcmcia nic.
mahto
First, I found this thread, thanks.
I had already used the wizard by both the "Connect" icon and Setup menu to configure a wired ethernet connection.
I had also loaded 4 driver modules in the process.
What I did was edit /etc/ethernetmodules so only the necessary module was included. That worked for 1 reboot.
Next I set a static IP, but that didn't work after a reboot.
I again ran the wizard and chose dhcp. Now it's working after a number of reboots.
Nothing has changed in any of the files mentioned in this thread.
Like I said, kind of random.
I'm using a fresh hd install of 2.12 and a pcmcia nic.
mahto
-
marksouth2000
- Posts: 622
- Joined: Wed 05 Apr 2006, 20:43
Is that an rt25xx?John Doe wrote:...my main laptop has a wireless card that I have to run dhcpcd twice for it to work. I've tried all different manner of combinations and I really do HAVE to run it twice, no matter what.
I have an rt2570 USB wireless stick. the network wizard cannot make it connect.
(Note that the network wizard does work, and keep the settings, with a Prism 2.5 PCMCIA card on the same machine.)
I put an icon on the desktop that runs the following script:
Code: Select all
modprobe rt2570
sleep 5
ifconfig rausb0 up
iwconfig rausb0 essid marks_nwid
if [ -e /etc/dhcpc/*.pid ]; then
rm /etc/dhcpc/*.pid
fi
dhcpcd -t 20 rausb0My DHCP server responds in about 3 seconds to all DHCP requests from other nodes on the network (about 10 in total) and the wireless link strength as shown by RutilT is about 90% in this location.
So what's going on?
marksouth2000
Your post prompts me to add a variation on your theme
Similar script to yours but mine can take upto 3 or 4 mins
to connect and watching things gives the following sequence:-
Blue lights on adaptor (WG111v2) comes on immediatley along with one very brief blink on blinky.
WAIT and WAIT and --
Two long flashes on blinky and we are connected.
Appears to be exact reverse of yours although I don't need to run the script twice. Running it a second time does not speed things.
Cheers
Geoff
Your post prompts me to add a variation on your theme
Similar script to yours but mine can take upto 3 or 4 mins
to connect and watching things gives the following sequence:-Blue lights on adaptor (WG111v2) comes on immediatley along with one very brief blink on blinky.
WAIT and WAIT and --
Two long flashes on blinky and we are connected.
Appears to be exact reverse of yours although I don't need to run the script twice. Running it a second time does not speed things.
Cheers
Geoff
No, I think it's a Broadcom or something like that. It's getting a new motherboard right now, so I can't check. I use ndiswrapper with it, so I always sort of just assumed that was the problem. I was a linux driver project for it once, but haven't check the status of it since I got it going.marksouth2000 wrote:Is that an rt25xx?
-
marksouth2000
- Posts: 622
- Joined: Wed 05 Apr 2006, 20:43
In my case it doesn't even get to the dhcp client. It is ifplugstatus-0.25 and ifplugstatus that are not working reliably.
Have you guys checked your bootlogs? What do they tell you? Are they saying anything like "Ethernet cable not plugged in, or network dead "? Those who are using ethernet, anyway...
Have you guys checked your bootlogs? What do they tell you? Are they saying anything like "Ethernet cable not plugged in, or network dead "? Those who are using ethernet, anyway...