4.1 Alpha 5

[rerwin]

To resolve the problems I reported earlier at
http://www.murga-linux.com/puppy/viewto ... 621#219621
I am appending a dot pet with the fixes as well as the corresponding difference files.

The following changes were made:
1. Modemprobe changed to utilize the current /dev/modem target device if the probe for it is successful. Previously, the device found via /dev/modem was ignored, making the probe useless. Also added return of wvdialconf result to pupdial (so code could be added there to correct its report to the user -- when not modem found).

2. To prevent the probe from attributing a successful probe to the wrong device (an old problem), particularly after a modem changeout, most of the PCI-modem scripts delete their device links/nodes if their driver is not loaded, leaving the device link/node for only the active/resident modem(s). In these cases, /dev/modem is also deleted, since it would point to a non-existent link/node. (This fix trusts that Puppy will create only the link/node required by a loaded PCI-modem driver module, as done in alpha5.)

3. Added ttyS... links for the Intel modems, so that modemprobe can find them. But ensured that the actual device name is retained.

4. Restored prioritization links for SmartLink modems, so that USB type checked first, then PCI, then ALSA. The ttySL0 link is not managed, since it does not conflict with the other PCI modems.

The attached dotpet is suitable for testing, since the modem scripts are in both the operational directory and the firmware tarballs. For incorporation into the next alpha, only /usr/sbin/modemprobe and the /lib/module/all-firmware tarballs need be copied into the "master."

BTW, since the "martian" Lucent driver does not work in alpha5, I compiled and ran it, and tested its script successfully in Puppy 4.0. I hope that the loading problems with martian_dev and slamr are related to the SMP kernel, and that they will work in the promised uniprocessor kernel. The slamr problem can be worked around, but the martian problem is a showstopper.
Richard

Unfortunately, I am unable to attach my dotpet file containing the corresponding all-firmware tarballs, receiving the following forum response:

Sorry, but the maximum filesize for all Attachments is reached. Please contact the Board Administrator if you have questions.

However, apparently the diff listings and the scripts themselves were accepted.

[rcrsn51]

otropogo: I have attempted to replicate your situation. I booted off a 4.00 CD and made a pristine 32 MB savefile in a 10 GB vfat partition. I then rebooted and successfully copied a 90 MB file to /mnt/home. Like Beem, it was obvious which areas were inside the savefile and what was in hda1 external to the savefile. Even when I manually mounted hda1 as /mnt/hda1, I was still outside of the savefile. I then booted another Puppy Live CD and had the same success.

I don't want to get into an argument over whether you have found a Puppy defect, but I am curious about how you are mounting /mnt/hda1.

[otropogo]

otropogo: I have attempted to replicate your situation. I booted off a 4.00 CD and made a pristine 32 MB savefile in a 10 GB vfat partition. I then rebooted and successfully copied a 90 MB file to /mnt/home. Like Beem, it was obvious which areas were inside the savefile and what was in hda1 external to the savefile.

Obvious - how?

In my many, many trials with this problem, both in 4.0 and in 4 alpha5, I was only ever able to get at one writeable directory on my host partition "/mnt/home", which contained the 2fs files. The only direction from there was the "parent directory" , which led right back to /mnt/home.

Both Pmount and MuppyQuickmount produced the same results. The host drive was shown as having some 7.9GB of free space, but when I dragged and dropped an 800MB folder into /mnt/home, only 400MB or so were written (the amount of space left in my 2fs file).

When I rebooted with the other version, that 400MB was not accessible.

Nor could xfprot access the data written there with 4.0, since I had xfprot working only on 4.05.

Even when I manually mounted hda1 as /mnt/hda1, I was still outside of the savefile. I then booted another Puppy Live CD and had the same success.

Well, guess what? After copying all of my 2fs files and the zdrv file to flash, deleting the originals from sda1/hda1, and then copying them all back again to hda1/sda1, the problem has disappeared.

