My guess is that the time in the persist file was created before time change, and so this time is being used. You said that it was ok on second boot, is that because you made the change to the time? Does it now boot to the correct time on every boot with persistence?

Re: Date in IceWM Taskbar

anticapitalista wrote:You said that it was ok on second boot, is that because you made the change to the time? Does it now boot to the correct time on every boot with persistence?

Boot using persistence=Root
Time off by 1 hour
Take no action to change time
Shutdown without saving

Immediately reboot using persistence=Home
Time off by 1 hour

Immediately reboot using persistence=Home
Time correct

Immediately reboot using persistence=Root
Time off by 1 hour

Immediately reboot using persistence=Home
Time off by 1 hour

Immediately reboot using persistence=Home
Time correct

What did you do differently between these 2 steps?

If timezone is incorrect, perhaps it just needs to be explicitly selected (by specifying CITY) via boot menu?

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/antiX-Linux/antiX-Gfxboot/commit/3ed655e2c1591caf5c66e791a6794ae88c85d769"
linktext was:"https://github.com/antiX-Linux/antiX-Gf ... e88c85d769"
====================================

Press [F3] to get at list of cities in various time zones. The cities are listed in time zone order so they circle the globe eastward. If your area uses Daylight Savings Time then
make sure you select a city that does also. These cities are marked with a trailing <em>*</em> (asterisk). Your system will be started using the timezone selected.

The menu is an easy shortcut for entering <em>tz=[your-timezone]</em> directly on the boot line.

testing on the home media machine, amd athlon II x2 processor.

inxi -F running live no persistence, nouveau driver is used, straight to desktop.

inxi -F running live w/ persistence, does not start X. presented with console login. startx also fails. booting with safe video mode (shown below) boots to desktop.

Re: Date in IceWM Taskbar

anticapitalista wrote:What did you do differently between these 2 steps?

Short answer, nothing. Simply view the time displayed on the taskbar then immediately reboot.


Further investigation into Test 3.
Immediately after shut down in Test 1, it seems the type of reboot is relevant.

• When conducting a cold reboot (i.e. from complete power-down) Test 3 presents the correct time
• When conducting a warm reboot (i.e. no power-down) Test 3 presents the incorrect time on the first reboot as reported

Irrespective of whether the system is started from a cold or warm boot, as far as I can determine:

• Test 1 is as reported i.e. the time is correct
• Test 2 is as reported i.e. the time is incorrect

Maybe cannot sync with the time server for the selected area?

As the times that are displayed an hour out... and one value is not honoured all the time (ie time set in the persistance file), it seems that at the incorrect times it is using the bios due to the network configuration not being fully loaded when the time sync service is started.

dolphin_oracle wrote:testing on the home media machine, amd athlon II x2 processor.

inxi -F running live no persistence, nouveau driver is used, straight to desktop.

Code: Select all

demo@antiX1:~
$ inxi -F 
System:    Host: antiX1 Kernel: 3.19.1-antix.1-486-smp i686 (32 bit)
           Desktop: IceWM 1.3.8
           Distro: antiX-15-beta1-V_386-full Killah P 16 March 2015
Machine:   Mobo: Gigabyte model: GA-MA785GM-US2H v: x.x
           Bios: Award v: F11 date: 05/17/2010
CPU:       Dual core AMD Athlon II X2 245 (-MCP-) cache: 2048 KB 
           clock speeds: max: 2900 MHz 1: 1700 MHz 2: 2200 MHz
Graphics:  Card: NVIDIA GT218 [GeForce 210]
           Display Server: X.Org 1.16.4 drivers: nouveau (unloaded: fbdev,vesa)
           Resolution: 1366x768@59.81hz
           GLX Renderer: Gallium 0.4 on NVA8 GLX Version: 3.0 Mesa 10.3.2
