tahrpup64 6.0.5 CE

[Snail]

In 6053, clicking on the button for the PPM Introduction that is in the Install Applications panel simply takes you to the Tahrpup64 jumping-off page. This is not all that helpful. Would it be better to go to the Howto for the PPM?

file:///usr/local/petget/help.htm

I would also like to suggest that the paragraph and link to Tahrpup's internal documentation should be at the very top of the Tahrpup64 jumping-off page, instead of right at the bottom, as it is at present. The current top link takes you to a very detailed but dated puppy website. The internal docs seem a lot better to me.

[torgo]

Sorry for the somewhat off-topic question, but seeing this I had to jump at the opportunity to ask...

The motherboard is an ASUS M2NPV-VM with integrated graphics most closely resembling early Quadros and sometimes designated as type 6150. Hardware-info describes this as NV4E.

Prehistoric - have you been able to get the component TV-out working in any version of Puppy? Or any version of Linux, for that matter?

I have three of these motherboards, and I'm wondering what it would take to get them to feed video through the component-out in Puppy, be it Precise or Tahr or Xenial or whatever. I haven't had any luck with it so far in Ubuntu.

[Pelo]

lazpaint is an application for both 32 and 64 bits, but i fail to launch it on tahrpup64, whatever the version.
I rarely use 64 bits Puppy. Because applications are not fun, old
Could somebody make a pet or SFS for Lazpaint 64 bits ?
"Image editor, like PaintBrush or Paint.Net, written in Lazarus (Free Pascal)."
"LazPaint
LazPaint Yes I appreciate any help. I am developping under Windows, however I apply adjustements so that it works well on Linux as well." Puppy Linux 32 bits (Slacko, Racy, and OBprecise ok) had no trouble with last version, and previous too.

[James186282]

A belated Merry Christmas to you all.

I'm having problems with USB 3 on my machine. I "think" the driver I'm supposed to see for this is the xhci driver? It doesn't seem to appear if I look for it with lsmod. There is a pet floating around that worked the first time I installed it but after that I get solid (good) messages about it finding the hardware but then

xhci_hcd 0000:01:00.0: Timeout while waiting for setup address command
xhci_hcd 0000:01:00.0: Stopped the command ring failed, maybe the host is dead
xhci_hcd 0000:01:00.0: Abort command ring failed
xhci_hcd 0000:01:00.0: HC died; cleaning up
xhci_hcd 0000:01:00.0: Timeout while waiting for setup address command
xhci_hcd 0000:01:00.0: Abort the command ring, but the xHCI is dead.
usb 4-4: device not accepting address 2, error -108

Not sure if this is connected but directly after the hardware is found I get this warning
fusbh200_hcd: FUSBH200 Host Controller (EHCI) Driver
Warning! fusbh200_hcd should always be loaded before uhci_hcd and ohci_hcd, not after

I tried the hardware info program and it sees
USB Controller VIA tech inc VL80x xHCI USB 3.0 Controller (rev 03) (prog-if30 [XHCI])

[jlst]

I notice that in this new version the "openssl version" is still 'OpenSSL 1.0.1f 6 Jan 2014' (same as the previous Tahr64 pup). Isn't this several versions ago of the latest openssl??? Do you happen to have the latest, updated version of openssl complied for Tahrpup64 (it's sort of important nowadays given the attack vectors by hackers)? Maybe so that we can download the latest as a pet and easily install it? Or do each of us--gulp--have to download the 'devx' files and then attempt to compile the latest openssl version for ourselves??

Again, mucho thanks for the latest Tahr64 pup!


P.S. [Edit] Wait, I remember Peebee explaining to me awhile back the crazy scheme ubuntu uses when updating something. Even when they update it, they still leave the same number. So maybe the openssl 1.0.1f is the latest??? Dang, wish I understood this stuff better. Now I know why Peebee said it is so much easier to grasp in Slacko---and it is!!! Slacko (like debian & the dogs), makes it flippin' simple to understand if you have the latest version of something, especially something important like openssl. If anyone knows the answer about this 1.0.1f version in the latest tahrpup64, would appreciate any feedback

I noticed that in ubuntu and debian.. apps require a specific version of a lib... and because they're compiling newer libs without recompiling the apps that depend on them... they keep the same name and stuff..

[radky]

removed - wrong thread

[James C]

Quick manual frugal test install of Tahr64 6.0.5.3.All good so far.

Code: Select all

root# inxi -Fxx
System:    Host: puppypc14195 Kernel: 3.14.79 x86_64 (64 bit, gcc: 4.8.4) 
           Desktop: JWM 2.3.6 dm: N/A Distro: tahrpup64 6.0.5.3