I'm now able to write the whole 800MB file to /mnt/home without getting an error, and I can access it with either version.

Yet the directory looks exactly the same as it did when I had the problem, And I initially installed the original 2fs files strictly by the default procedure.

I ran the live CD and accepted its suggestion to write the save file to one of the available drives, allowed it to abstain from searching for a serial mouse (an unadvisable choice anyway, as detailed elsewhere), and declined the offer to write the 400.sfs file to the hard drive.

In other words, the handicap I've endured for weeks (ever since I tried to clear my camera and found my other partition full) is built into Puppy's installation structure somehow - don't ask ME how. And the fact that I've been able to "fix" it on my machine now, with some desperate file shuffling (ie. "voodoo"), doesn't get rid of the bug. It just makes it harder to fix.

Like any problem, intermittency makes diagnosis hellishly more difficult. If everyone using Puppy experienced it, or even a significant number of regulars here, it would soon be solved.

If someone with the necessary technical skill had paid attention when I first posted the problem, we might have been able to figure out what was causing it. Now that opportunity is probably gone.

I don't want to get into an argument over whether you have found a Puppy defect, but I am curious about how you are mounting /mnt/hda1.

I find your question strange. The host drive for the pup_save file in use has always automounted on my system and been locked in that state on startup .. Pmount shows it as sda1 or hda1 with the "unmount" tab greyed out.

If I click on its icon in the Pmount window or on the desktop, /mnt/home opens. If I use ROX to navigate the filesystem, I can go uparrow/mnt/home. All these routes take me to the same place. "sda1/hda1" don't appear anywhere except in the pmount window and during the boot process, when the choice of save files is offered.

In Rox, /mnt/home is shown as a symlink to /initrd/mnt/dev_save, but when you click on it, the resulting window looks exactly the same as it does if you click on the desktop drive icon or the one in the Pmount window.

Nor has that changed since the problem was "fixed".

If the user has mount options for the host partition, or other paths to accessing it while mounted, they're well hidden.

What are they?

[rcrsn51]

There is no bug. I believe that you are not using the Puppy filesystem correctly.

When you run Pmount and click on the "hda1" button, a window opens into your full hda1 partition. Puppy names it /mnt/home. You can confirm this because you should see your pupsave file there. If you drag files into this window, you will be saving them where you want.

However, if you click the up-arrow, you are now in the /mnt folder which is part of your "personal" filesystem built inside the pupsave file. If you then go into the hda1 subfolder and store files there, you are actually putting them in your pupsave file. This is because the /mnt/hda1 folder is not automatically connected to /dev/hda1. It is the /mnt/home folder that is serving that purpose when you boot off the Live CD.

[otropogo]

There is no bug. I believe that you are not using the Puppy filesystem correctly.

When you run Pmount and click on the "hda1" button, a window opens into your full hda1 partition. Puppy names it /mnt/home. You can confirm this because you should see your pupsave file there. If you drag files into this window, you will be saving them where you want.

Maybe I didn't explain myself clearly enough. I've just finished editing my orignal response, apparently while you were responding to it.

The "proper" procedure your describe is EXACTLY what I have always done.

However, if you click the up-arrow, you are now in the /mnt folder which is part of your personal filesystem. If you then go into the hda1 subfolder and store files there, you are actually putting them inside your pupsave file.

Well, that's something I've never tried, and I couldn't even do it now if I wanted to because THERE IS NO HDA1/SDA1 subfolder as you describe, only exactly the same folder /mnt/home that I see when I click on /mnt/sda1 in the pmount window or on the /mnt/home icon on the desktop.

If what you say were true, then my 1GB save file would have inexplicably expanded all by itself to more than 1.8GB, since there are 1.2GB of image files in the folder at the location you describe - click on sda1 icon in Pmount, click on uparrow, click on "home" (as there is no sd1 there, or anywhere else in the file tree)

