Porteus-v4.0rc4 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
Ed_P
Contributor
Contributor
Posts: 4126
Joined: 06 Feb 2013, 22:12
Distribution: 4.0 Cinnamon 64-bit ISO
Location: Western NY, USA

Porteus-v4.0rc4 bug reports

Post#61 by Ed_P » 08 Mar 2018, 14:56

:shock: Nice catch jssouza.
Ed

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

Porteus-v4.0rc4 bug reports

Post#62 by brokenman » 09 Mar 2018, 00:02

Thanks jssouza,

I know there are many cheatcodes that won`t work. It`s a matter of me tracking them all down and adding the extra check. Thanks for the list.
How do i become super user?
Wear your underpants on the outside and put on a cape.

M. Eerie
Samurai
Samurai
Posts: 102
Joined: 31 Aug 2017, 21:18
Distribution: APorteus BUDGIE x64

Porteus-v4.0rc4 bug reports

Post#63 by M. Eerie » 09 Mar 2018, 00:19

jssouza wrote:
08 Mar 2018, 14:47
M. Eerie, can you execute the following command...
Done. And yes, the layout seems to be fixed now. ;)

However, in dconf-editor, the real path seems to be: /org/mate/desktop/peripherals/keyboard/kbd/layouts

Perhaps this schema was missing. I'll check it out booting again, prior to save my ~/.config/dconf/user file.

Thanks!

Edit: This was my previous setup. Not sure this makes a big change.

Image

Edit2: Sorry... :pulpfiction: :Oops:
Last edited by M. Eerie on 09 Mar 2018, 16:26, edited 1 time in total.

User avatar
Ed_P
Contributor
Contributor
Posts: 4126
Joined: 06 Feb 2013, 22:12
Distribution: 4.0 Cinnamon 64-bit ISO
Location: Western NY, USA

Porteus-v4.0rc4 bug reports

Post#64 by Ed_P » 09 Mar 2018, 05:20

brokenman wrote:
09 Mar 2018, 00:02
I know there are many cheatcodes that won`t work. It`s a matter of me tracking them all down and adding the extra check.
Maybe an early run routine that merges the .cfg file cheatcodes into the cmdline ones would be an easier approach. :happy62:
M. Eerie wrote:
09 Mar 2018, 00:19
Edit: This was my previous setup. Not sure this makes a big change.

Image
:%) Anyone able to read this image?
Ed

User avatar
Rava
Contributor
Contributor
Posts: 1582
Joined: 11 Jan 2011, 02:46
Distribution: Porteus 3.1.0 x86-64 XFCe
Location: Germany

Porteus-v4.0rc4 bug reports

Post#65 by Rava » 09 Mar 2018, 12:27

Ed_P wrote:
09 Mar 2018, 05:20
:%) Anyone able to read this image?
Nope, seems the image is just a preview? M. Eerie, you need to upload a higher quality image...
Cheers!
Yours Rava

M. Eerie
Samurai
Samurai
Posts: 102
Joined: 31 Aug 2017, 21:18
Distribution: APorteus BUDGIE x64

Porteus-v4.0rc4 bug reports

Post#66 by M. Eerie » 09 Mar 2018, 16:58

Fixed image above.

Digging up a bit more, I've found that keyboard reverts back to 'us' as before.

I'd swear this is happening whenever a system updating script fires up (i.e. a module gets activated, etc.). Then the layout can't get swapped by simply clicking system tray icon. You have to right-click on it, then select Layouts --> English (US), and only then, you are able to select another layout. :%)

Cheers!

jssouza
DEV Team
DEV Team
Posts: 640
Joined: 09 Jul 2015, 14:17
Distribution: Porteus x86 arm
Location: Liechtenstein

Porteus-v4.0rc4 bug reports

Post#67 by jssouza » 09 Mar 2018, 17:13

