You are not logged in.
My experience is, so far, that adding the set_path option in /etc/default/su outlined above works and su reverts to it's normal, expected behaviour. So, I can obtain root with a simple su, no extra dash required, and I stay in the current dir too!
Well, for the 2nd time tonight Beowulf crashed. I was browsing while playing 2 local video files (via smplayer and vlc respectively) and it froze solid. No input, audio looped continuously, no response at all. Only a hard reset could solve the issue. This was on the Xen-enabled kernel. On ASCII, this scenario was perfectly fine and it could do this literally all day and never miss a beat. Now running the non-Xen kernel, see if that changes anything.
So far, Beowulf impresses me badly for all the wrong reasons
Is not Sabayon dead (not being updated)? Though their google group indicates some activity.
Not anymore, if ever:
https://forums.funtoo.org/topic/4882-fu … ng-forces/
Daniel Robbins is/was the main architect of Gentoo, so expect some improvements to Sabayon when it comes to init systems.
Yeah, I did that too now. Didn't solve all issues, I still can't load a module required for Qemu. As root:
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# modprobe kvm-amd
modprobe: ERROR: could not insert 'kvm_amd': Operation not supported
# modprobe kvm_amd
modprobe: ERROR: could not insert 'kvm_amd': Operation not supported
# modprobe -c | grep kvm_amd
alias cpu:type:x86,ven*fam*mod*:feature:*00C2* kvm_amd
So, what next?
su got moved from shadow to util-linux. I don't know what thought went into the change in root's path when you get there via 'su'. If you use 'su -' it still works the same as it used to. It's in the release notes for beowulf along with some other inherited gems and workarounds. https://files.devuan.org/devuan_beowulf … _notes.txt
OK, fair enough. I don't use su -, I created an alias for su to invoke su - in ~/.bash_aliases. It works, but clearly not for everything.
Im not 100% certain but i believe this might be due to the UsrMerge scheme adopted by debian. I always choose not to merge during installation.
Regrettably, that wasn't an option during my upgrade.
In that case, during the upgrade this new directory should have been added to $PATH for root, but clearly it hasn't on my system. Or it was removed by the upgrade, that I can't be sure of as I didn't test it before upgrading.
[edit] Found the culprit, in /etc/profile:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH
So, if the user uses su into root from your normal user, the id does not equate to 0 thus /sbin is not in your $PATH
PS: which "bright spark" had the "luminous" idea to set terminal text as bright yellow on a bright white background? You should be clobbered into sense with a foam bat!
ASCII -> Beowulf upgrade
boot option: Qemu/Xen enabled
# whoami
root
# uname -a
Linux desktop 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
# echo $PATH:
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
# modprobe -c
bash: modprobe: command not found
# halt
bash: halt: command not found
WTF! >:-{
I have /boot, / and /home on separate partitions, most of the time, for simplicity/speed/convenience. For servers, /usr and /var are also separate.
So, what a difference a few days make. It turns out the problem was of my own making, typical PEBKAC! I'd forgotten to update the BIOS and the old version didn't support he 'new' APU. (insert facepalm smiley)
I know it's a pretty old thread, but I was finally sufficiently hacked off to attempt a workaround.
Create a file ~/.bash_aliases containing the following:
alias su='su -'
You'd need the single quotes as to evaluate every time the alias is used. It worked on a fresh Beowulf test install.
If it has no negative effects I may actually start consider upgrading my ASCII systems to Beowulf.
I hadn't installed the amd64-microcode package. So that's done now.
Meanwhile, I had another crash, while avoiding playing video files. During several failed boots the kernel hung on a message complaining about ECC memory signatures not present (it's non-ECC DDR3). I've now taken out 3 RAM sticks so now running on 1x 8CB. Playing mkv video finished fine, am mp4 crashed after a while (ca 4 min in). I've also removed the nVidia GPU, so now on the R7 APU.
Stress looks interesting, I'll install it and see what it can do.
Upgrade to Beowulf is a no-go, as it doesn't do how I like doing things, particularly regarding su. Current kernel is 4.9.0-15 so well after the release of this hardware. I've tried getting Funtoo running on it, but ran into an issue with some Grub dependencies which failed compiling. I may have another go (it has a 5 series kernel).
Recently the desktop started freezing randomly after a CPU upgrade. Prior to that I was able to play 2 video streams concurrently (using different media players) but now playing even one video stream crashes the desktop, freezing it completely. Keyboard and mouse no longer respond, a hard reset is the only way to regain control. But after a few such events the OS borks itself and a fresh install is required (and time consuming, as well as getting old now
A short-ish mkv file played fine, a longer mp4 video crashed the system. There are no logs, due to the hard reset, so no trace options available.
Apart from the CPU, the rest of the system hasn't changed. The old CPU was an AMD A8-5600K, the new one is the A10-PRO-8750B, both APU's. I've tried the R7 GPU as well as the nVidia GT710 card, both are supported in the respective drivers. Made no difference, so currently the GT710 card is in use. Other key components are: 4x8GB DDR3-1333 RAM, Samsung EVO850 120GB SSD. mainboard: Gigabyte F2A88X-D3H.
For the moment, not playing video, the system seems stable, but I'd like to give this a thorough stress-test so if the new APU is faulty I can reclaim the expense from the seller. Is there a way to do that?
TIA!
Did you install the build-essential package? This creates a full build environment by pulling in all essential packages. (by itself it installs nothing, but uses the dependency resolution from apt to get what it needs installed)
Devuan doesn't use ppa's, it's an Ubuntu thing. Devuan is not based on Ubuntu (and never will be) so you'd need to add the repository to /etc/apt/sources.list manually.
Rsync for backing up data, not the OS.
Sudo is a typical Ubuntu-base prefix, on Debian and Devuan by default* you don't need sudo, just su and you have root permissions. Achieve the same on Ubuntu with
sudo su
Now skip the sudo prefix from the above commands.
*this depends on whether or not you've set a root password during installation. If you have, sudo is installed, but disabled for your user. (installed because other programs need it anyway). Technically, if you set a root pw, your regular user is not added to the /etc/sudoers file.
Dutch_Master wrote:Does it include a patch package to undo the horrible change in su behaviour introduced in the 3.0 release?
What change is that?
Is su, more messed up then before?
Have a quick read, including the replies I got.
https://dev1galaxy.org/viewtopic.php?pid=21042#p21042
Does it include a patch package to undo the horrible change in su behaviour introduced in the 3.0 release?
Hmmmm..... Right, let's not go that way then.
OK, so, what next? I've never seen a live Proxmox install so I have no idea how that works. But I did find that it uses qemu and lxc for the virtualization, so at least in theory one could write a script to implement the functionality, if not the web-gui. Btw, as Proxmox is OSS, one could rewrite all the systemd-specific parts for other init systems, but as a non-coder, that's not gonna be me! Personally, I'd like a choice of underlying file systems, like BTRFS, JFS and XFS instead of "just" ZFS but I can imagine this to seriously complicate porting functionality now offered by ZFS over specifically JFS and XFS (BTRFS has a similar feature set to ZFS)
Time to ponder off and do some experimenting, I guess. Just don't hold your breath for it, it'll be a while (if ever!)
Proxmox is build on Debian, so in theory at least, Devuan should be a suitable replacement. Anyone tried that yet?
Proxmox has a page outlining how to install it on an existing Debian install (click!) so it shouldn't be too difficult.
Is there any reason it wouldn't work?
TIA!
I'll just re-iterate myself then:
"Freedom of speech" doesn't mean you can say absolutely anything, anywhere, anytime. Your "freedom of speech" ends where it encroaches on freedoms of others. Disagreeing is fine, as long as it remains respectful and civil. These principles of civilisation have been trampled by certain groups and individuals in the past and exactly that is now being addressed.
Take particular note of that first sentence, then contemplate on the 2nd. That's the core of civilisation in a nutshell.
"Freedom of speech" doesn't mean you can say absolutely anything, anywhere, anytime. Your "freedom of speech" ends where it encroaches on freedoms of others. Disagreeing is fine, as long as it remains respectful and civil. These principles of civilisation have been trampled by certain groups and individuals in the past and exactly that is now being addressed.
As this subject has the potential to explode I'd prefer to keep it at that.
Ah, then there's a different issue. Issue this command:
id <user>
It gives you a list of groups your user is a member off. In that list the video group should appear. If not, you need to make your user a member of that group.
usermod -G dialout,cdrom,floppy,audio,video,plugdev,<user>
Replace <user> with the correct username. Make sure there are no spaces in the list!