This is because the /mnt/hda1 folder is not automatically connected to /dev/hda1. It is the /mnt/home folder that is serving that purpose when you boot off the Live CD.

I think you need to reread my post and rethink our analysis. It clearly doesn't address either the present or the original situation.

[rcrsn51]

I stand corrected. A fresh copy of 4.00 does not have a /mnt/hda1 folder . I was misled by your statement

anything I write to "/mnt/sda1(hda1)"

[Béèm]

@otropogo
trange. I have a 12.6GB partition, vfat, on which I have a pup_save file.
Through /mnt/home I can read, write, delete etc.. to the part outside the pup_save file without problem.

which Puppy version are your running?

Dingo 405

does your partition also have zdrv_400.sfs on it?

No and no zdrv_405.sfs either

Which physical drive is it on (1st, 2nd, or 3rd IDE etc)?

1e HDD (only one)

Which partition is it?

2e

How large is your pup_save file?

704MB

Can you access the data written to this partition when booting with another Pup version?

Yes, with Puppy302 f.e.

I use the Lin'N'Win method for my frugal installs.

So in my laptop I have 1 HDD with 2 partitions.

Partition 1 is ntfs and has Windows XP.
For each version of puppy I want to use I create a directory.
puppy302, puppy400, puppy405
I mount the iso's (no creation of a CD) and copy the base files to those created directories. So f.e. in puppy400 I have also the zdrv_400.sfs

I copied the grup loader from Lin'N'Win to the root of the ntfs partition and made it selectable through the boot.ini
For every version of puppy I have, I create the entry in menu.lst

Partition 2 is a vfat.
It contains the pup_save files corresponding for each version.

When I boot I choose GRUB and once in GRUB I select the puppy version to boot.
I get that selection screen to choose the pup_sav file to use, so I take the one corresponding to the puppy version I boot from.

Boot continues until the desktop.
/mnt/home points to the partition 2.
I can save any file to it and thus it is outside the pup_save file.
I can choose to save a file inside the pup_save file if I want.

So installing a new version is a piece of cake.
Download the new iso.
Make a new directory on the ntfs partition for the new version.
Copy the pup_save file and give it a new name with the new version in it.
Add an entry in menu.lst for the new version.
Mount the new iso and copy the puppy base files to the newly created directory.

Boot and choose the new version in GRUB.

See the info on Lin'N'Win

[otropogo]

Hi Beem,

It looks like your setup is considerably different from mine. Aside from the different partition placement, if I understand your post correctly, you have Puppy in a frugal install to hard drive, while I'm booting from the LiveCD each time.

I should add that after moving both my 2fs files and zdrv off the hard drive to flash cards, and then moving them back to the hard drive, the problem I described has disappeared, although everything looks exactly the same.

So now when I try to copy 800MB of data to /mnt/home, it completes with no problem, instead of stopping at 400MB. And I can now read those files with 405, even though they were copied with 4.0, and xprot can now scan the first partition.

I'm interested in a couple of things you said, and wonder if you could explain them.

1. you mentioned that you could copy files into your save file or outside of them as you choose,

How do you copy a file into into the 2fs file, and why would you want to?

2. you also mentioned "mounting the ISO". Do you mean that literally? Are you running puppy from ISO without the use of a LiveCD or disk install? If so, that's something I'd like to investigate for my laptop, as it has no CDROM or USB, and none of the other load options Puppy is famous for seem to work anymore.

I've got a frugal install of 3.01 Retro on the laptop, and with it I can access a pcmcia scsi CDROM drive, pcmcia flash cards, and the network.So getting files onto the hard drive is not a problem. But booting is.

I can't even boot the installed version except with the WakePup floppy. I was never able to get Grub to boot from the hard drive, and only once managed to create a working Grub boot floppy. But it got corrupted and I haven't been able to repeat the trick.

