Discussion, talk and tips
https://forum.puppylinux.com/
This is 32-bit Tahr.
I believe I did this by overloading trash.
Yet there's nothing in ~/.Trash.
Increasing the pupsave size stops the warning alerts but does not return the icons.
Restarting X or rebooting this pupsave maintains the condition.
I don't know how you crashed it, but try to restore the /root/Choices/ROX-Filer/PuppyPin file.
You can copy a fresh PuppyPin file from the original puppy sfs, replacing the one inside you pupsave file.
Just guessing here with this very little information about what you did before this happend but it looks like your Puppy is missing its icon-theme.cache files.
Interessant you mention, this is JWM Tahr but slamming the icon cache is one of the main glitches I experience in X-Tahr.
I looked in obvious places for over-sized tmpfs and did not find anything.
This pupsave still exists, but the crash inspired me to spend hours starting over Saturday.
Do you know how to restore the cache?
I took a look in the iso file of tahr 6.0.2 to see which icons are installed. Seems like hicolor is the only gtk-icon-theme that needs to be cached.
Code: Select all
gtk-update-icon-cache -f /usr/share/icons/hicolor/In case something went wrong with cache files in general, /etc/gtk-2.0/gdk-pixbuf.loaders should be updated too:
Code: Select all
gdk-pixbuf-query-loaders > /etc/gtk-2.0/gdk-pixbuf.loadersand symlinked to /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
Code: Select all
root# gtk-update-icon-cache -f /usr/share/icons/hicolor/
(gtk-update-icon-cache:2992): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
This likely means that your installation is broken.
Try running the command
gdk-pixbuf-query-loaders > /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
gtk-update-icon-cache: Cache file created successfully.
root# The symlink was created.
If I can't find what filled personal storage, I think I really blew this pupsave up.
to see what is taking up space in a save file, type:
du -h /initrd/pup_rw/ tmp/ | sort -hk1
or you can use gdmap on /initrd/pup_rw/
EDIT: was the wrong path to pup_rw
@williams2 that is a script you wrote on my device called du4tmpfs.sh.
The bug issue is my save interval is 0 and nothing was saved at shutdown.
Code: Select all
41M /initrd/pup_rw/tmp
41M /tmp/
60M /initrd/pup_rw/
100M total/tmp has file called xerrs.log that is 38M and likes to keep growing. Roxfiler reports the size of this pupsave at 111M.
I deleted the .log and tried to resave:
Code: Select all
root# save2flash
(yaf-splash:3651): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
This likely means that your installation is broken.
Try running the command
gdk-pixbuf-query-loaders > /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
root# [ The suggested command does not work w/a file not found error. ]
Now use is modest again:
Code: Select all
14M /initrd/pup_rw/root
22M /initrd/pup_rw/
24M total
root# though still no icons.
I opened the 111M pupsave and it is full.
Mysterious/suspicious directory:
/usr/lib/i386-linux-gnu/opera
It looks like Opera installed, but it doesn't run.
I suspect it is the .sfs I was using.
It couldn't have been intentionally saved. There is no save icon on the desktop and the crash happened in use.
42mb
I think the default rox icons are in /usr/local/apps/ROX-Filer/images
and in /usr/local/apps/ROX-Filer/ROX/MIME
In my BionicPup64, the file /usr/local/apps/ROX-Filer/ROX/index.theme
has this content:
Code: Select all
[Icon Theme]
Name=ROX
Comment=Default ROX icon theme
Directories=MIME
Example=inode-directory
[MIME]
Size=48
Context=MimeTypes
Type=Fixed
I think nonstandard icons (icons not built into the RoxFiler AppDir) usually are in /root/.icons/
I have a symlink /root/.icons/ROX to /usr/local/apps/ROX-Filer/ROX
I don't know if this is helpful.
@williams2 I tried your ROX symlink and restarted X.
It's still the icons. They're also missing from the notification area.
Perhaps restoring them will provide insight into how they were disabled, which is the main loss at this point (lack of understanding).
almost the same:
Code: Select all
[Icon Theme]
Name=ROX
Comment=Default ROX icon theme
Directories=MIME
Example=inode:directory
[MIME]
Size=48
Context=MimeTypes
Type=ThresholdIf you want me to test a solution, I have this pupsave zipped for backup, but otherwise I'm going to move on.
My replacement from the weekend has quirks but is an improvement over what I lost.
Have you tried to set another icon theme and if that works try to set your preferred theme again? Just a thought no idea if it will work.
There aren't fonts in this system you can't see - memory serves they might be spared in the menu. If you tried to choose a theme in JWMDesk it would be by name.
So what happens when you choose a theme from JWMDesk? Can you see the icons in /usr/local/lib/X11/themes?
You can select a theme in Rox options, JWMdesk should not be necessary, by
right-clicking a desktop icon or right-click in a Rox window, click Rox Filer -> Options -> Types (at the left)
That should display using the theme's icon set.
you would probably need to move the mouse over the icons for the new icons to be visible.
Or restart X.
Or reboot.
Or restart the Rox pinboard.
There's discussion of different types of icon sets.
In rox the two options are ROX and hicolor.
I'm interpreting this to mean you believe the glitch is minor and after these changes icons should again be visible.
I will check again later.
JASpup wrote: ↑Mon Oct 11, 2021 5:59 pmCode: Select all
root# gtk-update-icon-cache -f /usr/share/icons/hicolor/ (gtk-update-icon-cache:2992): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory This likely means that your installation is broken. Try running the command gdk-pixbuf-query-loaders > /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache to make things work again for the time being. gtk-update-icon-cache: Cache file created successfully. root#The symlink was created.
If I can't find what filled personal storage, I think I really blew this pupsave up.
Mysterious/suspicious directory:
/usr/lib/i386-linux-gnu/opera
It looks like Opera installed, but it doesn't run.
Another look into the ISO:
It's the GdkPixbuf-WARNING that raises suspicion; Cannot open pixbuf loader module file '/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
/usr/lib/i386-linux-gnu/ is a relative symbolic link to ./ (which is /usr/lib ablolute).
If /usr/lib/i386-linux-gnu/opera is a real directory then other things don't work anymore.
You can try to move opera up to /usr/lib/ and replace directory i386-linux-gnu with a symbolic link to /usr/lib
HerrBert wrote: ↑Tue Oct 12, 2021 8:34 amAnother look into the ISO:
It's the
GdkPixbuf-WARNINGthat raises suspicion;Cannot open pixbuf loader module file '/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory/usr/lib/i386-linux-gnu/ is a relative symbolic link to ./ (which is /usr/lib ablolute).
If /usr/lib/i386-linux-gnu/opera is a real directory then other things don't work anymore.
You can try to move opera up to /usr/lib/ and replace directory i386-linux-gnu with a symbolic link to /usr/lib
It looks real to me, but what does real mean in this context?
Opera was never saved but loaded by .sfs in a boot with a modest amount of personal storage available.
There is no automated method of Opera removal, it is not in the .sfs list, so all I could do is just delete it.
Also, Opera .sfs that was never saved [combined with Trash?] crashed a small pupsave and obliterated all the icons. zerstören.
I do not need Opera in the pupsave, but I do not know what else to do with it besides delete it.
I will try the symlink later. I am in the (almost) elegant remaster I made after the crash.
If you don't want to keep opera either you can delete it and its parent folder i386-linux-gnu from the savefile.
In this case i would edit the savefile directly - when it is not loaded at boottime (boot with pfix=ram or choose another savefile to boot with or even another puppy...)
Clicking the savefile should mount it. Inside the mounted imagefile make sure that usr/lib/i386-linux-gnu and its content is what you want to delete. If so, delete it.
This way you don't need to create the symbolic link from usr/lib to usr/lib/i386-linux-gnu because the link from the puppy main file will no longer be overwritten by the real directory from the above layer.
Clicking the savefile again should unmount it.
I entered this command:
ln -sf /usr/lib /usr/lib/i386-linux-gnu
and now following the link, directory:
/usr/lib/i386-linux-gnu
has sole contents:
lib (symlink)
following that becomes:
/usr/lib/i386-linux-gnu/lib
richtig?
I can recover the pupsave from .zip archive, but the one I am working in already had Opera deleted (d.h., I did not edit the pupsave live).
This seems to get a lesson...
ln -sf /usr/lib /usr/lib/i386-linux-gnu is somewhat lightheaded.
Using the -f --force option always needs to think twice, no matter if it is used with cp, mv, rm, ln or similar commands. It will overwrite anything without warning.
Following the so created link /usr/lib/i386-linux-gnu leads to /usr/lib/i386-linux-gnu and its content should be the same as /usr/lib and not /usr/lib/i386-linux-gnu/lib. Following it twice leads to /usr/lib/i386-linux-gnu/i386-linux-gnu.
Code: Select all
# pwd
/usr/lib
# cd i386-linux-gnu
# pwd
/usr/lib/i386-linux-gnu
# cd i386-linux-gnu
# pwd
/usr/lib/i386-linux-gnu/i386-linux-gnu
# I can not reproduce your result here at all...
Also i wrote that /usr/lib/i386-linux-gnu is a relative link to /usr/lib. So the -r option is missing in your command.
(d.h., I did not edit the pupsave live)
If you didn't edit the pupsave live, your command will not edit anything in that savefile you try to edit because the leading slash in your command declares an absolute path to your systems root directory and not to any mounted image file of a savefile.
Also i wrote here that if you edit the savefile directly, you don't need to create the symbolic link at all.
Ich fahre siebenmal auf dem Kreisverkehr zu schnell, dann ich lightheaded werde.
Using the -f --force option always needs to think twice, no matter if it is used with cp, mv, rm, ln or similar commands. It will overwrite anything without warning.
Following the so created link /usr/lib/i386-linux-gnu leads to /usr/lib/i386-linux-gnu and its content should be the same as /usr/lib and not /usr/lib/i386-linux-gnu/lib. Following it twice leads to /usr/lib/i386-linux-gnu/i386-linux-gnu.
Code: Select all
# pwd /usr/lib # cd i386-linux-gnu # pwd /usr/lib/i386-linux-gnu # cd i386-linux-gnu # pwd /usr/lib/i386-linux-gnu/i386-linux-gnu #I can not reproduce your result here at all...
Also i wrote that /usr/lib/i386-linux-gnu is a relative link to /usr/lib. So the -r option is missing in your command.
This reads hopeful. If I did something wrong then it is possible your solutions might work.
If you didn't edit the pupsave live, your command will not edit anything in that savefile you try to edit because the leading slash in your command declares an absolute path to your systems root directory and not to any mounted image file of a savefile.
Also i wrote here that if you edit the savefile directly, you don't need to create the symbolic link at all.
I have to let this sink in (Ausdruck).
The JWM menu still has icons.
There are two parts to this problem:
1. How to restore icons
2. How icons were lost so that it does not happen again
A skeptic could accuse me of saving a full pupsave, but it is highly improbable with no save desktop icon & no menu option.
#1 has this simple solution:
HerrBert wrote: ↑Thu Oct 14, 2021 9:26 pmIf you didn't edit the pupsave live, your command will not edit anything in that savefile you try to edit because the leading slash in your command declares an absolute path to your systems root directory and not to any mounted image file of a savefile.
Also i wrote here that if you edit the savefile directly, you don't need to create the symbolic link at all.
It still has to sink in why the offending directory cannot be deleted from within the booted pupsave. I am working on understanding.
Deleting files or directories that exist in the puppy main sfs from within the booted pupsave will cause the union mount / aufs to whiteout these files in the pupsave, which becomes the writeable layer when it is loaded at boottime.
Taking your case of overwriting the symbolic link /usr/lib/i386-linux-gnu with a directory which contains opera breaks this link. Deleting it from the booted pupsave may delete usr/lib/i386-linux-gnu/opera from the pupsave, but will also create a hidden file .wh.i386-linux-gnu in /initrd/pup_rw/usr/lib, or respectively /initrd/pup_ro1/usr/lib when the session gets saved. Those .wh. files cause the aufs not to 'show' the original file from the puppy main sfs in a running system.
EDIT:
This may not be a perfect explanation of how things work. It is only intended to give a rough outline of what happens when data is deleted from a lower layer.
The whiteout in the pupsave covers/hides the base Puppy layer. Ich verstehe noch nicht: Why does the pupsave create a whiteout layer? It is not read-only .sfs but can contain them?
When I delete in a pupsave I believe what I deleted is gone. 
You can only physically delete files in an sfs archive (which is read-only) if you edit and rebuild the sfs itself. If you delete files in an sfs with normal system procedure the actual files in the sfs will only be hidden from view they are not physically deleted from the archive. In the latter case it's called white-out files which in effect is only a method not to show the actual files so that you can not see them. sfs's are mounted in /initrd/...and if you look there you will always see all the files in the sfs archive whether you have "deleted" them or not during a session.
The pupsave doesn't create the whiteout layer, it is the layer that saves the whiteout files created by the aufs.
The puppy main sfs is the lower layer**. It is read-only. Read-only means you can not write to it and you can not delete anything from it. Therefore the aufs creates the whiteout files on the writeable layer if a file on the lower layer has to be hidden.
Depending on the PUPMODE the writeable layer is /initrd/pup_rw or /initrd/pup_ro1. The latter is the pupsave it was booted with. When saving a session in PUPMODE 13, /initrd/pup_rw will be merged into it.
When you delete booted with a pupsave, you can not delete things from a lower (read-only) layer. So they have to be hidden to make the deletion persistent.
When you detete in a pupsave not booted with, what you delete will be gone, except it did cover/hide something else on the lower layer...
**)simplyfied for explanation - it may not be the lowest layer.
I think I understand better.
Deleting within a pupsave does not automatically reveal the layer beneath. For that you would have to reboot?
Ergo pupsave deletion not only erases the file(s) in it, but covers up the Puppy layer below it with whiteout creation.
To delete a file and still see it because it exists below ist Unsinn.
If the whiteout remains I suppose the Puppy layer would still be hidden after reboot.
Then what I did in the unmounted pupsave was delete the whiteout.
I had trouble loading .sfs after the repair, aber es ist nicht wichtig. I may have deleted too much (e.g., the i386-linux-gnu directory), not enough, or whatever caused the crash in the first place made subtle changes to the pupsave that are not easily discoverable.
Recovering the save is an improvement.
JASpup wrote: ↑Sun Oct 17, 2021 2:03 pm...
Deleting within a pupsave does not automatically reveal the layer beneath. For that you would have to reboot?
...
To delete a file and still see it because it exists below ist Unsinn.
...
I had trouble loading .sfs after the repair, aber es ist nicht wichtig. I may have deleted too much (e.g., the i386-linux-gnu directory), not enough, or whatever caused the crash in the first place made subtle changes to the pupsave that are not easily discoverable.
Recovering the save is an improvement.
1) Deleting in a pupsave that Puppy is not booted with of course needs a reboot.
Deleting in a pupsave booted with (i.e. /initrd/pup_rw or /initrd/pup_ro1) is not recommended and can cause data loss and / or crashes.
2) That's the way it works...
3) Deleting the i386-linux-gnu directory was exactly what recovered the symbolic link from the Puppy layer.
It is somewhat difficult to translate from native German into technical English, aber es freut mich, wenn ich helfen konnte.