Machine:   Mobo: ASUSTeK model: M5A97 LE R2.0 version: Rev 1.xx serial: 150545593600028
           Bios: American Megatrends version: 2601 date: 03/24/2015
CPU:       Hexa core AMD FX-6300 Six-Core (-MCP-) cache: 12288 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm) bmips: 42144.7 
           Clock Speeds: 1: 1400.00 MHz 2: 1400.00 MHz 3: 1400.00 MHz 4: 1400.00 MHz 5: 1400.00 MHz 6: 3500.00 MHz
Graphics:  Card: NVIDIA GT218 [GeForce 210] bus-ID: 01:00.0 chip-ID: 10de:0a65 
           X.org: 1.15.1 drivers: nouveau (unloaded: vesa) tty size: 68x23 Advanced Data: N/A for root 
Audio:     Card-1: NVIDIA High Definition Audio Controller driver: snd_hda_intel bus-ID: 01:00.1 chip-ID: 10de:0be3 
           Card-2: Advanced Micro Devices [AMD/ATI] SBx00 Azalia (Intel HDA) 
           driver: snd_hda_intel bus-ID: 00:14.2 chip-ID: 1002:4383 
           Sound: Advanced Linux Sound Architecture ver: k3.14.79
Network:   Card: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller 
           driver: r8169 ver: 2.3LK-NAPI port: d000 bus-ID: 02:00.0 chip-ID: 10ec:8168
           IF: eth0 state: up speed: 100 Mbps duplex: full mac: 1c:87:2c:5a:bb:e2
Drives:    HDD Total Size: 1120.2GB (-)
           1: id: /dev/sda model: KINGSTON_SV300S3 size: 120.0GB serial: N/A 
           2: id: /dev/sdb model: WDC_WD10EZEX size: 1000.2GB serial: N/A 
Partition: ID: swap-1 size: 8.60GB used: 0.00GB (0%) fs: swap 
RAID:      System: supported: linear raid0 raid1 raid10 raid6 raid5 raid4 
           No RAID devices detected - /proc/mdstat and md_mod kernel raid module present
           Unused Devices: none
Sensors:   None detected - is lm-sensors installed and configured?
Info:      Processes: 128 Uptime: 13 min Memory: 313.9/15931.2MB Runlevel: 5 Gcc sys: N/A 
           Client: Shell (bash 4.3.42 running in urxvt) inxi: 1.9.17 

Code: Select all

root# free
             total         used         free       shared      buffers
Mem:      16313540      1062376     15251164            0        97588
-/+ buffers:             964788     15348752
Swap:      8396796            0      8396796
root# 

[LateAdopter]

I notice that in this new version the "openssl version" is still 'OpenSSL 1.0.1f 6 Jan 2014' (same as the previous Tahr64 pup). Isn't this several versions ago of the latest openssl??? Do you happen to have the latest, updated version of openssl complied for Tahrpup64

You can install the latest version from the ubuntu Trusty repo or download the package and then click on it in rox filer to install it.

The last update was 23 sept 2016
http://packages.ubuntu.com/trusty/openssl

WARNING: Ubuntu packages have not been tested on Tahrpup64. Occasionally I try one and it breaks Puppy. So make a test copy of Puppy and try it on that first. Usually they work properly because they are compiled for the exact versions in Trusty Tahr

[peppyy]

Hi All, Remember me? lol been using Puppy for years but the 64 bit has me a little befuddled.tahrpup64 6.0.5CE Fully updated and full hd install.

System HP Desktop A2512p Dual core/ intel/ intel graphics/ 4gb memory/ full install/ and the fastest times I have ever seen reported by hardinfo!

I built it to replace my better half's really old "XP" computer. and I only have a couple things to still workout.

#1 When right clicking a photo and setting it as desktop wallpaper it creates a new directory called x/x/x original. if you then set the desktop background from that folder it is called x/x/x Original Original and so on. Is this something I can change with rox or jwm or pinboard or other?

I downloaded Nathan's Wallpaper setter and it works well on 64 however it does not always show previews and it is tough for her to find the files she used to use without that.

#2 Is there a 64 bit image viewer available that allows her to print from the menu? I didn't want her to have to open Gimp every time and find the file she wants to print before printing a photo or Mandela etc. I have added the 32 bit libs but I can't seem to get any 32 bit apps to work. I noticed in the report that a lot were not installed. I think it was 400+ skipped files.
Edit: 400+ not 4000+
I will save my other questions for later, just wanting to keep the better half happy!

BTW, Great job on this version!

Perhaps I should start an up-to-date search engine?

[mikeslr]

If you've built applications by using debs available from Ubuntu repositories, you are probably familiar with Lazy Puppy's PaDS pet to combine debs into an SFS. My experience was that it didn't work under 64-bit Puppies.

