Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 22 Nov 2019, 04:57
All times are UTC - 4
 Forum index » House Training » Bugs ( Submit bugs )
Puppy 4 Beta 2
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 8 of 8 [112 Posts]   Goto page: Previous 1, 2, 3, ..., 6, 7, 8
Author Message

Joined: 24 Aug 2005
Posts: 1955
Location: Maine, USA

PostPosted: Wed 30 Apr 2008, 20:33    Post subject: Re: Connection wizard last-minute major update!
Subject description: Risky to add new code with no coordination or beta testing

John Doe,
I applaud your accomplishment in dealing with ACM0 and USB0 USB modems that Puppy does not already detect. However, it is such a major addition to insert into the final puppy 4.00 release that it could compromise the perception of Puppy's straightforward and reliable behavior. It is also risky because there has been no beta testing of it and apparently no integration with the overall modem management function.

It is obvious to me that you and I need to coordinate our efforts. I have just (3.98+) updated the automatic detection of modems at initialization time, so understand the mechanism involved. As I watched the postings about the USB modems, I concluded that we need to add them to the set of modems already detected. But I did/do not have the full information necessary to implement that, yet. Would you consider working with me to get that done.

In response to your request for testers, I tested with my USB modem, a SmartLink USB modem that Puppy already supports at bootup. Your dialog boxes do not take that possibility into account, leaving a confused user. So we have the situation where some USB modems are detected automatically, like PCI modems, and are not represented in your ttyS... options, while others are not detected but let you start them from the desktop. To a user, this appears convoluted and inconsistent.

With that said, I propose that, for all USB modems, we provide both auto-detection when the modem is already plugged in at bootup, as well as the ability to start any of the USB modems after plugging them in as Puppy is running. This could simplify how the user starts a modem, because the auto-detection logic could also be used in usbmodemwizard.

Although I could not get to the "manage" and "link" dialogs (assuming they exist) I do see in the script something implying that the USB modem can be started even though a PCI modem is already detected and announced in pupdial. I think Puppy currently assumes only one modem in use at a time. So allowing a second to somehow pre-empt the PCI modem could be dangerous. I think we need to discuss the ramifications of that and whether it is necessary. We need more development time.

For me to start automating detection of the modems you address, I need to get their vendor and device IDs and the driver names they use. From that we can put the driver modules in the zdrv /lib/(modem) directories for automatic loading, and create modem scripts that do anything specific to the modem type and set the softlink in /dev/modem -- or not, if we implement a safe way of pre-emption. The script may need to run whenever the wizard activates a modem (definitely, for SmartLinks).

Let's see what we can work out for 4.01 or a service pack.
Back to top
View user's profile Send private message 

Joined: 14 Jan 2007
Posts: 156

PostPosted: Wed 30 Apr 2008, 22:44    Post subject:  

Right now I am worried that my 1st hard drive hda1 hasn't been blown up by pmount. It is not showing on the desktop. Sad

I downloaded beta2 and did a md5sum check - and am running as liveCD. The beta2 was useless because of Seamonkey crashing all the time. So I added the new Seamonkey 1.1.9 and did a remaster CD. Seamonkey is now working very very well but some of the other problems remain.

