Wary Puppy 0.9 (090) feedback

[tlchost]

The Open Office problem with the '35 kernel is a bit of a show stopper really.

Total show stopper in terms of having a system that can be used in a business environment.

Noticed the same problem with a bootable USB setup if that's any help.

Thom

[DaveS]

Confirming OpenOffice problem with .sfs, '35 Kernel. I downloaded the latest OO with the evil Oracle branding, built a new .sfs and it still totally locks up the system requiring a hard re-start.
I did not try with a .pet install, cant see why it should be any different.

[ICPUG]

Beem,

I have been looking at your latest posts (Friday - Saturday) regarding your save file problem. You ask a lot of questions and I think the answer to most of them is that the new init script coping with simple filenames is probably the cause of most of it.

I am not saying the new init script is better or worse - I haven't looked at it yet. I was quite intrigued when Barry first mentioned it on his blog as it might have brought back (in a different way) some of the changes we made in 4.2.1 to speed up booting when psubdir, etc is specified. It may be that the new init script is better and that we have to modify our behaviour a bit to get things working as we would like.

I am getting a little unclear as to where you put your files. In your early posts you state the puppy files are on sda1 with the save file on sda2. In your Friday post you say you copy the wary sfs to /mnt/home - which is on sda2. Do you do something on first run and then change the file position?

I would suggest removing the wary sfs file from sda1 once you have copied it to /mnt/home on sda2. Now it will be impossible to find it on sda1 and I wonder what happens now. I think wary in the new scheme of things will use the first it finds if there is more than 1 which may be why your pupstate does not reflect the movement. I am hoping my suggestion resolves this.

I am not sure why you don't keep your sfs files with the pupsave file anyway.

The way I operate is to keep my vmlinuz, initrd.gz, pupXXX.sfs and pupsaveXXX.2fs all in a subdirectory on a separate partition from my Windows partition (in my case sda5). The menu.lst is altered accordingly to point to vmlinuz and initrd.gz. I personally use PMEDIA, PDEV1 and PSUBDIR as well so that I don't get a choice of save files - just the right one to go with my selected puppy.

This isolates my puppies from each other as well as from Windows. The only problem I have run into is when I recently ran a Puppy Live CD for testing purposes forgetting that it searches everywhere and it tried to update one of the pupsave files it found! It had been so long since I ran a Live CD I forgot about the necessity for pfix=ram!

One of your queries in this thread and elsewhere is why the change in filename from wary-xxx.sfs to wary_xxx.sfs.

Barry did mention this in his blog somewhere.

If you remember filenames always used to be underscore and not hyphen. When it changed a lot of people found they were getting file not found errors because if they used Windows tools they found the hyphen got changed to an underscore. (This was all to do with CD file formats).

[DaveS]

For the sake of completeness, tried Open Office as a .pet install. Same problem, so it is nothing to do with .sfs handling I guess.

[Béèm]

Beem,

I have been looking at your latest posts (Friday - Saturday) regarding your save file problem. You ask a lot of questions and I think the answer to most of them is that the new init script coping with simple filenames is probably the cause of most of it.

I am not saying the new init script is better or worse - I haven't looked at it yet. I was quite intrigued when Barry first mentioned it on his blog as it might have brought back (in a different way) some of the changes we made in 4.2.1 to speed up booting when psubdir, etc is specified. It may be that the new init script is better and that we have to modify our behaviour a bit to get things working as we would like.

I am getting a little unclear as to where you put your files. In your early posts you state the puppy files are on sda1 with the save file on sda2. In your Friday post you say you copy the wary sfs to /mnt/home - which is on sda2. Do you do something on first run and then change the file position?

I would suggest removing the wary sfs file from sda1 once you have copied it to /mnt/home on sda2. Now it will be impossible to find it on sda1 and I wonder what happens now. I think wary in the new scheme of things will use the first it finds if there is more than 1 which may be why your pupstate does not reflect the movement. I am hoping my suggestion resolves this.

I am not sure why you don't keep your sfs files with the pupsave file anyway.

The way I operate is to keep my vmlinuz, initrd.gz, pupXXX.sfs and pupsaveXXX.2fs all in a subdirectory on a separate partition from my Windows partition (in my case sda5). The menu.lst is altered accordingly to point to vmlinuz and initrd.gz. I personally use PMEDIA, PDEV1 and PSUBDIR as well so that I don't get a choice of save files - just the right one to go with my selected puppy.

This isolates my puppies from each other as well as from Windows. The only problem I have run into is when I recently ran a Puppy Live CD for testing purposes forgetting that it searches everywhere and it tried to update one of the pupsave files it found! It had been so long since I ran a Live CD I forgot about the necessity for pfix=ram!

