I'm running from a USB drive. Every time I add an fstab config it gets wiped out by the default one on reboot. Only way I found to fix it is to create an sfs with just fstab in it to load at startup.
Next issue is that fstab config is not loaded at boot like it should be. To fix this I added a script in the startup folder to "mount -a" which fixes the issue.
Third is that any directory I add in the "mnt" directory is gone at reboot. I added the dirs I wanted into my sfs to fix the fstab issue, and that fixed that too.
Tahr 64 bit 6.0.6
Tahr 64 bit 6.0.6
"In a world that exists without walls and fences, who needs Windows and Gates?"
-
Sailor Enceladus
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
Can you refresh my memory on what fstab is supposed to do, and what you're trying to customize with it? If I remember right, it has something with full installs? gyrog has been working on patching some things with full installs lately, so maybe the next version of tahr will be able to accomplish what you want better? 
Does Tahrpup 6.0.5 (before his new init) behave correctly?
https://github.com/puppylinux-woof-CE/w ... ts/testing
Does Tahrpup 6.0.5 (before his new init) behave correctly?https://github.com/puppylinux-woof-CE/w ... ts/testing
Hmm. I just did a fresh install of 6.0.6 with the xenial 4.9.x kernel, and fstab now gets preserved.
It's for mounting things. I use it to mount my 4 HDDs and set them up with mhddfs at boot, to do a RAID 1 type deal to use for my NAS.
I still have my sfs with the "/mnt/XXXX" folders for my HDDs, because any dir in /mnt still gets wiped out on reboot, and I still have the "mount -a" command in the startup script.
It's for mounting things. I use it to mount my 4 HDDs and set them up with mhddfs at boot, to do a RAID 1 type deal to use for my NAS.
I still have my sfs with the "/mnt/XXXX" folders for my HDDs, because any dir in /mnt still gets wiped out on reboot, and I still have the "mount -a" command in the startup script.
"In a world that exists without walls and fences, who needs Windows and Gates?"
I just created directory "/mnt/xxx" in tahr64 6.0.6 and tahr 6.0.6.sketchman wrote:I still have my sfs with the "/mnt/XXXX" folders for my HDDs, because any dir in /mnt still gets wiped out on reboot, and I still have the "mount -a" command in the startup script.
This directory survived a reboot in both puppies.
Both are frugal installs running in pupmode=12, on ext4 partition.
Note: I've never got "/etc/fstab" to work in puppies. Which is a little strange, since there is a "mount -a" command in "/etc/rc.d/rc.sysinit" that is always executed.
I've always used a little script in "/etc/init.d" to mount on startup, and umount on shutdown, any extra partitions.
gyro
Is it a frugal install?
Do you have a "pmedia=usbflash" boot parameter?
This would mean that you are running in "pupmode=13" and depend on the "snapmergepuppy" script to "save" files from RAM to your savefolder. (You can check PUPMODE in "/etc/rc.d/PUPSTATE".)
I just had a look at "snapmergepuppy" and it deliberately omits "/mnt/*" from the "save".
If the boot parameter is changed to "pmedia=usbhd", then you would be running in "pupmode=12" with all writes being written directly to your savefolder, with no dependence on "snapmergepuppy".
gyro
Do you have a "pmedia=usbflash" boot parameter?
This would mean that you are running in "pupmode=13" and depend on the "snapmergepuppy" script to "save" files from RAM to your savefolder. (You can check PUPMODE in "/etc/rc.d/PUPSTATE".)
I just had a look at "snapmergepuppy" and it deliberately omits "/mnt/*" from the "save".
If the boot parameter is changed to "pmedia=usbhd", then you would be running in "pupmode=12" with all writes being written directly to your savefolder, with no dependence on "snapmergepuppy".
gyro
Palemoon running as spot, after palemoon update runs as root
Hope this is the correct thread for reporting Tahr64 6.0.6 bugs in general???
Initial setup, set palemoon to run as spot.
Later ... if you use Menu, Internet, Palemoon-Updater ... and a update occurs then palemoon no longer is set to run as spot and instead runs as root.
Possible fix :
If palemoon is named in /root/.spot-status i.e. has a entry of palemoon=true then if palemoon is updated then set to /root/.spot-status entry to palemoon=false and after palemoon completes being updated then run /usr/sbin/loginmanager so that the user is prompted to reset palemoon back to running under spot.
/usr/bin/pminstaller.sh that is run when menu, internet, palemoon updater is run, is a script with a tar file attached at the end that is extracted to tmp when run and where that tgz has its sha checksum tested. Perhaps the menu/internet/palemoon update choice needs to call another wrapper script first that performs all of the above additional checks/function around that pminstaller.sh script. i.e. change or swap out /usr/share/applications/palemoon-updater.desktop file/content for that alternative wrapper script.
Initial setup, set palemoon to run as spot.
Later ... if you use Menu, Internet, Palemoon-Updater ... and a update occurs then palemoon no longer is set to run as spot and instead runs as root.
Possible fix :
If palemoon is named in /root/.spot-status i.e. has a entry of palemoon=true then if palemoon is updated then set to /root/.spot-status entry to palemoon=false and after palemoon completes being updated then run /usr/sbin/loginmanager so that the user is prompted to reset palemoon back to running under spot.
/usr/bin/pminstaller.sh that is run when menu, internet, palemoon updater is run, is a script with a tar file attached at the end that is extracted to tmp when run and where that tgz has its sha checksum tested. Perhaps the menu/internet/palemoon update choice needs to call another wrapper script first that performs all of the above additional checks/function around that pminstaller.sh script. i.e. change or swap out /usr/share/applications/palemoon-updater.desktop file/content for that alternative wrapper script.