Porteus-v3.2rc5 bug reports

Please reproduce your error on a second machine before posting, and check the error by running without saved changes or extra modules (See FAQ No. 13, "How to report a bug"). For unstable Porteus versions (alpha, beta, rc) please use the relevant thread in our "Development" section.
User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Porteus-v3.2rc5 bug reports

Post#196 by brokenman » 07 Nov 2016, 23:49

Well that's because these are not command to be run from a command line, but rather part of a programming language to be compiled. Anyway, back on topic.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ed_P
Contributor
Contributor
Posts: 8315
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Re: Porteus-v3.2rc5 bug reports

Post#197 by Ed_P » 08 Nov 2016, 00:23

brokenman wrote:Anyway, back on topic.
OK. So can 3.2 be configured to support timezones when the pc's clock is set to localtime like prior releases of Porteus?
Ed

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Porteus-v3.2rc5 bug reports

Post#198 by brokenman » 08 Nov 2016, 02:04

No. It is either one or the other. Either the rclock is set to UTC or local time. If set to localtime then there will be problems between distros. mac, linux and azure will all adopt the UTC standard so that's where we will be. Best thing to do is to set up ntp to automatically set your clock for you.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ed_P
Contributor
Contributor
Posts: 8315
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Re: Porteus-v3.2rc5 bug reports

Post#199 by Ed_P » 08 Nov 2016, 03:53

brokenman wrote: If set to localtime then there will be problems between distros.
That has not been my experience so far with a variety of distros.
mac, linux and azure will all adopt the UTC standard so that's where we will be.
And when the standards change then so should you. But the standards haven't changed yet and Porteus 3.2 should support the current standards.
Ed

jssouza
Legendary
Legendary
Posts: 1165
Joined: 09 Jul 2015, 14:17
Distribution: Porteus x86 arm

Re: Porteus-v3.2rc5 bug reports

Post#200 by jssouza » 08 Nov 2016, 05:44

Does the hardware clock also set the timezone? This is the output from my system:
[root:/home/guest]# hwclock --show
Tue 08 Nov 2016 07:01:42 AM CET .088982 seconds
[root:/home/guest]# date
Tue Nov 8 06:01:46 CET 2016
Strangely, the system time (output of date) is the correct actual time here. This would mean, that even if I had the correct time, my hardware clock time is screwed up.

I think Porteus, being a live OS should never write to the hardware clock, even if time is set through ntp. The variables that determine system time are: the hardware clock, the file /etc/hardwareclock, and the cheatcodes 'timezone=' and 'utc'. Of these, except for the hardware clock itself none are persistent (unless a saving mechanism has been created by the user).
If a user:
* Uses timezone=cheatcode, /etc/hardwareclock says localtime but the hardware clock itself was in UTC, then the hardware clock would be written the localtime.
* Along with timezone=, also uses 'utc' (wrongly) but the hardware clock itself was localtime, again wrong information would be written to the hardware clock.
In both cases persistence is not used, but the time would have changed, not only in subsequent live porteus sessions, but on other operating systems as well.

User avatar
Ed_P
Contributor
Contributor
Posts: 8315
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Re: Porteus-v3.2rc5 bug reports

Post#201 by Ed_P » 08 Nov 2016, 06:32

Thanks jssouza. I didn't know about the hwclock command.

Porteus 3.0.1 RazorQT 64-bit

Code: Select all

root@porteus:/home/guest# hwclock --show
Mon 07 Nov 2016 07:34:33 PM EST  -0.603666 seconds
root@porteus:/home/guest# date
Tue Nov  8 00:34:51 EST 2016
root@porteus:/home/guest# 
Porteus 3.2rc5 Cinnamon 64-bit

Code: Select all

guest@porteus:~$ su
Password: 
root@porteus:/home/guest# hwclock
Mon 07 Nov 2016 07:54:13 PM EST  .328298 seconds
root@porteus:/home/guest# date
Tue Nov  8 00:54:19 EST 2016
root@porteus:/home/guest# 
Everything looks great. :good: And the clock and timezone look good on Windows too. :)