One of your queries in this thread and elsewhere is why the change in filename from wary-xxx.sfs to wary_xxx.sfs.

Barry did mention this in his blog somewhere.

If you remember filenames always used to be underscore and not hyphen. When it changed a lot of people found they were getting file not found errors because if they used Windows tools they found the hyphen got changed to an underscore. (This was all to do with CD file formats).

I consider the puppy files in their respective directories on sda1 only a way to boot, like from a CD.
Once on the desktop I don't need sda1 and it isn't mounted anymore which suits me very well, as it is the Windows partition and I don't like it to be mounted and open for anything coming in through wine.

I operated this way from certainly 3.xx on. For 2.xx I am not sure.
In the puppy boot process when booting with pfix=ram I always see that the puppy sfs is copied to /mnt/home. Therefor I make sure it is done. If it isn't done correctly, I have a kernel panic.
In puppy 3.xx this cause me problems as the puppy sfs file all had the same name, but a different contents for different releases.
Happily this changed somewhere in 4.xx.

Therefor as soon as I saw Barry's idea to use simplified names, I knew I would run into problems.

So yes indeed I think also that the new approach of the initrd causes what I experience now.

I'll do a test to see if the sda1 is still mounted also when the wary_090 is made inoperable in sda1. I'll let know.

I must have missed the information in the blog for the change to use the underscore.

[Béèm]

Beem,

I have been looking at your latest posts (Friday - Saturday) regarding your save file problem. You ask a lot of questions and I think the answer to most of them is that the new init script coping with simple filenames is probably the cause of most of it.

I am not saying the new init script is better or worse - I haven't looked at it yet. I was quite intrigued when Barry first mentioned it on his blog as it might have brought back (in a different way) some of the changes we made in 4.2.1 to speed up booting when psubdir, etc is specified. It may be that the new init script is better and that we have to modify our behaviour a bit to get things working as we would like.

I am getting a little unclear as to where you put your files. In your early posts you state the puppy files are on sda1 with the save file on sda2. In your Friday post you say you copy the wary sfs to /mnt/home - which is on sda2. Do you do something on first run and then change the file position?

I would suggest removing the wary sfs file from sda1 once you have copied it to /mnt/home on sda2. Now it will be impossible to find it on sda1 and I wonder what happens now. I think wary in the new scheme of things will use the first it finds if there is more than 1 which may be why your pupstate does not reflect the movement. I am hoping my suggestion resolves this.

I am not sure why you don't keep your sfs files with the pupsave file anyway.

The way I operate is to keep my vmlinuz, initrd.gz, pupXXX.sfs and pupsaveXXX.2fs all in a subdirectory on a separate partition from my Windows partition (in my case sda5). The menu.lst is altered accordingly to point to vmlinuz and initrd.gz. I personally use PMEDIA, PDEV1 and PSUBDIR as well so that I don't get a choice of save files - just the right one to go with my selected puppy.

This isolates my puppies from each other as well as from Windows. The only problem I have run into is when I recently ran a Puppy Live CD for testing purposes forgetting that it searches everywhere and it tried to update one of the pupsave files it found! It had been so long since I ran a Live CD I forgot about the necessity for pfix=ram!

One of your queries in this thread and elsewhere is why the change in filename from wary-xxx.sfs to wary_xxx.sfs.

Barry did mention this in his blog somewhere.

If you remember filenames always used to be underscore and not hyphen. When it changed a lot of people found they were getting file not found errors because if they used Windows tools they found the hyphen got changed to an underscore. (This was all to do with CD file formats).

I consider the puppy files in their respective directories on sda1 only a way to boot, like from a CD.
Once on the desktop I don't need sda1 and it isn't mounted anymore which suits me very well, as it is the Windows partition and I don't like it to be mounted and open for anything coming in through wine.

I operated this way from certainly 3.xx on. For 2.xx I am not sure.
In the puppy boot process when booting with pfix=ram I always see that the puppy sfs is copied to /mnt/home. Therefor I make sure it is done. If it isn't done correctly, I have a kernel panic.
In puppy 3.xx this cause me problems as the puppy sfs file all had the same name, but a different contents for different releases.
Happily this changed somewhere in 4.xx.

Therefor as soon as I saw Barry's idea to use simplified names, I knew I would run into problems.

So yes indeed I think also that the new approach of the initrd causes what I experience now.

I'll do a test to see if the sda1 is still mounted also when the wary_090 is made inoperable in sda1. I'll let know.

I must have missed the information in the blog for the change to use the underscore.

