The other posters have made sensible suggestions but to answer your question directly, ctrl+z was what you wanted; this suspends the process, then you can run bg to resume it in the background, or fg to resume as it was. Quite clunky, as redocbew puts it, and there’s “gory details”.
2 Likes
I’ve noticed something weird with wifi that isn’t a serious problem but just seems strange. My experience is mostly in Lubuntu, but I’d imagine it affects plenty of other distros. It seems that when you enter a wifi password, rather than the system saving and understanding it regardless of the wifi adapter, it requires saving settings for each adapter.
Furthermore, it isn’t just different chipsets. I have two pairs of adapters (Ralink and Realtek based) and if I use one, enter the password to connect, and change to any other wifi adapter, I must then reenter the password. If I do it with several adapters I end up with the same connections listed several times. I’d imagine very few people ever do this and it’s just a small quirk of the network manager that won’t be fixed anytime soon, but it just seems a little backwards.
You shouldn’t need to specify the target manually, you’re building on the system you want, itself. Without that, do you get a better error message? I don’t see any arch checks/restrictions in the spec file.
It’s possible you’ll need to run: yum groupinstall "Development Tools"
but I was hoping to avoid a big install of unnecessary stuff, but it might be the fix for you.
Staying with x86 will definitely make life easier. But Intel’s NUCs are a bit on the expensive side. Search Amazon for B08B3RY4GK. Runs on about 5W, fanless for $89. Compatible with RHEL8, just requires dropping-in one txt file to get WiFi identified and working. Performance will be about half what you’d expect from reading the specs. There are similar celeron mini systems for about $10 more if you need a faster, hotter CPU like ASIN: B0851W2D8R
Sorry for late reply, been out on a spontaneous trip to the alpes.
Leaving out --target armv7l leaves me with this errormsg:
I might try what @SgtAwesomesauce suggested, but I have never worked with docker before so I’d have to figure that out first, but might aswell learn while I’m on it.
NUC remains an option if I don’t get the Pi running. Thanks for the suggestions.
I updated to Fedora 32, everything seems to be working. I ran into issues where the activities panel would lock up, this prevented me from using my desktop without requiring a login-logout.
I later found out that the issue was caused by a out of date Dash to Panel gnome extension. I had neglected to update Dash to Panel for a really long time. When I tried updating the extension via the gnome shell extensions page, it threw an error and was unable to be installed or used. To fix this error, I restarted my computer and Dash to Panel seemed to be fixed.
I hadn’t upgraded to Fedora 32 since I wanted to wait I knew from past experience extensions will always be inevitably broken on new versions of Gnome and Fedora.
When I tried updating Dash to Panel on my laptop, it broke and I wasn’t able to use it. At that moment, I realized that I had nothing to lose if I had updated to the newest version of Fedora.
Oh the joys of upgrading Fedora.
1 Like
I didn’t notice the “-release” part in there before. You’re building the wrong SRPM! Not the source of the error, but a waste of your time.
What does the arch command say? Does that match some lines in /usr/lib/rpm/rpmrc and a folder in /usr/lib/rpm/platform/ ?
Seems like the problem is just something missing (for your arch) in rpm/rpmbuild. To confirm this, I suggest building something else from source tarball. e.g.
curl http://mirrors.ocf.berkeley.edu/gnu/ddrescue/ddrescue-1.16.tar.gz | tar xzv
cd ddrescue-1.16/
arch
./configure && make && ./ddrescue -VSorry my bad, I thought it would be a good test to recompile the release and see if it works.
When recompiling the zabbix-5.0.2-1.el7.src.rpm I want to change the arch in the .spec-file. Which attributes would I need to change? I found the following:
But also a lot of BuildArch: noarch. Would I need to change all x86_64 and noarch to armv7l?
Output of arch:
You don’t need to change anything. Source code always compiles to your current system arch.
1 Like
Working on my zshrc and trying to do some fancy tmux stuff.
Is there any way to detect I am in tmux after sudo -s? The $TMUX variable goes away. I’ve also tried exporting but nothing carries between the user session and the root session.
Hmmm. Let me see what I can dig up.
Found it!
sudo -s --preserve-env=TMUX
The --preserve-env var can be either passed with a csv list of environment variables to pass, or without. If it’s passed without, it’ll preserve all environment variables, which I’ve found tends to cause issues. So I’d just pass the ones you need.
For example: sudo -s --preserve-env=TMUX,SSH_AGENT_PID,LS_COLORS,LSCOLORS
1 Like
Thanks, it didn’t occur to me to just use sudo flags. Do you you alias that last line?
Because my root shell doesn’t have any config, so I pass some stuff to give it a bit of config.
I use root extremely seldomly and only if I absolutely need a shell.
1 Like
You don’t need to put that in the command-line. Look for env_keep in /etc/sudoers.
2 Likes
Nice, it works.
Me too, which is why I want it to be big and red, but only in tmux. I want to keep the bare shell stock in case oh-my-zsh or powerlevel10k breaks something. I am only loading them in tmux (and automatically starting tmux in zshrc.
alias sudo='sudo --preserve-env=TMUX'
Well, if your TERM=screen there’s a good chance you’re running under tmux…
Your shell’s PID is “$$”. Using ps you can check parent PID, and keep following the parent process until you find a “tmux” command, or do not.
1 Like
TERM TMUX is undefined after you call sudo -s. It doesn’t carry over.
This did occur to me. I think sgt’s solution is more lightweight though.
Next tmux question. Is it possible to capture an arbitrary exit code from tmux? If I exit 1 in tmux and them echo $?, I always get 0.
Are you mixing up TERM with TMUX?
TERM=screen definitely carries over through sudo -i and sudo -s. It would be major breakage if it didn’t… you can’t run vi or many other commands with TERM unset or set improperly.
2 Likes
Indeed I am, although not in the initial post. I think you used TERM first?
Oh I see, you’re saying use TERM instead of TMUX to determine if tmux is parent. Nvm. Yes, maybe. In my case, it’s screen-256color but sure, ^screen would work.
Yeah, this is the best solution.
printf '%s\n' 'Defaults env_keep += "TMUX"' | sudo tee /etc/sudoers.d/tmux
To transfer environment variables to sudo, can use ‘sudo -E’.
From man pages
-E’ The -E (preserve environment) option indicates to the
securityy policy that the user wishes to preserve their existing environment variables. The security policy may return an error if the -E option is specified and the user does not have permission to preserve the environment.