Audio:     Card-1 NVIDIA High Definition Audio Controller
           driver: snd_hda_intel
           Card-2 Advanced Micro Devices [AMD/ATI] SBx00 Azalia (Intel HDA)
           driver: snd_hda_intel
           Sound: ALSA v: k3.19.1-antix.1-486-smp
Network:   Card: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           driver: r8169
           IF: eth0 state: up speed: 100 Mbps duplex: full
           mac: 1c:6f:65:2d:c2:b2
Drives:    HDD Total Size: 2124.4GB (0.0% used)
           ID-1: /dev/sda model: Samsung_SSD_840 size: 120.0GB
           ID-2: /dev/sdb model: WDC_WD20EARX size: 2000.4GB
           ID-3: USB /dev/sdc model: Cruzer_Glide size: 4.0GB
Sensors:   System Temperatures: cpu: 23.0C mobo: N/A gpu: 36.0
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 105 Uptime: 2 min Memory: 135.1/3031.6MB
           Client: Shell (bash) inxi: 2.2.16 

inxi -F running live w/ persistence, does not start X. presented with console login. startx also fails. booting with safe video mode (shown below) boots to desktop.

Code: Select all

demo@antiX1:~
$ inxi -F
System:    Host: antiX1 Kernel: 3.19.1-antix.1-486-smp i686 (32 bit)
           Desktop: IceWM 1.3.8
           Distro: antiX-15-beta1-V_386-full Killah P 16 March 2015
Machine:   Mobo: Gigabyte model: GA-MA785GM-US2H v: x.x
           Bios: Award v: F11 date: 05/17/2010
CPU:       Dual core AMD Athlon II X2 245 (-MCP-) cache: 2048 KB 
           clock speeds: max: 2900 MHz 1: 2200 MHz 2: 1700 MHz
Graphics:  Card: NVIDIA GT218 [GeForce 210]
           Display Server: X.Org 1.16.4 driver: vesa
           Resolution: 1024x768@71.00hz
           GLX Renderer: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits)
           GLX Version: 3.0 Mesa 10.3.2
Audio:     Card-1 NVIDIA High Definition Audio Controller
           driver: snd_hda_intel
           Card-2 Advanced Micro Devices [AMD/ATI] SBx00 Azalia (Intel HDA)
           driver: snd_hda_intel
           Sound: ALSA v: k3.19.1-antix.1-486-smp
Network:   Card: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           driver: r8169
           IF: eth0 state: up speed: 100 Mbps duplex: full
           mac: 1c:6f:65:2d:c2:b2
Drives:    HDD Total Size: 2124.4GB (0.0% used)
           ID-1: /dev/sda model: Samsung_SSD_840 size: 120.0GB
           ID-2: /dev/sdb model: WDC_WD20EARX size: 2000.4GB
           ID-3: USB /dev/sdc model: Cruzer_Glide size: 4.0GB
Partition: ID-1: /home size: 969M used: 34M (4%) fs: ext4 dev: /dev/loop2
Sensors:   System Temperatures: cpu: 28.1C mobo: N/A
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 110 Uptime: 0 min Memory: 119.7/3031.6MB
           Client: Shell (bash) inxi: 2.2.16 
demo@antiX1:~
$ 

Update: so far, the only machine that the the liveUSB w/persistence gets to X is the machine upon which it was originally created. In this case, a virtual box machine booted with from=usb.

Does the persistance file have a etc/X11/xorg.conf. IIRC BitJam was going to have the system make an xorg.conf on startup if it did not exist so that it would use the vesa driver instead of the fbdev. If this is the case it would be matched to the Vbox install and would not make it on any other system due to its existence.

A quick test might be to boot so on a machine that only boots to CLI, rm etc/X11/xorg.conf followed by a startx. If it then starts X I would say that xorg.conf needs to be added to the persistance excludes like the udev rule for the network cards needed to be.

dolphin_oracle wrote:inxi -F running live w/ persistence, does not start X. presented with console login. startx also fails. booting with safe video mode (shown below) boots to desktop.
...
Update: so far, the only machine that the the liveUSB w/persistence gets to X is the machine upon which it was originally created. In this case, a virtual box machine booted with from=usb.

