elfprince
Thank you very much, it worked. I can do a reboot again.

I can only hope that the next sync will not make any further changes to the PATH again.

    In addition to the good advice you've received, you can always re-read your .bashrc without re-booting with the command line source ~/.bashrc

    @snowee Glad you got things working, but I can't help but wonder: how did your PATH get modified in the first place? On my fully updated system, I get

    marcus@fiora ~ $ echo $PATH
/home/marcus/.local/bin:/usr/sbin:/usr/bin

    which I'm pretty sure is bog-standard. Somewhere on your system that's getting changed. Likely some script is rewriting your path variable (e.g. export PATH=/usr/bin:/bin or something similar) instead of adding to it (e.g. export PATH=/my/custom/dir/bin:$PATH). I'd bet it's the same script that's putting /usr/local/bin on your PATH; that doesn't seem to be a standard location in my experience.

    Are you running any software that you suspect may make changes to your PATH?

      infinitymdm My $PATH is much longer than yours and it hasn't been changed, or I would see it right away. Yours is very short.

          elfprince My mistake, you are correct. I forgot that I had removed snapd from this system, which would change PATH a bit. There are probably a couple of other places where it differs from a brand-new system. Out of curiosity, what does your PATH look like?

              infinitymdm
              /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/snap/bin:/home/sasha/local/bin/:/home/sasha/bin:/home/sasha/.local/bin

                infinitymdm I am very mystified too.

                Mine was a pretty bog-standard Solus Budgie which I recently installed using the v4.5 ISO a few weeks ago.

                I have ran the weekly sync about 3-5 times since then, excluding the first sync done after the ISO install.

                I didn't install much programs, except for nvidia drivers, gufw, Steam and Heroic Launcher.
                I didn't uninstall anything either.
                I didn't modify my bashrc profile, I won't dare to.

                Perhaps you could share with me what are your thoughts on what might have changed my PATH settings?

                If a recent sync changed our PATH, then why wasn't such an important thing mentioned in the patch notes?

                I have never encountered this issue before in my 5 years of using Solus Budgie.

                    snowee It looks like somehow your PATH doesn't have any system binary directories. I would expect at least /usr/sbin, if not both /sbin and /usr/sbin. Those should get added to your PATH by profile setup scripts that run any time you log in. Edit to clarify: Those directories should already be on your path, and you shouldn't have to add them with your own changes to ~/.bashrc.

                    As far as how this happened: who knows? It didn't happen on my machine; I still have all those system binaries available because /usr/sbin is in my PATH. I suspect there is some offending piece of software that you have installed which I do not. The most likely explanation I can think of is that someone in the software supply chain made a mistake that got propagated to our packages, and thus to your system.

                    Now, there is a bit more troubleshooting we can do:

                    • Could you post the output of eopkg hs -l1? That will give a list of the packages upgraded on your system in the previous sync, and could help identify a package which has a mistake.
                    • Could you post the output of eopkg lr? If you happen to be on the unstable repo, that could explain some things. I don't think you are, but it never hurts to check.

                        infinitymdm

                        1. "Those should get added to your PATH by profile setup scripts that run any time you log in"
                          You mean, each time a user logs into Solus Budgie, scripts will automatically run in the background?

                        2. "As far as how this happened: who knows? It didn't happen on my machine"
                          May I check if you are on Solus Budgie also?
                          Mine was a fresh install using the v4.5 ISO Solus Budgie
                          I remember very clearly I was still able to do a reboot after my sync for Week 24 (our last sync was Week 25)

                        3. "I suspect there is some offending piece of software that you have installed which I do not"
                          As mentioned in my previous post, installed very minimal additional software, mostly pertaining to Nvidia drivers, gufw, Steam and Heroic.

                        4. "The most likely explanation I can think of is that someone in the software supply chain made a mistake that got propagated to our packages, and thus to your system."
                          Could you please inform the devs involved and alert them to this issue?
                          So that they can investigate further and reverse the changes, if necessary.

                        5. Could you post the output of eopkg hs -l1 ?

                        Operation #19: upgrade
                        Date: 2024-06-22 16:21

                        * openssl is upgraded from 3.2.2-50-1-x86_64 to 3.3.1-51-1-x86_64.