I may have solved that problem: http://www.murga-linux.com/puppy/viewto ... 515#938515

mikesLr

[Puppyt]

WARNING: Ubuntu packages have not been tested on Tahrpup64. Occasionally I try one and it breaks Puppy. So make a test copy of Puppy and try it on that first. Usually they work properly because they are compiled for the exact versions in Trusty Tahr

Dammit, don't I know that now - after my second plug-pull on a halted update of gcc from Ubuntu repositories in my TahrPup64 6.0.5. Found that it wasn't a simple hang when I rebooted into a kernel panic and a page of hieroglyphs. So that's what you get when trying to shoe-horn a FatDog64-710 sfs into TahrPup64 (I was grabbing steps latest R statistical environment offering, v3.1.3 from memory) by trying to stamp out spot-fire incompatibilities, rather than compile from source So I had this brainwave (I know what you're thinking - please be gentle) - what if I replace the damaged (?) kernel with the latest update? I was using a save folder rather than savefile, and just like my earlier glibc brainfade, all my files are intact, so I assume my foot-shooting is limited to kernel issues. Any thoughts on such a recovery process?

[peppyy]

I am running xnview mp on tahr 6.0.5 32 bit and tahr64 6.0.5 The 64 bit linux version worked very well.

Downloaded,extracted to My Applications and click on xnview.sh

I created a shortcut for the desktop and set it as my default image viewer.
So now the issue with photo management is solved.

Now running 3 full installs of Puppy Tahr on 3 different computers, 2 on 64bit and one 32. My latest is a full multimedia machine and although I can use rander to set my desired resolution for my widescreen TV, I am having issues making it stick on boot. Getting closer though.

Created a script in my apps and linked it to startup, works however I would like to execute it at boot. On to more searches!

[belham2]

Hi 666philb (or anyone),

Is there any possibility you can take a look at this problem and point me to a remedy? I posted about it before here (mistakenly put it in the 32-bit thread):http://murga-linux.com/puppy/viewtopic. ... start=1515

I just did another fresh download and install of Tahr64 on a friend's machine here, and sure enough, this problem pooped up again with the latest Tahr64 release. Tahr64-latest release has done this now on 3 different (diff machines) installs. When Tahr gets to the desktop, and if you ever want to click the sd#1 drive icon on the bottom left, look at the error message that pops up....below is a pic of it. You click the icon, and up pops the error msg box saying:

"Arguments (usbdrv ext4) given for non-executable item /root/.pup_event/drive_sde_1"

(also plz check the other link above for more detailed picture---doesn't matter what the sd# is, the problem reproduces on all installs I've done, with different downloaded & md5-checked ISOs, on--as noted--diff machines)

[mavrothal]

Is there any possibility you can take a look at this problem and point me to a remedy?

(the above has a link)

[belham2]

Hi Marv,

Are you referring to this reply in the Tahr32bit thread:

mavrothal
Joined: 24 Aug 2009
Posts: 2786

Please provide some more info.
Are you booting from the particular USB stick?
How is it formatted?
Does it used MBR or GPT?
Do other puppies work fine from the same USB stick?
What is the grub/grub2/grub4dos entry you boot with?
How come sd[a-d] do not appear and start with sde? ie what is that you have changed?
Does the the problem occurs if you boot with pfix=ram?
_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy

Anwsers:

1. booting from USB stick, SD card, and even HD install, Tahr64 keeps labelling stuff "sde#" (from two different ISO downloads now)

2. Ext 4 format device

3. MBT

4. Grub4dos

5. Standard grub4dos entry given by all (and, yes, this behavior occurs in ram too):

title Puppy Tahr64 (sde1)
find --set-root --ignore-floppies --ignore-cd /puppy_tahr64_6.0.5.3.sfs
kernel /vmlinuz pmedia=usbflash pfix=fask (as noted above, even if pfix=ram, it still occurs)
initrd /initrd.gz