As Dave mentioned. We've made a lot of changes in this area. I'm not surprised that beta1 had problems with X booting on different machines when persistence was used.

Dave wrote:Does the persistance file have a etc/X11/xorg.conf. IIRC BitJam was going to have the system make an xorg.conf on startup if it did not exist so that it would use the vesa driver instead of the fbdev. If this is the case it would be matched to the Vbox install and would not make it on any other system due to its existence.

A quick test might be to boot so on a machine that only boots to CLI, rm etc/X11/xorg.conf followed by a startx. If it then starts X I would say that xorg.conf needs to be added to the persistance excludes like the udev rule for the network cards needed to be.

ok, removing xorg.conf does enable X with the proper video driver. However, adding /etc/X11/xorg.conf to the static-delete list did not result in a deleted xorg.conf. I have to remove it by hand. adding xorg.conf to the persisent-excludes list worked as described, the xorg.conf file is not saved.

Re: Date in IceWM Taskbar

Dave wrote:Maybe cannot sync with the time server for the selected area?

That is not the cause in this case. Refer back to the initial report of this problem,
post40301.html#p40301
Test 1 shows that when running live with no persistence the correct time is consistently obtained. If reaching the time server were the root of matter the time would be consistently incorrect in live no persistence mode.

Dave wrote:As the times that are displayed an hour out... and one value is not honoured all the time (ie time set in the persistance file), it seems that at the incorrect times it is using the bios due to the network configuration not being fully loaded when the time sync service is started.

If this were the cause it would also adversely affect running live without persistence which is not the case.

Refer back to the original test reports which show that all tests are conducted using wired networking. This eliminates delays that might be experienced if wireless were used instead. Additionally, it is conventional that networking is set up reasonably early in the boot process.

The original report also indicates that when the incorrect time is displayed in the IceWm taskbar, the correct time is available but not used,

SamK wrote:A most unusual remedy antiX Menu-->Desktop-->Session Setting Global, when the prompt for the administrative password is displayed, press the Cancel button without entering the password. The desktop is refreshed and the correct time is displayed in the IceWM taskbar.

Summary of what has been established so far

• The problem is not present when booted live and persistance is not used.
• The problem is consistently present only when root persistence is in use
• The correct time is consistently available to the system, but not used when root persistence is in play.
• In the IceWM taskbar, an incorrect time can be corrected by starting Session Settings Global but cancelling the prompt for an administrative password without inputting any information.

Based on the above it seems reasonable to conclude that the problem is potentially seated in either or both the current incarations of root persistence and session tool chain.

Thinking aloud...
Does root persistence set up networking for a 2nd time?
Does session management have a misplaced or missing restart/refresh command which is corrected when the scripts underlying Session Settings Global are run even though it is cancelled without providing root authority or other information?

Question one, yes I am thinking that you are receiving issue with the time sync in the same way that you were recieving network trouble running live with persistence on multiple machines.

As to the second question you have not started the session settings stuff... which is just geany on some text files. On that note it should then fix itself with any instance of gksu being started. Try running any other program with gksu to switch to root and see if it still is resolved.

the only machine that the the liveUSB w/persistence gets to X is the machine upon which it was originally created. In this case, a virtual box

FYI: worked perfectly here when I tested on differing hardware (not virtualbox) using dynamic root persistence.

skidoo wrote:

the only machine that the the liveUSB w/persistence gets to X is the machine upon which it was originally created. In this case, a virtual box

FYI: worked perfectly here when I tested on differing hardware (not virtualbox) using dynamic root persistence.

it actually turned out that the xorg.conf that was created when I made the persistence files in virtualbox was not correct for the other machines. I made the change suggested to the excludes files and now the xorg.conf is delelted/not saved on shutdown, so its not there to conflict on later boots.