I have an old PC in my garage that I only use when I’m out there working. I may only need to google something or stream some music. So it doesn’t get updated all that much. It could go 6 months.
So yesterday I turned it on and did an update, which seemed to go fine. I rebooted and the first thing I tried from the terminal needed sudo .
I got some message about this user didn’t have sudo privileges. There is only one user.
I knew this was going to require a lot of work to fix, so I just blew it away and reinstalled a fresh OS.
As much as I love EOS, issues like this are why I can’t use it on what I consider mission critical PCs like my wife’s PC or laptop.
Probably just read the update log. Although updates shouldn’t mess with sudo like this, unless the sudoers file changes its format. In the end you probably just could have entered su, log in with the root password and edit the sudoers file or add the wheel group back to the the user which isn’t working anymore. In the future better ask for help, because this seems like a really small problem that can be fixed pretty fast.
Now we will never know what the problem was and therefor can’t answer how to avoid these things. Could simply be a fault on your end.
Not sure if I tried su without sudo and as you noted, we will never know. I didn’t think EOS has a root account with a password? I know some people want root to have it’s own password so they can recover from situations like this.
Usually, on my EOS systems I have BTRFS, grub-btrfs, and snapper so I can boot to a older snapshot and recover. On this particular system, it’s not important enough to go through the hassle.
It just bothers me on the OS I like to fool with the most, updates can cause these problems.
My wife’s PC and laptop are running Linux Mint 21.2 with Timeshift and grub-btrfs. I don’t think I’ve every had as reason to restore from a snapshot there. She screws up enough stuff just with browsers and password managers, so god forbid that was an EOS system
It does unless you manually removed it. By default it uses the same password.
I know it is too late now but it probably would have been a very simple fix.
Honestly, I can’t see how an update could cause the issue you are describing. sudo access is controlled by three things. Your user, your group and the sudo config. None of those things should be changed during an update.
Did you merge pacnew files after the update or something similar?
I don’t guess I did since I have no idea what merging pacnew files is.
But what I do know is I had a bear of a time trying to reinstall an OS on this Old PC circa 2012 Intel Core i7. EOS failed, then Linux Mint Debian edition failed to install grub properly, then I got LM21.2 installed.
So I went experimenting. I think my PC is too old to have UEFI done right. When I install Debian 12 on this machine I have to force grub to be installed a certain way that you don’t have to do on new machines. It’s an option on their expert install.
So I cleared CMOS, put in a new battery. Reset BIOS defaults which include UEFI boot enabled.
I then tried to install using the Endeavouros_Cassini_Nova-03-2023_R2 ISO but that failed with some error that popped up. I then tried Endeavouros_Cassini_Nova-03-2023_R3 IOS and that installed correctly. Both installs were Online/ Plasma KDE with no swap and using BTRFS.
I’ll keep an eye on it for a while and see if anything strange occurs.
You could gain root access through the extended bootloader options and create an new root password via “passwd” command, afterwards or in the same session you could add your “non root user” to the wheel group again.
After gaining root access: gpasswd -a <yourusername> wheel
Forgot. If this doesn’t help you could check if the “wheel” group is granted root access through sudo in the “/etc/sudoers” file. Perhaps this file got changed by the update.