Then this
Image
Which to me indicates the timezone with 3.2rc5 is Europe/London. :pardon:
Ed

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Porteus-v3.2rc5 bug reports

Post#202 by brokenman » 08 Nov 2016, 10:52

@Ed_P
Please read the code in /etc/rc.d/rc.S

Porteus does not touch your hardware clock unless you set your own time. If you find otherwise then please let me know, otherwise stop polluting this thread.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ed_P
Contributor
Contributor
Posts: 8315
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Re: Porteus-v3.2rc5 bug reports

Post#203 by Ed_P » 09 Nov 2016, 06:43

brokenman wrote:@Ed_P
Please read the code in /etc/rc.d/rc.S
OK. The file in 3.2 is different than the one in 3.0.

Code: Select all

guest@porteus:~$ diff  /etc/rc.d/rc.S /mnt/sda5/porteus3.0/3.0rc.S.txt
0a1
>  cat /etc/rc.d/rc.S
14,22d14
< # Ensure sane guest perms
< for a in `find /home -maxdepth 1 -type d | sed '1d'`; do
< 	b=${a##*/}
< 	if [[ `grep "$b" /etc/passwd` ]]; then
< 		chown -R $b: /home/$b
< 	fi
< done
< #chown -R guest: /home/guest
< 
41,46d32
< # Make sure /dev/shm exists and is mounted tmpfs
< if [[ ! `grep /dev/shm /proc/mounts` ]]; then
< 	[ ! -d /dev/shm ] && mkdir /dev/shm
< 	mount -t tmpfs tmpfs /dev/shm
< fi
< 
48a35
>     echo > /proc/sys/kernel/hotplug
70,78d56
< 	# Sync the clock once we have internet connection:
< 	(
< 	sleep 10
< 	ntpdate pool.ntp.org >/dev/null 2>&1
< 	# Store systemtime to hardware clock:
< 	grep -wq rtc /proc/ioports || CLOCK_OPT="--directisa"
< 	grep -wq "^UTC" /etc/hardwareclock && CLOCK_OPT="$CLOCK_OPT --utc" || CLOCK_OPT="$CLOCK_OPT --localtime"
< 	hwclock $CLOCK_OPT -w
< 	) &
131a110
> guest@porteus:~$ 
guest@porteus:~$ 
And this line indicates that Porteus is indeed capable of changing the system's clock.

Code: Select all

< 	# Store systemtime to hardware clock:
http://forum.porteus.org/viewtopic.php?f=117&t=6187&start=165#p49904 wrote:Porteus doesn't write to the system clock so as not to upset other OSs' times.
Anyways, I'm done with this. There is a problem with Porteus 3.2 setting the user's timezone on pcs that multi-boot whose system time is set to localtime. I've pointed it out. I've posted examples.
Ed

fulalas
DEV Team
DEV Team
Posts: 2050
Joined: 26 Oct 2016, 15:34
Distribution: Porteus
Location: Brazil

Re: Porteus-v3.2rc5 bug reports

Post#204 by fulalas » 09 Nov 2016, 07:09

Not exactly a bug, but could you update embedded Engrampa on XFCE build? The current 0.14.0 version can't open encrypted files. Here's the 0.16.0 txz package link:

https://www.mirrorservice.org/sites/dow ... 64-1gv.txz

EDITED: with this upgrade I think p7zip is no longer necessary once new Engrampa does everything. :)

Thanks!

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Porteus-v3.2rc5 bug reports

Post#205 by brokenman » 10 Nov 2016, 00:45

The new version of Porteus (released tomorrow) has the updated version of Engrampa. Thanks.

@Ed_P
And when the standards change then so should you. But the standards haven't changed yet and Porteus 3.2 should support the current standards.
Please. Do your homework before arguing so much. Porteus is set to localtime by default (check /etc/hardwareclock). If you use a cheatcode then Porteus will write to your hardware clock. If you don't mess with it then it won't. A quick duckduckgo search will show that MANY people are confused by the differences in OSs handling of time and indeed this was the case in Poreus-3.0.1, hence the change.