ALSA wizard doesn't complete if you "choose" not to save. Since I didn't save the settings (ALSA wasn't working for me in 3.01), I don't know if it correctly detected my soundblaster card as being preferred to the built-in audio on the motherboard, or even if the config is saved with 4.00 beta2.

Sometimes the desktop disappears, but restarting X seems to fix that. I find that when I click on the icons for the drives that the screen goes black also (desktop disappears).

Many things such as pmount and
other programs make the desktop go black. Seamonkey was very buggy until I replaced it with the latest version of Seamonkey - which works very very well.

Usually icons work the second time they are pressed. The first time they are pressed, the screen comes up for a split second then closes. Also under the command line, the xorg wizard will sometimes work, sometimes not. Seems like the same "Try it twice" that seems to be happening here.

The memory leak that plagued 3.00 and 3.01 seems to be gone. I can open multiple windows of Seamonkey 1.1.9 for hours and the system doesn't crash.

I had used beta1 and it was terrible. This is much better - but if you'd ask me neither of these is beta material - more like alpha material.

Best to all,

Back to top
View user's profile Send private message 

Joined: 14 Jan 2007
Posts: 156

PostPosted: Wed 30 Apr 2008, 22:49    Post subject:  

My hda1 drive reappeared after I "restart x" but when I return to X, when I resize Seamonkey screen or do anything, the desktop goes to black. Once it is black, the system is stable.

This beta is much better than beta1 which wouldn't even stay running for me. This will run for a long time and with the latest Seamonkey doesn't crash.

Back to top
View user's profile Send private message 

Joined: 20 Jul 2007
Posts: 12

PostPosted: Thu 01 May 2008, 05:56    Post subject:  

I can find on PETget package manager (Official Puppy2 repository) Openoffice 1.1.4 cutdown version. Could you give it to the list, please?
Back to top
View user's profile Send private message 

Joined: 10 Jun 2005
Posts: 5472
Location: Australia

PostPosted: Fri 02 May 2008, 05:04    Post subject:  

EDIT: b43-firmware attachment removed.
Puppy4-2.6.25 already contains this firmware.

Last edited by tempestuous on Sat 17 May 2008, 04:25; edited 1 time in total
Back to top
View user's profile Send private message 

Joined: 10 Jun 2005
Posts: 5472
Location: Australia

PostPosted: Fri 02 May 2008, 09:18    Post subject:  

EDIT: b43-legacy-firmware attachment removed.
Back to top
View user's profile Send private message 

Joined: 28 Dec 2009
Posts: 858

PostPosted: Sat 08 May 2010, 14:20    Post subject:  

While looking into the Roaring Penguin dueling symlink issue, I ran into a little mystery:

People testing Roaring Penguin in Puppy 4.0.0 tried just pressing ENTER at the "Enter the DNS information here" prompt during setup. This was to prevent the creation of the infamous symlink at /etc/resolv.conf, and it succeeded at doing that.

But Barry was concerned that
BarryK wrote:
There may be a problem if you type just the ENTER key instead of "server". It may setup PPPoE not to obtain the nameservers from the ISP.

People reported, however, that the nameserver information was coming through just fine. This was good for them, since that is what they wanted, and is what most people would want.
Leon wrote:
BarryK wrote:
Could you check that, start with nothing in /etc/resolv.conf, press just the ENTER key instead of typing "server", and see if it gets the nameservers from the isp.

Works fine for me.

Checked with fresh install. At DNS prompt just pressed ENTER.

This is the contents of my /etc/resolv.conf file created after starting internet connection for the first time:


This are the nameservers from my ISP.

oli wrote:
To press just ENTER works fine for me. /etc/resolv.conf than gets automatically the nameservers from my ISP.

But Barry was quite correct to think that there might be a problem since when "server" is not entered the usepeerdns option should not be passed from pppoe-connect to pppd, and no nameserver information should be written to /etc/ppp/resolv.conf.

When running pppoe-setup, the user is supposed to be able to specifically enter nameservers, or just press ENTER to leave the /etc/resolv.conf as it is. Only entering "server" should result in /etc/resolv.conf being overwritten with the nameservers obtained from the ISP server. So the fact that nameservers from the ISP server were coming through despite the fact that the user didn't specify "server" was a bit of a puzzle.

I checked and found that pppd was being called correctly, without the usepeerdns option. So what was wrong? After a bit of head-scratching I found that there is an /etc/ppp/options file, created for some other app, that always gets read by pppd. That file had the usepeerdns option in it.

What to do?

Simply removing that file would break one or more other PPP apps.

I was hoping to be able to make use of the fact that pppd accepts various other options files for things like specific serial ports or specific peers. Unfortunately those other files simply added to the options in /etc/ppp/options. They could add options; they could override options; but they could not take options away. For instance, it is possible to override defaultroute with nodefaultroute, but it is not possible to override usepeerdns with nousepeerdns because there is no nousepeerdns option.

(There is yet another type of options file which is used with the file name option. The pppd man page says that option will "Read options from file. . .", rather than "Read additional options from the file. . ." as other option files were described. So I was hopeful that this would be an alternative to /etc/ppp/options, not an extension of it. But experimentation proved otherwise. Rats.)

Well, I'd hoped to find a simple answer to this problem by changing a configuration file, but it looks like it will instead require a simple wrapper to temporarily hide /etc/ppp/options from pppd, like so:
mv -f /etc/ppp/options /etc/ppp/options.prev
pppoe-start1 "$@"
mv -f /etc/ppp/options.prev /etc/ppp/options

That would replace /usr/sbin/pppoe-start, which would, in turn, be renamed pppoe-start1.

Alternatively, /etc/ppp/options could be eliminated, and specific options files be created for any PPP app that needed one. But that would also require changes in those apps so that those application-specific files would be found. And that is not only for PPP apps included with Puppy, but also for PPP apps in the repositories now and in the future. That would be a nightmare.

Wait, how about all the other stuff in /etc/ppp/options other than usepeerdns? Does Roaring Penguin need any of that?

Not according to Roaring Penguin. If you run pppoe-start in debug mode, like so:
DEBUG=1 pppoe-start

the pppoe-debug.txt file it logs to will report:
* The following section lists /etc/ppp/options.
* You should have NOTHING in that file.

Roaring Penguin passes all its options to pppd on a command line, so does not require /etc/ppp/options.

Looking at /etc/ppp/options, it appears that, with one exception, all of the options provided by it are either identical to those passed by Roaring Penguin on the command line, or are related to using a serial port, which is not applicable to PPPoE. The one exception is asyncmap 0, but that is the default anyway if no asyncmap option is given.

If it was determined that, despite Roaring Penguin's claim that "You should have NOTHING in that file," something was needed that couldn't be put in by way of pppoe-setup or pppoe.conf, then a specific option file, /etc/ppp/options.rp, could be made for Roaring Penguin. In order for Roaring Penguin to find that file, a line would need to be added to /etc/ppp/pppoe.conf:
PPPD_EXTRA="file /etc/ppp/options.rp"

I should point out that this suggested wrapper script has not been fully tested since I just connect to my local network, and don't use PPPoE from Puppy. I have tried the script and verified that the original /etc/ppp/options file doesn't get read, and I've run pppoe-start in debug mode and verified that the options passed to pppd are correct. But, obviously, I'm not able make a connection to make sure that everything works properly.

Also, I should make it clear that although this behavior was first noted in this "Puppy 4 Beta 2" thread, the same /etc/ppp/options file has been around since at least Puppy 1.0.4, and is still present in 4.3.1. So this behavior probably exists in various Puppies.

And, finally, this change should not be made before applying Barry's 2005 fix to pppoe-connect so that users can safely choose "server" without running into the dueling symlinks problem. Otherwise they would no longer be able to get the nameservers from their ISP's server if they wanted.

Okay, I've rambled on long enough here. This obviously is not a high priority. Most people want to use the nameservers provided by their ISP's server, and that works today (if one avoids the dueling symlinks). But for other choices, Roaring Penguin does not currently work as described in pppoe-setup or /etc/ppp/pppoe.conf. And occasionally someone wants to use OpenDNS nameservers or some other alternative to those provide by their ISP. So it would be nice to get this working some day.

Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 8 of 8 [112 Posts]   Goto page: Previous 1, 2, 3, ..., 6, 7, 8
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » Bugs ( Submit bugs )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum

Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1200s ][ Queries: 12 (0.0161s) ][ GZIP on ]