Getta91 I've been in the middle of a sizable Haskell upgrade all week, so kernels haven't been on my mind. With everything else being upgraded this sync cycle I also didn't want to introduce even more churn. Based on the feedback I have received, I would like to upgrade to 4.14 for awhile while 5.4 stabilizes or the next LTS is announced, from there I will decide whether or not to upgrade to 5.4 or the latest LTS. We will skip 4.19 entirely.

      13 days later
      7 days later

      I just got a tuf a15 that runs a 4800h and 2060 and Solus 4.1 won't boot (some ppm issue). The only OS that work on it are Fedora and OpenSUSE, so I am using fedora for now. But, I really want to get solus running on it. Solus saves me so much time because I can access my network folders from every piece of software because the Solus mounting utility is so easy and powerful. The OS is just a breeze. Can someone let me know if i would be able to put the iso on a USB with Balena, and the update it is live to try and get a newer kernel durring install. I think with the 4800H you need at least 5.6.3. I really can't wait until that is available with Solus OS.

      PS Solus is running great on my thinkpad T450, and two T5500 with dual xeons, which is impressive range of hardware. Kudos to the people that made this!!! No more copying and pasting back and forth from network, or mounting to fstab in terminal <3

        holski What you could try is install Solus in another Laptop or PC, update the system and then just swap the m.2 to your A15. Otherwise we have to wait until we get a new ISO 🙂

          13 days later

          I just updated mine Linux Kernel and after reboot i get screen saying something bad happend with logout button.I am using solus budgie 4.1.
          How can i switch to LTS version of Kernel
          AMD® A4-3330mx apu with radeon(tm) hd graphics × 2 with 1.5 GB RAM.

            Vibhi this thread isn't intended for such support questions, you should have searched for existing problems like yours or opened a new thread if your question isn't answered anywhere already.

            But since we're already here... Check out the articles on this page: https://getsol.us/articles/troubleshooting/
            Probably most fitting to your question: https://getsol.us/articles/troubleshooting/boot-management/en/#bring-up-the-boot-menu-with-no-timeout-set

              There are 8 (eight) Solus installations here. They are independent one from another. Each DE is installed in its own, separate, independent partition.

              4 DEs run on 5.6.19-158.current kernel. They are installed in sda6, 7, 8, 9 partitions. From time to time each DE crashes on boot up. It's a pain.

              4 other DEs run on 4.14.189-161.lts kernel. They are installed in sda10, 11, 12, 13 partitions. None crashes on boot up. No problems. Never.

              The laptop has 2 (two) MBR (msdos)-partitioned internal hard disks. Each disk has 16 usable partitions. Paritions are labeled as:

              • sda1, sda2,.. sda16 on the 1st disk
              • sdb1, sdb2,.. sdb16 on the 2nd sisk

              Seems like 5.6.19-158.current kernel can't distinguish well between two internal disks. From time to time it mixes sda... with sdb... partitions on boot up and in file managers. It's an early impression. Didn't investigate deeper yet.

              Nothing similar happens in 4 other DEs, running on 4.14.189-161.lts kernel. They never crash on boot up. Never mix sda... with sdb... paritions in file managers. Solus DEs with LTS kernel seem to be rock-solid.

              Conclusion.

              • Solus Plasma, Gnome, Mate, (...) with 5.6.19-158.current kernel are not reliable

              • Solus Plasma, Gnome, Mate, (...) with 4.14.189-161.lts kernel are more reliable

              Thanks for reading

              Edit: Typo.

              6 days later
              19 days later

              just 2c from the peanut gallery: my girlfriend's 2019 Dell XPS 13 runs like butter on current but gets the black screen and cursor (no boot) with LTS. My personal (unsolicited) opinion is that 5.4 would likely be a good option at this point, but that said, i don't think 4.19 would be a bad option.

              been using solus since it was evolve, and it has eclipsed all the other distros to become my daily driver and the distro i put on all my friends machines when they want to try linux. THANK YOU for your work.

              11 days later

              HP EliteBook 2740p
              Solus 4.1 - Budgie
              linux-current: Failure upon suspend/resume
              linux-lts: Suspend/resume work properly

              I am thankful you maintain both current and LTS, as my wont is to go current/bleeding-edge unless something breaks (hello, suspend/resume),, in which case, lts/stable is a wonderful thing to have.

              Like you stated. 4.19 seems like a half-measure with likely nearly as much work as going to a 5.x LTS... I'd say maybe going all the way to 5.x LTS will buy you more time to patch/push fixes upstream against a kernel that should in theory, support more hardware than the 4.19 branch... We hope.

              I know this platform is ancient, but it is performant enough, and I can't get over the form-factor and repariability.

              (Just discovered Solus after distro-hopping for over a week, seeking a distro where I have easy access to the geospatial tools I need, and they're actually UP TO DATE!!!

              Solus is wonderful, and has taken the place of Lubuntu for me, which is something since I've been using that since 10.04)

                12 days later

                Just my 2 cents or Euro equivalent...Debian Stable offers newer kernels via the Backports repo for those instances where the stable kernel (Solus LTS equivalent) doesn't work well. I'm wondering why users with newer hardware would want to use an LTS kernel.

                Edit -- Just checked the Debian Testing repos and as of now, the kernel version that would be used in the next stable release would be 5.8.10.x, so maybe it might be a good idea to update the LTS kernel.

                I have installed the LTS Kernel and the Current Kernel with zero problems. Including every component package available via Eopkg. All of you have in my opinion made one of the best Linux Distributions available to date. Second to none. Equally as flawless (infer superior to Clear Linux) as the Clear Linux Project from which I very recently migrated even whilst being far more functional versus the more spartan nature of the aforementioned operating system. Congratulations and my thanks to the Core Team accordingly.

                a month later

                sothis6881 first we need to get 5.7/5.8 to current rolling so we can even think about 5.10 LTS 😉

                Hope that bugs with 5.7/5.8 will be fixed soon, so many new hardware is released and I'm preordering Ryzen 5900X and RX6900XT, hope Solus team will manage to solve those issues to the end of year. Don't wanna use Manjaro or Fedora as Solus is just a sweet spot for my like.

                  i'm not developer or maintainer and i don't have expert opinion, but i think the problem with NVMe the problem is with linux firmware and linux current kernel. Once again i'm not an expert, just thoughts on the go

                  Hey everyone,

                  Just an update. Today I spent some time trimming down our config to the bare essentials for my machine specifically, to minimize build times as I looked into this issue. With the latest release of 5.10.0-rc1, I opted to test against this, not bothering to immediately rebase our patches in the event it didn't resolve my NVMe namespaces to begin with.

                  Fortunately, I have some good news. I can confirm that this build of the kernel resolved our NVMe namespaces. After this, I passed it off to @DataDrake and @Girtablulu, which both have similar or identical (depending on the person) Samsung controllers for their NVMe drives as I do, and they both validated that their namespaces were also being resolved and they were able to boot into the desktop! @DataDrake 's logging documentation was also invaluable to validating that it was actually fixed and my initial issues were elsewhere (failing to reach the login screen made me suspicious initially), so massive thanks to him. I would've wasted countless hours otherwise ❤️

                  From this point, I went and rebased our kernel patches (such as for apparmor confinement, ELANtech touchpad support, etc.) then copied and updated our 5.6 kernel config for 5.10. I've listed some of the features / flags I've enabled below:

                  • ZSTD Compression. Changed from lz4 to zstd for default.
                  • Enabled
                    • ACPI_DPTF: Intel DPTF (Dynamic Platform and Thermal Framework) Support
                    • APPLE_MFI_FASTCHARGE: Fast charge control for iOS devices
                    • BRIDGE_MRP: Enables ethernet bridges to run MRP protocol to detect loops
                    • DM_MULTIPATH_HST: I/O Path Selector based on historical service time
                    • DPTF_PCH_FIVR: Dynamic Platform and Thermal Framework (DPTF) PCH FIVR Participant device support
                    • DRM_AMD_DC_DCN3_0: AMD sienna_cichlid DCN 3.0 family support
                    • INTEL_SOC_PMIC_BXTWC: Support for Intel Broxton Whiskey Cove PMIC
                    • MFD_INTEL_PMC_BXT: Intel PMC Driver for Broxton and Apollo Lake
                    • MMC_HSQ: Selects the MMC Host Software Queue support. This may increase performance, if the host controller and its driver supports it.
                    • MT7663U: MediaTek MT7663U (USB) support
                    • NVME_TARGET_PASSTHRU: NVMe Target Passthrough support
                    • PINCTRL_EMMITSBURG: Intel Emmitsburg pinctrl and GPIO driver
                    • PINCTRL_JASPERLAKE: Intel Jasper Lake PCH pinctrl and GPIO driver
                    • RMI4_F3A: RMI4 Function 3A (GPIO)
                    • RTW88_8723DE: Realtek 8723DE PCI wireless network adapter
                    • RTW88_8821CE: Realtek 8821CE PCI wireless network adapter
                    • SENSORS_AMD_ENERGY: AMD RAPL MSR based Energy driver
                    • SND_HDA_INTEL_HDMI_SILENT_STREAM: Intel hardware has a feature called 'silent stream', that keeps external HDMI receiver's analog circuitry powered on avoiding 2-3 sec silence during playback start. This mechanism relies on setting channel_id as 0xf, sending info packet and preventing codec D3 entry (increasing platform static power consumption when HDMI receiver is plugged-in). 2-3 sec silence at the playback start is expected whenever there is format change.
                    • SND_SOC_AMD_RENOIR: AMD Audio Coprocessor - Renoir support
                    • SND_SOC_AMD_RV_RT5682_MACH: AMD RV support for RT5682
                    • SND_SOC_INTEL_CATPT: Intel Haswell and Broadcom support with I2S codec present.
                    • SND_SOC_INTEL_SOF_PCM512x_MACH: Adds support for ASoC machine driver for SOF platforms with TI PCM512x I2S audio codec.
                    • SPI_AMD: Enables SPI controller driver for AMD SoC.
                    • SPI_MUX: Adds support for SPI multiplexers. Each SPI mux will be accessible as a SPI controller, the devices behind the mux will appear to be chip selects on this controller. It is still necessary to select one or more specific mux-controller drivers.
                    • SURFACE_3_POWER_OPREGION: Support for ACPI operation region of the Surface 3 battery platform driver
                    • USB_LGM_PHY: Support Intel DWC3 PHY USB phy

                  Alongside all of this, I grabbed a patch that enables the building of nvidia-glx-driver against 5.10. In all likelihood this can be applied to the other drivers (390, beta, and developer). I've validated that graphics work, as you can see from the screenshot below, and that snaps work as well (in other words, I didn't break the AppArmor confinement, which is always a plus).

                  Given all of this, it does indeed appear that 5.10 will be the kernel that current will see an update to. That being said, 5.10 isn't scheduled for release until late December, so @DataDrake and I need to determine whether or not we're going to defer Solus 4.2 until then or ship with an RC, given it doesn't appear 5.9 has gotten all the NVMe changes. Obviously we recognize that Solus 4.2 is much needed (we want to release it too!), especially given I'll be starting the GNOME 3.38 upgrade locally next week and Budgie 10.5.2 will be officially released when GNOME 3.38 lands in our stable repo. At that point there won't be any blockers besides the kernel for tagging.

                  big updates hype !