I recently bought my wife a new ACER laptop and installed Solus 4.3 Budgie on it. It turned into a real ordeal because the .ISO file was so outdated. Solus didn't have drivers that would access the Wi-Fi in the new computer, so I needed to order a TPLink dongle from Amazon and pay extra for overnight delivery. I didn't want to waste more than one day because of this.

The dongle at least gave me 2.4 MHz access to the Internet, and I was able to update Solus. That update upgraded 435 packages, among them a driver for the Intel Wi-Fi radio in the new computer. It now provides 5 MHz access to our internal network and the Internet.

The reason I'm pointing this out is because anyone who downloads our current .ISO files and tries to install Solus on a fairly new computer is going to run into the same problems I did. And that's not going to help popularize Solus at all. The .ISO files are obsolete.

I've been here long enough to know better than to ask for an ETA, but if we're nowhere near a product upgrade, could we please at least release some newer .ISO files? If we are near a product upgrade, I'll just sit down and shut up. Which is it?

    henkesteen Didn't that work out of the box?

    Thanks. It probably would have. I thought of that too ... after the fact.

    DataDrake Got just a few things to sort before an new ISO. Don't worry. It's coming.

    This could well be a naiive question, Bea, because I haven't been involved in distributing Solus (other than giving lots of "Live" USB sticks to friends and family). However I know from decades of software development that many such processes are either fully- or partially-automated.

    If the creation of the .ISO files isn't already automated by scripts or makefiles, is it possible that they could be?

    It would seem like the best way to pull Solus out of relative obscurity among better-known distros is to make it a top priority to provide potential new users with the most up-to-date installers possible, not ones that requre 435 package upgrades to become fully functional. Ideally, it could be part of the sync process, but if that's not possible, maybe at least a monthly update?

      My opinion for what it's worth: 6 to 8 months is way too long for a new ISO file. When I got my Ryzen 5 laptop I couldn't install Solus for months. Add my vote for a monthly or bimonthly update.

      WetGeek I think the issue isn't whether the process is automated or not, but rather that the team waits for relatively stable and LTS versions of the kernel and main drivers to ship a new ISO. They don't want to ship an ISO with an intermediate kernel release that'll already be EOL when you install it (even if you upgrade it right after install).

      At least that's what I gathered from the times we heard about why ISO refresh were held back for a long time. And it seems to still be the case here according to @Harvey's message.

      DataDrake

      I wasn't aware that every installer needed to install an LTS version. openSUSE gets around that by distributing both Leap (LTS) and Tumbleweed (rolling) releases. Maybe we could do something like that?

      In other words, just leave the LTS .ISOs on the web page until the next LTS is available, but give new users installers that will provide them with up-to-date functional versions of Solus in the meantime. I'm concerned that the potential new users whose attempts to install and use Solus probably just move on to trying the next distro instead.

      It is not about LTS.

      Building the ISO is easy. It is the testing of the ISO consumes a lot of time and in testing you might find an issue which you then need to fix and re-test. When I last helped test pre-release ISOs with Josh we were testing each edition in 4 different install scenarios. So that is 16 fresh installs. Find a bug in any one of those and after you fix it, you may need to restart testing on all editions.

      Then of course there is the blog post that comes with every new official release, someone needs to write that, get input from other team members and proof read.

      Then there is the newer ISOs provided to people contributing to certain tiers through the OpenCollective inbetween official releases. I do not know if as much testing is done on those, I suspect not. But I would assume with Solus in the middle of restructuring there would be disruption to these being pushed out too.

      I already pointed out we would need to move off the EOL 5.14 kernel before getting a new release (OpenCollective ISOs would not have this sort of restriction).

      You also have to have time post-release to answer questions from users who are reinstalling for no reason or the new influx of users that happens every release who see the new ISO and decided to give it a try. Potentially having to fix issues that were missed in testing. There is also setting up of torrent seeds etc etc etc.

      A single week easily sees way more than 500 packages updated, so I personally do not think this part is a significant concern. It is the new hardware enablement provided by the newer kernel in the updated ISO that is the important part. An switching kernel branches does not happen often enough for monthly to make sense.

      • 5.14.0 was released 29th August 2021
      • 5.15.0 was released on 31 October 2021
      • I think 5.16.0 was released 10th January 2022

      An we very rarely jump on new kernel branches straight away due to issues. Quarterly makes more sense to me.

        Harvey Harvey, thanks to laying it out so clearly.

        I don't have any experience in distro builds, but I've managed software rollouts/updates in an enterprise environment. You have to build, test, rebuild, test, rebuild and test again in scenario after scenario. The process itself consumes a lot of resources and comes at the expense of development, but the highest resource burn comes during and immediately after rollout, when support needs skyrocket for a while,

        Solus resources are limited, and you and others on the team will need to figure out the right balance between ISO updates, maintenance and development. I don't know what the right balance is, given the team's resources.

        I think that twice a year (the pace at which most distros issue new releases) ISO rollouts is fine, but if the team has the resources to update the ISO quarterly, that would be fine, too if that is what the team wants to do. However, I think that the team might want to do a careful cost/benefit (including team burnout) before adopting a quarterly schedule. I also wonder whether it might make sense to change the weekly maintenance update schedule to every other week to put less strain on resources.

        16 days later

        #TeamSolus - I know this is not at the forefront of the issues these days. I simply want to share the love and give a working ISO to a friend. How is the kernel update/mitigation coming along?

          jppelt I just did a fresh install with the 4.3 ISO without too much issue under older hardware (~ 2019). The ISO might work, indeed, and with a working Internet connection, the ~ 900 MB updates should fix issues AFAIK. What issues are you having with the ISO not working?

          [unknown] Even without Nvidia support during the installation, Solus does offer DoFlicky on the ISO which will grab the correct proprietary drivers for you.

          I know this isn't a user-friendly method but, if you can't boot into your installation of Solus, you could always drop to TTY and install the driver from there (if you're still struggling getting the system up and running).

            Bhibb it’s a new AMD GPU and all I get is a blank screen. The ISO works fine on any older hardware but with the RX6500 is does not work.

              kaktuspalme Thanks! I tried it and it does not work for this desktop. I’m patient. Good things come to those who wait….right? 🤣

              [unknown]

              You gotta make it to TTY with CTRL + ALT + F3 to F6 I think?
              Then you gotta login to the live USB with just typing "live" for the user and hit enter. Need to install nvidia-glx-current and then:

              systemctl stop gdm.service

              systemctl restart gdm.service

              I think that did it or a startx after that, and I gonna be able to see the GUI. That did it for me, I have a 5600X and 3070.