M. Eerie wrote:
09 Mar 2018, 16:58
I've found that keyboard reverts back to 'us' as before.
Hmm, I was today the whole day on Mate with kb layout "at" with a programmatical fix in the mate startup scripts what I mentioned earlier, and not once it reverted back to "us". I will keep an eye on it. Maybe you are running gsettings much later, and my fix comes much earlier in the DE startup, maybe even earlier than the setxkbmap itself, and that's why it works.
The surest way (before this change) to reproduce this issue is to connect a new USB, a HDMI monitor, or just go Ctrl-Alt-F1 to VT1 and then come back to the Xorg terminal. The layout would have jumped to "us".
M. Eerie wrote:
09 Mar 2018, 16:58
Then the layout can't get swapped by simply clicking system tray icon.
This I've seen. I have a workaround in mind. I will see if it works.
Thanks.

User avatar
Blaze
DEV Team
DEV Team
Posts: 1913
Joined: 28 Dec 2010, 11:31
Distribution: ⟰ Porteus current Xfce x86_64
Location: ☭ Russian Federation, Lipetsk region, Dankov
Contact:

Porteus-v4.0rc4 bug reports

Post#68 by Blaze » 09 Mar 2018, 17:21

M. Eerie, I use this configuration + cheat code kmap=us,ru in /mnt/sdb1/boot/syslinux/porteus.cfg
BTW, I prefer us for keyboard layout by default. Probably it help you to fix your issue.

ru_RU-locales-files-new.xzm

Code: Select all

/ru_RU-locales-files-new
├── etc
│   ├── profile.d
│   │   ├── lang.csh
│   │   └── lang.sh
│   └── rc.d
│       └── rc.font
└── usr
    └── lib64
        └── locale
            └── locale-archive

6 directories, 4 files

Code: Select all

cat /etc/profile.d/lang.csh

Code: Select all

#!/bin/csh
# Set the system locale.  (no, we don't have a menu for this ;-)
# For a list of locales which are supported by this machine, type:
#   locale -a

# en_US.UTF-8 is the Slackware default locale.  If you're looking for
# a different UTF-8 locale, be aware that some of them do not include
# UTF-8 or utf8 in the name.  To test if a locale is UTF-8, use this
# command:
#
# LANG=<locale> locale -k charmap
#
# UTF-8 locales will include "UTF-8" in the output.
setenv LANG ru_RU.UTF-8

# 'C' is the old Slackware (and UNIX) default, which is 127-bit ASCII
# with a charmap setting of ANSI_X3.4-1968.  These days, it's better to
# use en_US.UTF-8 or another modern $LANG setting (or at least en_US)
# to support extended character sets.
#setenv LANG C

# Non-UTF-8 options for en_US:
#setenv LANG en_US
#setenv LANG en_US.ISO8859-1

# One side effect of the newer locales is that the sort order
# is no longer according to ASCII values, so the sort order will
# change in many places.  Since this isn't usually expected and
# can break scripts, we'll stick with traditional ASCII sorting.
# If you'd prefer the sort algorithm that goes with your $LANG
# setting, comment this out.
setenv LC_COLLATE C

# End of /etc/profile.d/lang.csh

Code: Select all

cat /etc/profile.d/lang.sh

Code: Select all

#!/bin/bash
export LANG=ru_RU.utf8
export LC_COLLATE=C

Code: Select all

cat /etc/rc.d/rc.font

Code: Select all

#!/bin/sh
#
# This selects your default screen font from among the ones in
# /usr/share/kbd/consolefonts.
#
setfont -v UniCyr_8x16.psf
Linux porteus 4.18.3-porteus #1 SMP PREEMPT Sat Aug 18 16:50:00 UTC 2018 x86_64 Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz GenuineIntel GNU/Linux
MS-7A12 » [AMD/ATI] Tobago PRO [Radeon R7 360 / R9 360 OEM] (rev 81) » Vengeance LPX 16GB DDR4 K2 3200MHz C16

M. Eerie
Samurai
Samurai
Posts: 102
Joined: 31 Aug 2017, 21:18
Distribution: APorteus BUDGIE x64