And this line indicates that Porteus is indeed capable of changing the system's clock.
Of course it is. What operating system isn't capable of doing this? The fact IS that Porteus DOES NOT touch your hardware clock by default. If you read the code more carefully you will see that it only does this if you choose to use a timezone cheatcode.

http://forum.porteus.org/viewtopic.php?f=39&t=6369
This link explains it as best I can. If you find this isn't functioning as it should, then please make a bug report, otherwise we have just chewed through 2 pages of needless noise.
How do i become super user?
Wear your underpants on the outside and put on a cape.

fulalas
DEV Team
DEV Team
Posts: 2050
Joined: 26 Oct 2016, 15:34
Distribution: Porteus
Location: Brazil

Re: Porteus-v3.2rc5 bug reports

Post#206 by fulalas » 10 Nov 2016, 01:14

Cool! I've seen the new files here: dl.porteus.org/x86_64/Porteus-v3.2/
:good:

But I have a bug to report. It's a little bit weird, but if you create (don't need to execute it after creation) a xzm package from a tgz Nvidia driver the system behaves really oddly, not responding when you try to open new apps and sometimes even freezing. I'll give you the step by step soon.

EDITED: OK, so the step by step is really simple. You have to build a tgz package from here (doesn't matter which version of the driver you pick): https://slackbuilds.org/repository/14.2 ... ia-driver/ . After the build you'll have a tgz package of the driver with something around 54mb (here's a direct link of my build if you want to save your time), then right click on it and choose 'txz2xzm'. You'll notice that the system starts to behave really oddly -- the first thing is that you won't see a finish notification, and the worst: you can't open any new process. This behavior occurs with both Porteus 3.2rc5 XFCE x64 and Porteus 3.2 XFCE x64 (from the first link above), even booting on 'Always fresh' mode.

fulalas
DEV Team
DEV Team
Posts: 2050
Joined: 26 Oct 2016, 15:34
Distribution: Porteus
Location: Brazil

Re: Porteus-v3.2rc5 bug reports

Post#207 by fulalas » 11 Nov 2016, 16:15

brokenman wrote:The new version of Porteus (released tomorrow) has the updated version of Engrampa. Thanks.
I checked and it's still on 0.14.x. And p7zip + GUI -- which in my opinion is not necessary with last Engrampa release -- is there too.

BTW, have you seen the bug I reported above?

Thanks!

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Porteus-v3.2rc5 bug reports

Post#208 by brokenman » 11 Nov 2016, 20:48

Thanks fulalas.

Yes I see that mate has the updated engrampa but not xfce4. I am updating it now along with some other quite essential things and will repack the ISO on the server. I can not test your bug as I don't have access to an nvidia card right now.
How do i become super user?
Wear your underpants on the outside and put on a cape.

fulalas
DEV Team
DEV Team
Posts: 2050
Joined: 26 Oct 2016, 15:34
Distribution: Porteus
Location: Brazil

Re: Porteus-v3.2rc5 bug reports

Post#209 by fulalas » 11 Nov 2016, 23:17

brokenman wrote:Yes I see that mate has the updated engrampa but not xfce4. I am updating it now along with some other quite essential things and will repack the ISO on the server.
Great! :good:
brokenman wrote:I can not test your bug as I don't have access to an nvidia card right now.
Well, if you look carefully you'll see that the problem isn't related to Nvidia cards, but to xzm package creation. You don't need to install/run anything related to Nvidia driver, but just convert a tgz package to xzm and voilà. I think is just a coincidence that this happens with a Nvidia driver package.

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Porteus-v3.2rc5 bug reports

Post#210 by brokenman » 12 Nov 2016, 00:31

Well, if you look carefully you'll see that the problem isn't related to Nvidia cards, but to xzm package creation.
I assumed it was the nvidia module since this GUI for txz2xzm is in 002 (same script in all desktops) and I have been right clicking on packages and converting them without any problems all day. Can anyone else confirm this bug?
How do i become super user?
Wear your underpants on the outside and put on a cape.

Post Reply