Just upgraded to UM 24.04 today from UM 22.04. Apart from the usual Ubuntu quirks when upgrading, i.e asking you to install the Firefox and Thunderbird snaps in a terminal window, where you need to tab in and press enter instead of getting a pop up window where you can press ok or cancel, no cancel option in the terminal either, but keeping the current grub config file is a pop up window (seriously, who comes up with these UX choices), the upgrade utility again crapped itself at the end and just errored out because of some ibus issue, otherwise everything else installed without any issues. I just used the fix broken packages option in the Software Boutique to fix that little issue and everything was good to go.
But I spoke too soon. I changed the swappiness value in the sysctl.conf file to 10 and that's when the system crapped itself again on the next reboot and took me to a systemd recovery terminal. I deleted that entry in the sysctl.conf file through the terminal and it booted up fine again. The real weirdness of this issue is that changing the swappiness value messed up something with the greeter splash screen as it just came up with 4 small dots instead of the usual UM splash screen. Why changing the swappiness value would mess with the display driver/greeter is beyond me
Does anyone have any idea why changing the swappiness value crashed systemd or the display driver/greeter? Is there another more "stable" way to change this value permanently in UM24.04 instead of adding an entry to the sysctl.conf file? This sysctl setting was working fine in UM 22.04 but clearly doesn't work in UM24.04. It did ask to replace the sysctl.conf file during the upgrade, which of course I cleverly did in hindsight, as if I had kept the original file, the system wouldn't have booted up at all.
Thanks for all your help guys. This issue has really piqued my curiosity and I look forward to your responses
One thing is - I'd look at /etc/sysctl.d/README.sysctl and follow its recommendations for new entries - rather than (creating entries in) /etc/sysctl.conf.
This is the recommended (or necessary?) way to manage configuration files for systemd-sysctl which, I believe, is the service used by Ubuntu MATE.
It's then unlikely your changes will disappear or interfere with future upgrades (provided you chose a sensible file name within /etc/sysctl.d/)
You should verify swappiness is being set correctly via sysctl vm.swappiness.
I upgraded my system from UM 22.04 to UM 24.04 in place. Swappiness setting was reset to default and I restored it through /etc/sysctl.conf without a problem. I.e. added extra line in the end of the file and ensured that there was line feed after the line.
$ tail -n 2 /etc/sysctl.conf
vm.swappiness=10
$
You can compose extra startup script with the following command
sysctl -w vm.swappiness=10
The problem could be to execute the script with root privileges. The task can be accomplished by configuring system-wide crontab or creating custom systemd unit.
I added vm.swappiness=10 with a line feed after the line, same as before, into the new sysctl.conf file and that was why I was shocked that it crapped out systemd. It shouldn't have.
This isn't the first time I have had weird issues with systemd. The system I upgraded yesterday was a Kodi/streaming box that I use to watch streaming sites and IPTV. I have a separate HDD for recording IPTV channels. I had that drive mount automatically at startup through fstab so I wouldn't have to mount it manually every time I boot the machine and wouldn't miss out on recording any of my shows. The drive was very old, bought it second hand, so eventually it just died, specifically the SATA connector on the drive. Now when the drive finally wouldn't initialise at startup, what did systemd do? It crapped itself again. Since the drive isn't a system or home drive, it should have just skipped over it when it wouldn't initialise instead of crapping out to a systemd recovery terminal. Went into fstab in the recovery terminal, deleted the drive entry, saved and rebooted and the system booted up normally again. That's just poor design for erroring out. You can probably gather I'm not a fan of systemd. It's another Red Hat project, so it doesn't surprise me at all. That's why I don't edit config files unless I really have to now with systemd, don't know what weird quirks or error issues might result.
To solve this issue and avoid editing a config file, I created an alias in bash called change-swappiness, with the following command:
and just run it manually at startup when I update the apt repos. You avoid problems with simple solutions, that's my philosophy.
Even though the haters like hating on snaps & flatpaks, I use them as much as possible as they really do make the Ubuntu/Linux experience so much more straightforward and easier, not having to deal with conflicting dependency/settings issues and most of the apps are designed with a gui interface in mind. I only install a deb if there's no snap or flatpak of the app. So that's my 2 cents and thank you all for your help with this issue
Yeah Steve, I added the line back with a line break into the sysctl.conf again and it failed to boot again like last time. Deleted the line again from the sysctl.conf file and rebooted and the system booted fine. Ran the startup script that Eugene suggested, it changed the swappiness value and the system has been running fine for the last 24 hours.
This is clearly a systemd quirk/bug with my system setup or hardware. Don't really like troubleshooting systemd issues as they can be finicky or just flaky/intermittent. Just easier to avoid touching systemd settings unless I really have to. In this case, with your guy's help, I don't have to. Systemd is designed to run in a perfect world and we don't live in a perfect world, far from it. So it makes sense that it craps out when it encounters anything that isn't perfect or what it expects. In my case, it could be some older hardware driver, or some bug in the open source driver of my old Radeon GPU that hasn't been discovered yet, who knows and who cares. I don't know what swappiness has to do with this, but since systemd is monolithic, it's all connected in some way or another. I'm definitely not a systemd expert by any stretch of the imagination!
Didn't check the system log on the 2nd failed boot as I just wanted to get my system back up and running again. I can do that in a few days and get back to you. Either way, that's why I'm more of a Shuttleworth/Canonical fan and definitely not a RHEL fan, as Ubuntu, generally speaking, just works. And MATE & Budgie are definitely the best DEs. LM probably has the complete package as the install/upgrade experience is much better/simpler than Ubuntu. And that's why it's installed on my wife's laptop. Troubleshooting most stuff on Ubuntu is easy, but if it involves systemd, it's usually going to be a pain, so I just avoid it, like I said before.
I'll keep you guys posted regarding system stability. Your laptop system is much newer than mine, i'm running a 4th gen Intel CPU on a mobo that I bought 2nd hand on ebay, so your hardware will definitely have less bit rot than my system, that's for sure! That could be an issue in itself, but we'll see in a few days.
I'm doing a bit of test driving of other DEs/distributions at the moment, a few things are starting to glitch out in Ubuntu MATE 25.04 (e.g. the global application menu, the indicator applet in the panel, other quirks); gotta stay sharp if MATE development isn't able to keep up with changes to gnome/GTK and other dependencies (which is not MATE devs' fault, but a pain none-the-less for the user).
That's why I like the MATE & Budgie DEs, every new version has some useful new features, unlike Gnome, which has a penchant for removing useful features. Keep up the good work!
Thanks for that info, really appreciate it. I'll keep that in mind when I find a new drive and add the new drive entry to fstab.
But again, this shouldn't be the default behaviour for non-system drives. I read through many forum posts when I added the IPTV drive entry to fstab and nobody mentioned the nofail parameter. This should be the default setting for non-system drives IMHO.
If a user modifies fstab and doesnt add the correct options, I don't see why the boot system or systemd should detect that error and correct it (and I'd argue it shouldn't).
Forums often contain poorly explained fixes for issues (including this forum) - I'm not surprised at all that they didn't cover what the changes to fstab might do or how they might fail.
I understand your logic but this is one of the things stopping more people from switching over to Linux especially disgruntled windows users. Most people, including myself, when they switched over to Linux got their solutions and fixes to common problems from various forums posts. That's they way Linux support works for the average user. If the information on those forum posts isn't correct, these people are going to keep on having problems and eventually go back to windows.
The first time I installed Ubuntu (Trusty 14.04) on my laptop, my wifi didn't work at all. I didn't know what the deal was as the wifi card worked fine in windows. I finally googled the problem, and I found a forum post that said that I needed to install the proprietary Broadcom driver to enable wifi, which I did.The Wifi card then magically starting working and I was shocked. Had I not found that forum post and solution, I would have just gone back to windows as I needed the wifi working on my laptop. So it is in the best interests of all distros to purge from their forums solutions that don't work or are outdated. The Ubuntu and Stack Exchange forums do this well with the upvote/downvote & tick feature and comments. I don't know what would be relevant to this MATE forum, but having the OP ticking a solution is definitely a step in the right direction, but not all forum posts have a solution.
Anyway, thanks again for all the useful info and have a great weekend.
BTW Could you send me the command that you would like me to run to get the error info from the systemd journal. Again, like you said, there's quite a few commands for getting this info floating around on the various forums, so I want to send you the systemd info that you actually need
