tahrpup64 6.0.5 CE

[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

[gyro]

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.

It might be even better if sfs_load stored it's data somehow in "/root/.packages" and copletely ignored any files used by init, like BOOTCONFIG.
There is now a separation of responsibilities between sfs_load and init, only sfs_load handles "extra" sfs files, init does not even look at them.

gyro

[OscarTalks]

Decided to have a go at compiling the latest svn snapshot of MPlayer with GUI enabled in tahr64 6.0.5

The build process downloads the latest ffmpeg "master" branch source, but this gives an error in libavutil due to a recent change, so I substituted the latest ffmpeg release (3.2.2) source and mplayer (37916) compiled OK. This happened the same when I tried in Slacko64. This produces a version even newer than the latest release which has codec support for formats such as HEVC/h265 and VP9.

I uploaded a .pet package in case anyone wants to take a look. Tahr64 has VLC as the default media player but the shipped version does not play some things. There is a VLC upgrade available which may be an improvement but in some cases I have found that MPlayer copes better with the latest formats. Anyway, the package does not change the default but it does add mplayer to right-click>SendTo in ROX.
http://smokey01.com/OscarTalks

[melon688]

user report

Create bootable USB flash drive.

Desktop > Install > BootFlash USB installer > USB-HDD > ...

tahr 6.0.5
tahr 6.0.5.3
Xenial 7.0.x
no working

lucid 5.2.8.7
working

[prehistoric]

Hi folks,

I'll tell you right away that Tahrpup 64 6.0.5.3 is not my regular OS, so I may be asking something obvious. I'm switching OSes regularly at the moment to get around a networking bug. Sulu2 works, but I'm still having trouble with Tahrpup 6.0.5.3 and Fatdog 710.

While I was checking on the behavior of different networking tools and browsers, I installed Google Chrome via quickpet. The version this downloaded will not run as root normally, which is good for security. I have now found Mike Walsh's sfs for tahrpup which runs as spot.

Now the problem: when I go to uninstall the previous version of Google Chrome using the Puppy Package Manager, I see no evidence it was installed. Loading the sfs, and attempting to run it takes me back to the warning about running as root.

I've now unloaded the sfs, but I would still like to remove the version of Google Chrome causing the confusion. Is there some method that does not require finding where every file in the package was installed, and removing it manually?

[mikeslr]

Hi prehistoric,

When you install google-chrome or load an SFS and run it for the first time it creates a hidden folder of settings @ /root/.config which later also will record any bookmarks, Addons, etc.

Uninstalling pets and/or unloading SFSes may not remove the /root/.config folder. Perhaps its persistence is why "Loading the sfs, and attempting to run it takes me back to the warning about running as root."

That's a guess. But the following is worth trying. After you've unloaded the SFS and/or uninstalled the pet, browse into /root/.config --showing hidden files-- and delete any residual google-chrome folder. Also, run pfind a couple of times using "google" "chrome" ".google" and ".chrome" as targets. Note the "dots". Delete anything other than pngs. Remember to Save.

You also mentioned that "when I go to uninstall the previous version of Google Chrome using the Puppy Package Manager, I see no evidence it was installed." I suspect you are using a SaveFolder rather than a SaveFile. My experience is that regardless of what precautions I take --e.g. Remove Automatic Save-- on occasion some files of pets I'm "just testing" get written to a SaveFolder. Using pfind and manually deleting is the only way I've found to remove those.

Hope this helps.

mikesLr

[prehistoric]

Thanks Mike, that sounds quite plausible. I didn't know about the hidden files in /root.

At the moment I don't remember if I used a save folder instead of a save file. I usually do the latter when I'm experimenting just so it is easy to undo mistakes.

I'm on another OS until I get the network problem completely sorted. I'll reboot and try your suggestions.

Added: you were right, it was a save folder. Your suggestion worked, though I also removed some icons which should have been replaced when I loaded the sfs.

I'm now posting from Google Chrome running as spot in Tahrpup 64 6.0.5.3. This is where I discovered that I still need to replace the nvidia driver to stop Chrome from screwing up scrolling. (Did that for Fatdog 710, but not for Tahrpup.) At the moment I've even worked around the flaky networking.

[mikeslr]

Hi again prehistoric,

I don't doubt that SaveFolders provide some advantages when you know exactly what your going to install and that doing so won't create a problem. But SaveFiles with Automatic Save removed are less likely to result in unintended incorporation of files when you are experimenting. So, like you, that's what I do.

Frankly, I think the current recommendation of SaveFolders on first shut-down should be replaced by an statement to the above effect; perhaps with the added suggestion that "if you're new to Puppy Linux a SaveFile is recommended while learning".

Although I've never done it, it should be possible to extract a SaveFile and turn the extracted folder into a SaveFolder.

mikesLr

[prehistoric]

Hi again prehistoric,
...Although I've never done it, it should be possible to extract a SaveFile and turn the extracted folder into a SaveFolder.

It is possible, and I have done it on Fatdog 710 installations. Here are the instructions from James Bond. You may have problems on other versions, but Fatdog only checks the main part of the name; it determines the form of the save filesystem itself. I was concerned because I had an ext4 savefile in an old ext3 file system on a partition I didn't want to completely change, since that would stop me from running systems built prior to ext4. Removing the extension was not even necessary, though I did that to avoid future confusion.

[prehistoric]

Just one more question: where do I find kernel source 3.14.79? That is what my system tells me it is running.

I have the nvidia 304.xxx .run file to build and install the proprietary module, and the devx_tahr64_6.0.5.sfs, but the kernel sources mentioned in the quickpet don't include this version.

[bigpup]

http://distro.ibiblio.org/puppylinux/test/tahrpup/

666philp is using this kernel as a test, so he put this in the test directory of the repo.