tahrpup64 6.0.5 CE

[James C]

.

[peebee]

Hi 666philb

Downloaded and frugally installed on my HP laptop with Intel graphics.
Booted to desktop - tick.
Rebooted and created savefolder - tick.
Established Broadcom B43 wifi through sns - tick.
Used sfs-load to install Chromium64 - tick.
Ran Chromium64 - tick.

Only problem so far - pfind doesn't work - running in terminal indicated pfilesearch is missing.....

Cheers
peebee

[666philb]

Hi 666philb

Downloaded and frugally installed on my HP laptop with Intel graphics.
Booted to desktop - tick.
Rebooted and created savefolder - tick.
Established Broadcom B43 wifi through sns - tick.
Used sfs-load to install Chromium64 - tick.
Ran Chromium64 - tick.

Only problem so far - pfind doesn't work - running in terminal indicated pfilesearch is missing.....

Cheers
peebee

missed that http://www.murga-linux.com/puppy/viewtopic.php?t=26764

cheers

[don570]

Fast download site of tahrpup64 iso

http://ftp.nluug.nl/os/Linux/distr/pupp ... o/testing/

[Illutorium]

X.org broken at AMD Radeon HDMI output. (alpha2 as 6.0.2)
In the rest: Works.

[LateAdopter]

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.

does anyone have any ideas why it's happening and how to stop it?

When an archive is extracted from a package, it overwrites anything already there without asking.

I'm no linux expert, but I repackaged a load of mesa 10.4 debs for fatdog. The process of extracting all of the data.bz files into a directory tree creates the multiarch folders. For fatdog I had to rearrange and rename the folders anyway to fit the fatdog rules, so it didn't matter.

Presumably the package manager (petget?) code needs to be modified so that it writes the files, but does not create the directories unnecessarily.

EDIT

It could be that you are using busybox and not the real dpkg-deb to do the installation.

[radky]

tahrpup64 pre-alpha

perl: error while loading shared libraries: libperl.so.5.18: cannot open shared object file: No such file or directory

http://packages.ubuntu.com/trusty/amd64 ... e/download

[radky]

run pclock 3.5 in terminal, then exit

sh: line 17: echo: write error: Broken pipe
sh: line 18: echo: write error: Broken pipe

[James C]

Forgot to mention it last night, "Screeny" the screenshot app produces an empty png file.I installed and used MTpaint for the screenshot in the prior post.
Conky and Dillo also installed and working with no apparent problems.

[neerajkolte]

HI,
Tahr64-6.0.2 boots ok on my intel i3, intel Dh61BF, two monitors, one connected to vga another to dvi.
Net connected through my droid usb0.

Will test more.
Thanks.

- Neeraj.

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

[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?

[666philb]

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

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

[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

[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

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

[gcmartin]

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

[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

[gyro]

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