Moderators: dimkr, Forum moderators
Hi guys
I want to upgrade to
latest version
Use the version
vanilladpup-x86-9.0.47
I want to upgrade to
vanilladpup-x86-9.2.19
How do I upgrade? Will I lose my data if something goes wrong?
I want a detailed explanation
I thank you all from the bottom of my heart for everything you give us 
welcome Joeseph
did you see
How do I upgrade? Will I lose my data if something goes wrong?
not if you make a backup of your vanilladpupsave onto a different drive
you can install vanilladpup-x86-9.2.19 in a folder alongside your existing vanilladpup-x86-9.0.47 without deleting anything.
you can also make a copy of your existing save in the new install to see if the saves are compatible.
you will need to add an additional stanza to sdxx/boot/grub/menu.lst
I want a detailed explanation
if you add two folders to your drive named 9219 and 9047, then post a screen shot of the rox window it will be easier to help explain.
also post a copy of your existing menu.lst
I don't recommend upgrading from 9.0.x to 9.2.x while keeping the same save file/folder, because 9.2.x is incompatible in 9.0.x in multiple fronts. (I do recommend upgrading to 9.2.x, it's actively supported and much more polished.)
Either start with a fresh save file/folder, or create a backup before you do the upgrade (and keep it until you're absolutely sure you haven't lost anything).
Hi! What I would really like to know is if there is a way to keep updating my vanilladpup-x86-9.0.47 installation, without switching to later versions, as this 9.x.x version works perfectly for me and doesn't change the internal time of PC, on shutdown. 
There is a way to update it, but you'll need to do this update manually. I recommend you to copy the save file/folder aside for backup, create a new save with 9.2.x, then move over things you want from your 9.0.x save. If you don't do that and just reuse the same save, you're very likely to run into trouble with apt and some Puppy configuration tools.
EDIT: regarding time - just configure Puppy to use local time (or UTC, depending on what your other OSs use) and set the clock correctly once.
Sorry to dwell on the clock subject....
I've done several tests with the configuration. I used all OS configured as UTC or Local. When I return to Vanilladpup (version 9.2.x), I check the time and it is correct. When restarting, I click "F2" and enter the BIOS and there is the time changed by +3 hours. It's always the same and that's why I gave up on the above versions of vanilladpup-x86-9.0.47. It's a shame, I really liked your work ..... I don't give up easily, I don't mind doing weight training on the keyboard and sweating in front of the PC! But, I have several other systems in test and in use and the only one that messes up the schedule is Vanilla! He's a bad boy and doesn't behave well in a group..... 
If I insist on this, it's because I continue to appreciate your work!
Duprate wrote: Tue Oct 11, 2022 6:11 pmHi! What I would really like to know is if there is a way to keep updating my vanilladpup-x86-9.0.47 installation, without switching to later versions, as this 9.x.x version works perfectly for me and doesn't change the internal time of PC, on shutdown.
Easy answer.
If it is not broken, do not try to fix it.
Get off the idea that you must constantly update!
Puppy has always required, a complete new install, of any newer version, that is drastically different, from the earlier version.
dimkr seems to indicate this applies to what you want to do.
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected 
I used all OS configured as UTC or Local.
When I return to Vanilladpup (version 9.2.x), I check the time and it is correct.
When restarting, I click "F2" and enter the BIOS and there is the time changed by +3 hours.
The internal clock of a computer, will go bad and not keep good time.
The only way to get around this is to set the time, by syncing to a time server, when the computer boots, and connects to the internet.
I assume you do have the internal time clock set to correct local time.
The bios setup should allow you to set the time.
The things you do not tell us, are usually the clue to fixing the problem.
When I was a kid, I wanted to be older.
This is not what I expected
I set my hardware clock 763 days ago
after Fatdog changed it (totally wrong) without asking permission.
By setting /etc/adjtime, my hardware clock is correct to less than plus/minus 1/2 second, after 763 days.
Setting the hardware clock effectively ends the experiment and I would need to start over again.
Please leave my hardware clock alone.
Please do not set my hardware clock without asking permission.
I no longer download Fatdog. I can't trust it.
Vanilla seems to be another OS that I can't trust to leave my HW clock alone.
If all of your OSs use local time and not UTC, and only one of them adds 3 hours, this OS probably uses the wrong timezone.
bigpup wrote: Wed Oct 12, 2022 12:15 amPuppy has always required, a complete new install, of any newer version, that is drastically different, from the earlier version.
dimkr seems to indicate this applies to what you want to do.
No, this is not what I'm saying. Most Puppy releases are one-off builds: for example, there's no 9.5.1 after 9.5. You can't update even if you really want to! And those that do have some form of updates (like VoidPup) are either based on a rolling distro (like Void) which is constantly changing or use different woof-CE versions for different builds, which sometimes introduce new issues or breaking changes, leading people to believe all updates are risky and bad. Also, most Puppy builds are built on somebody's computer and not in a clean environment.
Vanilla Dpup 9.2.x ("9.2.x" as in "everything in the range between 9.2.0 and 9.2.99999999999999") is built from Debian Stable (which, as the name implies, doesn't change unless it's a stability or security fix) and the same woof-CE tree (plus fixes) in a clean environment without any remains from previous builds: therefore, it's extremely easy to tell what has changed and updates are small, incremental and safe. You don't have to do a clean install when you update to a later Vanilla Dpup 9.2.x bugfix release.
Upgrades from 9.0.x and 9.1.x to 9.2.x don't follow the same logic, and don't come with the same stability guarantee, because of breaking changes. That's why I recommend a clean install of 9.2.x in this case.
I've been using VanillaDpup for about 2 months now and since then I've been seeing similar things as described by Duprate. These are time shifts (always 2 hours back).
There is win7 on the hard drive. All Linux OS´s have local time set (Fatdog64, VanillaDpup64, Fossapup64).
Sometimes the time shift happens, sometimes not. If it happens, I solve it by setting it manually in the given OS (including win7).
I don't know the cause, maybe VanillaDpup is innocent in this.
Feek wrote: Wed Oct 12, 2022 5:15 amI've been using VanillaDpup for about 2 months now and since then I've been seeing similar things as described by Duprate.
Is it configured to use local time and uses the correct time zone?
williams2 wrote: Wed Oct 12, 2022 1:54 amPlease do not set my hardware clock without asking permission.
Do you click "Ok" or just close the "Quick setup" wizard?
Hi! I use vanilladpup-x86-9.x.x from alpha and beta to the latest, vanilladpup-x86-9.0.47. I believe that during all this time I have tested and collaborated with the developer as much as possible. When I do tests, I usually write down everything I do so I can redo it, go back to the original state, or discover any mistakes I made. When quoting about the date change, I had already exhaustively done all the necessary tests (CMOS internal battery charge, all systems configured as UTC, then all as Local), I restarted countless times each one of the systems and checked the time and it was all right. The problem of changing the internal time by +3 hours, only happens with the UPPER VERSIONS of Vanilladpup 9.x.x.
As everyone, including myself, must already be annoyed with this subject, I won't talk about it anymore! We'll put the matter over and forgotten.
Regarding a possible unofficial update of the vanilladpup-x86-9.0.47 version that could be done by the user (since it is based on Debian), it was not my intention to change this version to a higher one, but to update some packages, if possible and for security reasons if necessary.....
Good morning everyone, and sorry for anything that didn't go well!
The file "clock" in /etc contains: HWCLOCKTIME='localtime'
Symbolic link "localtime" in /etc points to the right location in /usr/share/zoneinfo/...
The file "timezone" in /etc contains: Etc/UTC
Typing "date" in the terminal shows CEST (central european summer time), which is correct (UTC/GMT +2 hours).
Would be the solution to use syncing with a time server in all my linux systems?
Duprate wrote: Wed Oct 12, 2022 2:49 pmThe problem of changing the internal time by +3 hours, only happens with the UPPER VERSIONS of Vanilladpup 9.x.x.
Like I said, 9.2.x has changes incompatible with 9.1.x and 9.0.x, hence the difference in version numbers: don't expect them to behave exactly the same. The change to UTC (rather than localtime) as the default in 9.2.0 (as requested by some users) will cause a 3 hour time drift if in you're in GMT +3 and currently using local time, unless you change the default from UTC to local time in the "quick setup" wizard or the timezone change tool.
Feek wrote: Wed Oct 12, 2022 2:57 pmWould be the solution to use syncing with a time server in all my linux systems?
ConnMan synchronizes the clock using NTP, so Vanilla Dpup shouldn't be affected by hardware clock changes, as long as you chose the correct timezone. If you set the wrong time and reconnect to the internet, you'll see this synchronization in action.
dimkr wrote: Wed Oct 12, 2022 3:06 pmConnMan synchronizes the clock using NTP, so Vanilla Dpup shouldn't be affected by hardware clock changes, as long as you chose the correct timezone. If you set the wrong time and reconnect to the internet, you'll see this synchronization in action.
I just tried it. It works as you say. Nice.
---------------------------------------------------------------------------------------------------------------------------------------------
I got an idea. At the beginning I created a savefolder and during about 2 months of using VanillaDpup I created 4 backups using the Pupsave Backup utility. They were all continuously created from the same savefolder. The timezone and hardware clock type settings (use local time) were done at the beginning using the quick setup wizard and never changed.
I checked the /etc/clock in each of them and strangely 2 of those backups have HWCLOCKTIME='localtime' in /etc/clock and 2 of them have HWCLOCKTIME='utc'. As I say, I haven't changed this setting since the beginning. I have no idea how this is possible.
Maybe your system clock trouble will be gone soon, once the post-https://github.com/puppylinux-woof-CE/woof-CE/pull/3493 kernels are built. This fix will go into 9.2.20.
@Feek @williams2 @Duprate Does 9.2.20 solve your clock-related issues?
dimkr wrote: Sat Oct 15, 2022 10:42 am@Feek @williams2 @Duprate Does 9.2.20 solve your clock-related issues?
It seems not, unfortunately.
I tried to check the times in different places:
reboot -> go to bios and check the time -> time is ok
boot into Fossapup64 -> the time after typing "date" in the terminal and the time in the tray are correct; after typing "hwclock" the time is +2 hours (which surprised me a bit)
then reboot -> go to bios and check the time -> time is ok
boot into VanillaDpup -> after typing "date" and "hwclock" in the terminal the times are correct
then reboot -> go to bios and check the time -> time is -2 hours
I ended up settling on a configuration that uses UTC on all my linuxes.
So far I have followed the opinions and recommendations that the setting when using "localtime" will display the correct time in both windows and linux. However, I've also read that it doesn't always work 100%.
I very rarely use windows7 on my hard drive and I don't go online anyway (could be risky). The problem with unwanted time drifts wasn't actually in the confrontation of windows vs. linux, but between multiboot multiple linuxes (from the PL family) with the configuration that uses localtime.
So I hope the setting that uses UTC will work fine. I will also have to accept that windows will probably show the wrong time, but I don't mind.