Page 2 of 44

Woof-CE savefile - shutdown bug

Posted: Fri 12 Dec 2014, 15:25
by LateAdopter
Hello 666philb

Thanks for providing this. I try any 64 bit puppies, as 32 bit ones have too low video decode/playback on my hardware.

tahrpup64 has the savefile-shutdown bug that is common to all woof-CE puppies that I have tried. e.g. slacko64 and a trusty64 built with jamesbond's woof-ce-next. Woof2 puppies and fatdog64 don't have the problem.

If I boot without a savefile, there is no problem.

If I boot with a savefile and shutdown, the next boot has this error in the messages:

Code: Select all

FAT-fs (sda5): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Win2k complains too, and runs the disk check.

I don't know how to debug shutdown, because it doesn't create any logfiles.

If I run another puppy, that doesn't have the bug, from the same partition and shutdown, it doesn't clear the error.

I presume this implies that the savefile is been left open when the woof-CE puppy is shut down.

My puppies run from a FAT32 partition. Is there anything I can do to help solve this? Thanks.

Posted: Fri 12 Dec 2014, 18:34
by Satori
Hiyas..

boots, connects and runs well on my dell E6510 / i7Q, finds 8 cores.

I'll try to get nvidia going, are the kernel source files the same as the 32bit version?

Posted: Fri 12 Dec 2014, 19:33
by 666philb
Satori wrote:Hiyas..

boots, connects and runs well on my dell E6510 / i7Q, finds 8 cores.

I'll try to get nvidia going, are the kernel source files the same as the 32bit version?
no .. they should be at the same link as the iso

Posted: Sat 13 Dec 2014, 23:27
by Terry H
Have just downloaded and manual frugal install on my desktop PC (HP H8 FX-6100, AMD Radeon 7450 Video card, 10 GB RAM, Broadcom WIFI, 1920 x 1080 monitor).

Setup no problems, wifi working, correct resolution on monitor. All OK after reboot and created save folder.


So far , so good. Thank you, well done.

savefolder - using symbolic links

Posted: Tue 16 Dec 2014, 08:36
by gyro
First boot -> desktop fine, ethernet fine.
Created a savefolder on reboot, everything looks good.

On investigation I found that the savefolder was accessed via a 'mount -o bind'.
So, I started to create the patched stuff to support the implementation of savefolder using symbolic links.
The patch to the 'init' script went smoothly.
The patch to 'rc.shutdown' failed, so I had a closer look at the scripts in tahrpup64.
It appears that the script patches required to implement savefolder using symbolic links, are already included in tahrpup64, except for the 'init' script.

This is not a real problem since all the 'savefolder' patches make things work with either the new or the old, which ever is used.

I then made a patched 'initrd.gz' and rebooted.
Then the savefolder is accessed as a symbolic link and all seems ok, except 'freememapplet_tray' crashes.

So, a patched "initrd.gz" is here, http://www.fishprogs.info/puppy/tahr64/initrd.gz.
And a "ydrv" containing a patched "freememapplet_tray" is here, http://www.fishprogs.info/puppy/tahr64/ ... _6.0.2.sfs

The "frememapplet_tray" binary is one I compiled for Slacko64.

gyro

.jwmrc-tray gets reset on boot

Posted: Wed 17 Dec 2014, 14:23
by gyro
Found a slight annoyance.
Deleting the buttons in the tray does not persist. I usually run puppies with only the 'menu' button in the tray.

If I delete the buttons and restart X, they remain deleted.
If I view '/root/.jwnrc-tray' from another puppy, it's as expected, but after booting into tahrpup64 again, it's identical to the one in 'puppy_tahr64_6.0.2.sfs', the buttons are back.
It seems that '/root/.jwmrc-tray' is clobbered with it's original version during each boot.

It seems to be happening while 'rc.services' is in "wait for snd_ modules to complete loading", but it doesn't look like the code in that loop could be doing it.
The code in 'rc.sysinit' following the call to 'rc.services' doesn't look like it is the culprit either.

It doesn't matter if I use a savefolder or a savefile, or if I use the released 'initrd.gz' or my patched 'initrd.gz'.

I have a very crude workaround;
1) After deleting the buttons, make my own copy of '/root/.jwmrc-tray'.
2) Place a script in '/etc/init.d/' that clobbers '/root/.jwmrc-tray' with my own copy.

gyro

Posted: Wed 17 Dec 2014, 16:28
by 666philb
hi giro,

yes lots of settings aren't being saved ..... or are being overwritten by the base files .
same with rox pinboard and wallpaper.

Managing SFSs in Live/Frugal boots

Posted: Wed 17 Dec 2014, 19:49
by gcmartin
666philb, in your opening post, you wrote:...or download the libreoffice+gimp64.sfs from the link above
Question
If one downloads those SFS files, can they be placed in root/folder on the ISO (via ISOMASTER, say) and the boot process will discover and incorporate them into the running system (simlar or alike what @TaZoC does in his Lighthouse distros)?

Curious if this is automatically or must be loaded manually to get them to present themselves in the running desktop.

Thanks in advance

Posted: Wed 17 Dec 2014, 22:41
by radky
Many of the standard Netpbm utilities (graphics tools and converters) are missing in tahrpup64.

For example, the wallpaper application calls the /usr/sbin/background_reshape utility which requires the following graphic tools:

jpegtopnm
pnmtojpeg
pnmtopng
pnmcut
pamcut

Posted: Thu 18 Dec 2014, 08:39
by gyro
666philb wrote:yes lots of settings aren't being saved ..... or are being overwritten by the base files .
same with rox pinboard and wallpaper.
I'm pretty sure files are being saved but then overwritten.
When I boot into another puppy, I can see the correct modified file in tahrpup64's savefolder.