Given all these problems, I'm not prepared to do a hard drive install or to try another Grub installation on the laptop. But if I could boot an ISO or a virtual LiveCD using a floppy, that would definitely be worth trying.

[Béèm]

1. you mentioned that you could copy files into your save file or outside of them as you choose,

How do you copy a file into into the 2fs file, and why would you want to?

A small example for using the pup_save.
I created in /root another directory: my-pictures
When I take a screenshot to highlight a post, I put the .png file in there.
So this is inside the pup_save.

Secondly newly installed programs (pets) go automatically inside the pup_save in my case.

All other files like documents, spreadsheets etc... go on a USB attached HDD, It has a vfat partition as this HDD is connected to my desktop if needed. So All my important data is accessible to both my laptop in XP and Puppy and the desktop in XP.

Most of the time this external HDD is plugged in the desktop in a docking station. With pnethood I go from the linux laptop to the share in the desktop XP to retrieve and update those documents.

[Béèm]

2. you also mentioned "mounting the ISO". Do you mean that literally? Are you running puppy from ISO without the use of a LiveCD or disk install? If so, that's something I'd like to investigate for my laptop, as it has no CDROM or USB, and none of the other load options Puppy is famous for seem to work anymore.

I had a bad experience trying to install a linux on my laptop with MBR on the partion to boot from etc...
I couldn't boot XP anymore and it took me one week of asking questions and scanning forums before I could solve the issue.

I swore I would never allow anymore for a MBR to be written on my PC's.

I then saw the method in the Lin'N'Win project
The method is very simple.
So on my ntfs partition I have the different puppy version and flavors, each in their own directory. So the base files for puppy 400 in puppy400, those for puppy 403 in puppy403 and now those of puppy 405 in puppy405

Let's say I start from puppy 403. I have a pup_save pup_save.403.2fs
I download the new 405 ISO image to that famous external HDD.
I create on the ntfs partition (hda1/sda1) the new directory puppy405
Still in 403 I go to the directory where I copied the 405 ISO and in rox click on it. The ISO is mounted. and I copy all the files to the new directory puppy405 on the ntfs partition.
I go to menu.lst and create an entry for puppy 405.
I reboot the system and edit the puppy 405 entry in GRUB to add pfix=ram. I boot and I answer the questions for the keyboard and X.
I am in puppy 405 now, but without a pup_save file.
I then copy the pup_save.403.2fs to pup_save.405.2fs and reboot (no need to save the configuration)
This time I don't edit to add pfix=ram.
I get the list with the pup_save files and select the newly created pup_save.405.sfs
During the boot process it is detected that there is a version change (403 to 405) and a versioncleanup directory is created in /tmp.
Ones in the desktop, I run puppy 405 with the updated pup_save for puppy 405.

Very simple and no need to burn CD's/DVD's anymore.

[nooby]

Beem,
tanks indeed for such detailed description. Seems to be a good
set up to have an external hdd with eerything important if the Computer
get broken HDD it wont effect what one saved on the hdd.

But Ifail to get this iso open thing. Are you doing it with a puppy program and how do you tell it to extract them to that new folder/directory?

Or are you doing it in windows and what program can do such.

I always have to burn it first in windows using burncdcc and then open the cd with the windows file viewing program and copy the files over.

would be very practical if I could do it all from within puppy and stay in puppy too.

Does that need one are in different hdd or could I open an iso on same sda1 or hda1 as the puppy are in frugal install on?


Hope it is not a too much derail for the thread.
I can delete it and send pm if you want.

[trapster]

With puppy 300 and up you can just click on an .sfs or .iso file and it will open the contents in a rox file window.

You can then open another rox window and drag from the .iso contents to copy wherever.

This is also how I download and boot different puppies with Windows. I use tiny.exe from gujin to boot with.

[otropogo]

1. you mentioned that you could copy files into your save file or outside of them as you choose,

How do you copy a file into into the 2fs file, and why would you want to?

