Bug 1889674 - vi is the editor used when reporting anaconda bugs from text mode, instead of nano
Summary: vi is the editor used when reporting anaconda bugs from text mode, instead of...
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 33
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F33FinalFreezeException 1854444
TreeView+ depends on / blocked
Reported: 2020-10-20 11:10 UTC by Kamil Páral
Modified: 2020-10-21 22:22 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)

Description Kamil Páral 2020-10-20 11:10:55 UTC
Description of problem:
Nano should be the default editor in the whole Fedora 33:

However, when reporting an anaconda crash from the text mode, "vi" is started instead. Here's a reproducer:

I verified that nano is present on the image, and it's even set as $EDITOR:

> [anaconda root@fedora /]# echo $EDITOR
> /usr/bin/nano

It seems that anaconda (or libreport) invoke "vi" directly, instead of using the default editor. 

Version-Release number of selected component (if applicable):
anaconda 33.25.4-1.fc33

Comment 1 Kamil Páral 2020-10-20 11:11:45 UTC
Probably not a blocker, but proposing as a freeze exception.

Comment 2 Vladimír Slávik 2020-10-20 12:26:54 UTC
I think libreport should just work as-is? See: https://github.com/abrt/libreport/blob/84ed0489731418c8cadc51321f294ea68661d585/src/cli/cli-report.c#L305

That probably means the variable is not what you think when/where anaconda actually runs. FWIW normally (not on Live) we have a systemd unit that starts anaconda in tmux. No idea if you expect EDITOR to be set there? (I do not, but that's just a guess.)

Anyway, if that's it, the fix involves setting EDITOR here: https://github.com/rhinstaller/anaconda/blob/master/data/systemd/anaconda.service#L8 ...and in some other files in that directory probably too. Alternatively, there is one more opportunity here: https://github.com/rhinstaller/anaconda/blob/master/anaconda.py#L198 But I think that's not the right place for that, rather for a fallback if EDITOR is not set.

(Unfortunately everything is stuck on metacity right now, or I'd try that immediately.)

Comment 3 Vladimír Slávik 2020-10-20 12:27:49 UTC
Oops, sorry, assigning back to us, that was a mistake.

Comment 4 Chris Murphy 2020-10-20 14:32:44 UTC
Possibly similar to bug 1889576.

Anaconda runs as root. I'm not sure whether it runs literally under root user or via sudo; but it's likely that environment doesn't have nano set as the default editor and that's why. I agree it's probably not a feature blocker, but it's not good UX and should be considered a bug to be fixed. If anaconda runs with sudo then maybe it's possible for a drop-in file to sudoers, as I mention in 1889576.

Comment 5 Chris Murphy 2020-10-20 22:18:19 UTC
13:03:36  adamw | cmurf: on live images the launcher runs a smallish wrapper called liveinst which sets up some environment stuff then runs anaconda as root, iirc                                                                    
13:05:01  adamw | oh, right, liveinst is wrapped in consolehelper, that's how it gets to be root
13:05:24  adamw | of course this is all super old and hasn't been touched in forever

Comment 6 Adam Williamson 2020-10-20 23:19:01 UTC
Kamil was testing an installer image, though, so that's not relevant. On installer images there is no (interactive) user but root, I don't think, everything runs as root.

Comment 7 Kamil Páral 2020-10-21 07:56:57 UTC
# pgrep -a anaconda
1712 /usr/bin/python3 /sbin/anaconda

# cat /proc/1712/environ | tr '\0' '\n' | sort

No EDITOR, no VISUAL. Yes, the actual anaconda environment doesn't have nano configured.

Please note I'm talking here about the DVD environment here, not Live. I don't think it makes sense to run anaconda in text mode on Live (not even sure if that's possible, but even if it was).

Comment 8 Adam Williamson 2020-10-21 21:40:22 UTC
I think /etc/profile.d probably isn't read in the installer env. lorax runtime-postinstall.tmpl does this:

install ${configdir}/profile root/.profile

that file is I think lorax share/templates.d/99-generic/config_files/common/profile , which just has this:

PS1="[anaconda \u@\h \W]\\$ "
export PATH PS1

in an installed system, the chain by which profile.d stuff is used for a typical user shell is that ~/.bashrc sources /etc/bashrc , which sources everything in /etc/profile.d . But that profile used in the installer environment doesn't source /etc/bashrc , or source /etc/profile.d contents itself.

Comment 9 Adam Williamson 2020-10-21 21:41:33 UTC
+3 votes for FE in https://pagure.io/fedora-qa/blocker-review/issue/186 , accepting. This isn't that critical, but it *is* in the installer environment and can't be fixed with a post-release update.

Comment 10 Chris Murphy 2020-10-21 21:57:11 UTC
Sorry about my suboptimal reading comprehension :P

Maybe because it runs from within tmux?

man tmux:
     When tmux is started, it inspects the following environment variables:

     EDITOR    If the command specified in this variable contains the string ‘vi’ and VISUAL is unset, use vi-style key bindings.  Overridden by the mode-keys and
               status-keys options.

ps aux shows this which might be related...

/usr/bin/tmux -u -f /usr/share/anaconda/tmux.conf start

That conf file has a comment at the top:
# tmux.conf for the anaconda environment

And it isn't explicitly setting $EDITOR

Comment 11 Adam Williamson 2020-10-21 22:22:56 UTC
I think the explanation is just what I wrote in comment #8. We're not sourcing the thing nano-default-editor installs.

Note You need to log in before you can comment on or make changes to this bug.