6. Behavior was not present in any previous version of 64bit Tahr (and it is not present in the new 32 bit version: only the new 64-bit version is displaying this....do I have a gremlin or something, even with diff ISO downloads and installs on various machines, that somehow "sde" desgination is showing up instead of "sda", causing the autogenerated mounting of the sd# partition to go haywire looking for "sda' and finding only "sde'???? I can't findin Tahr64 where in Tahr64 I can correct this, as we both know it can't be coming from the hardware (haha) If it is, my systems are cooked and/or pwned or possessed by demons.


P.S. I will try a 3rd download & frugal install of the latest Tahr64 ISO later tonight, to see if it still displays this behavior. Maybe the first two separate downloads were not good, despite the md5 sums checking out.

[mavrothal]

P.S. I will try a 3rd download & frugal install of the latest Tahr64 ISO later tonight, to see if it still displays this behavior. Maybe the first two separate downloads were not good, despite the md5 sums checking out.

I can not see this neither in USB nor HD frugal installs and I would assume that if it was a general issue may have been noticed by someone else too.

Out of curiosity, if you exit X and "rm -rf /root/.pup_event/*" and then "startx" what happens?
Is it still showing as sde?
Does pmount shows the correct dreves/partitions?
What is the output of the "blkid" command?

[belham2]

P.S. I will try a 3rd download & frugal install of the latest Tahr64 ISO later tonight, to see if it still displays this behavior. Maybe the first two separate downloads were not good, despite the md5 sums checking out.

I can not see this neither in USB nor HD frugal installs and I would assume that if it was a general issue may have been noticed by someone else too.

Out of curiosity, if you exit X and "rm -rf /root/.pup_event/*" and then "startx" what happens?
Is it still showing as sde?
Does pmount shows the correct dreves/partitions?
What is the output of the "blkid" command?

Hi Marv,

Ok, that's weird, on diff machines I booted up existing Tahr64 installs (w/o using the 3rd downloaded OS yet), went to desktop on both of them, let everything settle down, and Exited to prompt, then ran the command "rm -rf /root/.pup_event/*", and this is the reply I got back on both machines:

rm: cannot remove /root/.pup_event/drive_sde : Input/output error

(and there's unicode square characters (field separators?) before " remove" and at the end of "sde ")

Pmount shows: "sde1" mounted (yet the desktop sortcut still spits up that error)

root# blkid shows:

/dev/sde1" LABEL="PuppyLinux" UUID=(then the correct uuid) TYPE="ext4"

If it matters, Gparted is showing "sde" too.


I can't think of what else to do except to blast all my existing Tahr64 installs away, then try the 3rd ISO and both frugal & full install (like before), and see if it the problem goes away. I've never seen this type of behavior before in the other pups and pup-related OSes I run. I must have (multiple times) screwed something up with both previous ISOs downloadeds & frugal/full installs, trying to solve this problem, but for the life I cannot think what.

Thinking out loud here, could something in my Tahr64 savefile that I always pull over to fresh frugal and/or full installs (so I don't have to set things up again) be over-riding things, where whatever in the savefile tries ot look for "sde#" yet the underlying frugal and/or full install is looking for "sda#"...thus I get this behavior?? I've honestly never heard of something like this before---I thought savefiles were agnostic (i.e. have no effect) when it came to things like automounting at OS bootup? I guess I could delete my savefile, and do everything all over again...was trying to avoid that Much thanks for helping, Marv, this one has me flummoxed.

[mavrothal]

could something in my Tahr64 savefile that I always pull over to fresh frugal and/or full installs (so I don't have to set things up again) be over-riding things, where whatever in the savefile tries ot look for "sde#" yet the underlying frugal and/or full install is looking for "sda#"...thus I get this behavior?? I've honestly never heard of something like this before---I thought savefiles were agnostic (i.e. have no effect) when it came to things like automounting at OS bootup? I guess I could delete my savefile, and do everything all over again...was trying to avoid that Much thanks for helping, Marv, this one has me flummoxed.

I guess you never answered the question

Does the the problem occurs if you boot with pfix=ram?

...

[belham2]

I guess you never answered the question

Does the the problem occurs if you boot with pfix=ram?

...

Awww, nuts...yeah, I had already tried "pfix=ram" in grub4dos and it had still done it. I completely brain-farted trying to think about this and writing the reply above.

Oh well, does not matter anymore....I had to screw something up with the 2 previous ISO downloads and installs, because I put the 3rd ISO download in just a few minutes ago, frugal installed it, and it booted right up and the problem was gone. So, I deleted everything else from the other installations and waved my wife's magic garlic necklace over my office machines (haha).

Thanks again for helping. Really appreciate it

[ravensrest]

I'd like to suggest a small change to how the on-the-fly sfs mounter/dismounter works. I would find it convenient if BOOTCONFIG were copied to BOOTCONFIG.save immediately whenever an sfs is added or deleted.

I am in the habit of copying the Puppy save file to another partition as a backup when I am experimenting with new software so that if something goes wrong I can simply load the old save file back and start again. I was very surprised when I tried this the other day and discovered that after crashing my system, the save file I had copied did NOT contain the sfs files I had added since last reboot. It is easy enough for me to simply copy BOOTCONFIG to BOOTCONFIG.save each time I change the sfs files to be loaded now that I know what is going on, but it would be nice if it happened automatically.

Thanks for listening.
BS