Puppy 4 Beta 2

Please post any bugs you have found
Message
Author
User avatar
HairyWill
Posts: 2928
Joined: Fri 26 May 2006, 23:29
Location: Southampton, UK

#101 Post by HairyWill »

There is a bug in init for puppy 3.01, I don't think this has been fixed in dingo. They don't always set PUPMODE=13 for ideflash type installs. There is a fix here:
http://www.murga-linux.com/puppy/viewto ... 681#193681
Last edited by HairyWill on Wed 30 Apr 2008, 07:56, edited 1 time in total.
Will
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#102 Post by Lobster »

Last chance coding . . .

release candidate planned for Friday 2 May

Sunday 4 May
Puppy 4 Final . . .

check Barrys Blog - oh I guess you do ;)

ok and the wiki
http://puppylinux.org/wikka/Puppy4
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#103 Post by John Doe »

oh my, I hope this makes the deadline.

I went nuts with the connection wizard and added (hopefully) usb modem and cellphone support as well as MS VPN support.

still have to fix the 'configure' tab a bit, but it should all work ok. There are a few files under /usr/sbin and the config files for vpn are under /etc/ppp. The vpn wizard overwrites 4 files in there. Two of them have there own names but the other two are ip-up and chap-secrets. Most people don't have anything in those files anyway, but if you do back them up. Very soon, I'll add logic to only edit one section of the files. Rather than overwrite them.

I'd recommend testing this in Beta2 with a pfix=ram boot. Install the pet and then click the connect icon on the desktop.

Also added "ping and traceroute" to the options under the "tools" tab and moved the firewall wizard over there. In addition to adding functionality, I was shooting at making it fit nicely at 640x480.
Attachments
Connection-Wizard.pet
(5.12 KiB) Downloaded 991 times
connectionWizard.png
(30.01 KiB) Downloaded 2197 times

FuturePerfect
Posts: 47
Joined: Fri 01 Sep 2006, 02:40
Location: Southwestern U.S.

Barry: hopefully still plans for a barebones Dingo?

#104 Post by FuturePerfect »

Barry:

Have I missed any recent references to a barebones Dingo?

Back in October in your developer blog, you talked about having an official barebones Dingo.

I think this might reduce the size of the Puppy folks need and be of great use to those non-technical people like me who are nervous about trying Unleashed to get a Puppy with less stuff.

Thanks for your consideration of a barebones Dingo now or in an upcoming Dingo release.

barriew
Posts: 88
Joined: Tue 17 Oct 2006, 17:16
Location: Essex, UK

Problem with CUPS printing to Windows printer

#105 Post by barriew »

This doesn't work in 4.0Beta2 - I think because there is no symlink to smbspool in /usr/lib/cups/backend.

At least this gives the 'Windows Printer via Samba' option in the set up. I still have a problem getting the print to work, but at least this gives the connection option!

Barrie

I now have CUPS printing to my XP printer, despite the error message

Tree Connect failed (NT_STATUS_ACCESS_DENIED)

I think my earlier problems were to do with wireless networking. I have this working, but only by hard coding for my home network. The problem appears to relate to DHCPCD - still investigating.

Barrie
Last edited by barriew on Thu 01 May 2008, 19:21, edited 1 time in total.

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

Re: Connection wizard last-minute major update!

#106 Post by rerwin »

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.
Richard

djringjr
Posts: 157
Joined: Sun 14 Jan 2007, 21:08

#107 Post by djringjr »

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. :-(

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,

djringjr

djringjr
Posts: 157
Joined: Sun 14 Jan 2007, 21:08

#108 Post by djringjr »

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.

Best

josh.viklef
Posts: 12
Joined: Fri 20 Jul 2007, 20:44

#109 Post by josh.viklef »

I can find on PETget package manager (Official Puppy2 repository) Openoffice 1.1.4 cutdown version. Could you give it to the list, please?

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#110 Post by tempestuous »

EDIT: b43-firmware attachment removed.
Puppy4-2.6.25 already contains this firmware.
Last edited by tempestuous on Sat 17 May 2008, 08:25, edited 1 time in total.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#111 Post by tempestuous »

EDIT: b43-legacy-firmware attachment removed.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#112 Post by npierce »

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:

nameserver 193.189.160.13
nameserver 193.189.160.23

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:

Code: Select all

#/bin/sh
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:

Code: Select all

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:

Code: Select all

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.

--npierce

Post Reply