Puppy Linux Discussion Forum

I don't think this has anything to do with the fact that I used Save2SFS to create a ydrv. (See here, https://www.forum.puppylinux.com/viewto ... 294#p89294). But it might. After doing so --booting pfix=ram to move old Saves so they wouldn't be used-- I booted up and rebooted creating a new SaveFolder. I then added Rox Book-marks, Queing LibreOffice SFS to load and rebooting (on reboot LibreOffice was present and functional) I ran Setup Defaults to ID LibreWriter as the default Wordprocessor, etc. and executed a Save. Received a notice that 'Some Errors were detected). /tmp/snapmergepuppy-error reported:

cp: cannot stat '/initrd/pup_ro1/run/udev/links/snd\x2fby-path\x2fpci-0000:00:1b.0/c116:11': Not a directory
cp: cannot stat '/initrd/pup_ro1/run/udev/links/snd\x2fby-path\x2fpci-0000:00:1a.0-usb-0:1.2:1.0/c116:4': Not a directory
cp: cannot stat '/initrd/pup_ro1/run/udev/links/snd\x2fby-id\x2fusb-0d8c_C-Media_USB_Audio_Device-00/c116:4': Not a directory

The notice also suggested: "Filesystem check of Savefile (pfix=fsck) is highly recommended. I had forgotten to return it to BWP64's boot stanza. Have done so now. I'll reboot and see what happens.

Update: ReBooting with the fsck argument in the boot-stanza did not change anything. The above error was again reported when a Save was executed. I'm wondering if BWP64 is finding an error other Puppys missed. It seems only to relate to C-Media. I don't know what C-Media is supposed to do; or where it came from. AFAICT, it's never worked. Under Pulse-Audio it is OOTB the default 'audio device'. But it has never rendered sound. To obtain sound I have to configure the playback preference to Built-in Audio Stereo which continues to function.

In pretty much all distros except Puppy, /run is non-persistent.

The cp failure should be fixed by https://github.com/puppylinux-woof-CE/woof-CE/pull/3940. I don't remember who opposed it, but at least one woof-CE developer did. If I remember correctly, there's some old .pet package that stores stuff in /run and assumes it's persistent, and it's probably gone by now.

Thank you, dimkr, for the explanation. My take-away is that the occurrence was peculiar to my hardware-software combination and not something that will frequently cause problems to others employing BWP64. Hopefully, the fix you referred to will alleviate it. But see below for my current 'work-around'.

@amethyst , as the error manifested after creating a ydrv but not after a remaster using Remaster-Alternate, I can hypothesize that Remaster copies more of the files and folders (in particular the /run folder) currently in RAM (or if not from the base.sfs) than does Save2SFS.

My practice has been to use and update adrvs to hold applications which will require frequent updates, e.g. web-browsers; and use ydrvs to hold applications which will rarely, if ever, be updated, e.g. those employing qt(4) now that it's been deprecated. A remaster can be used to accomplish the latter. And your Remaster-Alternative is so easy to use and creates a remastered base.sfs so quickly that it is actually preferable. The resulting system is more efficient, reducing the need for Storage space and the time required to copy files into RAM and index them. So --for now at least and until I have reason to think otherwise-- my procedure will be to create a Save Folder, install applications I'll always want and expect never to be upgraded, remaster. Then create and/or modify adrv holding often updated applications as and when needed.

That your Remaster Alternative does NOT include the contents of adrvs, ydrvs or 'Applications SFSes' was what I expected. I should have made that clearer in my post. It is a positive feature. It was one of the reasons I had concerns about loosing AUFS. I thought that would result in an operating system requiring applications to be installed with an Upper folder ever increasing in size. AppImages have reduced our need for SFSes. But on low-source computers, SFSes still provide a mechanism by which applications not always needed can be quickly added when needed; can be upgraded without modifying the system as a whole, and neither demand resources nor create conflicts when not employed.

@mikeslr :-

Although it doesn't really apply to me - I have so much storage to play with these days it's embarrassing! - one way to, say, run a collection of my 'portables' (for example) on a low-resource machine, would be to purchase either a decent-quality, large-ish USB 3.1 or 3.2 flash drive - OR one of these portable SSDs that are now quite common - and to run the entire collection from there.

They won't use any system resources until you start to run them, same as an SFS really.....or ANY application, for that matter.

T'other Mike.

@mikeslr
(in particular the /run folder) currently in RAM (or if not from the base.sfs) than does Save2SFS.
No, with none of the applications the contents of /run are copied. In my Puppy, the /run folder is symlinked to /tmp which is specifically excluded. With Save2SFS the same copying method is basically followed as with the alternative remaster script, ie. the files are copied from /initrd.

This may be a 'red herring'. Starting again with a pristine deployment, I added a lot of applications, then remastered. Then made additional changes and additions --e.g., now working with a SaveFolder created links to portables on /mnt/home-- and additional Saves all without incident.
Then I SFS loaded LibreOffice, the only application I still use via an SFS. Configured LibreOffice --e.g. eliminate the update nag, and italization turning on when / is typed-- and Saved. Then changed my mind. Decided to use LibreOffice.AppImage instead of the SFS. After Un-loading LibreOffice, the error appeared.

By the way, how to unload an SFS is very confusing.