Strange!!!
In an earlier post, I noted that YaPI in the cobbled 6.0.6 did not appear in Menu>Setup, but OK in other places.
Now I find that it isn't listed in the Uninstalled in PPM, so I am going to install over what exists. I did and it still is not listed among "Uninstall"
Running the new YaPI has essentially the same results. But launching from console selecting "any" gave the error shown in screenie=error_with_new_yapi. YaPI can't even find an ISO "under its nose".
Now, from the console, I'll cd to /root/ISOs then launch yapi like this:
. This was successful before.
...
It did not produce a populated drive despite what seemed to be all the correct dialogs. Scapping that proc.
I am back to using the tahr-6.0.2~6.0.5
No suprise that YaPI launched from Menu failed as before.
YaPI does not appear in PPM/Uninstalled. I seem to recall that it should. How else does one uninstall it? This looks like a badly created pet.
cd to /mnt/sda1/ISOs/
launched YaPI tahr-6.0.6-uefi.iso
all the correct dialogs seemed to appear including screenie=where2install-2
And results in a properly operating tahr-6.0.6 on flash drive.
Here is the
console page of my successful install using tahr-6.02~6.0.5 and yapi command with iso parm
Code: Select all
root# yapi tahr-6.0.6-uefi.iso
ISO to be installed is: tahr-6.0.6-uefi.iso. SIZE is 243.
Select WHERE to install to.
Mount is denied because the NTFS volume is already exclusively opened.
The volume may be already mounted, or another software may use it which
could be identified for example by the help of the 'fuser' command.
/usr/sbin/yapi: line 472: [: /tmp/PUI/ISOBOOTER_sda: binary operator expected
chosenPARTITION=sdc1
cp: omitting directory ‘/tmp/PUI/ISO/help’
BINSTALLER=bootlace.com
80.0GB
8006MB
16.0GB
sdc|16GB_General_UDisk_
sda|80GB_ATA_SAMSUNG_HD082GJ_
sdb|7.8GB_KingstonDT_101_G2_
sdc|16GB_General_UDisk_
/usr/sbin/grub4dosconfig: line 739: 10505 Terminated $GTKDIALOG -p DIALOG -c &> /dev/null
PCPARTS:
/dev/sdc1|vfat|15667200
LPART:/dev/sdc1|vfat|15667200
MYPUPPY=sdb1/tahr602/puppy_tahr_6.0.2.sfs
sdc1/tahr606uefi/puppy_tahr_6.0.6.sfs,initrd.gz|puppy_tahr_6.0.6
sdc1/tahr606uefi/puppy_tahr_6.0.6.sfs|puppy_tahr_6.0.6
1:0:3
/usr/sbin/grub4dosconfig: line 1353: 11547 Terminated $GTKDIALOG -p DIALOG -c &> /dev/null
sdc1/tahr606uefi/puppy_tahr_6.0.6.sfs,initrd.gz|puppy_tahr_6.0.6
:Windows:
/dev/sdc Bootalbe: yes, yes
/usr/sbin/grub4dosconfig: line 2079: 13164 Terminated $GTKDIALOG -p DIALOG -c &> /dev/null
head: cannot open ‘/tmp/PUI/PUIfrom’ for reading: No such file or directory
root#
I am coming to some conclusions:
- * The problem is my hardware configuration.
* There may be something wrong with my flash drive with the "cobbled" tahr-6.0.6.
* Since you can't duplicate my experience, then there is a conflict between the GUI, the search function and my hardware.
System-wide search
I think I've said this before: searching the entire system is not appropriate. If the system has multiple drives and/or large drives, it will take a very long time to find the target - a waste of time. I submit that most if not all of us keep our ISOs in some known location; there's no need for a system-wide search. The user will normally know which ISO s(he) wants to install. Why not let the user navigate via a browse button and related code to the known location. Having a system-wide search function here is "finding work for a tool" demonstration.
It seems to me that search is appropriate when you don't know where the target is. Furthermore, I can't conceive that the user does not know the exact ISO s(he) wants to "burn". It is better IMHO to provide the means to navigate to the known location where ISOs are kept. But if there is an odd set of circumstances that warrant a system-wide search, the user can use pFind before using YaPI. Alternatively, the developer could provide both the ability to browse to a known place plus an independent "Search for ISOs" button for those odd cases. It is bad design to force all to use the system-wide search.
Another example of bad design is that once you begin the process, there is no way of backing out. Neither "Cancel" or "X" on the task-bar allows you to quit.
Trying yapi with -h or --help does not provide a help screen. Instead, yapi is launched. YaPI has no escape route once it starts - another poor design decision. YaPI does not make an entry in PPM/Uninstall. Hence, it does not provide the standard way to easily delete a properly created pet.
Your placement of Puppy installs and iso's is not really the best.
snip
All my Puppy installs are just on a partition.
Example:
/mnt/sda1/xenialpup647085uefi
The argument that I have my ISOs too deep in a path is a specious one. Where you choose to place your ISOs or I, mine should not affect the efficacy of the search, even if there needs to be one. One should not design software solely on one's likes, environment or how the developer uses it.
Bye to YaPI GUI
These unsuccessful trials using YaPI from the Menu and from the console without an iso as a parameter, mark the end of my contribution. What has given me success is cd to where the target iso is, then yapi with the named iso. I'll use this procedure until there is a complete rewrite of YaPI.
Thanks for staying with me through this ordeal. Unfortunately, nobody else is interested.
Adios amigo!
[color=blue]B.K. Johnson
tahrpup-6.0.5 PAE (upgraded from 6.0 =>6.0.2=>6.0.3=>6.0.5 via quickpet/PPM=Not installed); slacko-5.7 occasionally. Frugal install, pupsave file, multi OS flashdrive, FAT32 , SYSLINUX boot, CPU-Dual E2140, 4GB RAM[/color]