user@debian:~$ sudo for i in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do mount -B $i /mnt/$i; done
bash: syntax error near unexpected token `do'
user@debian:~$ sudo bash bash.sh
mount: /mnt//dev: mount point does not exist.
dmesg(1) may have more information after failed mount system call.
On 25/03/2025 19:47, J wrote:
Notice that the page suggests "# for i in /dev /dev/pts /proc "
so it is assumed that users should run
$ sudo -i
sudo *SH -c '...' -* as mentioned above. But it is not written in WIki.
In my opinion, "sudo -i" might be added to the wiki articles. I would prefer to see a warning concerning compound shell commands in *sudo* docs.
J, my impressions is that you read some docs strongly suggesting to prefix every command instead of just becoming root. It is reasonable recommendation in general case since sudo facilitates auditing and this practice encourages running most commands without elevated privileges. On the other hand system rescue using a live image is a special case. Logs are not saved by default. You need to run a bunch of commands requiring root privileges. It is more convenient to run "sudo -i" or "su -" once.
If somebody is going to add a hint concerning sudo to wiki, please, make https://wiki.debian.org/RescueLive
https://wiki.debian.org/GrubEFIReinstall https://wiki.debian.org/GrubEFIReinstallOnLUKS
articles consistent (perhaps by including a fragment of some page to others using wiki macros).
In my opinion, "sudo -i" might be added to the wiki articles. I would prefer to see a warning concerning compound shell commands in *sudo* docs.
J, my impressions is that you read some docs strongly suggesting to
prefix every command instead of just becoming root.
Actually it is easier than this. I couldn't use a *root *account on *Live CD*, at least I didn't know how, so I had to stick with *sudo*.
And i thought *sudo -i*, you speaking about, is something like *--interactive*, which is not, how i see now...
Will this command (
for i in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do
mount -B $i /mnt/$i; done)
work with* root?* I will try to test.
On Wed, Mar 26, 2025 at 02:15:03PM +0300, J wrote:
And i thought *sudo -i*, you speaking about, is something like *--interactive*, which is not, how i see now...
The long form is "--login", not interactive. But the "-i" stands
in for the interactive shell it gives you. Go figure :-)
[SNIP]
I normally use "sudo -s", which is the closest sudo approximation to
the traditional behvior of "su" (before it was broken in buster).
I normally use "sudo -s", which is the closest sudo approximation to
the traditional behvior of "su" (before it was broken in buster).
"sudo -i" is meant to approximate the behavior of "su -". Before buster, nobody would have used that on a Debian system. It's horrible. The
fact that people are now embracing it as a norm is even worse.
On 3/26/25 6:55 AM, Greg Wooledge wrote:
[SNIP]
I normally use "sudo -s", which is the closest sudo approximation to
the traditional behvior of "su" (before it was broken in buster).
I don't understand the reference to some "brokenness" of "su".
I've not closely followed this thread so I may be missing context.
I only use "su" when doing something in MATE terminal on my local machine. I do not use any command line options to "su". I just wait for it to ask for
my root password. I perform a few commands and then close that MATE
terminal.
Does this "brokenness" of "su" have any potential effect on my usage?
On 3/26/25 6:55 AM, Greg Wooledge wrote:
I normally use "sudo -s", which is the closest sudo approximation to
the traditional behvior of "su" (before it was broken in buster).
I don't understand the reference to some "brokenness" of "su".
I've not closely followed this thread so I may be missing context.
I only use "su" when doing something in MATE terminal on my local machine. I do not use any command line options to "su". I just wait for it to ask for
my root password. I perform a few commands and then close that MATE
terminal.
Does this "brokenness" of "su" have any potential effect on my usage?
work with* root?* I will try to test.
I fully expect it to, yes.
Oh, yes, it works. I just had to use *sudo su* and not not
On 2025-03-26, Greg Wooledge <greg@wooledge.org> wrote:
Does this "brokenness" of "su" have any potential effect on my usage?
Maybe. If you haven't created an /etc/default/su file, then something
like this:
If he hasn't noticed yet, I doubt it.
I noticed when I finally erased Stretch and installed Bookworm and tried
to run some command (whose name has escaped my memory) as root. The
command wasn't found because it wasn't in my PATH. At that moment I
recalled the "su -" 'workaround' thanks to you.
This caused ALL KINDS of problems. People would do things like:
$ su
# apt update
# apt install somepkg
And the postinstall script for somepkg would fail because it couldn't
find commands that are in /sbin or /usr/sbin, because those directories
which should have been in PATH, which *had* been in PATH for the last
20 years, were suddenly not there.
$ su -
# make install
Whoopsie!
My recommendation is to create a one-line configuration file:
On 2025-03-26, Richard Owlett <rowlett@access.net> wrote:
If he hasn't noticed yet, I doubt it.
I agree.
If I understand what people want to accomplish by using command-line
options, I would likely have gone to System->Log Out ... and then logged
in as root.
Not recommended.
On 2025-03-26, Richard Owlett <rowlett@access.net> wrote:
If he hasn't noticed yet, I doubt it.
I agree.
If I understand what people want to accomplish by using command-line options, I would likely have gone to System->Log Out ... and then logged in as root.
Not recommended.
$ su
# make install
Whoopsie! The Makefile just pwned you.
$ make DESTDIR=/tmp/i install
$ sudo cp -r /tmp/i/blabla /blabla
host!auser 09:57:47 /somewhere/that/is/obnoxiously/long/program-1.2.3$ /bin/su --login
Password:
bullseye on /dev/sda5 toto05
host 09:57:59 ~# cd /somewhere/that/is/obnoxiously/long/program-1.2.3
host 09:58:08 /somewhere/that/is/obnoxiously/long/program-1.2.3#
where that's a simple cut and paste.
David Wright <deblis@lionunicorn.co.uk> writes:
host!auser 09:57:47 /somewhere/that/is/obnoxiously/long/program-1.2.3$ /bin/su --login
Password:
bullseye on /dev/sda5 toto05
host 09:57:59 ~# cd /somewhere/that/is/obnoxiously/long/program-1.2.3
host 09:58:08 /somewhere/that/is/obnoxiously/long/program-1.2.3#
where that's a simple cut and paste.
Yes. I don't remember why but at some point in the distant past I got
into the habit of su - and expect to end up in root's home dir and
nowhere else.
Thinking back, it could be argued some crude consoles like Sun's or old school text terminals might not have copy-paste available. Maybe even
today it could be a thing, don't really know. If my old HP Microserver
gen8 is any indication, server people like to do extremely weird stuff
for remote management.
It could be argued that it would be simple enough to communicate
the user's cwd to root, as a workaround, so that it didn't have to
be retyped.
I'm certain sudo has its use cases, but all I do personally is su to
root and update and upgrade my stable Bookworm using apt, so I feel no
need to complexify the issue with sudo.
Excellent, that solves the problem for those on old terminals or
lacking copy/paste. As for me, I'll continue to use /bin/su --login,
as I have for nigh on three decades, so that I land in my preferred, >consistent cwd, /root.
Approximately a decade ago I
noticed that new entries were not added to some history file, I do not remember if it was .bash_history or for some other tool, but the owner of
the file was root. It was the reason why I decided to use some option to set $HOME.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 04:30:48 |
| Calls: | 10,386 |
| Calls today: | 1 |
| Files: | 14,058 |
| Messages: | 6,416,623 |