Wary 090 wants the wary_090.sfs on sda1.
At the point of switch root I got a kernel panic. So the init script doesn't look on sda2. Altho the message before the switch was that wary_090.sfs was loaded.

Also I come to a certain conclusion that the new init script fills in parameters if not given in the kernel line. Example in my case PDEV1='sda1' which I didn't supply anywhere.
I think the same is true for PSUBDIR=

Another reason for having my save files on another partition is, that sda1 was rapidly out of space. A certain moment I had save files of 512MB.

[ICPUG]

I think what you are telling me Beem is that Wary wants puppy sfs on sda1 if you do not specify pdev1 (which you don't). I really must install Quirky 1.3 or Wary 0.9 to see what happens when you specify pdev1 as I do. It would be a fail in my eyes if it did not respect pdev1.

It seems what may have changed is the default behaviour. Previously puppy searched everywhere - now it only searches sda1 by default.

This copying of the sfs to /mnt/home by puppy is something Barry introduced in series 4 (I think). If you keep the save file and the sfs file in the same folder it does not happen.

You say the sfs is on sda1 purely for boot up but you have still not answered why you cannot put it with the save file on sda2 right from the get go. Even more reason if sda1 was getting short of space. OK the default option of Wary90 seems to fail with this configuration but we don't know what happens when pdev1 is specified.

This post in the comments to 'Welcome 1st Boot' entry on Barry's blog seems to show he is doing some work on the init script.


Quote
Posted on 20 Oct 2010, 8:57 by BarryK
Re welcome
It is in Woof, so applies to all builds.

Um, I really should upload the latest Woof. I was holding off until I had fully debugged the file-finding in the init script, which currently has a few issues. Well, I will see if I can get that sorted out pronto.
Unquote

[maddox]

battery tray icon:
doesn't display charge rate or color. Clicking on batt tray icon displays a pop-up box with contents from /proc/acpi/battery/BAT1 and BAT2 slots
.. seems that maybe the slot/file info is mixed up in this powerapplet_tray.
Tried replacing the file from quirky-13/wary-06, charge rate & color is restored but update time is variable (worst case 2~3min).
rebooted live-cd, then waited 1 min for welcome msg to disappear (/var/log/messages tz time/date skew, another post)
unplugged AC : screen goes to lowest brightness level and laptop charge led switches off after 1~2 sec
plugged in AC : backplane brightnes is directly restored, but there is a 16~18 sec delay before laptop battery charge led switches on (this was rather fast in other versions, 1~2 sec delay)
if I unplug AC, then wait 3~12 sec & replugin AC and click on batt icon in tray before the imparted delay, I get a 'charging state: charged'
after the delay it indicates 'charging state: charging'

from a translators point of view : the battery pop-up box reveals a lot of usefull info for those who speak the lingo,
a colored icon is nearly universal & does show me when it's nearly out of juice, albeit the hover tooltip.
My laptop battery is rather tired : 'design capacity: 4400 mAh' 'last full capacity: 2554 mAh' ~53% usefull capacity left

nice to see the atiX600 16 bit color depth work.

[ICPUG]

Following up my last post.

I have now installed Quirky 1.3. You are right Beem. If the sfs is not on sda1 and you do not specify PDEV1 etc it does not get found.

However, my approach of storing everything on a non-windows partition (sda5) AND SPECIFYING PMEDIA, PDEV1, PSUBDIR still works.

Barry's blog says he is now testing a fix to solve your problem so it looks as if you may have two solutions!

[peebee]

One of my "New Puppy" tests is to see if digital TV DVB-T works:

wary090 - mplayer does not seem to support DVB-T which is a shame? unless I've missed something

luci232 - DVB-T works just great

dpup010 - same mplayer as luci232 but it just flashes the window a lot and then dies.

Cheers
Peter

[Billtoo]

After adding libsamplerate_DEV-0.1.6-w5.pet and
libsamplerate-0.1.6-w5.pet I was able to compile deadbeef-0.4.2.The
source code for deadbeef is available at sourceforge.net.
Deadbeef is a good music player and also plays audio cds.

[rjbrewer]

Wary has an odd Gparted that insists on leaving 1mb of free space
before every new partition?

[JonT]

With my fussy Intel 845 graphics, the Wary 0.9 2.6.30.5 kernel version has good video with i810 and Xvesa.

The 2.6.35.7 version works properly only with Xvesa (md5sum checked). i810 results first in 5-10 seconds of a normal screen (sometimes with a flickering cursor), then a black screen. On ctrl-alt-backspace, "xwin" (typing blindly, no video) Wary runs normally until an attempt to "exit to prompt", shut down. etc. which gives a black screen (i.e. no visible console) though typed commands function normally, just no video. I made a save file by blindly hitting "enter" to take defaults on shutdown. I realize there are other, more significant problems with this kernel.

One funny bug, likely something simple: for both kernels, Ogle and Mplayer work, but once a DVD is inserted, Ogle runs when Mplayer is selected from the main menu. To use Mplayer, it must be opened before inserting the DVD.

Not complaining, just FYI. My graphics system is so picky; wouldn't want to hold up progress.

[Béèm]

You say the sfs is on sda1 purely for boot up but you have still not answered why you cannot put it with the save file on sda2 right from the get go.

Maybe I didn't explain well enough.
The sfs and the save file are on sda2 (/mnt/home)
This has always been the case.

So at first boot, sda1 is taken the lead.
After the save to sda2, sda1 is taken the lead to boot as from CD, but gives control to sda2 to load the save and sfs.

[ICPUG]

Beem

I am not explaining myself clearly enough.

On my XP machine I NEVER use sda1 to boot the sfs from, not even at first boot.

I put the sfs on sda5 (actually in a subdir - but you could leave it at /mnt/home if you must).

At the end of first boot you are asked to create a save file and the default location will be the same as the sfs file.

Of course, grldr and menu.lst is always on sda1 but I don't think we are talking about that.

[Béèm]

ICPUG, I see.
Unfortunately, I only have sda1 (ntfs the XP one) and sda2 (fat)
The latter isn't big enough to hold also the puppy files. For the save files I can cope.

I have a external USB HDD, which I could use for the save files, thus freeing space on sda2.

If I could boot from such a external HDD, that would be great, but as far as I understand puppy doesn't permit this.
This external HDD is used only for the moment for data.

[Billtoo]

I got a new pc and the only puppy that will work on it so far is wary
090 2.6.35.7 and even that can't see the wireless adaptor but it works
with eth0, also works with a usb wireless adaptor by linksys that I
have.
The graphics card is an ati radeon hd 5570 and I downloaded the
ati-driver-installer-10-10-x86.x86_64.run file and after installing
the devx and kernel source sfs files (and renaming depmod and
depmod-FULL) I exited to the prompt and installed the ati driver, that
worked:
# report-video
VIDEO REPORT: Wary Puppy, version 090

Chip description:
oem: ATI ATOMBIOS
product: REDWOOD 01.00

Driver used by Xorg:
#card0driver

Video mode used by Xorg:
Resolution: Depth 24 Depth: "Display"

...the above also recorded in /tmp/report-video
#
I also had a little problem with sound but it's working okay now.
I'm running live with a save file and it's working well, I look
forward to trying the next wary release on it.

edit: I've done everything as above but with wary 070 kernel 2.6.34.1 and it's working well so far.I think it's working better actually.

edit: I running live with a save file wary 092 kernel 2.6.34.6 and the devx is still uploading so I renamed the 090 devx and installed that along with the kernel source sfs for 2.6.34.6 and then exited to the prompt and ran the ati-driver-installer-10-10-x86.x86_64.run file.I saw that the depmod didn't need changing and the driver installed okay.
# report-video
VIDEO REPORT: Wary Puppy, version 092

Chip description:
oem: ATI ATOMBIOS
product: REDWOOD 01.00

Driver used by Xorg:
#card0driver

Video mode used by Xorg:
Resolution: Depth 24 Depth: "Display"

...the above also recorded in /tmp/report-video
# uname -r
2.6.34.6
#
I will test more but it's working good on this pc so far.

[taca0]

How I can used wary 092 with the xorg version 1.4.2 of Wary 030 ?? Thats the only version that works stable for Via CLE266 chip.


Thanks!

[BarryK]

How I can used wary 092 with the xorg version 1.4.2 of Wary 030 ?? Thats the only version that works stable for Via CLE266 chip.


Thanks!

What do you mean by "stable"?

It might just be a matter of compiling a later Via X driver for 092.

If you are in to compiling packages, you can do it yourself. Sources here:

http://www.x.org/releases/individual/driver/

It goes something like this:

# ./configure --prefix=/usr/X11R7 --sysconfdir=/etc --localstatedir=/var --build=i486-pc-linux-gnu
# make
# new2dir make install

Some driver sources need the xorg-server source, like this:

# ./configure --prefix=/usr/X11R7 --sysconfdir=/etc --localstatedir=/var --build=i486-pc-linux-gnu --with-xserver-source=/mnt/sdb3/downloads/input080/xorg-server-1.3.0.0

[BarryK]

...er, I just noticed that the via X driver hasn't been updated since 2006, and Wary 092 already has the latest. So much for that.