Be "Happy" - New Alpha TESTING released
help is missing for "secure ssh telnet"
file:///usr/share/doc/ssh.htm cannot be found
file:///usr/share/doc/ssh.htm cannot be found
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]
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]
Found a synaptics touch pad module for xorg 7.2 that works. Unzip it and put it in /usr/X11R7/lib/xorg/modules/input/ , then restart X.
- Attachments
-
- synaptics_drv.so.gz
- (15.85 KiB) Downloaded 574 times
thanks for the driver kirk hope it works with mine
Taking Puppy Linux to the limit of perfection. meanwhile try "puppy pfix=duct_tape" kernel parem eater.
X86: Sager NP6110 3630QM 16GB ram, Tyan Thunder 2 2x 300Mhz
Sun: SS2 , LX , SS5 , SS10 , SS20 ,Ultra 1, Ultra 10 , T2000
Mac: Platinum Plus, SE/30
X86: Sager NP6110 3630QM 16GB ram, Tyan Thunder 2 2x 300Mhz
Sun: SS2 , LX , SS5 , SS10 , SS20 ,Ultra 1, Ultra 10 , T2000
Mac: Platinum Plus, SE/30
System: Pentium-2 350MHz - 128MB RAM - 3 FAT32 Partitions on an IDE Hard Drive
I already have a 2.17.1 Frugal install with the pupsave and .sfs files in the root directory and the vmlinuz, initrd.gz in /boot/puppy.217/ of hda1.
Normally I don't touch Alpha releases. One of the main thrusts of this Puppy was to enhance the frugal install experience and simplify the startup script. As most of my communications on this forum deal with frugal install I felt I should participate at an early stage. I even used the Puppy Universal Installer rather than setup my frugal manually. Here is my experience.
Boot up Live CD with pfix=RAM
Delay at the fuse int ( API Version 7.8 ) line
Searches for Puppy files on hard disk before CD-ROM
Switch Root failed - wait 60 secs and it carries on OK ???
Get to the desktop after setting for UK keyboard - x-org - 800x600x24
Immediately shutdown
Say I want to 'save to file' - Note this is different to the usual SAVE
It shows the proposed pupsave on hdc (CD-ROM!) with a size of 1 MB. I was not asked what size I wanted or where to save it. I ESCaped and let it shut down without saving settings.
Boot the Live CD again and everything happened as before up to getting the desktop.
This time decided to run the Puppy Universal Installer to IDE (ATA) internal hard drive - hda.
It told me it had Puppy version 2.17 installed on all 3 of my partitions whereas it is only installed on hda1
Install Puppy to hda1
Everything else was OK. I chose the default directory of puppy220
I was not asked to install grub - which pleased me but I am not sure what a newbie would do.
I was told how to adjust menu.lst (good).
I shutdown and tried to save pupsave again but still wrong.
I use a Grub4DOS grub.exe file so using Windows I adjusted my menu.lst as suggested.
VERY IMPORTANT - make sure the psubdir is correct. I think I had an error on day 1 of testing and I got all the problems Leon and Hairy Will mentioned (i.e. the frugal would not load unless I put everything in the root)
On day 2 of testing I started from scratch and did all the above again then:
Rebooted and it started to load the frugal from the subdir ... but it wanted to upgrade my 2.17 to 2.20. I guess this was because it found the 217 pup_save.2fs in the root directory. Just because you tell it psubdir is puppy220 doesn't mean puppy doesn't look everywhere else. Stupid puppy!
OK - I have a backup. Reset my 217 pupsave but call it pup_save_217.2fs
Rebooted and puppy 220 still wanted to update!
OK - Reset the 217 pupsave and call it pup_save_217.2f0
Finally the frugal loads properly.
NOTE: It still has the delay on the fuse line and won't pivot root so waits 60 secs.
When I shut down this time it asks if I want to create a pupsave and gives me a SAVE button - NOT 'Save to File'
Answered SAVE - NORMAL - 512MB
It showed the check screen as hda1 pupsave.2fs 512MB in /puppy220 so I let it be created.
Shutdown worked but the power did not go off!
Went back to Windows:
Renamed my 2.17 pupsave back to pup_save_217.2fs and renamed my 2.20 pupsave to pup_save_220.2fs
When I rebooted 2.20 it gave me the choice, despite the pup_save_217.2fs being in the root directory.
When I rebooted 2.17 it loaded the pup_save_217.2fs without question - presumably because it cannot find the 2.20 pupsave in the directory.
I wanted to have a look at the new init file that was /initrd/sbin/init in Puppy 2.17.1 but I could not find it. /initrd does not have an sbin directory - I presume because the pivot root failed. I tried to look at /sbin/init but that showed itself as a symlink to bash rather than a script file.
Conclusion:
It would appear the frugal works BUT there are a lot of pitfalls to overcome. If you specify a psubdir I don't think puppy should look anywhere else for puppy files, but it does and causes havoc as well as delays while looking. (Of course PDEV1 STILL does not work!!!)
Why does it try to put the pupsave on CD when you boot from the Live CD. This is a major bug. If you cannot save your settings you are stuffed!
I cannot get to see another prime new feature (the simplified init file). Admittedly this may be my lack of knowledge although why it should be different to 2.17.1 is questionable.
A feature of all previous Puppies (quickness in booting and operation) has been made worse.
Why was this inability to pivot root not found by Barry. Is it a FAT32/NTFS partition problem?
So far, Lobsters nickname for 2.20 (Happy) does not apply - well, not to me anyway.
ICPUG
I already have a 2.17.1 Frugal install with the pupsave and .sfs files in the root directory and the vmlinuz, initrd.gz in /boot/puppy.217/ of hda1.
Normally I don't touch Alpha releases. One of the main thrusts of this Puppy was to enhance the frugal install experience and simplify the startup script. As most of my communications on this forum deal with frugal install I felt I should participate at an early stage. I even used the Puppy Universal Installer rather than setup my frugal manually. Here is my experience.
Boot up Live CD with pfix=RAM
Delay at the fuse int ( API Version 7.8 ) line
Searches for Puppy files on hard disk before CD-ROM
Switch Root failed - wait 60 secs and it carries on OK ???
Get to the desktop after setting for UK keyboard - x-org - 800x600x24
Immediately shutdown
Say I want to 'save to file' - Note this is different to the usual SAVE
It shows the proposed pupsave on hdc (CD-ROM!) with a size of 1 MB. I was not asked what size I wanted or where to save it. I ESCaped and let it shut down without saving settings.
Boot the Live CD again and everything happened as before up to getting the desktop.
This time decided to run the Puppy Universal Installer to IDE (ATA) internal hard drive - hda.
It told me it had Puppy version 2.17 installed on all 3 of my partitions whereas it is only installed on hda1
Install Puppy to hda1
Everything else was OK. I chose the default directory of puppy220
I was not asked to install grub - which pleased me but I am not sure what a newbie would do.
I was told how to adjust menu.lst (good).
I shutdown and tried to save pupsave again but still wrong.
I use a Grub4DOS grub.exe file so using Windows I adjusted my menu.lst as suggested.
VERY IMPORTANT - make sure the psubdir is correct. I think I had an error on day 1 of testing and I got all the problems Leon and Hairy Will mentioned (i.e. the frugal would not load unless I put everything in the root)
On day 2 of testing I started from scratch and did all the above again then:
Rebooted and it started to load the frugal from the subdir ... but it wanted to upgrade my 2.17 to 2.20. I guess this was because it found the 217 pup_save.2fs in the root directory. Just because you tell it psubdir is puppy220 doesn't mean puppy doesn't look everywhere else. Stupid puppy!
OK - I have a backup. Reset my 217 pupsave but call it pup_save_217.2fs
Rebooted and puppy 220 still wanted to update!
OK - Reset the 217 pupsave and call it pup_save_217.2f0
Finally the frugal loads properly.
NOTE: It still has the delay on the fuse line and won't pivot root so waits 60 secs.
When I shut down this time it asks if I want to create a pupsave and gives me a SAVE button - NOT 'Save to File'
Answered SAVE - NORMAL - 512MB
It showed the check screen as hda1 pupsave.2fs 512MB in /puppy220 so I let it be created.
Shutdown worked but the power did not go off!
Went back to Windows:
Renamed my 2.17 pupsave back to pup_save_217.2fs and renamed my 2.20 pupsave to pup_save_220.2fs
When I rebooted 2.20 it gave me the choice, despite the pup_save_217.2fs being in the root directory.
When I rebooted 2.17 it loaded the pup_save_217.2fs without question - presumably because it cannot find the 2.20 pupsave in the directory.
I wanted to have a look at the new init file that was /initrd/sbin/init in Puppy 2.17.1 but I could not find it. /initrd does not have an sbin directory - I presume because the pivot root failed. I tried to look at /sbin/init but that showed itself as a symlink to bash rather than a script file.
Conclusion:
It would appear the frugal works BUT there are a lot of pitfalls to overcome. If you specify a psubdir I don't think puppy should look anywhere else for puppy files, but it does and causes havoc as well as delays while looking. (Of course PDEV1 STILL does not work!!!)
Why does it try to put the pupsave on CD when you boot from the Live CD. This is a major bug. If you cannot save your settings you are stuffed!
I cannot get to see another prime new feature (the simplified init file). Admittedly this may be my lack of knowledge although why it should be different to 2.17.1 is questionable.
A feature of all previous Puppies (quickness in booting and operation) has been made worse.
Why was this inability to pivot root not found by Barry. Is it a FAT32/NTFS partition problem?
So far, Lobsters nickname for 2.20 (Happy) does not apply - well, not to me anyway.
ICPUG
I had that experience too.kirk wrote:2) Booted up ram only to make a second pup_save file. When I rebooted It had overwritten my first pup_save file.
more on pup_save resize
After manually moving pupsaveresize.txt to the correct location and rebooting I still don't have anymore usable space. pup_save.2fs has been made larger but the filesystem inside hasn't been enlarged (properly).
pup_save.2fs is 640MB but the device on loop1 is only 124MB
Code: Select all
# df -h
Filesystem Size Used Available Use% Mounted on
/dev/hda3 5.8G 1.3G 4.1G 24% /initrd/mnt/dev_save
/dev/loop1 124.0M 102.9M 21.0M 83% /initrd/pup_rw
tmpfs 76.6M 75.6M 1000.0k 99% /initrd/mnt/tmpfs
/dev/loop0 75.6M 75.6M 0 100% /initrd/pup_ro2
/dev/loop3 62.4M 62.4M 0 100% /initrd/pup_ro3
unionfs 124.0M 102.9M 21.0M 83% /
tmpfs 638.4M 40.0k 638.4M 0% /tmp
shmfs 82.4M 0 82.4M 0% /dev/shm
# ls -lh /mnt/home/pup_save.2fs
-rw-r--r-- 1 root root 640M 2007-09-06 07:45 /mnt/home/pup_save.2fs
#
Code: Select all
fsck.ext2 /mnt/hda3/pup_save.2fs
e2fsck 1.39 (29-May-2006)
Superblock last mount time is in the future. Fix<y>? yes
/mnt/hda3/pup_save.2fs was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 15 has zero dtime. Fix<y>? yes
Deleted inode 16 has zero dtime. Fix<y>? yes
Deleted inode 17 has zero dtime. Fix<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(3585--3648) -(3651--3652) -(3660--3665)
Fix<y>? yes
Free blocks count wrong for group #0 (7093, counted=7165).
Fix<y>? yes
Free blocks count wrong (21647, counted=21719).
Fix<y>? yes
Inode bitmap differences: -(15--17)
Fix<y>? yes
Free inodes count wrong for group #0 (1872, counted=1875).
Fix<y>? yes
Free inodes count wrong (25764, counted=25767).
Fix<y>? yes
/mnt/hda3/pup_save.2fs: ***** FILE SYSTEM WAS MODIFIED *****
/mnt/hda3/pup_save.2fs: 7001/32768 files (2.9% non-contiguous), 109353/131072 blocks
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]
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]
If that were true, I would be happier. As it says in my post the pivot root would not happen even when I had a pupsave. Although this case was when I picked from a choice of two. Perhaps I should test to see if the pivot root works when there is only one pupsave and it takes it automatically.kirk wrote:Why was this inability to pivot root not found by Barry. Is it a FAT32/NTFS partition problem?
No, only happens when booting with no pup_save file.
ICPUG
- veronicathecow
- Posts: 559
- Joined: Sat 21 Oct 2006, 09:41
Barry
pptp is giving me this
upgrading to 1.7.1 fixes it
It seems silly not to report it as I spent several hours yesterday getting pptpconfig to work. I suspect this is caused by an upgraded libc
If you've left the old pptp in the next release I'll make sure I bump this
pptp is giving me this
Code: Select all
*** glibc detected *** pptp: call manager for 152.78.68.187: double free or corruption (fasttop): 0x08058588 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7e93c23]
/lib/libc.so.6(cfree+0x90)[0xb7e970f0]
pptp: call manager for 152.78.68.187[0x804b422]
pptp: call manager for 152.78.68.187[0x804f61b]
pptp: call manager for 152.78.68.187[0x8049728]
pptp: call manager for 152.78.68.187[0x8049857]
pptp: call manager for 152.78.68.187[0x8049d55]
/lib/libc.so.6(__libc_start_main+0xd8)[0xb7e41df8]
pptp: call manager for 152.78.68.187[0x8049391]
It seems silly not to report it as I spent several hours yesterday getting pptpconfig to work. I suspect this is caused by an upgraded libc
If you've left the old pptp in the next release I'll make sure I bump this
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]
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]
Re: slackware compatibility, extend puppy modularity proposa
I've tried a game and lazarus with free pascal .mo files from SLAX. renamed them .sfs and used the boot manager and they worked in 2.20. They also worked in 2.16. I plan on trying more and seeing if there are any that work only in 2.20. Small games can just be mounted and the contents copied into puppy to get around the 3 limit. Or made into .pet files.ferikenagy wrote:I hope it will include the posibility on mounting .mo (SLAX) sfs files too (by ROX & Boot Manager). For an experimented user is straitforward to get and compile software from source package, sometimes in smaller softwares with few dependencies it works for me too, but I had to admit I prefer to get it in working precompiled binaries, so extending pupy to be slackware binary compatible is wonderful.Even more easy for an newbie is workink with .sfs (puppy) and .mo (SLAX) modules!
Ralph
wuwei
Tried 2.20 and did an experimental upgrade from 2.17.1.
Everything works fine, even my internet connection (use tkpppoe on a dsl-modem).
Did all my adjustments and created a new ISO with Dougal. Burned it to CD with Grafburn. But when I booted from that remastered CD and tried to restart, the SAVE to CD function did not work. It starts fine, but does not write to CD, and yes, it is a multisession CD.
Okay maybe I am new to this, but that function works fine in 2.17.1.
Maybe there is a glitch here?
wuwei
Everything works fine, even my internet connection (use tkpppoe on a dsl-modem).
Did all my adjustments and created a new ISO with Dougal. Burned it to CD with Grafburn. But when I booted from that remastered CD and tried to restart, the SAVE to CD function did not work. It starts fine, but does not write to CD, and yes, it is a multisession CD.
Okay maybe I am new to this, but that function works fine in 2.17.1.
Maybe there is a glitch here?
wuwei