Porteus-v4.0rc4 bug reports

Post#69 by M. Eerie » 09 Mar 2018, 19:01

jssouza wrote:
09 Mar 2018, 17:13
just go Ctrl-Alt-F1 to VT1 and then come back to the Xorg terminal
I was into it, when system got totally frozen and had to... errrrrrrrrrrm unbusier him... ALT+SYS Req+reisub

Upon reboot, I've made a shot of what's going on...

Image

Hope this helps.

Blaze, I will follow your advices and see how it goes. Hopefully this will help solve the lack of locale support in Nemesis as well.

Thanks all!

Cheers!

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

Porteus-v4.0rc4 bug reports

Post#70 by brokenman » 11 Mar 2018, 13:42

Ed_P wrote:
09 Mar 2018, 05:20
Maybe an early run routine that merges the .cfg file cheatcodes into the cmdline ones would be an easier approach.
Splendid idea! I'll see if it's practical

Added in 4 hours 12 minutes 16 seconds:
I've implemented that superlative idea. Now all boot line arguments are collated into one single file at /etc/bootcmd.cfg and I've updated scripts to check this single file. Please do so with /etc/rc.4 for your respective desktops.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ed_P
Contributor
Contributor
Posts: 4126
Joined: 06 Feb 2013, 22:12
Distribution: 4.0 Cinnamon 64-bit ISO
Location: Western NY, USA

Porteus-v4.0rc4 bug reports

Post#71 by Ed_P » 11 Mar 2018, 21:53

:hmmm: cp /etc/bootcmd.cfg /proc/cmdline work? I have scripts accessing the /proc/cmdline file also. :%) And I suspect maybe other users.
Ed

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

Porteus-v4.0rc4 bug reports

Post#72 by brokenman » 11 Mar 2018, 23:12

cp /etc/bootcmd.cfg /proc/cmdline work?
No. No. Absolutely not. This is a process file created every boot. I've put a few lines in linuxrc to copy all used cheatcodes from both /proc/cmdline and the porteus-v4.0-$ARCH.cfg file into a single config file so all scripts can just check one file.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ed_P
Contributor
Contributor
Posts: 4126
Joined: 06 Feb 2013, 22:12
Distribution: 4.0 Cinnamon 64-bit ISO
Location: Western NY, USA

Porteus-v4.0rc4 bug reports

Post#73 by Ed_P » 12 Mar 2018, 05:12

brokenman wrote:
11 Mar 2018, 23:12
I've put a few lines in linuxrc to copy all used cheatcodes from both /proc/cmdline and the porteus-v4.0-$ARCH.cfg file into a single config file so all scripts can just check one file.
I understand the concept but why not have the lines in linuxrc copy all the cheatcodes from the porteus-v4.0-$ARCH.cfg file into the /proc/cmdline file when booting so all scripts can continue to check the file they currently check?
Ed

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

Porteus-v4.0rc4 bug reports

Post#74 by brokenman » 12 Mar 2018, 23:17

I understand the concept but why not have the lines in linuxrc copy all the cheatcodes from the porteus-v4.0-$ARCH.cfg file into the /proc/cmdline file when booting
Perhaps not. /proc/cmdline is a process file. It's not writable even as root during boot and it is used to communicate with the kernel. One could hijack the file by bind mounting over it as a mask but this is polluting the boot process. It's a rather messy measure to take and it could inadvertently impact other applications that read the file. Also, I've already made the changes by creating a third bootcmd.cfg file.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ed_P
Contributor
Contributor
Posts: 4126
Joined: 06 Feb 2013, 22:12
Distribution: 4.0 Cinnamon 64-bit ISO
Location: Western NY, USA

Porteus-v4.0rc4 bug reports

Post#75 by Ed_P » 12 Mar 2018, 23:46

Oh! Ok. Thanks for the detailed followup.

Basically you just like creating .cfg files. :D
Ed

Post Reply