antiX-23-beta1-runit-full (64bit) for testing

Forum Forums antiX-development Development antiX-23-beta1-runit-full (64bit) for testing

  • This topic has 404 replies, 32 voices, and was last updated Jul 16-4:42 am by andfree.
Viewing 15 posts - 391 through 405 (of 405 total)
  • Author
    Posts
  • #108792
    Member
    marcelocripe

      Motherboard Gigabyte GA-VM900M
      Placa-mãe Gigabyte GA-VM900M

      demo@antix1:~
      $ inxi -zv7
      System:
      Kernel: 5.10.173-antix.1-amd64-smp arch: x86_64 bits: 64 compiler: gcc
      v: 12.2.0 Desktop: IceWM v: 3.3.2 dm: slimski v: 1.5.0
      Distro: antiX-23-beta1-runit_x64-full Grup Yorum 21 March 2023 base: Debian
      GNU/Linux bookworm/sid
      Machine:
      Type: Desktop Mobo: Gigabyte model: VM900M v: Rev2.0
      serial: <superuser required> BIOS: Award v: FD date: 09/14/2007
      Battery:
      Message: No system battery data found. Is one present?
      Memory:
      RAM: total: 890.5 MiB used: 675.6 MiB (75.9%)
      RAM Report: permissions: Unable to run dmidecode. Root privileges
      required.
      CPU:
      Info: single core model: Intel Celeron 420 bits: 64 arch: Core2 Merom rev: 1
      cache: L1: 64 KiB L2: 512 KiB
      Speed (MHz): 1566 min/max: N/A core: 1: 1566 bogomips: 3215
      Flags: acpi aperfmperf apic arch_perfmon bts clflush cmov constant_tsc
      cpuid cx16 cx8 de ds_cpl dtes64 dtherm dts fpu fxsr lahf_lm lm mca mce
      mmx monitor msr mtrr nopl nx pae pat pbe pdcm pebs pge pni pse pse36 pti
      rep_good sep sse sse2 ssse3 syscall tm tm2 tsc vme xtpr
      Graphics:
      Device-1: VIA CN896/VN896/P4M900 [Chrome 9 HC] vendor: Gigabyte
      driver: viafb v: kernel bus-ID: 01:00.0 chip-ID: 1106:3371 class-ID: 0300
      Display: server: X.Org v: 1.21.1.7 driver: X: loaded: openchrome
      unloaded: fbdev,modesetting,vesa dri: swrast gpu: viafb display-ID: :0.0
      screens: 1
      Screen-1: 0 s-res: 1024×768 s-dpi: 97 s-size: 269x202mm (10.59×7.95″)
      s-diag: 336mm (13.24″)
      Monitor-1: VGA-1 res: 1024×768 hz: 60 dpi: 98
      size: 265x199mm (10.43×7.83″) diag: 331mm (13.05″) modes: N/A
      API: OpenGL v: 4.5 Mesa 22.3.3 renderer: llvmpipe (LLVM 15.0.6 128 bits)
      direct-render: Yes
      Audio:
      Device-1: VIA VX900/VT8xxx High Definition Audio vendor: Gigabyte
      driver: snd_hda_intel v: kernel bus-ID: 80:01.0 chip-ID: 1106:3288
      class-ID: 0403
      Sound API: ALSA v: k5.10.173-antix.1-amd64-smp running: yes
      Network:
      Device-1: VIA VT6102/VT6103 [Rhine-II] vendor: Gigabyte driver: via-rhine
      v: N/A port: d000 bus-ID: 00:12.0 chip-ID: 1106:3065 class-ID: 0200
      IF: eth0 state: unknown speed: 100 Mbps duplex: full mac: <filter>
      IP v4: <filter> scope: global broadcast: <filter>
      IP v6: <filter> scope: link
      WAN IP: <filter>
      Bluetooth:
      Message: No bluetooth data found.
      Logical:
      Message: No logical block device data found.
      RAID:
      Message: No RAID data found.
      Drives:
      Local Storage: total: 14.65 GiB used: 24.5 MiB (0.2%)
      ID-1: /dev/sda type: USB model: N/A size: 14.65 GiB type: N/A
      serial: <filter> rev: 2.00 scheme: MBR
      Floppy-1: /dev/fd0
      Partition:
      ID-1: /live/boot-dev raw-size: 1.56 GiB size: <superuser required>
      used: <superuser required> fs: N/A dev: /dev/ventoy mapped: ventoy
      label: N/A uuid: N/A
      ID-2: /media/VTOYEFI size: 31.9 MiB used: 24.5 MiB (76.9%) fs: vfat
      dev: /dev/sda2 label: VTOYEFI uuid: 5079-58EC
      Swap:
      Alert: No swap data was found.
      Unmounted:
      ID-1: /dev/dm-0 size: 1.56 GiB fs: <superuser required> label: N/A uuid: N/A
      ID-2: /dev/sda1 size: 14.62 GiB fs: exfat label: Ventoy uuid: 4E21-0000
      USB:
      Hub-1: 1-0:1 info: Full speed or root hub ports: 8 rev: 2.0 speed: 480 Mb/s
      chip-ID: 1d6b:0002 class-ID: 0900
      Device-1: 1-2:2 info: USB Disk 2.0 type: Mass Storage driver: usb-storage
      interfaces: 1 rev: 2.0 speed: 480 Mb/s power: 100mA chip-ID: ffff:5678
      class-ID: 0806 serial: <filter>
      Hub-2: 2-0:1 info: Full speed or root hub ports: 2 rev: 1.1 speed: 12 Mb/s
      chip-ID: 1d6b:0001 class-ID: 0900
      Hub-3: 3-0:1 info: Full speed or root hub ports: 2 rev: 1.1 speed: 12 Mb/s
      chip-ID: 1d6b:0001 class-ID: 0900
      Hub-4: 4-0:1 info: Full speed or root hub ports: 2 rev: 1.1 speed: 12 Mb/s
      chip-ID: 1d6b:0001 class-ID: 0900
      Hub-5: 5-0:1 info: Full speed or root hub ports: 2 rev: 1.1 speed: 12 Mb/s
      chip-ID: 1d6b:0001 class-ID: 0900
      Device-1: 5-1:2 info: Trust B.V. Optical Mouse type: Mouse
      driver: hid-generic,usbhid interfaces: 1 rev: 1.1 speed: 1.5 Mb/s
      power: 100mA chip-ID: 15d9:0a4f class-ID: 0301
      Sensors:
      System Temperatures: cpu: 44.0 C mobo: N/A
      Fan Speeds (RPM): N/A
      Info:
      Processes: 122 Uptime: 4m wakeups: 40 Init: runit v: N/A runlevel: 2
      Compilers: gcc: 12.2.0 alt: 12 Packages: pm: dpkg pkgs: 1617 Shell: Bash
      v: 5.2.15 running-in: roxterm inxi: 3.3.25
      demo@antix1:~
      $

      #108793
      Member
      marcelocripe

        The Gigabyte GA-VM900M Motherboard when it was started with Kernel 5.10. 173 it was possible to start with the graphic mode and with the resolution 1024×768. The same motherboard with kernel 6.1.18 failed to start graphics mode. Boot process stopped on black screen with some error messages. The screen was flickering all the time, meaning the text and image were constantly appearing and disappearing. Due to the screen flickering, it made it very difficult to take pictures.

        – – – – –

        A Placa-mãe Gigabyte GA-VM900M quando foi iniciada com o Kernel 5.10.173 foi possível iniciar com o modo gráfico e com a resolução 1024×768. A mesma placa-mãe com o kernel 6.1.18 não conseguiu iniciar o modo gráfico. O processo de inicialização parou na tela preta com algumas mensagens de erro. A tela ficava piscando o tempo todo, ou seja, o texto e a imagem aparecia e desaparecia constantemente. Devido a tela ficar piscando, tornou muito difícil registrar as fotos.

        http://ibb.co/Tmp7fZW
        http://ibb.co/C9Khrrz
        http://ibb.co/rFRdWQf
        http://ibb.co/cNp21dn
        http://ibb.co/RyC6pWJ

        #108820
        Member
        mcpderez

          gazelle-installer doesn’t respect user’s choice of 12-hr or 24-hr clock format

          In gazelle-installer (http://github.com/gazelle-installer/gazelle-installer/blob/master/oobe.cpp), this choice is handled by doing a string replacement on the relevant configuration files under /etc/skel.

          For 12-hour (currently at lines 433-436):

                  //antix systems
                  proc.shell("sed -i 's/%H:%M/%l:%M/g' " + skelpath + "/.icewm/preferences");
                  proc.shell("sed -i 's/%k:%M/%l:%M/g' " + skelpath + "/.fluxbox/init");
                  proc.shell("sed -i 's/%k:%M/%l:%M/g' " + skelpath + "/.jwm/tray");
          

          For 24-hour (currently at lines 465-468):

                  //antix systems
                  proc.shell("sed -i 's/%H:%M/%H:%M/g' " + skelpath + "/.icewm/preferences");
                  proc.shell("sed -i 's/%k:%M/%k:%M/g' " + skelpath + "/.fluxbox/init");
                  proc.shell("sed -i 's/%k:%M/%k:%M/g' " + skelpath + "/.jwm/tray"); 

          In /etc/skel/.icewm/preferences there are two TimeFormat lines, but they are both commented out. Even if they weren’t, they do not contain %H:%M. This seems to have broken around antiX-19; antiX-17.5 still has %H:%M.

          mcpderez@x230t:/etc/skel/.icewm
          $ grep TimeFormat preferences
          #TimeFormat="%a %m/%d %l:%M" #US format?
          #TimeFormat="%I:%M" #UK format?

          As a result, regardless of the choice in the installer, IceWM just uses the compiled-in default “%X” because the TimeFormat remains commented out:

          mcpderez@x230t:/etc/skel/.icewm
          $ icewm -p | grep TimeFormat
          TimeFormat="%X"

          For the US, the TimeFormat for a 12-hour clock could be: “%r” and this may work for other locales as well. It’s not ideal as we generally do not use the leading 0 on single digit hours, but this simple format string may be more applicable to the rest of the world, and I know how to change it to “%l:%M:%S %p” to drop that 0.

          From the strftime (3) man page:

          
                 %r     The time in a.m. or p.m. notation.  (SU) (The specific
                        format used in the current locale can be obtained by
                        calling nl_langinfo(3) with T_FMT_AMPM as an argument.)
                        (In the POSIX locale this is equivalent to %I:%M:%S %p.)

          For a 24-hour clock, I’d suggest “%T”. I recognize that default formats, such as whether to include seconds or not, and what provides the best localization results, could be up for further discussion.

          It looks like a similar issue exists in the settings for JWM. I don’t recall if I selected 12-hour or 24-hour on this latest installation, but my /etc/skel/.jwm/tray has:

          
             <Clock format="%H:%M">

          which could not be a possible outcome of the substitutions called for by gazelle-installer.

          The resolution of this bug and any decisions about default formats could also influence @PPC’s script to manage IceWM’s settings via a GUI. Please let me know if I can provide any further testing or details.

          Finally, I’d like to thank the development team for already providing the latest release of IceWM from June 5 which incorporated a change championed by @Wallon. That was an interesting discussion for sure, and I am delighted the release already made it to us.

          • This reply was modified 8 months, 3 weeks ago by mcpderez.
          • This reply was modified 8 months, 3 weeks ago by mcpderez.
          #108852
          Moderator
          Brian Masinick

            I’ve been using %r for my clocks for many years. Works great.

            --
            Brian Masinick

            #108913
            Member
            ChPol

              A few malfunctions that seem to exist only on my workstation, and the corrections I’ve made to fix them when I do a new installation.
              Dell Latitude E5430 with antiX 23 runit installed on the machine’s hard disk

                Trouble with a language other than English

              • I’m using an obsolete variant AZERTY keyboard for Dell Latitude (laptop). If the keyboard stays in AZERTY after a startup, the variant jumps and in particular AltGr + W gives me ł instead of open quotation marks « (other characters change too but it’s an easy test).
                The hard-coded keyboard in X11 configuration is selected according to the logs, but is no longer active when I start my session. The keyboard configuration set in the session startup, even with a delay, works from time to time. Even when it does work, after a long sleep of several hours, waking up is accompanied by the loss of the variant. I made a shortcut to launch the correct mapping just before writing correctly.
              • setxkbmap -model latitude -layout fr -variant oss_latin9

              • The tty2… console uses a QWERTY layout, which is not practical for typing username and password. This configuration is modified by adding setupcon at the end of the file /etc/runit-core/*S17bootmisc.sh (Command that applies the machine’s default settings and works regardless of language or keyboard).
              • This reply was modified 8 months, 3 weeks ago by ChPol.
              • This reply was modified 8 months, 3 weeks ago by ChPol.
              • This reply was modified 8 months, 3 weeks ago by Brian Masinick.
              #108942
              Member
              ChPol

                Boot-up problem
                AntiX on key worked normally, but when installed on hard disk I noticed a 15-second pause in the middle of startup, with no access to the disk.
                I haven’t really found the cause, but I’ve done the following.
                In /etc/runit-core
                I removed various services located in /etc/runit-core/old (folder created)
                – mounting encrypted partitions
                – nfs mounts at start
                – screen lighting
                I don’t use an encrypted home, I don’t use an nfs folder to mount at startup and the laptop bios seem to manage screen lighting on mains and battery power.

                In /etc/runit/runsvdir/default
                I removed the symbolic links to:
                – avahi-daemon
                – getty-tty3
                – saned
                – ufw
                cups left but disabled in service management. I start it by hand when I need it.

                When I was making these changes, there were big updates on the Debian side and I don’t know if I addressed the problem or if a Debian bug was fixed.
                Startup is much faster now.

                #108950
                Member
                marcelocripe

                  Please post your tests in the antiX-23-beta1-runit-full (64bit) for testing thread.

                  Thanks for helping with the tests.

                  – – – – –

                  Por favor, poste os seus testes no tópico antiX-23-beta1-runit-full (64bit) for testing.

                  Obrigado por ajudar com os testes.

                  #108955
                  Member
                  ChPol

                    I’ve already posted these problems in developement and people have told me that I’m the only one having these problems. Although this may be an exaggeration, it’s quite possible that the number of users affected is very, very small, so the antiX team doesn’t have to worry about it.
                    (Particular language on a particular laptop with a special SSD…) I don’t have any requests on these posts since I’ve found a solution to fix them.

                    I’m publishing this in the documentation to provide a solution for the unlucky few who have similar problems. Now that Debian stable has been released, antiX will follow and some people will probably have the same problems (I expect they don’t but they have solutions).

                    #108959
                    Moderator
                    Brian Masinick

                      Boot-up problem
                      AntiX on key worked normally, but when installed on hard disk I noticed a 15-second pause in the middle of startup, with no access to the disk.
                      I haven’t really found the cause, but I’ve done the following.
                      In /etc/runit-core
                      I removed various services located in /etc/runit-core/old (folder created)
                      – mounting encrypted partitions
                      – nfs mounts at start
                      – screen lighting
                      I don’t use an encrypted home, I don’t use an nfs folder to mount at startup and the laptop bios seem to manage screen lighting on mains and battery power.

                      In /etc/runit/runsvdir/default
                      I removed the symbolic links to:
                      – avahi-daemon
                      – getty-tty3
                      – saned
                      – ufw
                      cups left but disabled in service management. I start it by hand when I need it.

                      When I was making these changes, there were big updates on the Debian side and I don’t know if I addressed the problem or if a Debian bug was fixed.
                      Startup is much faster now.

                      I like your work around; seems that it was effective for you and if you are not utilizing the services you disabled anyway and they were affecting performance, I think you made an intelligent choice. Thanks for sharing it with us.

                      I’ll see if I can either merge or copy these comments into the antiX 23 beta1 testing thread…

                      --
                      Brian Masinick

                      #108966
                      Moderator
                      Brian Masinick

                        @ChPol your sub-thread has been successfully merged into the antiX 23 Beta 1 testing thread topic.

                        --
                        Brian Masinick

                        #108974
                        Moderator
                        christophe

                          some people will probably have the same problems (I expect they don’t but they have solutions).

                          That’s good work. I have a similar situation on the beta – but only when installed (not live) – as you pointed out. My system pauses for 2-3 minutes before continuing to boot. If that issue continues into the final release, for our niche cases, your workaround would be a great addition to our Tips & Tricks section.

                          • This reply was modified 8 months, 3 weeks ago by christophe.

                          confirmed antiX frugaler, since 2019

                          #108994
                          Moderator
                          Brian Masinick
                            #111170
                            Member
                            andfree

                              (…)
                              dbind-WARNING **: 18:11:18.217: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
                              (…)
                              another potential solution I found on the web (but failed to test before installing at-spi2-core) is to set the environment variable NO_AT_BRIDGE=1 by adding it to .bashrc or similar — this solution, if it works, takes almost no space:

                              export NO_AT_BRIDGE=1

                              It seems that it worked for me (in beta2, 32-bit). Many thanks.

                              • This reply was modified 7 months, 3 weeks ago by andfree.
                              #111260
                              Member
                              andfree

                                It seems that it worked for me (in beta2, 32-bit).

                                Unfortunately, it didn’t. After a dist-upgrade, the Error appeared again. I’m not sure what exactly should I have done:
                                – add “export NO_AT_BRIDGE=1” to .bashrc?
                                – add “NO_AT_BRIDGE=1” to .bashrc?
                                – run “export NO_AT_BRIDGE=1” via a terminal?

                                #111801
                                Member
                                andfree

                                  I’m not sure what exactly should I have done:
                                  – add “export NO_AT_BRIDGE=1” to .bashrc?
                                  – add “NO_AT_BRIDGE=1” to .bashrc?
                                  – run “export NO_AT_BRIDGE=1” via a terminal?

                                  Nothing of the above seems to have worked for me. Only this seems to have fixed the issue:

                                  sudo apt install at-spi2-core

                                  • This reply was modified 7 months, 2 weeks ago by andfree.
                                Viewing 15 posts - 391 through 405 (of 405 total)
                                • You must be logged in to reply to this topic.