A small example for using the pup_save.
I created in /root another directory: my-pictures
When I take a screenshot to highlight a post, I put the .png file in there.
So this is inside the pup_save.

"What do you mean by "take a screenshot to highlight a post"?

Secondly newly installed programs (pets) go automatically inside the pup_save in my case.

Of course, but as you say, that happens automatically in the case of pets or pups. Or by carefully directed placement in other cases.

IOW, it seems extremely unlikely that any user would accidentally write data files to the pup_save , and certainly not repeatedly.

[nooby]

With puppy 300 and up you can just click on an .sfs or .iso file and it will open the contents in a rox file window.

You can then open another rox window and drag from the .iso contents to copy wherever.

This is also how I download and boot different puppies with Windows. I use tiny.exe from gujin to boot with.

Thanks I download teenpup today and test

[otropogo]

...

I had a bad experience trying to install a linux on my laptop with MBR on the partion to boot from etc...
I couldn't boot XP anymore and it took me one week of asking questions and scanning forums before I could solve the issue.

Basically what happened to the Win98 installation on my laptop, except that my disaster was permanent, due to my having run afoul of both Gparted (which "sucessfully" resized my two DOS partitions) and GRUB, which refused to boot either DOS or Puppy, and further messed up everything.

I swore I would never allow anymore for a MBR to be written on my PC's.

I then saw the method in the Lin'N'Win project
The method is very simple.

Sounds very promising, and I'll see if I can make it work on my systems. Thanks!

[otropogo]

With puppy 300 and up you can just click on an .sfs or .iso file and it will open the contents in a rox file window.

You can then open another rox window and drag from the .iso contents to copy wherever.

This is also how I download and boot different puppies with Windows. I use tiny.exe from gujin to boot with.

Other than moving the ISOs and sfs files around (and does that include 2fs files?), can you also edit them?

I ask specifically because of a very annoying problem I'm experiencing with xfprot.

With some help from GeoW, I managed to get xfprot running under 405 on my main Linux desktop. However, where I really need to run it is on my Win98 system, which hasn't been properly scanned since Fprot dropped free DOS sig files months ago.

Since I'm running 405 from LiveCD, I thought I should be able to simply write the 2fs file holding the configuration to a flash card, then boot the other system with the LiveCD and the pup_save file from the Puppy system. 405 comes up fine, but when I try to run xfprot, it aborts with a "version number not found" error, or words to that effect.

Have posted this problem some time ago, but haven't had any feedback. Is it possible to edit a pup_save file to preadapt it to another hardware platform?

[Béèm]

If you know exactly where to edit that pup_save file you can boot with pfix=ram and through rox, mount that pup_save.2fs file and do all the editing you want.

[CHLee]

Last I posted the "Freememapplet disappear after frugal install", and have more information now.
If the size of pup_save.2fs is small(<512M), the Freememapplet disappear.
If the size of pup_save.2fs is big(>512M), the Freememapplet display normal.
Hope can help debug. Thanks !
C.H.Lee

[RoteSocke]

Is it possible to kompile the nfs-Support for my own?

On Dingo, i needed only to modules:
sunrpc.ko in /lib/modules/2.6.21.7/net/sunrpc
lockd.ko in /lib/modules/2.6.21.7/fs/lockd

How can I do this?
Or could somebody compyle them and upload them to this forum?

[djringjr]

Hello; to open the optical drive tray is easy:

1) open a Terminal session (Main menu => System => Terminal)

2) type 'eject'

Nice try, Nick, but that won't work because the cd won't unmount because it is being used

[/code]# eject
umount: cannot umount /initrd/mnt/dev_ro2: Device or resource busy
eject: unmount of `/dev/sr0' failed
#

Code: Select all

I wish there was a way to do this!!!

It makes this version of Puppy not so good because to play DVD or copy CD/DVD or even remaster Puppy, you now have to buy an additional DVD player so you can watch movies!

Best

David