Note: I think the timing in my previous post could be unreliable.
The overwriting could be happening directly (outside aufs), I was dumping the file as '/root/.jwmrc-tray', hence via aufs.

EDIT: No, I tested again, accessing the file via it's real path, and it still shows it is being overwritten while 'rc.services' is waiting for 'snd' modules.
Also noticed that the 'Last modified' time was wrong for the good file, but correct for the overwritten file. So it appears that 'time' is also being setup during this interval.

gyro

Posted: Thu 18 Dec 2014, 13:36
by gyro
Could someone please tell me what copies "rc.sysinit" and "rc.update" to "pup_rw"?

EDIT: Or what sets up the 'time'?

gyro

Re: Woof-CE savefile - shutdown bug

Posted: Sat 20 Dec 2014, 09:06
by gyro
LateAdopter wrote:If I boot with a savefile and shutdown, the next boot has this error in the messages:
Sorry LateAdopter, I realise that this comment doesn't really help your situation.

I consistently get clean shutdowns when using a savefolder on an ext4 partition.

gyro

TAHRPUP64-XFCE ISO

Posted: Thu 25 Dec 2014, 18:01
by zagreb999
TO MR. 666philb !
FOR ONE ELEMENTARY SCHOOL,PLEASE,
DO MAKE TAHRPUP64 WITH XFCE DESKTOP-
TAHRPUP64-XFCE.ISO!
THANK YOU!

Posted: Wed 31 Dec 2014, 03:17
by futwerk
background.

Posted: Sat 03 Jan 2015, 01:12
by live
Hi 666philb,

First review tahr64-6.0.2.iso, from http://distro.ibiblio.org/puppylinux/pu ... o/testing/

What a great job!

Now I'll annoy you a bit :)
Some common issues as with the beta of tahr32, suppose some script issue:

* No menu icon for multi monitors, and please prefix menu name as multi monitors
* Global font size, allow for larger font size
* missed opus codec
* misses common MIME association with extensions: jp2(jpeg2000), tif or tiff, wma, opus
* ntfs-3g is not version 2014
* openssl latest??
* Geany update to 1.24.1 preferably with:
Files>Default encoding=UTF-8
Interface>Toolbar>Image only
Editor>Complitions>XML/HTML tag auto-closing
Would be nice if you add in standard Vibrant Ink theme (for dark background)
See http://www.geany.org/download/extras

Other issues
* at first launch no request for Internet Connection configuration
* pfind does NOT launch
* missing QuickPet
* wishing ROX with first video preview enabled, such as Vanguard Carolina 1.3 (http://www.murga-linux.com/puppy/viewtopic.php?t=96863), and second with pdf preview.

Personal preferences:
* SMplayer over VLC (UI is not as convenient as SMplayer)
* Firefox over Seamonkey
* gcc 4.8.4 or gcc 9.2

Suggest to remove:
* Leafpad (redundant with Geany)
* Meld instead Xfdiff
* games and put them as a separated sfs or pet

Many thanks for your work

tahrpup64 pre-alpha

Posted: Tue 27 Jan 2015, 02:18
by icake
Thanks 666philb for all the work on tahrpup64.

I have made 2 half-Chinese and 2 Chinese Language pets for tahr64 6.0.2. These will enable users to display and input Chinese (applicable to both Simplified and Traditional Chinese) in tahrpup64 6.0.2.

For more details and download addresses, please see these links:

English: http://murga-linux.com/puppy/viewtopic. ... &start=210

Chinese: http://www.minilinux.net/node/2545?page=1

Posted: Thu 19 Mar 2015, 21:39
by LazY Puppy
Hi.

I don't know if anyone has posted this, but Tahr 64 6.0.2 seems to lack pfilesearch, so pfind won't work.

Can I just install a version from the forum?

Posted: Thu 19 Mar 2015, 22:08
by LazY Puppy
Please have a look first at my post above.

Also pgprs is not included (WoofCE trouble, but fixed lately by mavrothal).

Like in Tahr 6.0 I installed the package from Slacko 5.7 (provided by SFR earlier) and it works out of the Box - now online using Thar 64 with an modified initrd.gz (init script).

Posted: Fri 20 Mar 2015, 04:35
by LazY Puppy
Hi.

Just discovered a third issue.

When extracting a .pet (by right click action), the wrapper exits with an error.
'tar -xf internet-fix21947.tar.gz' failed in
/mnt/sdd1/Downloads/00-2015-03-19-Tahr64 with error code 2.
'tar -xf pgprs-s5720425.tar.gz' failed in
/mnt/sdd1/Downloads/2015-03-19 with error code 2.
The internet-fix.pet was downloaded from forum and the pgprs-s57.pet was build using Tahr64.

This doesn't seem to happen on all .pet packages.

Extracting pfilesearch-2.1.pet and pfind-6.2.pet (downloaded from forum) finished successfully. Also some of my own .pet packages (created with a Lucid and/or Precise based Puppy) do extract successfully.

Any hints?

Thanks.

Posted: Fri 20 Mar 2015, 21:43
by 666philb
hi LazY Puppy

yes there's quite a bit wrong with tahrpup64! the biggest problem is ..
one bug that keeps occuring.

in /lib and /usr/lib there are symlinks called 'x86_64-linux-gnu' which are links to the /lib and /usr/lib folders

occasionally when installing something, either manually or from the PPM, the symlink gets overwritten with an actual folder causing catastrophic failure needing hard power off. you then need to boot pfix=ram and delete the folder & .wh file to rescue the save.
i don't recommend using tahrpup64 at the moment as so much needs fixing. i will revisit it eventually (when i get some time) and see if i can get it up to snuff