Faster Boot for antiX Linux 23

Forum Forums General Tips and Tricks Faster Boot for antiX Linux 23

  • This topic has 61 replies, 13 voices, and was last updated Oct 8-7:11 pm by olsztyn.
Viewing 15 posts - 1 through 15 (of 62 total)
  • Author
  • #116402

      antiX is a lightweight and fast Linux distribution based on Debian GNU/Linux, aimed at low-specification computers and older systems. Despite its small size, it still provides a full range of applications and utilities without sacrificing functionality. However, even with its small footprint, there are always opportunities to improve performance, and the boot process is no exception. In this article, we will explore various methods to optimize the antiX Linux system for faster boot times and enhanced overall performance.

      When booting from an installed or live USB antiX Linux system, the boot process involves several stages, including loading the Linux kernel and initial RAM disk (initrd) images, mounting the root file system, starting the various system services, and finally loading the graphical environment through the desktop session program. Each stage can be optimized, but the biggest influence in performance will be the hardware configuration of the machine running antiX. We can begin our improvements here.

      1. Hardware Upgrades

      Upgrading your computer’s hardware is the fastest and easiest way to improve both boot time and overall performance. Here are some recommendations:

      Faster Storage:
      antiX Linux can benefit greatly from faster storage devices. The following are some ways to improve boot times by upgrading your storage:

      • Using a Solid State Drive (SSD): Installing an SSD as the primary storage device for your antiX installation can significantly reduce boot time and enhance overall system responsiveness. This is because SSDs have much faster read and write speeds compared to traditional hard disk drives (HDDs). This improvement is good for both normal and frugal installations.
      • Faster USB devices: Those utilizing an external device to take advantage of one of the best live Linux systems available can also take advantage of faster storage. Using the latest USB-3 and USB-C ports with a faster USB storage device, such as an external SSD or high-speed flash drive, will enhance the booting and operating speed of the system, making its performace very close to running as an installed system.

      Faster CPU:
      A faster processor reduces the time it takes to decompress the initrd image and process kernel and boot commands, leading to shorter boot times. Additionally, it improves system responsiveness across the board.

      RAM speed can slightly impact the boot time, especially when using a ramdisk to launch startup programs and services during initialization. And having more RAM will reduce the dependence on swapping on the hard drive, which improves responsiveness. On live environments, more RAM increase the size of persistent data, remaster larger images and even run the entire system in memory for maximum performance (though this may slow down the startup process).

      2. Shorter time for GRUB boot loader

      If the main Operating System installed on your machine is antiX, you may consider reducing the grub bootloader selection time to 0 or 1 seconds. This will reduce the time GRUB is displayed before automatically selecting the first item on the list of available boot options.

      Edit /etc/default/grub with root privileges and change the value of the GRUB_TIMEOUT variable to 0 (to skip grub as fast as possible) or 1 (for a 1 second timeout).

      After saving, update grub from the terminal with the command:
      sudo update-grub
      and in the following reboots, GRUB will wait a shorter amount of time before selecting the default OS (hopefully antiX).

      The live-USB system also has a timeout. For the grub live boot menu, you can also change the grub timeout by adding
      set timeout=1
      to the end of the grub.cfg file inside the /boot/grub folder in the antiX USB device. Change 1 for the amount of seconds you want the menu to wait for.

      The legacy menus also have a timeout value you can change. Edit the timeout value found in syslinux.cfg inside boot/syslinux and or the isolinux.cfg file inside boot/isolinux folder of the live USB (not tested).

      3. Kernel and initramfs optimization

      On installed systems, reducing the size of critical files like the Linux kernel and initramdisk images is another way to improve boot and overall system performance.

      Lighter Kernel:
      The kernel plays a crucial role during boot, where it loads and unloads modules, initializes drivers, and sets up the file system. By default, antiX uses a pre-configured kernel optimized for most common systems, but you can also get smaller and lighter kernels from other sources (even newer ones from the antiX repository). It is best to experiment and find the kernel release that best matches your machine hardware.

      Alternatively, compile your own kernel using the latest versions of the Linux kernel sources to achieve maximum performance. This is a more advanced option, and its complexity will not be explored in this article.

      Smaller Initramfs:
      Reducing the size of the initramfs by including only necessary kernel modules and drivers specific to your machine’s hardware will result in a smaller initrd.image file. Additionally, choosing a faster compression algorithm will accelerate the uncompression process during initialization.

      To achieve this, edit (with root privileges) the file /etc/initramfs-tools/initramfs.conf
      Change the MODULES variable from most to dep so that only the required microcodes and kernel modules are loaded during boot. If you know which modules are essential, list them in /etc/initramfs-tools/modules instead and set MODULES to the list value.

      For the COMPRESS variable, select a compression algorithm that best matches your hardware. Choose between faster decompression (for example, lz4, best for slower and older machines) or smaller file sizes (for example, xz compression, best for faster CPUs). Install the necessary libraries for xz or lz4 compression algorithms if needed.

      After saving the changes to initramfs.conf, you need to update the initrd.image files for all kernel. First test the change with the current kernel
      sudo update-initramfs -u
      If after rebooting everything seems to work, do it for all the available kernels on your systemYou can use this command:
      sudo update-initramfs -u -k all
      If it didn’t work properly, boot with a different kernel and undo the changes to MODULES (and again run the command above).

      Personal experience: I use MODULES=dep and COMPRESS=lz4 (I installed the lz4 package to make it work), and with the above change, the kernel and initramdisk initialization stage has improved from 3-4 seconds to 2-3 seconds.

      Note: The initrd optimizations only make sense for installed systems, as the initrd creation process is different for the antiX live system (uses the live-kernel-updater program, which already creates a small initrd file).

      4. Removing Unnecessary Services

      Removing services that you don’t immediately need or use can also improve boot times. For example, if you rarely use the scanner or printer, remove these services from the bootup process and enable them only when needed. Doing so reduces the amount of time spent initializing unnecessary services, thus speeding up the boot process.

      To see all running services, run in the terminal
      sudo service --status-all
      which will show you the state of all services for either the sysvinit or runit edition. You can manage these services through a GUI or CLI app found in the “Choose Startup Services” entry under the “System” tab of the Control Centre.

      Additionally, when runing live, disabling groups of services using the “disable” boot parameter can further optimize the boot process. More information in the antiX FAQ.

      5. Desktop Startup Optimization

      In the final stage of booting, the desktop environment loading stage, you can also find some possible optimizations. Mainly in the selected desktop, the login manager and startup commands.

      Login manager:
      Before the desktop loads, the login manager needs to start. If you have your system autologin your user, you could try replacing it with a faster method to log-in and start the user’s desktop. Greetd, as an example, is faster when starting the xorg environment (and even faster for wayland compositors), but it isn’t as easy to set up for xorg environments (possible tutorial in the future).

      Avoiding a login manager is an even faster option. Using xinit and startx has a similar complexity to setting up greetd, and achieves similar times.

      Personal Experience: On live-usb, on my computer, slimski takes about 3.6 seconds (min 3.28 – max 4.19) to reach the icewm desktop, while using greetd has an average loading time to desktop of 3.0 seconds (min 2.76, max 3.21). Pure startx and xinit is just a bit faster than greetd, 0.4s average less time with my tests.

      This step can only shave off milliseconds from your startup time, but maybe this is all you need. I haven’t tested with slim, lxdm or xdm, but they are probably similar to slimski, if not a bit faster.

      Desktop session startup time:
      antiX Linux’s desktop loading is generally managed by desktop-session. By default, there is a delay of 2-3 seconds before the startup sccript runs, to give enough time for the window manager or desktop environment to load. This amount is ideal for older machines, but faster computers dcan do with a smaller value.

      This delay can be reduced by editing the variable”STARTUP_DELAY found inside the $HOME/.desktop-session/desktop-session.conf file. For most cases, a number between 0 and 1 should work.

      Startup programs:
      Another option is to remove unnecessary startup programs that load with the graphical environment. Open $HOME/.desktop-session/startup and remove or replace programs that you don’t need or want. Examples include autoscale-antix, network-check-antix, volumeicon, etc. This will help reduce the amount of time it takes the desktop session to finally load.

      Faster Xorg Window Managers or Wayland Compositors:
      It is difficult to beat the minimal window managers provided by default in antiX. But there is always a way to squeeze even more performance. If you are ready to experiment with other environments, you could try other faster Window Managers. Herbstluftwm, included with antiX base and full, is a tiling window manager that has a much smaller footprint compared to the default fluxbox, icewm or jwm. It boots just a bit faster, but it is a totally different experience compared to floating window managers, so the average user may not feel welcomed.

      Another alternative is to use a wayland compositor, like sway or wayfire. Because it doesn’t use the X server, it boots up much faster. But for most linux desktop users, it may feel too barebones and different, but it still is a valid option for those adventurous enough to try something new.

      In this article, we have discussed both hardware and software improvements. While some optimizations may only shave off milliseconds, others can save seconds in the overall boot process, resulting in a faster and smoother experience. Remember that these optimizations are not one-size-fits-all solutions, and it’s up to you to decide what works best for your hardware and use case. With experimentation and testing, you can achieve significant performance gains while still enjoying the benefits of an efficient and lightweight operating system like antiX Linux.

      Note: How to measure the boot time? antiX provides a cli tool that will output the time before a program was launched since the kernel loaded. This command is start-t. Example:
      start-t icewm
      fot the total system time until icewm launched, or
      start-t slimski
      for the time since the system started to slimski’s service start


        PART 2 – Experimental boot improvements for antiX 23 runit edition

        antiX Linux is known for being a modern Linux operating system that is fast and efficient, thanks in part to the use of “alternative” init systems. runit, a simple init replacement for SysVInit that has been part of the antiX distribution since 2019, offers a fast initialization process that complements the overall efficiency of the operating system. In this article, we will explore how to optimize it even further while also presenting new experimental features planned for future antiX releases.

        This guide covers three main areas of improvement: logging of runit stages, optimization of the initialization process (stage 1), and an alternative sysvinit init compatibility service for stage 2.

        Before proceeding, note that most changes require manual intervention, such as modifying files or creating new ones. It’s recommended to back up important files before making modifications or test them on a live system with persistence. If something goes wrong, you can easily remove the persistence file and start over without risking your working system.

        All changes and improvements discussed here can be found in these three gitlab repos, which I will be referencing throughout the article:

        0. About runit stages

        runit operations can be divided into three stages:

        • Stage 1: System Boot – This stage involves initializing the system’s one-time operations. The stage file is located in /etc/runit/1.
        • Stage 2: Running the System – During this stage, the system operates normally until it undergoes a halt or reboot operation. The runit service scripts are loaded here. Located in /etc/runit/2.
        • Stage 3: System Shutdown – This stage performs the necessary tasks required to shut down the system properly. The stage file is located in /etc/runit/3.

        The startup (starting with “S”) and shutdown (starting with “K”) scripts are part of the runit-core collection of packages, and can be found inside the /etc/runit-core directory.

        To optimize the boot process, we need to focus on stages 1 and 2, as they occur immediately after the kernel and initrd loading and initialization. For a faster shutdown, we would have to look into stage 3 instead.

        1. Logging runit stages

        Proper logging is essential for troubleshooting and understanding system behavior. As this was a lacking feature for the runit stages, we have addressed this recently, by adding logging to the runit stages. By logging the progress of the initialization process, this data can then be used to troubleshoot booting errors and further refine the system’s performance.

        Steps to Enable Logging​:

        1. Replace the content in /etc/runit/1 with the same file found in the runit-antix git repo.
        2. Add the file (found in the contrib/lib folder) to the /lib/runit/ folder in your system.
        3. Edit the /etc/default/runit-antix config file to enable both DEBUG=1 (saves the log file), and VERBOSE=1 (to save timestamps for each message printed by stage 1).
        4. Assign a new variable LOG_FILE to /etc/default/runit-antix. The value should be set as LOG_FILE=”/etc/runit/runit.log”, but you can decide on a different path if you want.
        5. Optionally, you can also add logging to stages 2 and 3 by replacing them with the ones in runit-antix testing/sid git repo.

        After enabling logging, you’ll be able to check the time it takes for stage 1 to perform each step. Very useful for checking how long it takes for the kernel and initrd images to load (first timestamp in stage 1). It will also help if you update all runit-core scripts (see section 3).

        2. Stage 2 optimization: Faster SysVInit script loading

        While runit offers many advantages over traditional init systems, some users may still require compatibility with legacy sysvinit scripts. To address this need, antiX already provides a step in stage 2 that launches the necessary init scripts in /etc/rc2.d sequentially. This process delays starting the desktop, as all init scripts need to be executed first. To speed up this step, we have developed an alternative init compatibility service that runs alongside the standard runit services during stage 2, instead of before it.

        Enabling it in the future will be as simple as updating the system, but right now you need to make many changes.

        As starting and stopping the SysVInit scripts will be managed by a runit service, we need to first remove all problematic shutdown scripts from both /etc/init.d/ and /etc/rc0.d/ and /etc/rc6.d/ which would interrupt the shutdown of other runit services. These are ““, ““, “umountfs“, “umountroot“, and “sendsigs“. Once removed, we can replace them with runit-core scripts, and place them in /etc/runit-core/ (,,,, and can be found here). Remember to make them executable.

        Next, we will create a new folder in /etc/sv named “sysvinit-compat” and copy over both the run and finish files from the runit-antix git repo to /etc/sv/sysvinit-compat and make them executable.

        Finally, we enable the new sysvinit-compat service (you can use the runit-service-manager for this), and replace both runit stages 2 and 3 with the ones in the runit-antiX gitlab repository if we haven’t yet done it.

        After rebooting, the service sysvinit-compat will be in charge of starting and stopping sysvinit scripts.

        Personally, I found that on a pristine antiX 23 full runit live-USB, stage 2 went from taking 0.2 seconds before starting the runit services, to 0.01 seconds.

        3. Stages 1 and 3 optimizations

        In the process of cleaning the runit-core scripts, we decided to move to an easier folder organization. Startup scripts (name starting with the letter “S“) were moved to a startup.d folder and the shutdown tasks (starting with a “K” letter) were moved to a shutdown.d folder. Logging for these scripts was also improved to use simpler and more optimized functions.

        These are the steps to make this change work:

        • Replacing the, and scripts in the /lib/init/ directory on your machine with the ones in runit-core-services-antix testing/sid git repo (/init folder).
        • Creating a startup.d folder in /etc/runit-core and copying all startup.d scripts from the runit-core-services-antix testing/sid git repo and from the runit-full-core-services-antix testing/sid git repo. Remember to make them executable.
        • Optionally, you can also copy the shutdown.d scripts from same git repos as above.

        These steps look simple, but if you are to do it manually, it will take a very long time. It is easier to clone both runit-core git repositories and copy the startup.d and shutdown.d folders over to /etc/runit-core, but if you don’t know how to, better wait for the future upgrade. These changes will help you scrape some milliseconds of the boot time. But the biggest benefit is improved logging and more accurate boot time measurements.

        Personal Experience: Default runit stage 1 (no runit-core script change) takes about 5.2 seconds (min 4.68 – max 5.5) to run on live-USB. After replacing them with the cleaner runit-core scripts in startup.d, (with VERBOSE turned off), this stage takes an average amount of 4.9 (4.74 – 5.21) seconds to run. All this on antiX 23 full runit on live-USB.

        4. Dealing with the “Waiting for /dev to be fully populated …” very long delay

        One of the slowest steps during startup is waiting for pending udev events while building the list of available devices. If the kernel has problems with some devices, it will wait for up to 120 seconds before continuing with the boot process.

        Included in the runit core scripts cleanup (mentioned in section 3 of this article) is an improvement to udev settle by adding a timeout override. This will give more control on boot-up delays (so the user doesn’t have to wait 2 minutes for the system to start) and can give an edge on startup optimization. The variable that controls this timeout (in seconds) can be edited in /etc/default/runit-antix, as UDEV_SETTLE_TIME.

        will limit the max time for udev to settle to 30 seconds (only full numbers). You can make it shorter by using a smaller amount.

        You can even make it 0 if you observe that it doesn’t cause problems on your system. If running a dedicated graphical card, better not skip this step with a 0 value, as it could lead to no graphical environment. It is best to test how tolerant is your system to this change.

        The long delay experienced with this step (the udev settle process) could be related to an external device (like a DVD or Blue-ray player) not properly detected by the kernel. It is faster to skip this detection and later unplug and re-plug the device to try to get it detected when already in the graphical environment than to wait a whole 2 minutes and still not get detected.

        5. Removing runit-core scripts from execution

        After following the instructions in the third section of this article, you can now measure which startup tasks take the longest time. For example, udev settling takes the longest on my system (about 3 seconds), but it is needed for my external USB hub to properly work. Also, setting up the console or the keyboard configuration are also slower than other tasks, but I prefer to keep them. Some runit-core scripts like the urandom startup, the nfs setup and the cryptdisk preparations are not needed in my system. If I remove them, I can shave off a few milliseconds from my boot time.

        New alternative options for the runit-core tasks (be it order or content) can be applied thanks to the updated stage 1 instructions. You can now:

        • Create a custom /etc/runit-core/startup script that will run whatever you have set up there instead of the scripts in /etc/runit-core/startup.d.
        • Add a different extension to the scripts in startup.d folder to have stage 1 skip them. Same effect as removing the file, but letting you keep it instead.
        • Use a completely separate startup.d folder in some other path, where you can add, remove, reorder and modify any runit-core script, and they won’t be affected by unexpected updates. You can set the path to this alternative folder inside the /etc/default/runit-antix file with the variable STARTUP_DIR=”/path/to/startup-folder” (the path must not end with a slash “/” symbol).

        Improving the boot process is an essential part of ensuring a smooth and efficient user experience. With these experimental improvements, antiX Linux continues its tradition of excellence in performance, reliability, and usability.

        We’re confident that these improvements will make antiX an even more attractive option for those seeking a fast, efficient operating system. As always, we welcome feedback to help us continue to refine and optimize our software. Stay tuned for updates on our progress.

        You can see in more detail the list of changes that were implemented in the original merge request for the runit-antix source. It explains the reasoning behind each modification, for those interested.

        • This reply was modified 8 months, 1 week ago by abc-nix. Reason: Emphasis on git repositories

          Thank you for these explanations.
          Can I use the runit-antix, runit-core-services-antix and runit-full-core-services-antix from the testing/sid repos and use them on my bookworm stable system for testing purposes or do I need to test them on an antiX testing/sid system? I would prefer to test them on my stable system.


            Thank you @abc-nix for this excellent study and analysis of boot process and performance in antiX world.
            This will be included in my knowledge database.
            Greatly appreciated.

            Live antiX Boot Options (Previously posted by Xecure):


              These are the steps to make this change work:

              Could you please clarify what needs to be done on updated Trixie/SID system, which means antiX SID/Debian Unstable?
              My current ‘production’ antiX 23 turned into Trixie/SID and I keep it as stable and a rock day-to-day system… Just antiX compatible updates allowed.
              I am not clear if the new optimized Runit components are already included in SID…

              Live antiX Boot Options (Previously posted by Xecure):


                Can I use the runit-antix, runit-core-services-antix and runit-full-core-services-antix from the testing/sid repos and use them on my bookworm stable system for testing purposes

                Could you please clarify what needs to be done on updated Trixie/SID system, which means antiX SID/Debian Unstable?

                Sorry I didn’t explain it properly. These changes work on antiX 23 and antiX testing.
                When I am talking about “repo” I meant the antiX git repositories on gitlab (I changed the text of the article), and when I talk about “testing/sid repos”, I mean the testing/sid branches in these git repositories.

                These changes are not packaged yet, and are being tested in the experimental state they currently are in. Once more testing and fixes are found, they can be packaged and made available in the dev branch repo for antiX testing and sid.

                A note on how these changes (both general and runit improvements) have made an impact on my system. My main antiX installation is using the testing repositories. I have reduced the size of my initrd image, used a modern 6.4 kernel, replaced slimski with greetd, and moved from a heavy window manager (enlightenment) to a wayland compositor (Hyprland). I also actively use the runit changes proposed in the git merge request and discussed in my second post.

                My old boot times (published several months ago in the forum):

                and about 12 seconds to my window manager:

                start-t enlightenment

                My current boot time to Hyprland:

                start-t Hyprland

                Almost half the time. Probably it would be about 10 seconds previously if running icewm, so about 25% improvements.
                If I set the udev settle time to 0, I got boot times of less than 5 seconds, but randomly my USB hub would not work, and I needed to unplug and replug it.


                  I love these articles! Thank you. Perhaps they can be added to the wiki.

                  I played a bit with Hyprland with antiX-22 but I blew that install away when I started testing antiX-23. At the time I was taking inspiration from several posts in r/unixporn (which I am glad to discover has reopened). Would you consider posting a snapshot in the respin sub forum? I understand if you would have too much personalization to undo to make that a judicious use of your time. Posting a screenshot could be cool too.


                    Reading, visiting the GIT pages, reading more, then Messing with UDEV settle time made
                    my boot wait infinite, No X, just black screen and cursor. fixing the problem took
                    me longer than the time I could save with quoted reductions when booting once a day for years….

                    Normally the system boots to ICEWM from NVME in very few seconds.

                    Make sense to me, sorry no.


                      Next week I will see if I can package the runit experimental changes for easier testing.

                      Would you consider posting a snapshot in the respin sub forum? I understand if you would have too much personalization to undo to make that a judicious use of your time. Posting a screenshot could be cool too.

                      A snapshot wouldn’t work properly, as I have Hyprland set up with a nix package and don’t know how this would work in live USB. And my configuration it is hideous, not like the systems showcased in reddit. I may share a screenshot when I fix some broken icons in waybar.

                      Make sense to me, sorry no.

                      It is an extra option for the people wanting to make antix boot even a little faster. The runit improvements are experimental, so not for everyone until they are stable.

                      I hope you could at least find something useful in the post, even if you cannot use it now.


                        These changes are not packaged yet, and are being tested in the experimental state they currently are in. Once more testing and fixes are found, they can be packaged and made available in the dev branch repo for antiX testing and sid.

                        Got it… I am looking forward to these runit enhancements. It is not those seconds that matter to me but rather the fact that architecture of runit implementation will be cleaner and consistent.
                        I greatly appreciate all the work you are doing for antiX…

                        Live antiX Boot Options (Previously posted by Xecure):


                          I have Hyprland set up with a nix package…

                          No worries! Were there any tricks to getting the nix package manager working on antiX?

                          I don’t balance the time saved on boot vs. the time spent learning. To me, the learning, analysis, and problem solving experience is the valuable (and fun!) part.


                            Dear @abc-nix

                            Nice piece to study, many thanks.

                            - free your mind -


                              Excellent idea to make startup faster, but I just need to use a distro other than Antix to regain the feeling of speed, not to mention Windows… now I find XP fast!

                              Years ago, Fedora developers tried to make a power-saving version, but had to stop because it lost data.

                              In Italian they say: “the best is the enemy of the good”.

                              Try to see how Ubuntu with Gnome goes, you’ll find Antix with Jwm/zzzFM a party!

                              Sorry for my spaghetti english, i'm italian.


                                I packaged the runit changes that were described in the second post. You can download them from this folder.

                                I recommend testing on a live system with persistence.

                                You can install all packages at once. First download all files, save them into an empty folder, and install from the terminal:
                                sudo apt install /path/to/folder/*.deb

                                After installing, edit /etc/default/runit-antix and make sure the LOG_FILE variable is there. If not, set it to
                                You can also enable logging with verbose output changing DEBUG and VERBOSE to 1.

                                After rebooting (and seeing it all went well), you can optionally enable the new sysvinit-compat service (you can add it using the runit-service-manager). If disabled, sysvinit scripts will not be started and your system will not run them (for those who don’t need sysvinit compatibility).

                                If after restarting the live system doesn’t boot, remove the rootfs persistence file and let me know what happened. I tested myself on a clean antiX 23 full runit live-USB, and it worked for me (first tests with a different version didn’t boot, so I hope I uploaded the newest ones).

                                If you ever decide to test it on an installed system, first:

                                1. Backup your /etc/runit-core scripts.
                                2. Backup your /etc/runit/ 1, 2 and 3 stage scripts.
                                3. Backup your /etc/inti.d/ folder

                                If you cannot boot or it acts strange starting and stopping, restore from the backups done in step 1 and 2. If you find important sysvinit scripts missing, restore them from your backup explained in 3 (only the ones you need).


                                  I packaged the runit changes that were described in the second post. You can download them from this folder.

                                  Hello @abc-nix,

                                  I tried your packaged runit changes on an installed antiX23 b3 system that I have been using a lot as my main system.
                                  Prior to your changes, start-t icewm says that my system boots up in 21.62 seconds. But the changes produced a slower boot time, in about 23.25 seconds.

                                  First thing I noticed that after installation, I could not reboot or shut down. The system was stuck at the reboot/shutdown exit session window. So I had to do a hard shutdown with the power button. Upon reboot, the system had to recover journal and clear ionode etc.

                                  This is part of the install log:

                                  $ sudo dpkg -i '/media/jakersfan/AWESOME/temp8/getty-run_2.1.2-54.1alpha1_all.deb' '/media/jakersfan/AWESOME/temp8/runit-antix_2.1.2-54.1alpha1_amd64.deb' '/media/jakersfan/AWESOME/temp8/runit-core-services-antix_0.1.8.1_all.deb' '/media/jakersfan/AWESOME/temp8/runit-full-core-services-antix_0.1.3.2_all.deb' '/media/jakersfan/AWESOME/temp8/runit-init-antix_2.1.2-54.1alpha1_all.deb' 
                                  (Reading database ... 153889 files and directories currently installed.)
                                  Preparing to unpack .../getty-run_2.1.2-54.1alpha1_all.deb ...
                                  Unpacking getty-run (2.1.2-54.1alpha1) over (2.1.2-43.0antix3) ...
                                  dpkg: warning: unable to delete old directory '/etc/sv/getty-ttyS0/supervise': Directory not empty
                                  Preparing to unpack .../runit-antix_2.1.2-54.1alpha1_amd64.deb ...
                                  runit: switching /etc/service to current... done
                                  Unpacking runit-antix (2.1.2-54.1alpha1) over (2.1.2-54.0antix2) ...
                                  dpkg: warning: downgrading runit-core-services-antix from 0.2.0 to
                                  Preparing to unpack .../runit-core-services-antix_0.1.8.1_all.deb ...
                                  Unpacking runit-core-services-antix ( over (0.2.0) ...
                                  dpkg: warning: downgrading runit-full-core-services-antix from 0.1.4 to
                                  Preparing to unpack .../runit-full-core-services-antix_0.1.3.2_all.deb ...
                                  Unpacking runit-full-core-services-antix ( over (0.1.4) ...
                                  Preparing to unpack .../runit-init-antix_2.1.2-54.1alpha1_all.deb ...
                                  Unpacking runit-init-antix (2.1.2-54.1alpha1) over (2.1.2-43.0antix3) ...
                                  Setting up getty-run (2.1.2-54.1alpha1) ...
                                  Setting up runit-antix (2.1.2-54.1alpha1) ...
                                  Installing new version of config file /etc/default/runit-antix ...
                                  Installing new version of config file /etc/runit/1 ...
                                  Installing new version of config file /etc/runit/2 ...
                                  Installing new version of config file /etc/runit/3 ...
                                  Copying sysvinit-compat service to /etc/sv
                                  Setting up runit-init-antix (2.1.2-54.1alpha1) ...
                                  Setting up runit-core-services-antix ( ...
                                  Setting up runit-full-core-services-antix ( ...
                                  Processing triggers for man-db (2.11.2-2) ...

                                  This is my test system for these runit changes:

                                  $ start-t icewm
                                  $ inxi -b
                                    Host: antix1 Kernel: 6.4.15-2-liquorix-amd64 arch: x86_64 bits: 64
                                      Desktop: IceWM v: 3.4.1 Distro: antiX-23-runit_x64 bookworm September 15
                                    Type: Desktop System: Dell product: Inspiron 530 v: N/A
                                      serial: <superuser required>
                                    Mobo: Dell model: 0G679R v: A00 serial: <superuser required> BIOS: Dell
                                      v: 1.0.18 date: 02/24/2009
                                    Info: dual core Intel Core2 Duo E7300 [MCP] speed (MHz): avg: 2667
                                      min/max: 1600/2667
                                    Device-1: Intel 82G33/G31 Express Integrated Graphics driver: i915 v: kernel
                                    Display: server: X.Org v: driver: X: loaded: intel dri: i915
                                      gpu: i915 resolution: 1600x900~60Hz
                                    API: OpenGL v: 2.1 Mesa 22.3.6 renderer: i915 (: G33)
                                    Message: No PCI device data found.
                                    Device-1: Realtek RTL8188FTV 802.11b/g/n 1T1R 2.4G WLAN Adapter type: USB
                                      driver: rtl8xxxu
                                    Local Storage: total: 262.14 GiB used: 30.49 GiB (11.6%)
                                    Processes: 120 Uptime: 0m Memory: 2.41 GiB used: 342.2 MiB (13.9%)
                                    Shell: Bash inxi: 3.3.25
                                Viewing 15 posts - 1 through 15 (of 62 total)
                                • You must be logged in to reply to this topic.