* cryptsetup is upgraded from 2.7.2-19-1-x86_64 to 2.7.3-20-1-x86_64.
* pcre2 is upgraded from 10.42-14-1-x86_64 to 10.44-15-1-x86_64.
* libxml2 is upgraded from 2.12.7-48-1-x86_64 to 2.12.8-49-1-x86_64.
* libfido2 is upgraded from 1.14.0-7-1-x86_64 to 1.15.0-8-1-x86_64.
* nghttp3 1.4.0-1-1-x86_64 is installed.
* curl is upgraded from 8.8.0-90-1-x86_64 to 8.8.0-91-1-x86_64.
* btrfs-progs-libbtrfs is upgraded from 6.8.1-63-1-x86_64 to 6.9-64-1-x86_64.
* clr-boot-manager is upgraded from 3.3.0-34-1-x86_64 to 3.4.0-35-1-x86_64.
* pcre2-32bit is upgraded from 10.42-14-1-x86_64 to 10.44-15-1-x86_64.
* libwebp is upgraded from 1.3.2-26-1-x86_64 to 1.4.0-27-1-x86_64.
* firefox is upgraded from 127.0-318-1-x86_64 to 127.0.1-320-1-x86_64.
* python3-pyudev is upgraded from 0.24.1-12-1-x86_64 to 0.24.3-13-1-x86_64.
* tcp_wrappers is upgraded from 7.6-3-1-x86_64 to 7.6-4-1-x86_64.
* qemu-guest-agent is upgraded from 9.0.1-68-1-x86_64 to 9.0.1-69-1-x86_64.
* serd is upgraded from 0.30.4-4-1-x86_64 to 0.32.2-5-1-x86_64.
* zix 0.4.2-1-1-x86_64 is installed.
* sord is upgraded from 0.16.4-4-1-x86_64 to 0.16.16-5-1-x86_64.
* sratom is upgraded from 0.6.4-4-1-x86_64 to 0.6.16-5-1-x86_64.
* wireplumber is upgraded from 0.5.3-29-1-x86_64 to 0.5.3-30-1-x86_64.
* tcp_wrappers-32bit is upgraded from 7.6-3-1-x86_64 to 7.6-4-1-x86_64.
* solus-hardware-config is upgraded from 16-31-1-x86_64 to 16-32-1-x86_64.
* exfatprogs is upgraded from 1.2.3-8-1-x86_64 to 1.2.4-9-1-x86_64.
* libwebp-32bit is upgraded from 1.3.2-26-1-x86_64 to 1.4.0-27-1-x86_64.
* curl-gnutls-32bit is upgraded from 8.8.0-90-1-x86_64 to 8.8.0-91-1-x86_64.
* btrfs-progs is upgraded from 6.8.1-63-1-x86_64 to 6.9-64-1-x86_64.
* solus-artwork is upgraded from 30.0-50-1-x86_64 to 30.0-51-1-x86_64.
* switcheroo-control is upgraded from 2.6-2-1-x86_64 to 2.6-3-1-x86_64.
* appstream-data is upgraded from 40-42-1-x86_64 to 41-43-1-x86_64.
* libdc1394 is upgraded from 2.2.6-3-1-x86_64 to 2.2.7-4-1-x86_64.
* gstreamer-1.0-plugins-bad is upgraded from 1.24.4-104-1-x86_64 to 1.24.4-105-1-x86_64.
* openssl-32bit is upgraded from 3.2.2-50-1-x86_64 to 3.3.1-51-1-x86_64.
* curl-32bit is upgraded from 8.8.0-90-1-x86_64 to 8.8.0-91-1-x86_64.
* libdatrie is upgraded from 0.2.12-1-1-x86_64 to 0.2.13-2-1-x86_64.
* inxi is upgraded from 3.3.34-53-1-x86_64 to 3.3.35-54-1-x86_64.
* libxml2-32bit is upgraded from 2.12.7-48-1-x86_64 to 2.12.8-49-1-x86_64.
* openjpeg is upgraded from 2.5.0-20-1-x86_64 to 2.5.2-21-1-x86_64.
* python3 is upgraded from 3.11.9-63-1-x86_64 to 3.11.9-64-1-x86_64.
* luajit is upgraded from 2.1.1713773202-8-1-x86_64 to 2.1.1716656478-9-1-x86_64.
* sg3_utils is upgraded from 1.46-5-1-x86_64 to 1.48-6-1-x86_64.
* libgpod is upgraded from 0.8.3-5-1-x86_64 to 0.8.3-6-1-x86_64.
* python3-cairo is upgraded from 1.24.0-16-1-x86_64 to 1.26.0-17-1-x86_64.
* libthai is upgraded from 0.1.28-1-1-x86_64 to 0.1.29-2-1-x86_64.
                        1. Could you post the output of eopkg lr ?

                        Solus [active]
                        https://cdn.getsol.us/repo/shannon/eopkg-index.xml.xz

                            snowee

                            1. Yes, more or less. Any time you log in, there is a sequence of scripts run that set up all the right environment variables. These scripts come from a variety of sources: mostly essential system packages, but often other packages need to add environment variables. It's a pretty common thing; so common, in fact, that there's a set of dedicated directories for it. See this excellent answer on askubuntu for more info.

                            2. I am running Solus Budgie also, set up using the 4.5 install ISO. My system is fully updated and on the Stable package repo. I can still run reboot as of today (06/27).

                            3. We'll take a look at this in #5.

                            4. The Solus devs pay pretty close attention to these forums; in fact, you've already had at least one reply in this thread. I wouldn't be too surprised if they're also trying to identify the cause of this issue. That, of course, is the real challenge here: figuring out how and why all sbin directories got dropped from your PATH. At this point we know very little about the actual root cause - we just know there's a problem, and we've applied a band-aid by adding a line to your .bashrc file.

                            5. Thanks for posting this. I'll take a look at my own system and try to ID packages that you have which I don't - that will give us a starting point to (hopefully) figure out what went wrong.

                            6. You're on the Stable repo. Awesome.

                            I'm not at my Stable box right now, but I will be tomorrow. I'll compare packages and see if I can identify a root cause for you. Thanks for your patience with this so far.

                              The reason /usr/sbin/ was removed from PATH was because it should not be in the PATH for users. Things that do not need sudo privileges probably should not not be shipped in /usr/sbin/

                              It was not clear this PATH change was intentional and "fixed it" by adding /usr/sbin back and cherry-picked it to stable.

                              This may be reverted back to not having /usr/sbin in PATH but for now it remains.

                                Harvey

                                1. "The reason /usr/sbin/ was removed from PATH was because it should not be in the PATH for users."
                                  "It was not clear this PATH change was intentional."
                                  So may I confirm that it was indeed an intentional change for PATH? That was one of the original intent for Week 24 sync?
                                  If so, then I'm ... relieved.
                                1. "Things that do not need sudo privileges probably should not not be shipped in /usr/sbin/"
                                  Philosophically speaking, and also from a security standpoint, should 'instant-apply' commands such as reboot and shutdown be gated behind a sudo? ... Or should the user have a choice?
                                  I defer to the more experienced linux users.
                                1. If it's an intentional change for PATH, then why was infinitymdm's Solus not affected by the PATH changes?
                                  After all, both of us are using the same Solus Budgie, and we cannot pick and choose our packages to sync each week.

                                  1. Yes it was intentional. I did not realise this was the case and reverted it at which point it was explained to me.

                                  2. If shutting down / rebooting from the system menu does not require elevated privileges I do not see why the CLI should have any such restriction.

                                  3. They may have checked their PATH after I "fixed it" / not rebooted since the change was made to PATH, etc.

                                    Harvey
                                    I refer to WetGeek's comment for his Week 26 sync.

                                    Given that he encountered a Apparmor PATH error after syncing Week 26, and that he previously had the same issue as me of being unable to do a reboot after Week 25 sync, kindly advise if I need to modify my bash.rc file before i do my Week 26 sync?

                                    Myecho $PATHas follows, this is after I followed elfprince's advice above
                                    /usr/sbin:/usr/local/bin:/usr/bin:/bin:/snap/bin

                                      No you do not need to do anything. If wetgeek had not updated and rebooted those systems for my "fix" that added /usr/sbin/ back to PATH before updating then for the post-install script it wouldn't have apparmor_parser in PATH.

                                      You do not need elfprince's change to PATH because #1 /sbin shouldn't be in PATH (and looking at your PATH it is not) and #2 /usr/sbin/ was added back to PATH by my "fix" to bash which was cherry-picked to stable 5 days ago which to my knowledge you have already updated and rebooted for so that is why /usr/sbin is in PATH.

                                      After this sync it is also now defined in systemd https://github.com/getsolus/packages/blob/main/packages/s/systemd/package.yml#L138 so it is in PATH regardless of which shell you use.

                                      To cap it all off I tested it in a fresh VM and it had no errors after updating and even if it wasn't and the post-install script broke for apparmor like in wetgeeks error, your system would still boot fine.

                                        Harvey $ which reboot
                                        /sbin/reboot
                                        Why is it not in /usr/sbin ? If I remove /sbin from my $PATH, then the command reboot will not work from the command line, right?

                                            elfprince
                                            You did this:
                                            export PATH=/sbin:$PATH

                                            So you forced /sbin to be added to PATH which it should not be and it is added before the PATH the OS sets. Which means you made /sbin/reboot the priority, it never gets to /usr/sbin/reboot

                                                Harvey Thanks for pointing that out. Indeed, it is so.

                                                Is it wrong or harmful to have /sbin in my PATH?

                                                EDIT: $ ll /sbin
                                                lrwxrwxrwx 1 root root 8 May 14 09:37 /sbin -> usr/sbin/
                                                I see now, that I can remove it. 😃

                                                  6 days later

                                                  The 'reboot' command had stopped working on my Solus Budgie system too some weeks ago, so I had started using 'sudo reboot'. But now I find that 'reboot' is working again.