mistfire wrote:To achieve PUPMODE 13 it requires large ram, the computer has a battery, and the battery was in good health.
It's a Dell Latitude 3350 Laptop with i5-5200U CPU with 8GB RAM also 8GB Swap on internal SSD, the battery is good (capacity is down a bit) . Earlier iterations of TazPuppy woud boot to PUPMODE 13 on this laptop.
Does the battery of your computer was detected by the kernel?
tux@TazPuppy:~$ dmesg|grep battery
ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
ACPI: Battery Slot [BAT0] (battery present)
I've done some testing on older tazpuppies, on Beta 35 with kernel 4.14.150 save2flash was OK. On Beta45 with 4.14.156 (which is same as current kernel) save2flash was OK. So it appears that between Beta 45 and Beta 50, something has changed on how PUPMODE is being set.
The dmesg output checking for battery was the same on all versions that I checked.
So far just a quick test to check PUPMODE, it is now being set to 13,shutdown and save2flash now OK.
Thanks mistfire, will continue and set up and test further.
Edit: I spoke too soon. Nothing is being saved. Created new document in /home/tux/Documents. Added Application Launchers to Panel. None of these are being retained over Shutdown/Reboot. I have manually ran save2flash as tux and root, it appears to run. I've checked with changing save interval to 0 or +0. No changes as stated above are retained. I have done multiple shutdown and reboots.
Note: I created a symlink to palemoon in /usr/bin and added a palemoon.desktop to /usr/share/applications and added an icon. These changes have been retained. So, it appears that changes within /home/tux aren't being saved.
This as a new clean frugal install on USB Flash drive, with a new save folder.
Initial test was to test upgrading existing save folder. This was done after deleting the previously provided snapmergepuppy from the save folder. Saves and reboots working OK.
I then did a clean install (pfix=ram). Save and reboot working OK. All other software is OK
There is on observation, which may be intentional. On initial save when creating save folder, there is no option provided to add a chosen suffix to the save folder name. The save folder creation does however create unique names adding -n to the name.
I found something weird. the shutdownconfig script works fine without problems on previous releases of TazPuppy then recently the dialog inputbox suddenly don't work on commandline upon shutdown process while the menubox works fine. However when it launched from commandline shell the dialog and gui version of shutdownconfig works.
On my latest experiment the GUI version of shutdownconfig is now working on first shutdown if Xorg was running. Also GUI version of Save Session messagebox upon shutdown for PUPMODE 3/7/13 is added.
The only problem we need to solve was the commandline version where the dialog was buggy. But shutdownconfig works nicely if it was launched from logged in shell.
Changes:
* Build from recent Slitaz release
* First shutdown dialog now runs on both GUI mode and commandline mode
* Dialog asking to save session for PUPMODE 3/7/13 now runs on both GUI and commandline mode
* Fixed bugs on shutdown script
* More bugfixes
New frugal install of Beta 53 on Sandisk USB Flash drive., on Dell Latitude 3350 Laptop with Core i5-5200U 8GB Ram Intel 7265 AC wifi card.
I first tested first shutdown to check save file/folder creation, including adding suffix to name. All OK, with all changes made contained in save folder created. I then booted with pfix=ram and checked first save against reboot. Save folder creation OK. with all changes being saved.
In this lot of testing I have encountered an issue with the fdrv. I normally don't use the fdrv. I generally just manually load my own firmware and do a modprobe to load it and have it included in the save folder. for this testing I just used the fdrv provided, which encountered strange behaviour.
I found thet the iwlwifi-7265D*.ucode wasn't loaded, when checking the /lib/firmware there was only 1 directory inside NXP-linux-firmware-67b7579. Checking this directory showed that all the linux firmware was contained in this directory.
I viewed the content of the fdrv, which does not contain such a directory name. I did notice another issue with the supplied fdrv with in the tazpuppy.iso. With in the /lib/firmware directory there is another nested directory firmware which contains all the firmware. This is different to the fdrv contained in other versions of puppy.
On my latest experiment, I successfully upgraded xorg and mesa on TazPuppy the problem was mesa requires llvm libs which makes tazpup sfs larger by 6Mb+
Frugal install to USB flash drive. As a clean install saved with new save folder. All seems OK.
For information only :
This version won't boot to X desktop using any previously created save folders, tried with 3 different save folders. Only boots to CLI. I assume it is due to xorg changes.