UNOFFICIAL antiX-23 “init-diversity” spin.

Forum Forums antiX-development Development UNOFFICIAL antiX-23 “init-diversity” spin.

  • This topic has 71 replies, 9 voices, and was last updated Mar 23-4:51 pm by Brian Masinick.
Viewing 12 posts - 61 through 72 (of 72 total)
  • Author
    Posts
  • #136460
    Moderator
    Brian Masinick

      @masinick @entropyagent @calciumsodium

      It looks that the s6-rc shutdown also has a timer, and it should also work with the new init-diversity-tools.deb update…

      https://skarnet.org/software/s6-linux-init/s6-linux-init-shutdown.html

      I happen to be using the sysVinit instance of init-diversity right now, so I can double-check the functionality, but I believe I’ve already tried all four init alternatives with the 03-02 build (plus the package update you recommended) and everything seems fine. In fact, the reboot, shutdown and poweroff were the first things I checked because the previous version was not quite right; I wrote my own routines for that one, but yesterday it seemed to be correct.

      I’ll examine the file now — YES – poweroff.sh reboot.sh shutdown.sh
      all have distinct logic for each scenario; based on reading them, they appear to be correct. I will explicitly run sysVinit now and report.

      --
      Brian Masinick

      #136461
      Moderator
      Brian Masinick

        I’m back. In that short time, I ran reboot.sh, poweroff.sh and shutdown.sh with the sysVinit and all of them worked.
        I also ran two of them with runit and they also worked. Given that I’m almost positive that I tested all of them the other day as well, I am confident that they work as expected, and given that I examined ALL three of the scripts and read the code, they also appear to be correct.

        I suggest installing the latest image, running the one package change that @ProwlerGr recommended, and try again; it definitely works.

        Actually I am really pleased with all of it. Once 66 eventually adds a complete service infrastructure ALL of these will be able to work almost perfectly. I only say “almost” because even the best software is occasionally subject to edge cases, unusual errors, etc. Whether that is the case here or not, I can already use these in my every day tasks. Even in earlier builds I’ve been able to run any of these instances all day long. I ran sysVinit for an hour or two earlier; now I’m using 66.

        Looking GREAT!

        --
        Brian Masinick

        #136662
        Moderator
        Brian Masinick

          With the latest March 2nd edition of antiX 23.1 init-diversity, I have an uptime of nine hours, fourteen minutes; time to go for today;
          VERY solid 66 configuration that I’ve been using today!

          --
          Brian Masinick

          #136727
          Member
          entropyagent

            @ProwlerGr Thanks for the feedback on the shutdown hh:mm command. I use it a lot, and miss it on my runit systems.

            Both s6-rc and s6-66 (built 2024-03-08 on “antiX-23.1_x64-full Arditi del Popolo 21 February 2024”) shut down reliably at the specified time.

            There do seem to be some discrepancies between sysv/s6-rc/s6-66 regarding how they react to certain parameters, which could cause confusion for people jumping between inits. This is in the context of my hardware (and wetware), using the aliased “shutdown” command with lowercase/uppercase p/P/h/H and a shutdown message.

            #136728
            Moderator
            Brian Masinick

              @ProwlerGr Thanks for the feedback on the shutdown hh:mm command. I use it a lot, and miss it on my runit systems.

              Both s6-rc and s6-66 (built 2024-03-08 on “antiX-23.1_x64-full Arditi del Popolo 21 February 2024”) shut down reliably at the specified time.

              There do seem to be some discrepancies between sysv/s6-rc/s6-66 regarding how they react to certain parameters, which could cause confusion for people jumping between inits. This is in the context of my hardware (and wetware), using the aliased “shutdown” command with lowercase/uppercase p/P/h/H and a shutdown message.

              I haven’t worked with the time unit recently on shutdown; I definitely used these as a system administrator in two of my UNIX assignments.

              I’d always send out maintenance reminders whenever there was a release update or re-installation, or routine maintenance. Just before actual shutdown, I’d use the shutdown reminder messages, using either a 15 or 30 minute window; when the system was imminently about to shutdown, the shutdown tool was actually pretty good about it. On my personal Linux system, I could care less about those matters; IF I use shutdown, it’s shutdown NOW. Still, it’s very good to have this available because some people use their systems as server units; my laptops are PERSONAL use only, hence the reason I don’t currently utilize this method at the present time; nevertheless, it’s a useful feature to have available.

              So far the early March build is the best one so far; we’ve made a great deal of progress on it in just a month of experimental builds; GREAT job!

              --
              Brian Masinick

              #137571
              Member
              calciumsodium

                Hello @ProwlerGR,

                I made a snapshot of your latest 23.1 x32 init-diversity spin that also contains the openrc init. When it boots into the liveDVD, I don’t see the different selection of default, sysvinit, runit, s6-rc, s6-66, or openrc that you had in your published iso. Instead, I get the usual antiX menu with one selection. How were you able to have the menu present with the different selections of init in the live iso?

                Also another question. I was curious how the grub-multi-init-enabler work? Which file does the update-grub command access that enables the OS to find s6-rc, s6-66, and openrc inits?

                Just curious how you were able to solve these problems?

                Thanks

                #137583
                Member
                calciumsodium

                  Hello,

                  I wanted to summarize some of the tweaks/optimizations that I have done in my own systems that may help others with respect to the different inits, with respect to antiX.

                  1. On some of my slower systems, using s6-rc init, upon booting to desktop, I do not get wifi, even though connman is up. The way to get around this is to have slimski as a dependency within the connman s6-rc service:

                  
                  sudo touch /etc/s6-rc/sv/connmand-srv/dependencies.d/slimski
                  sudo s6-db-reload
                  

                  After this modification, now I always get wifi to come up upon booting to desktop using s6-rc.

                  2. On all my systems, I autostart links2 to a particular news website. This is the fastest way to get my news. One all my systems, whether slow or fast, using runit init, upon booting to desktop, sometimes connman startup is not completed fast enough before links2 startup is complete. The result is an error message within links2 saying there is no internet. The way I got around this is to add dbus and then connman to the runit slimski service and to remove debus as a dependency in the connman run service.

                  That is, in the file /etc/sv/slimski/run, I added two lines to start dbus and connman:

                  
                  # Start elogind first (optional) - Don't start
                  # sv start elogind && sv check elogind || true
                  sv start dbus
                  sv start connman
                  # Load language code
                  

                  And in the file /etc/sv/connman/run, I commented out the dbus start:

                  
                  # Start dbus first
                  #sv start dbus  &&  sv check dbus  ||  exit 170
                  

                  After this modification, connman more reliably starts and completes its start before links2 starts. Because of this success, I now use this modification in all my solo antiX runit systems.

                  3. On some of my slower x32 systems, I downgraded the kernel to 4.9. There is a side effect to this change. The inits runit, sysvinit, openrc, and s6-rc would boot to desktop. But not s6-66. There is an error during boot:

                  mount-cgroups: fatal; crashed!
                  

                  and then s6-66 crashes immediately after that.

                  To get around this, I modified the s6-66 boot@system:

                  
                  sudo 66 configure -e nano boot@system
                  

                  (You can use other text editors besides nano.)
                  and modified the cgroups to no:

                  
                  ## Mount cgroups [yes|no].
                  CGROUPS=!no
                  

                  then reconfigure 66 system for the next boot:

                  
                  sudo 66 reconfigure boot@system
                  

                  After this modification, now s6-66 boots to desktop using the 4.9 kernel.

                  4. After I install the init-diversity system from a snapshot, I have to manually create the /run/66/scandir/0 folder once in order to boot into s6-66 for the first time.

                  
                  sudo 66 scandir create
                  sudo 66 tree init global
                  

                  From my experience, without this modification, one cannot boot into s6-66 after installation from a snapshot. If there was a way to automatically create the scandir without the user having to do it after installation, that would be great.

                  5. The inits runit, sysvinit, s6-rc, and openrc accepts the /etc/localtime that is set up during installation. But s6-66 does not. The s6-66 boot@system has the default time zone TZ=GMT and hardwareclock to UTC.

                  Within the boot@system, I manually change TZ to:

                  
                  ## Set your timezone, available timezones can be found at /usr/share/zoneinfo.
                  TZ=America/Chicago
                  

                  and hardwareclock to:

                  
                  ## Set RTC [UTC|localtime].
                  HARDWARECLOCK=localtime
                  

                  After these modifications, all the inits are now syncronized to the /etc/localtime.

                  Hope my experience is useful.

                  • This reply was modified 3 weeks ago by calciumsodium.
                  #137587
                  Member
                  ProwlerGr

                    How were you able to have the menu present with the different selections of init in the live iso?

                    I actually create the additional menus manually:
                    I’ve modified file /etc/iso-snapshot.conf to enable option edit_boot_menu=yes
                    This way the isosnapshot tool pauses at a point which allows you to edit the live /boot/isolinux/isolinux.cfg file.
                    I take this opportunity to also edit the live /boot/syslinux/syslinux.cfg & /boot/grub/grub.cfg files with the additional options.

                    I was curious how the grub-multi-init-enabler work?

                    In a nutshell it replaces the following files:
                    /etc/default/grub
                    &
                    /etc/grub.d/10_linux

                    There is a line in 10_linux (around line 35) where you can add paths to inits that you want grub to recognise in a ‘update-grub’ invocation

                    #137591
                    Moderator
                    Brian Masinick

                      Very creative solution; this also provides the technical background behind the mechanics to get the grub-multi-init-enabler to include the additional entries once we rerun it and also run the update-grub procedure. Very good work @ProwlerGr and once again, thank you for that and your kind explanation!

                      --
                      Brian Masinick

                      #137592
                      Moderator
                      Brian Masinick

                        @calciumsodium You have also done some really interesting modifications of the procedures to suit your own configurations and I thank you for these too. I added your HARDWARECLOCK=localtime to my procedures.

                        When I run the init-diversity system, by default it has stuff set up to UTC; I’m a rebel in this area; most stuff says to use UTC as the base and report the local time by using various variables; for my personal systems, I like to have ALL of it set up to my timezone from the start, so one of the tools I wrote for myself was

                        # fix-localtime.bash 
                        sudo ln -sf /usr/share/zoneinfo/EST5EDT /etc/localtime
                        sudo hwclock --hctosys --localtime

                        Any time my configuration doesn’t show what I want, on ANY of my systems, I run this procedure; if additional adjustments are still required, then I run our antiX —> Date and Time procedure and then Use Internet Time Server to set automatically time/date. Works for me.

                        --
                        Brian Masinick

                        #137596
                        Member
                        calciumsodium

                          How were you able to have the menu present with the different selections of init in the live iso?

                          I actually create the additional menus manually:
                          I’ve modified file /etc/iso-snapshot.conf to enable option edit_boot_menu=yes
                          This way the isosnapshot tool pauses at a point which allows you to edit the live /boot/isolinux/isolinux.cfg file.
                          I take this opportunity to also edit the live /boot/syslinux/syslinux.cfg & /boot/grub/grub.cfg files with the additional options.

                          I was curious how the grub-multi-init-enabler work?

                          In a nutshell it replaces the following files:
                          /etc/default/grub
                          &
                          /etc/grub.d/10_linux

                          There is a line in 10_linux (around line 35) where you can add paths to inits that you want grub to recognise in a ‘update-grub’ invocation

                          Ola @ProwlerGR,
                          Thank you for these explanations. I have to confess. My main driver used to be the solo runit antiX 23.1 pre-final iso. After participating in this thread, and figuring out how to optimize runit via the runit-service manager and further manual modifications, how to optimize s6-rc via the s6-rc service manager and further manual modifications, how to optimize the s6-66 by its boot@system and manually enabling and disabling 66 services that @eric had explained, I now use the init-diversity 23.1 as my main driver in ALL my computers. My x64 computers use the runit antiX 23.1 prefinal iso as base that I have added sysvinit, s6-rc, s6-66, and recently openrc. In these systems, my reboot and poweroff commands are slightly different from yours. With my x32 systems, I use your latest premade x32 init-diversity iso and recently added openrc. With your latest instructions, I will see if I can create my own live boot menus for my own use. Thank you so much.

                          #137608
                          Moderator
                          Brian Masinick

                            For me, a different bootable system manages my primary boot loader, so what I do is configure all of the software, make certain that I run the grub-multi-inst-enabler before I update my primary boot loader.

                            In the case of adding in OpenRC, it was no problem at all; I simply went to the primary boot loader and ran sudo update-grub and the next time I booted inst-diversity, it was there in my choices in the boot loader.

                            --
                            Brian Masinick

                          Viewing 12 posts - 61 through 72 (of 72 total)
                          • You must be logged in to reply to this topic.